World: r3wp

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 :-)

Cross-compilation is now supported from the command-line: do/args 
%rsc.r "[-vvvv] [-f PE|ELF] %path/source.reds"

That's a really cool ability. It will turn some heads

I published a new version of the 0MQ binding:

http://rebol.esperconsultancy.nl/extensions/0MQ/ZeroMQ-binding.reds

This one is adapted for the latest Red. Since the basic runtime is 
now included by Red, it is removed from the binding

The send/receive functions have been changed from string to binary, 
so they can handle generic data

If you want to send data to Red from R3 or R2 using the Hello World 
example, you need to add a zero byte to the data, though, C style, 
because the example still expects string data

The test executables should now run on Windows, instead of just WINE:

http://rebol.esperconsultancy.nl/extensions/0MQ/server.exe

http://rebol.esperconsultancy.nl/extensions/0MQ/client.exe

works fine under windows xp !

Cool, thanks for reporting

Works here under XP x64! Wow. Just...wow.

X64. :-) It's 32 bits, but good to know there are no compatibility 
problems

The current ELF backend format doesn't satisfy Syllable's loader 
yet (Syllable Desktop has its own in-kernel ELF loader)

When I compile the tests on Linux and try to run them on Syllable, 
I get this in the kernel log:

0:bash::bash : Error: load_image() Invalid section size 0, expected 
40

0:bash::bash : ERROR : execve(./empty) failed. Too late to recover, 
will exit

Do you have a readelf command-line utiliy on Syllable?

Yep, the standard GNU BinUtils one

Can you paste me here the result of : readelf -l empty

(just the program header entries)

I don't think it would be any different than on Linux, but I will

Should be 2 lines starting with LOAD.

OK

Also, do you know if Syllable requires a "section headers" part in 
executable binaries? (it's optional in ELF specifications)

[[kaj-:-syllable]:~/Red]readelf -l empty

                                                                                                                                                                                                        
Elf file type is EXEC (Executable file)
Entry point 0x8048074
There are 2 program headers, starting at offset 52

                                                                                                                                                                                                        
Program Headers:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg 
  Align

  LOAD           0x000000 0x08048000 0x08048000 0x00184 0x00184 R E 
  0x1000

  LOAD           0x000184 0x08048184 0x08048184 0x00032 0x00032 RW 
   0x1000
[[kaj-:-syllable]:~/Red]

Indeed, exactly the same as on Linux, as it's the same executable, 
and the same readelf

I have to mention that Syllable does something odd by compiling all 
its own programs as shared libraries, so it could also be a problem 
in our loader that wasn't hit before

Seems good, sizes are specified, 0x32 (40) for the 2nd segment. Don't 
know what could cause the issue for the image loader, maybe the lack 
of section headers?

oops, 0x32 = 50