World: r3wp

As for ARM CPU support, I will have to rescan this group, about what's 
supported. We have one dev board with Cortex-M3

In order for Red to appear on the Tiobe Index, one requirement is 
to have an entry on (english) Wikipedia, clearly describing it as 
a programming language, as explained here: http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm


I have contacted Tiobe and they are ok for including Red when this 
requirement will be fulfilled. If someone here is willing to do it, 
that would really help boost Red's visibility. That is typicaly something 
that I cannot do myself, it would go against Wikipedia's rules.

Cortex-M3: Andreas mentioned that it requires the Thumb2 instruction 
set, so, it won't work with the current Red ARM backend.

If there's is a corresponding instruction in Thumb2 for each one 
we currently use in the ARM backend, a new port could be quickly 
made (but don't expect me working on this one in the next months, 
it's too low priority).

that's ok ....

We support ARMv5+ at the moment. So that means ARM9E, ARM10E, XScale, 
ARM11, Cortex-A based cores should work fine. Most notably, Cortex-M 
won't (as those cores only support the Thumb instruction set). Neither 
will StrongARM (which is ARMv4).

thanks ...

I have a rather nice Cortex-M3 based board lying around as well. 
So maybe I'll get around to tackle the Thumb profile some day :)

Doc - what layer will be e.g. events implemented in? Red/System, 
or Red? I mean - will you use your own implementation, or will you 
adopt some libraries for concurrency, events, e.g. libevent, liboop, 
etc.?

We'll start simple, so implement our own internal event loop which 
will have a Red/System backend and a frontend at Red level, probably 
following the R3 port model.

I don't see the necessity for an external lib for concurrency or 
events management, when the OS are already providing everything we 
need (I guess that pthread lib is standard part of Linux now?).

Float support so far:

---
Red/System [ ]

#import [
	LIBC-file cdecl [
		cos: "cos" [
			x 		[float!]
			return: [float!]
		]
	]
]

pi: 3.14159265358979
printf ["%.14f" cos pi]
---

outputs: -1.00000000000000

The only drawback for now is that 64-bit values break the typed/variadic 
stack layout (meant for 32-bit values only). I need to find a workaround 
for that.

So, currently PRINT and PRINT-WIDE can't be used with floats.

(I haven't pushed the float branch yet, I still need to improve this 
first version)

PThreads are the native Linux threads implementation for a number 
of years

Pushed first version of float preliminary support in `float-partial` 
branch, please read the commit logs for more info: 


https://github.com/dockimbel/Red/commit/bea1aa7fc4b6f7b6acf57d304d90235300734580

I've got my binding with the C math library to work, so all the ANSI 
C math functions are available now

It works on Linux and should also work on Windows

On Mac, the math library path may have to be adjusted

On Syllable, I get:

*** Runtime Error 101: no value matched in SWITCH
*** at: h

This looks like an error in the runtime to me, quite possibly not 
even float related

It could be an unknown signal group in POSIX.reds

The default error definition on a signal doesn't work anymore since 
the last SWITCH change

The at: report is also odd

The x87 FPU init code wasn't stable when I pushed the commit yesterday 
night, and I forgot to launch the test suite. It should be ok now.

Hmm, your error report looks odd indeed, I'll fire up my Syllable 
image and try to reproduce it.

The latest hello script and my float test script above are both working 
ok on my Syllable image.

Please have a look at the signal handling code. It doesn't comply 
with SWITCH semantics anymore

Kaj: have you tested again with latest commit? This issue should 
be fixed now, I've left some lines commented in _PRINT function, 
so that pointers and structs addresses were not printed anymore, 
that matches with your buggy error report.

Kaj's article on OSNews translated in Chinese for OSEye.net: http://www.oseye.net/kb/show/2774

I wonder what is written on the orange banner on top of the Android 
screenshot?

Cool :-)

Thanks, I'll test again

They have taken over Syllable articles before

Kaj, Will float deployment in Red allow GTK range widgets to be supported 
in your binding?

I think so, but you won't be able to calculate such things yourself 
yet. Do you need them?

Floats work better on Linux now. Before, it crashed when combined 
with other code

On Syllable, I now get:

*** Runtime Error 101: no value matched in SWITCH
*** at: 80000C2Eh

Indeed, I don't see the SWITCH fixed in POSIX.reds

The fact that it crashes with a signal in the first place, I can 
fix with the workaround from bug #129, so this is another case this 
bug affects

Basically, nothing works without LibC initialisation code, except 
programming the kernel directly and exclusively

What's the ETA for fixing this? I would like to promote all the bindings, 
on OSNews and such, but I can't really do so as long as they don't 
work on Syllable

Do you have an unhandled choice in SWITCH? Rather than return an 
undefined value (since Red/System doesn't have none!) it triggers 
an error instead. Put in a default clause.

Of course if that's not the problem, never mind.

Right, the SWITCHes in POSIX.reds need default clauses. I need to 
see which signal is raised on Syllable that is not listed in ***-on-signal.

LibC init code: I need to have a deeper look in the init/exit libC 
routines first to see what's exactly happening there before wiring 
it in Red/System. I'll do that once I finish the current work on 
partial float support.

Kaj, I am doing very simple UI now using GTK based on your Doc-Kaj 
work.  It is totally adequate for what I need to do in the next month 
but after that I want to add value to my users with the range widget 
and some others such as Calendar.   I think they will allow me to 
build smaller more precise user interfaces quickly.