World: r3wp

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

Anyway, forcing cdecl for all callbacks might be a better option. 
I would need to check first if there's no internal compiler drawback 
on this option.

Not always. You can for example pass gtk-quit without parameters, 
while the regular number of parameters is two

If I force the 'action callback in the GTK script to 'cdecl (by hardcoding 
it in the compiler), it's not crashing anymore. So the cause is confirmed.

Cool

Just thinking about a drawback for your proposition: Windows API 
expects callbacks using stdcall convention...

I'm falling apart here. I'm going to sleep

Same here.

:-)

In C system programs it's common to specify the calling convention. 
It's probably reasonable to require an attribute, but I would say 
callbacks for Windows are the exception that would require one

Red/System uses stdcall too internally, so forcing user to use a 
cdecl attribute for Red level callbacks is not natural. Need to think 
more about it to find a better option.

No, I mean to default to cdecl - which I thought was already implied 
by CALLBACK - and require to add stdcall only for Windows system 
callbacks

I don't think it is a good solution to put the burden on Windows 
users only.

It's only for Windows system callbacks. Most all other libraries 
on Windows use cdecl, and it is only for callbacks, not for general 
Windows system functions

If stdcall would be the default, even Windows users would have to 
write it many more times than the other way around