World: r3wp

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.

Cool, thanks!

That enables another large class of programs

great! now it's getting more useful.

Command line arguments access now available: http://groups.google.com/group/red-lang/browse_thread/thread/4b8cb7a5a49308ba?hl=en

Tested ok on all OS (including Syllable).

Great, I was just looking over it, and couldn't see anything wrong 
yet

In my first release, I wrongly read ESP data instead of [ESP] for 
Syllable.

Ah, the detail devil :-)

I once offered a little glowing "code protecting" angel statue to 
one of my developers. It was supposed to keep devil out of your code 
if you kept it close to your screen. Can't find it online anymore, 
maybe that would help...:-)

:-)

New Red/System document is available: BNF language grammar description 
(by Rudolf W. Meijer)
http://static.red-lang.org/A_BNF_grammar_of_Red_System.pdf

Very cool Doc (and Rudolf).

I've cleaned up my cURL binding enough to put it in a repository: