World: r3wp

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

I've started on an SQLite binding

Ah, nice :-)

I have documented the calling convention issue here: https://github.com/dockimbel/Red/issues/176

I think it should be reasonable enough to choose cdecl when a function 
pointer is passed to a variadic function.

Doc - I noticed (in your presentation), that port! dtype will be 
supported. I wondered how IO is going to be done,e.g. networking,or 
files. Will it be wrappers written in RED upon read-io, write-io 
Red/System functions?

I haven't decided yet on the implementation detail, but my current 
plan is to use a R3-like approach, passing messages to a lower-level 
layer wrote in Red/System.

Note that I'm only using variadic functions in the GTK binding so 
far. The issues in the other bindings are with regular functions

Are you using also function pointers only in GTK binding?

Are you using function pointers only in GTK binding?

No, there are callbacks in most bindings

The crash on the older GTK on Syllable Server is gone

Will it be wrappers written in RED upon read-io, write-io Red/System 
functions?
 


Just to be sure there is no confusion: the read-io and write-io function 
mentioned in the slides have nothing to do with the REBOL homonyms. 
The Red/System ones are wrapper on CPU's IN and OUT instructions.

OK, thanks for the clarification ...

SDL audio still crashes

You should compile it in verbose mode (-v 6) and check the callbacks 
calling convention in the symbols block at the end of the compilation 
logs.

It should be stdcall or cdecl. If you see ??, it means the compiler 
hasn't been able to solve it.

Bingo, it says ?? for the audio callback

Ah!

The ?? is the default value for cconv. When the compiler encounters 
a get-word!, it propagates the cconv from the function using it as 
argument.

How are you passing callbacks? Same way as with GTK binding through 
a variadic function?

As I noted above, no variadic functions in the other bindings yet

Can you show me the code pattern you're using for the callbacks in 
SDL audio binding?

stream!: alias struct! [
;	data				[binary!]
	index				[binary!]
	rest				[integer!]
]
fetch-audio: function [  ; Read sound buffer to be played.
	[callback]
	source				[stream!]
	sink				[binary!]
	size				[integer!]
	/local slice
][
	slice: source/rest
	if slice > size [slice: size]

;	copy-part source/index sink slice
	sdl-mix-audio sink source/index slice sdl-mix-max-volume

	source/index: source/index + slice
	source/rest: source/rest - slice
]

Ok, so how are you installing the fetch-audio callback?

desired/callback: as-integer :fetch-audio

desired:	declare sdl-audio-spec!

Ok, so the cause is obvious, no way for the compiler to figure out 
the cconv in such case.

I think that I will just accept both 'stdcall and 'cdecl attribute 
in cases like this where the compiler can't determine the right calling 
convention. I will also add a check at the end of the compilation 
to raise errors for unresolved calling conventions.

That's nice, but why not default to cdecl?

The default needs to be a non-usable value for the compiler to be 
able to catch unresolved calling convention. If it's cdecl or stdcall, 
the compiler won't report the error which can lead to stack corruption 
at runtime.

Are you sure the current resolver is watertight, then?