World: r4wp

(So it's propapbly best to remove the "syntax" section in the float32! 
spec and add a note describing the above.)

Agreed.

Doc fixed.

I found another freak bug

ah?

In the tracker

Kaj: proper libc init code added for Syllable. It works fine on my 
Syllable VM.

That is great, thanks!

Doc - so your sister tweets about the Red development? Cool :-)

Why not delete the Twitter message if it was an error?

Good movie?

Behold, an OpenGL triangle rendered by a Red/System program:
http://earl.strain.at/share/reds-opengl-triangle-20120227.png

GUI next?

Can we view the code that does this?

Of course:
https://gist.github.com/d3b0e5c6fdbc4f19ff7a

(2/3 inline binding code and the rest is very plain OpenGL and, yuck, 
GLUT.)

Looks good and the code looks some much easier on the eye than C 
to me.

so what to add to be able to click on something and get a calback 
working?

a few 1000s of LOC :)

That's where dialects can shine: abstract low-level APIs.

andreas, cool! perhaps time to add GLFW? ;-)

tombon: would most likely be better than glut :)

events for free :))

ah, events are "for free" in glut as well :)

as clean as in GLFW? argh.... ;-)

didn't say anything about clean :)

Just updated the Gist, you can now rotate using the arrow keys:
https://gist.github.com/d3b0e5c6fdbc4f19ff7a

(Graham: +10 lines binding, +12 lines reds code)

2 factors overestimate by me :)

2 orders of magnitude! :)

But then, you asked for clicking, and I only gave you typing :)

yes what I meant ...

10 x 10 x is two factors?

Had to enable double buffering to stop the flickering. Another 4 
lines.

harr..harr. andreas the human coding machine :))

Doc, do I understand it correctly, that lists/arrays are now supported 
via 'typed funcitonality, hence structs? How much would it complicate 
red/system to have a native block implementation? :-)

I'm sure Doc will answer this question as: "Red/System is for low 
level system programming, no need to implement blocks unless we need 
it while writting Red".  :)
I think blocks etc. is for Red not for Red/System.

I know. OK, maybe I need an advice. I was looking into some C code 
educatory example, which contained something like:

char multi[5][10];

decomposed to:

    multi[0] = {'0','1','2','3','4','5','6','7','8','9'}
    multi[1] = {'a','b','c','d','e','f','g','h','i','j'}
    multi[2] = {'A','B','C','D','E','F','G','H','I','J'}
    multi[3] = {'9','8','7','6','5','4','3','2','1','0'}
    multi[4] = {'J','I','H','G','F','E','D','C','B','A'}


which gets stored in a memory block of a "0123456789abcdefghijABCDEFGHIJ9876543210JIHGFEDCBA" 
value.


If I would be supposed (for any reason :-), to interface to such 
a construct, I would simply use a pointer in Red, and would be responsible 
to manually decompose/treat the value of arrays, not to break it 
for the C level code?

Yes. (And there's hardly a breakage you could incur.)

Note that in C, multidimensional arrays are really just a convenience. 
So a `char[5][10]` is actually identical in memory to a `char[50]`.

And, as you know, an array type and a pointer type are (for most 
things) interchangeable, a `char[50]` is the same as a `char*`, therefore 
a `char[5][10]` is also the same as a `char*`.

OK, thanks. So btw - how are REBOL blocks (most probably), implemented 
in the C level? As structs of "arrays", chars?

Andreas: No possibility to be multi[0] and multi[1] are not interleaved? 
I mean, couldn't be 2 different memory blocks instead of continues 
one? Normally it will char[50] but same for all compilers? all memory 
models? small hardwares etc.?

Petr, it is true that typed function arguments can be used to implement 
blocks to some extent

REBOL blocks have larger cells

Endo: it's guaranteed to be a single, contiguous area of memory. 
So yes, that behaviour is the case for all compilers and all memory 
models and all hardware (if they claim compliance with the C standard).

Endo: thanks for avoiding me to repeat myself over and over. :-)

When I will write app in Red, it will compile to Red/System in the 
first pass, and then to the native code from R/S? So that it means, 
that you write Red in R/S? Hmm, if Carl would release R3 sources, 
it would not help you much, as you plan to write Red in R/S, not 
C?

Pekr: "Doc, do I understand it correctly, that lists/arrays are now 
supported via 'typed funcitonality"


No, it can look like "lists", but there are only function calls with 
arguments.

Arrays might be supported in future though, if we really need them 
for implementing Red.