World: r3wp

The code uses the new preprocessor. It's starting to look quite nice, 
and I've split off the examples into separate files, to the binding 
is now a proper separate library/#include file

Source code looks good. I need to add a "contributions" section in 
red-lang.org to reference your 0MQ page.

Thanks. It's very nice how you keep solving the crooked parts in 
it :-)

Your first implementation was very helpful for improving Red/System, 
especially the preprocessor part.

Communicating in code :-)

Almost all of the mezzanine changes to R2 starting with 2.7.6 are 
MIT licensed as part of R2/Forward. The R2 SDK source includes an 
attribution clause in the headers. Anything else in REBOL written 
by me can be contributed under the same license.

I am now able to compile RED program that throws "Illegal instruction" 
under OSX which is good thing as it means that the compiler now produces 
at least valid Mach-O header :)

You're implementing Mach-O?

I'm just trying to ;)

Cool!

Rebolek: great news! :-)

I'm glad someone picked up the task of implementing Mach-O output 
format.

Rebolek: maybe OS X requires position-independent code for executables? 
Checking it right now...

I should have basics required for functioning executable soon. If 
it still throws "illegal instruction" then, well...

Doc no it doesn't, I just still haven't got all the sections done.

but I'm close.

Good, it will make the porting easier.

A link for Andreas: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/dynamic_code.html


I was thinking about using some similar trick for ELF to allow efficient 
PIC support (avoiding the indirection table). It works by having 
a fixed offset between CODE and DATA segments in memory, so DATA's 
start address can be calculated at runtime, and all globals can be 
accessed using a simple offset.


It should be enough to reserve enough space for CODE segment (let's 
say 10MB) and make DATA entry point fixed? I wonder if the relative 
offsets between segments are preserved when the segments are moved 
by OSes (I hope so)?

10 MB should be enough for everyone ;-)

Heck, 640K should be enough for anyone. ;-)

And...REALLY cool Bolek.

I first wrote 1MB, then I raised it thinking of possible libs that 
could get statically linked by users. But, it could be even easier, 
just hardcoding the DATA address offset somewhere in the CODE segment 
at linking time might be enough (no need to reserve fixed space in 
CODE segment).

Another milestone reached ;) Now I get "segmentation fault" instead 
of "illegal instruction" :)

Have you defined a new runtime in red-system/runtime/ for OS X?

Right now I just copied the Linux one.

Does OS X support the same syscalls?

Yes. It's not recommended, but I think that for basic test it's enough.

http://www.opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master

are there specific CPU limitations? could this be done for, say, 
a 6502?

It requires 32-bit integer support for source compatibility with 
other platforms, but if you don't care about compatibility, it should 
be possible to make a 6502 emitter ;-)

ok

6502 is a bit far reach with its 8/16 bits architecture, but 68k 
should be doable while preserving all Red/System's features.

that would also be quite interesting.

I'd been phantasising about that, and about porting my 6502 emulator 
:-)

porting 6502 emulator to 6502? :-)

If I would port the emulator and someone would do a 6502 backend, 
then yes :-)

doc, do you planing later external bindings features like SWIG / 
FFI  /ALIEN  etc ?
or would it be possible to access C/C++ libs directly with RED?

Red/System is a C level language, so you can just call C functions

Calling C++ requires a C wrapper for the C++ interface, as always 
with C++

Binding systems such as SWIG are way too heavy for Red, and C functions 
are neither foreign nor alien to Red/System, so FFI and ALIEN would 
be too heavy as well :-)

The only thing you have to do to call a C function is to translate 
the defintion of it in the C header to Red/System. It would be possible 
to write a C header parser to automate that process, one of the things 
that SWIG does. However, it would lead to ugly Red function definitions 
that don't make the most of the interface

Agreed with Kaj.
 

AFAIK, it might be possible to interface with C++ at very low-level, 
to be able to instanciate C++ objects and call their methods from 
Red. Same solution for obj-c interfacing, which will be required 
at some point to port Red to iOS.

thx, for info

That's in any case possible very naturally for Objective C. Io for 
example has a transparent Objective C bridge that allows accessing 
any Objective C object

For C++, you'd need RTTI to go in the direction of that level of 
transparency

Ruby has also a bridge to obj-c (I guess Python too).

The Io one is likely simplest, and BSD licensed, so you might be 
able to use some code from it

changing currently my serverbackends from rebol to luajit/FFI. what 
a relief and cool experience to just drop some c header inline and 

access the appropiate lib in seconds. the mapping is nice also.  
thought that this feature is quite important for Red.

Nice! We will see if we can come up with something even simpler with 
Red.

with the last beta you can detect also a real firework of new and 
planned very usefull bindings there.

a feature like this defines a real 'multipropose language' as I stated 
many times before.