World: r4wp

OpenCL: yes, I have that in mind too, but it's most probably for 
a later version of Red (> v1.0). Also I have other plans to give 
Red access to GPGPU, by directly having a GPU machine code assembler 
and a dialect on top of it. It would be mainly for compiler internal 
use, but such dialect could be exposed for user code if some are 
willing to implement some fast GPU-powered routines.

If you're doubting about such approach, read this article:

 http://www.geeks3d.com/20110317/low-level-gpu-programming-the-future-of-game-development-on-pc/

Nice Doc, Thanks for taking time to answer. I'll "follow the guide" 
as we say here ! Have a nice day. Now I'll go reading  your link.

bOK Doc I agree for the speed factor But then you would do the multi-targets 
road again this time for multiple GPUs , isn't it ?

have to do ...

In between, here is the PyOpenCL lib link for those interested to 
see how the OpenCL API is accessed by other languages - and this 
could pave the way for some Red binding ... http://mathema.tician.de/software/pyopencl

OpenCL is certainly a quicker way to access it. My plan for direct 
GPU access is not only motivated by speed gains, but also by reducing 
complexity, having a simple, lightweight access to GPGPU capabilities.

Also, for direct GPU access, it will only be doable for GPU that 
have all the required specification published (unless drivers provides 
the right API already).

I know the french guy who used OpenCL to automatically parallelize 
some iterators for Scala, so it's definitely something I want to 
try for Red:
 
http://code.google.com/p/scalacl/

(I'm trying to compile Insight debugger on the RPi, compiling since 
half an hour...hope it will finish before tonight)

Ah, of course it ends up earlier with an obscure compilation error...

I haven't isolated any callback case yet, but the existing cases 
don't actively use floats

Thanks Doc - I know your way is the best you can choose for fine 
tuning GPU access without adding much overhead !

Kaj: I've pushed a fix for ARM that should improve the stability, 
can you do some quick tests to see if some of the issues are fixed?

cURL example script still crashing...

OK

I've added preliminary support for 64-bits integers to the SQLite 
binding. They're represented by a float! so they can be passed around, 
but they're hard to compute with

Ok, it seems we'll have to return to an explicit callback declaring 
syntax. In cURL, the callbacks passing (get-word! syntax) occur after 
the callback declaration, so when the compiler is creating the callback 
prolog, it has no way to guess that this particular function will 
be used as callback later....

We already have discussed this in the tracker, but I can't find the 
related tickets...

I also seem to remember this. Maybe it was the problem behind this:
https://github.com/dockimbel/Red/issues/204

#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