World: r3wp

yes

I need to factorize the code first, there's some redundancies, but 
it's also untested code. So, once it will work ok, I'll clean it 
up.

Go Go Gadget

:-)

Btw, you've opened an issue ticket too...good opportunity for me 
to test github's tickets management options.

Hm... I did nothing though.

It seems a ticket is opened for each pull request...

I guess it's automated.

I just click ramdomly like a foul

lol

But how can I resync my fork, I wonder...
I don't see your modification

I guess you need to pull changes from my repo (dockimbel/Red)

This is my commit: https://github.com/dockimbel/Red/commit/e9c6e78cf77ed388b688681d463a9960952f5a79

got it
it's in the 'fork queue'

But I can't apply my previous commits, they failed.
I just applied your commit and now it's ok.
So it's ok.

Are you using a Git client or just github's web UI?

Both of them.
TortoiseGit on my PC

I made a clone of my fork on my PC

I only forgot, that I must commit the both

steeve, locally do a "git pull --rebase" from doc's repo

(that's the effect of one shortcoming of github's fork queue)

Good to know!

Thanks to Andreas' help, we now have a first experimental support 
for Linux/ELF for Red/System. It's still very limited (basically 
just being able to call a system function with an argument), but 
it's a good start. It should be extended in the next days to support 
compilation of the hello.reds demo script.

Nice. So you will not postpone it?

Nope, seems that a ELF support large enough to run the demo script 
could be doable tomorrow or in the next days.

Btw, Red/System is now able to do syscalls directly, bypassing the 
libc dependency.

We'll see if this can hold long enough to avoid calling the libc 
at all.

Will that be optional? The libc interface is actually much more portable 
than kernel interfaces

yes

libc support will come as soon as we get support for a loader done

but syscall support is nice (and lean) on it's own :)

It is

So can't Red load dynamic libraries yet?

not on linux/elf, no

Ah

Kaj: I had a quick look at *BSD syscalls, there are pretty much the 
same as Linux (at least for the most used ones). The calling convention 
is different thought, but can be supported by one or two more lines 
of code in Red/System emitter.

When I see how Carl fights with various libc versions...I wonder 
if syscalls are not an easier path even if it can have some minor 
porting costs here and there? Anyway, a libc mapping will be possible 
soon, so all options are open.

I'm not sure the current R3 versions for different GLibC versions 
make any difference. It's R2 that has problems, but usually with 
the higher level X libraries

The syscall calling convention on Syllable is also different. It 
doesn't use SYSENTER/SYSEXIT yet

Red/System uses currently software interrupts for making syscalls, 
I'll add support for SYSENTER/SYSEXIT in the next days.

When I look at R2/Core downloads list, it stills has to ship in two 
flavors for Linux, isn't it because of libc issues?

Yes, but R3 is much better isolated

Anyway, we'll make sure Red runs ok on Syllable, that's the least 
I could do. ;-)

OK :-)

The issue R2 currently has with old Linux systems is with floating 
point. That's in the math library, part of GLibC, not the kernel, 
so there's no way around it unless you use a completely different 
implementation

I'm not denying the libc interface is problematic on GNU systems, 
I'm just saying there's probably no alternative with fewer problems 
:-(

The best strategy is to keep the interface as small as possible, 
like R3

That's more of a Red problem though. Red/System doesn't have floating 
point, just integers.

But it's always good to look to the future :)

Decimal Floating-Point Math Library: http://software.intel.com/en-us/blogs/2008/03/06/intel-decimal-floating-point-math-library/
That's interesting!