World: r3wp

derivated  - no such englsh word :)

New compilation targets have been provided for Linux and derivated 
OS running on ARM:

change to 


New compilation targets have been provided for Linux and derivative 
OSs running on ARM:

Hmm, another "frenglish" of mine. :-)

ahh... your own dialect !

BTW, can acronyms in english take an ending "s"? Is that allowed?

okay,make it OSS :)

hehe :)

http://www.english-test.net/forum/ftopic25371.html


And then in Microsoft Manual of Style (version 3.0) we can read "To 
form the plural of an acronym, use a lowercase "s" without an apostrophe." 
Example: several IFSs.

In British English, an apostrophe is more common, so both are correct

Congratulations on the ARM port. It's an important milestone

Thanks Kaj, I hope to be able to demo some running Android app in 
Red/System (or Red) in march at the RedTopaz conf.

the only arm device I know I have is the http://en.wikipedia.org/wiki/NSLU2
 uses an ARM-compatible Intel XScale IXP420 CPU.

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.