World: r3wp

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

Good start!

Ok, these are the changes I will make today wrt cconv resolution:

- 'cdecl and 'stdcall keywords will be accepted as function attributes.

- 'callback attribute remains, it lets the compiler decide on the 
cconv to apply. If it fails to solve it, an error will be raised 
and user will have to manually set it instead (replacing 'callback 
by 'cdecl or 'stdcall).

You can only have one function attribute?

then we need typesets and attribute sets :-)

BrianH: no, there are several others that can be mixed together, 
but only one from [callback stdcall cdecl].

So that means that any function declared as 'cdecl or 'stdcall can 
now be used as a callback? Or can all functions?

Only those having one of those above 3 attributes can be used as 
"callbacks".

I think I see your concern. It might be probably less confusing to 
leave the 'callback keyword mandatory for "callbacks" and accept 
'stdcall and 'cdecl as additional attributes, but it is a bit more 
verbose also.

What's the difference between a cdecl callback and a regular cdecl 
function?

IIRC, no differences, the callback attribute was just meant to help 
the compiler figure out that the cconv has to be solved at compile-time.