World: r3wp

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?

The current resolver only works for simple cases, basically, only 
when you're directly passing a function pointer as argument to a 
function.

I need to add the unresolved calling convention error routine.

When such error will be reported, users would need to provide manually 
this information, by adding 'cdecl or 'stdcall as attribute.

I don't really see a connection between the function a pointer is 
passed to and the function that will eventually call it

Well, it depends if the function taking a function pointer is invoking 
it directly or if it's passing it to another function (local or imported). 
In the former case, the compiler can set the right cconv itself, 
in the latter case, it can't and need some help from the user.

Yes, so is the current inferer always guessing right?

Let me have a look at the specs, I remember there was an edge case 
documented there...

No trace of any special cases in the specs anymore. So, the compiler 
is always guessing right, when it can guess. When it can't, it leaves 
the cconv in undetermined state (??).

The inferer is very simple, it just looks at the cconv of the calling 
function and propagates it to the callback. If the callback has already 
a cconv defined, it checks if both cconv matches, and raise an error 
if it's not the case.

Not much to report yet, except this:

bash-4.0# hello-SQLite-world                                     
                                                                 
           
SQLite version: 3.6.22
SQLite version number: 3006022

SQLite source ID: 2010-01-05 15:30:36 28d0d7710761114a44a1a3a425a6883c661f06e7