World: r3wp

You shouldn't need to use the verbose option, unless you want to 
have a closer look at what the compiler is doing internally, or to 
more easily locate a compiler internal error.

BTW, I had a great time at Software Freedom Day and met very interesting 
peoples. Thanks to Bas & Kaj for organizing it and inviting me.

Kaj: I am cleaning up my slides before putting them online. I am 
still not sure to understand your remark during my presentation about 
the usage of VPRINTF instead of PRINTF in this import definition:

	printf: "printf" [[variadic]]

Here is Nenad ´s Red presentation during Software Freedom Day: http://www.youtube.com/watch?v=wgtgoliZ454

Thank you Bas.

I will release the slides in a few minutes, so people can watch the 
slides more comfortably.

Slides are available here: http://portal.sliderocket.com/AOLUS/Red_SFD2011_45mn_2

The C library's vprintf() function is the one that gets passed one 
argument that is a list of the variable arguments. This seems to 
match the declaration of a variadic Red function, so I thought PRINT 
would match vprintf(). Looking at it again, is it the other way around 
and does PRINT match printf() ?

The example in 6.3.3 in the manual also mixes up these names

Magnusson, are you sure you have the latest versions of the bindings?

About the examples in 6.3.3, I would need to rename the vprint and 
vprintf functions to avoid confusion.

About the [variadic] attribute used in imported functions declaration, 
as you can notice, you don't need to declare any arguments. In this 
context, the attribute is interpreted just as "variable number of 
arguments" and the C calling convention will be used in such case 
(the Red/System variadic stack layout is different than the C one, 
as it also passes the arguments count).

Kaj, I downloaded all files again and tried it on another PC with 
Win 7 (x64). Same compilation error, but I also noticed while running 
do/args %rsc.r "%tests/hello-GTK-world.reds"

The first run


*** Warning: type casting from pointer! to pointer! is not necessary
*** in: %tests/hello-GTK-world.reds
*** at:  [as integer! :gtk-quit null

*** Compilation Error: invalid struct member alias in: type
*** in file: %tests/hello-GTK-world.reds
*** in function: window
*** at:  [type system/alias/gdk-image! [

The next runs


*** Compilation Error: a variable is already using the same name: 
window
*** in file: %tests/hello-GTK-world.reds
*** in function: window
*** at:  [

MagnussonC: have you downloaded the latest version of Red sources 
(the "Download.zip" button and not the v0.2.1 link)?

If the Red variadic stack layout is different from C, how can you 
import printf() from the C library? Or do you mean it's compatible 
for imports?

I think so, after reading it three times. :-) I previously assumed 
just one method was used

The meaning of [variadic] is relative to the context. ;-) In imports, 
it will just pass a stack of arguments as expected by the C calling 
convention. When used in a Red/System function, it will add more 
information on stack.

OK, thanks. I feel certain enough now to update the C library binding

Dockimbel, no, I didn't realize there was a difference, but now I 
have and it compiled OK. Thanks.

Good! I will make a new 0.2.2 release asap to avoid such issues with 
the older version.

GTK-input-field.reds compiles OK and catches the input, but exe also 
gives *** Runtime Error 1: access violation at: 63A45193h

I have a similar error here. It's on my todo list, I'll investigate 
that issue in a couple of hours.

That looks like the error I'm getting on Linux on an older GTK version

The crash is occuring in the 'action callback function.

It seems to happen on callback exit.

I think I get what is going wrong: the action handler calling convention 
is inferred as stdcall, because it is passed to a Red/System 'button 
function. But this function is passing it to an imported C function, 
so the hanlder's calling convention should be cdecl.

The compiler can't infer correctly in such case, so we need a way 
to force the cdecl convention on the callback function.

I guess a solution could be to implement a 'cdecl attribute support, 
to be able to manually force the right convention. But that would 
make things it a bit more complicated for the GTK binding user. 


Another option would be to define a trampoline function in the GTK 
binding that would call the user callback. That trampoline function 
would be directly (no nested calls) passed as argument to the imported 
function, so the compiler could infer its calling convention correctly.

I was suspecting something like that. I hope it also helps the Linux 
and SDL cases

It could also be what went wrong for Jocko with cURL on Windows

It's probable if you're not passing callbacks directly to their caller 
function. So, what option for solving it do you prefer?

Thinking. I'm a bit foggy today

Ah, I know that feeling very well. :-)

Have to get back into Red. I've been looking into Freecoin and other 
stuff for a few days

How complicated would it be to make a Red binding for Freecoin?

Red would be more suitable than Red/System

It's quite a mess, and that's why everybody is rewriting stuff

Freecoin still has the Bitcoin interface, so you'd have to do JSON 
with a daemon. Not very comfortable until you have PARSE

I see. I haven't looked yet at Freecoin source code.

LibBitcoin has bindings, so you could bind to the C interface. But 
they're using 64 bits numbers everywhere, so that would be uncomfortable 
until Red/System has them

Freecoin doesn't seem to use LibBitcoin at all yet

I've decided to first port some of it to Syllable and wait a while 
with the bindings

There are also horrible heaps of C++ dependencies

On the callback matter, wouldn't it be better to always generate 
them as cdecl?

Maybe.

I don't see how a trampoline would work very well, because we're 
talking user written callbacks, so each would need its own trampoline

No, only your GTK dialect API would need them (one for button, one 
for window, ...).

The callbacks can have different numbers of arguments, and the widgets 
will eventually have multiple callbacks

Ah, I thought that "action" callback would all share the same definition.

callbacks