r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Red] Red language group

Jerry
10-Jul-2011
[2738]
happy to know that Mac version is in progress.
Dockimbel
10-Jul-2011
[2739]
Actually, the link I gave to Apple's docs does not cover syscalls...I 
couldn't find any official Apple doc about that. MacOS X seems to 
conform to BSD syscalls calling convention.
Geomol
10-Jul-2011
[2740]
I use #pragma pack(4) to control alignment. Read about it here:


http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/64bitPorting/MakingCode64-BitClean/MakingCode64-BitClean.html
Andreas
10-Jul-2011
[2741]
GCC 4.5+ uses/requires 16 byte stack alignment per default.
Dockimbel
10-Jul-2011
[2742]
Hello.reds running on MacOS X: http://static.red-lang.org/MacOSX-hello.png
Andreas
10-Jul-2011
[2743]
cool :)
Henrik
10-Jul-2011
[2744]
Doc, another stupid question: Are there going to be certain platform 
specific parts of code in a Red/System program?
Dockimbel
10-Jul-2011
[2745x8]
Only OS bindings.
But those defined in current Red/System runtime have an abstraction 
layer, so the runtime API is the same for users on all platforms.
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.
PeterWood
11-Jul-2011
[2753x2]
Wonderful !!!
The unit tests run in approximately two-thirds of the time under 
OS X than they do under Windows/XP running under VirtualBox.
Kaj
11-Jul-2011
[2755]
VirtualBox can make systems very slow
Dockimbel
13-Jul-2011
[2756]
Kaj: what is the status of the issue #129 that you have opened? Does 
it still crash?
Kaj
13-Jul-2011
[2757]
It's all in there. It doesn't crash with the added solution - which 
should become native
nve
13-Jul-2011
[2758x2]
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
Kaj
13-Jul-2011
[2760]
Very nice :-)
Gregg
14-Jul-2011
[2761]
Very nice indeed. In GET-KEY, should 'cc be local?
Geomol
15-Jul-2011
[2762]
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?
Gabriele
15-Jul-2011
[2763]
I don't see the calling of those functions
 - the C compiler handles that.
Geomol
15-Jul-2011
[2764]
As I understand it, it's about fetching and calling functions at 
runtime, not compile time, so is that really the case?
Dockimbel
15-Jul-2011
[2765]
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.
Geomol
15-Jul-2011
[2766x2]
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).)
Dockimbel
15-Jul-2011
[2768]
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.
Geomol
15-Jul-2011
[2769]
So, when Red is running, you don't have functions to load another 
library and use its functions?
Dockimbel
15-Jul-2011
[2770]
Not for now. In most use cases, binding at load time is enough.
Geomol
15-Jul-2011
[2771]
ok, I think, I get it now. Thanks!
Steeve
15-Jul-2011
[2772]
Do Red handles block data-type so far ?
PeterWood
15-Jul-2011
[2773]
Red/System does not have a block datatype.
Steeve
15-Jul-2011
[2774]
Will it  ?
PeterWood
15-Jul-2011
[2775]
I'm pretty sure that Red will have a block datatype, not so sure 
about Red/System
Kaj
15-Jul-2011
[2776x2]
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
Dockimbel
15-Jul-2011
[2778]
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.
Gabriele
16-Jul-2011
[2779x2]
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.
Geomol
16-Jul-2011
[2781x2]
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.
Gabriele
16-Jul-2011
[2783]
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."
Geomol
16-Jul-2011
[2784x2]
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.
Andreas
16-Jul-2011
[2786]
R3 uses dlopen/dlsym/dlclose to load R3 extensions, which have a 
clearly defined exposed API (RX_Init, RX_Call).
Dockimbel
17-Jul-2011
[2787]
Mac OS X now fully supported: http://www.red-lang.org/2011/07/mac-os-x-port-released.html