World: r4wp

#204: that's the one I would have loved to see documented ;-)

I think #193 might be the closest.

Ok, I think I see where lies the issue in the compiler.

The compiler is using two ways to encode the fact that a function 
is used as a callback:

- through the CDECL attribute presence (destined to be called by 
external code)

- through the internal CALLBACK flag that is assigned to all functions 
that get their pointer passed as argument (get-word! syntax).

Somewhere in the compiler, these two conventions are conflicting...let 
see if I can fix that without having to change anything to the current 
semantics.

Kaj: your code is ok, as long as it sets CDECL for marking functions 
called by external libs.

I should be doing that everywhere

Normally a function can't be used before it's defined. How could 
I pass a pointer to a function that's not defined yet?

It can if called from the body of another function.

(IIRC)

Function's body compilation is deferred. During global code compilation, 
only functions prototypes are collected, so all functions are known 
before the first function body gets processed.

That approach allow to solve cross-reference issues.

Basically, Red/System compiler is doing automatically what C compiler 
requires you to do manually (i.e. specifying function prototypes 
separately in headers).

So there is no forced function order?

When I put one of the cURL callbacks behind the function that uses 
it, the code size increases by four bytes, even for Intel. But when 
I then remove the [cdecl] it goes back to the original size

The stack fix has degraded the behaviour. I now get an access violation 
on all programs

I'm working on it, the fix is fine, but it seems it doesn't work 
with __libc_start_main call (and only that one).

It's like this call doesn't respect the ARM EABI...

I will push the fix for callbacks correct prolog/epilog generation 
in a minute.

Fix pushed.

cURL binding should now work correctly (except the ending segfault 
caused by bad libc init call...I'm working on it).

Ok, this time, it's the good one :-)

(A bad copy/paste earlier changed the position of the first fix before 
I commited it, libc init is fine).

Both cURL and SDL audio test are now working fine on my RPi.

BTW, I've also applied the same fix for callbacks on IA-32 backend, 
so retesting all bindings on Linux/Intel would be needed.

Kaj: I can't find the URL for Glib repo?

Ok, found it, it's "GLib"...

PeterPaint-SDL demo works on RPi now.

That already worked :-)

Ah! :)

The URL for GLib is Red-GLib

For GTK demos, I get an Xlib error: 

Xlib: extension "RANDR" missing on display ":1:0"

I'm now running my RPi headless and using it remotely through VNC 
and ssh. Maybe the error is related to that?

Could be, although it's also possible that the RANDR extension is 
really not there, because it seems to fix its screen resolution, 
needing its own utility to change it

Doesn't seem like it should influence GTK, though

Hmm, there are some bug tickets about that (old ones): https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/157319

It seems turning off the multiple screens feature might fix it. I'll 
try tomorrow on the RPi localy (not through VNC).

Hello-GTK-world is still segfaulting on my Debian-armel image on 
QEMU. I will investigate that tomorrow.

Yep, seemed to be a separate issue, like 0MQ

Actually, 0MQ works now. But I'm still getting the access violation 
on GTK, not an XLib error

Kaj: for debugging the GTK issue, we need a minimalistic app. Could 
you re-implement the hello-GTK-world using only direct GTK calls 
and not going through typed functions? We could at least see if it's 
related to GTK calls or not.

New RPi, doubling the memory for the same price - http://www.engadget.com/2012/10/15/raspberry-pi-model-b-512mb-ram/

Kaj: couldn't wait so I've implemented it myself. ;-) See ticket 
comments.

so, are ARM fixes almost complete now, and is 0.3.0 going to be oficially 
out soon? :-)

Pekr: I have set my RPi memory split to 192MB for apps, 64MB for 
video, not memory issues so far.

Pekr: still a lot of details to work on before that, as always before 
a major release.

I think it will take me one or two days for the 0.3.0 release todo-list 
to get done.

That also means, we'll probably postpone floats hardfp ABI support 
for a later release (probably 0.3.1).

Some blog article about what 0.3.0 brings to the table, would be 
nice then, to show ppl what is implemented, what one can do already 
in Red (eventual list of supported dtypes, natives, actions?), and 
what comes next? That would keep ppl motivated ...

Wrinting a new blog entry is part of the todo-list. ;-)