World: r3wp

however, it is a bit difficult to use, and also - allowing non-market 
sources could be marked as dangerous. Will there be ability to produce 
native Android apps, which could be published via the market?

Henrik - what do you mean by ppl being "over it" - somehow can't 
translate it myself :-)

Pekr, I'm not sure if it's important anyway, but it might detract 
from the reputation of Red, if some parts are not factually accurate 
in the article. As in: "this guy doesn't know what he's talking about."

Anyway - not sure if such a news article for OSNews is not a bit 
preliminary ... no bindings yet, no possibility to use standard channes 
(market), no RED yet = not much of a REBOL featureset either. Achievement 
is great - RED gets us onto mobile OSes, still far superior to R2 
or R3, except that Red/System is mostly a C with REBOL syntax. I 
can understand, why Doc wants to work on RED itself some bits too 
:-)


Anyway - I am here to do some testing with HTC Sensation. The fun 
part comes, when the bridge is going to be done. Imagine having parse 
and REBOL like series handling, with access to stuff like SMS, calendar, 
address-book, and other APIs :-)

Henrik: agreed, it's confusion, will change it right now. Thanks!

confusion => confusing

better :-)

Produce native Android apps: certainly, but that requires the Java 
bridge. It should be possible to also use the NDK for accessing a 
subset of Android API, but I haven't investigated yet that option 
much, especially if it requires Dalvik code support or not.

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!