World: r3wp

I try to make sure that Red/System code can work the same on all 
platfoms (at least for 32/64-bit ones).

First MacOS X support version released: https://github.com/dockimbel/Red/commit/8b34c8684e273dd31b6778fc654f5e5548db6f37

There are still several things to fix in the runtime.

And I need to change the OS default selection code in the compiler, 
so that the `-t Darwin` option won't be required when running on 
OS X. That fix will also enable the unit tests to work properly.

Just reading %rsc.r, it seems Andreas already added such feature...there's 
probably a bug in compiler.r preventing it from working properly...

Ok, issue fixed, the `-t` option is no more required on MacOS X for 
native compilation.

Wonderful !!!

The unit tests run in approximately two-thirds of the time under 
OS X than they do under Windows/XP running under VirtualBox.

VirtualBox can make systems very slow

Kaj: what is the status of the issue #129 that you have opened? Does 
it still crash?

It's all in there. It doesn't crash with the added solution - which 
should become native

New editor in REBOL for Red/System : edit | compile | run for Windows, 
Linux, MacOSX !
http://www.red-chronicle.com/2011/07/new-red-editor-in-rebol.html

Make a docs directory in the rebol installation folder and type in 
REBOL console :
do http://perso.numericable.fr/frajouen/Red/editor.r

Very nice :-)

Very nice indeed. In GET-KEY, should 'cc be local?

About calling functions in shared libraries and calling conventions, 
there seem to be differences between CPUs and compilers across operating 
systems. There's a lib, called libffi, to help with this, and it 
has bee widely ported.
http://en.wikipedia.org/wiki/Libffi


Why isn't a lib like libffi used in Red? Is it because of overhead, 
making it slower? Or maybe using such a lib makes little sense the 
way Red is implemented?


When looking at the host-kit for R3, I see functions to open, close 
and find functions in DLLs, but I don't see the calling of those 
functions. Shouldn't that be part of the host kit?

I don't see the calling of those functions
 - the C compiler handles that.

As I understand it, it's about fetching and calling functions at 
runtime, not compile time, so is that really the case?

Red/System relies on shared libraries dynamic linking at load time. 
CPU and ABI specific calling conventions are handled by respectively 
Red's target emitters and file emitters. I don't see how libffi could 
make it simpler or better. From what I understand from FFI (very 
short) descriptions, it is more suitable for high-level languages 
that can't or don't want to deal with low-level interfaces.

Ok, it's probably because I don't understand Red completely. At "load 
time", is that when the system starts up? (Maybe comparable to compile 
time.)


FFI is, as I understand it, a way for high-level languages like Python, 
Ruby, Rebol, etc., to load a library at runtime and call its functions. 
Like we do in R2 with load/library and then some make routine! and 
finally call the functions.

(Actually FFI just handle the calling conventions, you have to load 
the libraries yourself with e.g. dlopen, dlsym, dlclose (POSIX) or 
LoadLibrary, GetProcAddress, FreeLibrary (Win32).)

Load time = Red executable load time. The OS does the job of binding 
the required shared library and making their functions available 
to Red/System programs.

So, when Red is running, you don't have functions to load another 
library and use its functions?

Not for now. In most use cases, binding at load time is enough.

ok, I think, I get it now. Thanks!

Do Red handles block data-type so far ?

Red/System does not have a block datatype.

Will it  ?

I'm pretty sure that Red will have a block datatype, not so sure 
about Red/System

I guess there will be a way to access Red blocks from Red/System. 
Until then, you can implement your own

I'm about to for cURL, to receive an unknown quantity of data into 
memory

Red/System will not have high-level datatypes, but will be able to 
use the low-level methods of Red's datatypes if required (mainly 
for supporting Red). Anyway, Red/System is not meant to use those 
"boxed" datatypes, only low-level and close to the CPU types.

Geomol, this is an example in C:

    #include <stdlib.h>
    #include <stdio.h>
    #include <dlfcn.h>

    int main(int argc, char **argv) {
        void *handle;
        double (*cosine)(double);
        char *error;

        handle = dlopen ("/lib/libm.so.6", RTLD_LAZY);
        if (!handle) {
            fputs (dlerror(), stderr);
            exit(1);
        }

        cosine = dlsym(handle, "cos");
        if ((error = dlerror()) != NULL)  {
            fputs(error, stderr);
            exit(1);
        }

        printf ("%f\n", (*cosine)(2.0));
        dlclose(handle);
    }

who generates the appropriate assembly code for the     (*cosine)(2.0) 
   call? The C compiler.

Yes, but we're talking doing that in a high-level interpreted language, 
like Python, Ruby, Rebol, etc.

In a situation, where you don't know the function at compile time.

R3 does not have such ability, so I'm confused by your "When looking 
at the host-kit for R3, I see functions to open, close and find functions 
in DLLs, but I don't see the calling of those functions."

Ok, I thought, R3 had that ability and used those open/close functions 
to do it.

The code is in R2, but out of reach.

R3 uses dlopen/dlsym/dlclose to load R3 extensions, which have a 
clearly defined exposed API (RX_Init, RX_Call).

Mac OS X now fully supported: http://www.red-lang.org/2011/07/mac-os-x-port-released.html

Nice, but the original "hello" demo was with red color:)

Well, if someone could bring color (using ANSI codes?) to the Mac 
and Linux version, that would be nice! :-)

Ok, I have added the red color to Mac and Linux platforms...updating 
the screenshots now ;-)

Looks much better now. :-)

I don't have Linux nor Mac at this moment... are you using just string 
like "^[[31mRED^[[0m" ?

Yes, have a look at the hello.reds source code: https://github.com/dockimbel/Red/blob/master/red-system/tests/hello.reds

You're too good for us :-)

I like colors... I'm looking forward to see colorized console one 
day:)

Implemented support for argc, argv and env for UNIX platforms, will 
publish it tomorrow when Windows support will be ready too.