World: r3wp

XScale is based on ARMv5, so it should work, you just need to figure 
out how to download an executable from the NSLU2 and run it.

I've tested all example programs in all my bindings and they still 
work with the new release

I've also compiled them for Android. I can't test them, but they 
do all compile

Good! I'll try to test them on my QEMU instance (at least the non-graphic 
ones).

Don't you have X11 installed there?

I have an X11 (with Gtk I think) image for QEMU but it's dead slow, 
so I never use it.

I will give it a new try to see if I can get Gtk binding working.

I've tested the cURL binding on Debian armel, works fine (used the 
example script and my own wget script).

For GTK, it stops on a symbol issue with atexit():

[root-:-debian-armel]:~/ARM# ./GTK-widgets 

./GTK-widgets: symbol lookup error: ./GTK-widgets: undefined symbol: 
atexit

The `atexit` symbol is present in both the dynamic symbol and relocation 
tables of the ELF binary.

It's in the ANSI standard for the C library, but it may not be in 
the Bionic C library for Android

I'm testing on Debian 6 in QEMU.

I've checked the dependencies via ldd, all are met.

Maybe Andreas would have a clue about this.

I've already had to leave it out of the C library binding for Syllable. 
That's also odd, though, because it uses the GNU C library, like 
Debian, and Syllable is supposed to have atexit

It's also strange that the cURL binding would work, because it imports 
the same C library binding

If I remove the atexit() dependency, I get segfaults on first calls 
to external functions (on printing the GTK version).

So the issue is not specific to atexit().

I guess that it might be causing by a bad version of one or several 
shared lib from GTK.

causing => caused

I've upgraded GTK to 2.20.1, but still getting segfaults.

I will investigate that deeper in the next days.

atexit is often not present in libc's (it is neither in the x86-64 
libc or in the ARM EABI libc).

Some weird stuff with shared library unloading and what not. Don't 
ask me, really :)

They use __cxa_atexit on those platforms, typically.

GCC either rewrites atexit directly or redirects atexit calls to 
__cxa_atexit via libcc, I don't exactly remember.

(That should have been: "via a stub in libgcc".)

CASE native implemented in Red/System (same syntax as REBOL's one).

Doc and tests will be added tomorrow.

Nice!

Missing double-quote in:

http://static.red-lang.org/red-system-specs.html

either a > 0 [print "TRUE"][print "FALSE]

Henrik: thanks, I'll fix that today with the addition of CASE description.

as for CASE - I could not fin it in the Docs, in the section talking 
about eventually planned features. I could find there only SWITCH 
directive :-) Maybe that section could be revisioned, to let us know, 
what is eventually planne, and what is not ....

I forgot to add an entry for CASE in the "Planned features" of the 
spec document. CASE and SWITCH were announced in slide 36 of my presentation 
at SFD: http://www.red-lang.org/2011/09/red-at-software-freedom-day-2011.html

Other native functions were also announce, but their priority is 
lower. I should update the "Planned feature" section of the spec 
document.

I plan to also add SWITCH today or tomorrow.

are those required to have function refinements in red/system?

No, they are not related to refinements support. They just enable 
to write cleaner code and more readable code.

for SWITCH I can see the need (computing labels in array to support 
indirect threading ) a speed issue.

But why do you need to implement CASE in red/system, it's only a 
sequence of if/else statements ?

(answered just above :-))

CASE helps "flatten" the nested IF or EITHER constructions.

except than the if-else statement (the c one) is usually mis-used.
It doesn't need to be nested to work.
if .... else if .... else if .... else if .... else

FLAAAAT :-)

In REBOL we tend to use CASE instead of EITHER because CASE is faster 
when there are more than 2 tests. Flat is just a side benefit. Of 
course, an optimizing compiler could change the resulting code from 
one to another when it's appropriate, just like most modern C/C++ 
compilers do.

I hope you have a CASE/all option. We used the CASE/all style in 
the R3 module system code to great benefit, mostly in maintainability 
but also in speed, when compared to the nested IF and EITHER code 
it replaced. It enabled us to add features and simplify code at the 
same time.

I wasn"t against CASE implementation in Red.

I was asking if it was the right place to have it in Red/system as 
a core function instead of as a latter compiled mezz.

but maybe a mixed the things between Red/system and the other layers

To be clear about that. Doc can you confirm that the mezz constructed 
with Red will be also compiled ?

IF, UNLESS, EITHER, CASE and SWITCH all make sense to compile in 
a compiled language because they all translate to branches and/or 
index lookups in the generated code, and optimizing that would need 
some decent compiler support. If anything, CASE is the most general 
(the others can all be implemented with CASE), and would benefit 
the most from optimization.

what is make-float-auto-test.r? Do we have floats supported or so? 
:-)