World: r3wp

I thought about adding a full macros system, I think it will be useful 
until we can compose Red/System code from Red itself.

Right, I ran into the preprocessor zeal before, and replaced some 
other values with variables

Once that definition fixed in %ZeroMQ-binding.reds, I can compile 
working versions of client & server...testing...seems to work ok, 
the server is receiving a list of Hello messages from the client. 
:-)

Congrats!

Thanks :-)

Is the preprocessor necessary at all? It's usually much nicer to 
implement this functionality at a more integrated level in a language

I'm thinking about descending it one level below to process the script 
at block! level instead of string! level, after all, the compiler 
has the full power of REBOL.

Yes

That should avoid the nasty side-effects.

With the Linux backend, did the system loose its ability to cross-compile 
to Windows?

Nope, I just need to adjust the compiler front-end (rsc.r) to pass 
an option for the desired format (PE, ELF, ...).

Currently, a default format is applied depending on the REBOL binary 
used.

You can compose Red/System from REBOL in lieu of a preprocessor, 
until the compiler is ported to Red.

I mean in lieu of preprocessor macros

Do you mean replacing .reds scripts by .r scripts?

Kaj: if you want to cross-compile, you currently need to hardcode 
the target format in %compiler.r at:

    fmt: select [			;TBD: allow cross-compilation!
        3	'PE			;-- Windows
        4	'ELF			;-- Linux
        5	'Mach-o		;-- Mac OS X
    ] system/version/4

No, I mean that when you say that your long-term strategy is to compose 
Red/System code in Red, thus making preprocessor macros unnecessary 
in Red/System, you could start that strategy much earlier by composing 
the code in REBOL. What you learn from doing so and the code you 
write can be adapted to Red later once that exists.

Doc, would you mind if I started some research on generating Dalvik 
binaries? I notice it's not on your list of planned platforms.

Sure, no problem.

I plan to support ARM directly.

Thanks, Doc, I just found it. I wanted to take the scenic route :-)

It's amazing how much more approachable this system is compated to 
everything else out there - save for the very early teaching examples 
in computer science history

compared

I wanted to get back to the roots (80's for me) of computing, a time 
where an entire OS + programming langage could fit in a 16KB ROM 
;-).

Brilliant

That was the ZX Spectrum ROM to be specific.

I'd allow for 20KB, though. Atari was 8K OS + 8K BASIC + 4K decimal 
floating point :-)

Or was it 2K math? I'm really getting old. Anyway, it beats the pants 
off that Intel stuff

I think that up to 64K, it's acceptable. :-)

The Commodore Max beats that.

http://scacom.bplaced.net/Collection/max/BASIC1.gif

Supporting ARM directly only gets you so far on Android. Native Activities 
were only introduced in 2.3, so the vast majority of Android devices 
don't support them. This means that unless you have some way to generate 
Dalvik code, applications witll still need some Java in them in order 
to run.

Eh, you can do a lot in 510 bytes!

Like a modern boot record...

That reminds me of the Syllable demo I did where I installed the 
system in a Gentoo swap partition in order not to disturb the demo 
machine :-)

Brian: I was planning to bridge with the Java API using JNI. Having 
a generic Java app to embed the Red native app (would be contained 
in a DLL in such case).

Though I've long maintained that Syllable is bloated, under weird 
looks of my colleagues, so we'll do some collapsing with Red :-)

Similar to what you were proposing for R3 on Android.

Swap: nice trick! :)

sorry for not being able to do something more creative, other than 
say - this all looks awesome so far! Red progress, red on linux, 
red + 0mq!!

BrianH: red for dalvik, I think that is really a good idea! there 
is and will be a whole bunch of android devices out there, so this 
would be great.

Janko: it's still an early phase of the project, but it's progressing 
well.

I know it's early, I am surprised by how fast and wide it's moving 
at so early stage.

Like greased lightning :-)

Although I'm running into a bit of a wall when I try to import functions 
under cdecl. I'm getting undefined symbols (path values into the 
emitter symbol table) all over the place

Kaj: you should wait that I add all the type & specs checking to 
the compiler and some unit tests (this week). It will make the compiler 
more usable.

Kaj: I've fixed the cdecl bug (I guess it's the one you've hit), 
will push the sources in a few minutes.

Revision pushed.

Thanks. I don't even know if I need it, but you mentioned it for 
C libraries

I don't mind the current limitations much if I know they will be 
fixed. I like to push the boundaries :-)