World: r3wp

problem with the cURL example  on windows XP: 
Runtime Error 1: access violation 
at 00000F16h.

jocko: try to compile it with the -g command line option, you should 
get the error location in sources.

Runtime Error 1: access violation
in file:

that's all.  No filename

Kaj: the error seems to come at the line 
status: curl-do session url

Are you using the latest Red?

Can someone explain how arrays work in red. I've seen an example 
where you progress through an array args with  args: args + 1. I 
would have understood better if it were the index that were increased 
for each loop, like item: item +1 in args/item ...

There are no "standard" arrays in Red/System though I'm sure that 
there will be, or something which provides the same functionality 
in Red (when it becomes available).


args is not a standard array and is navigated through pointer arithmetic 
just like  a c-string. I suspect that args points to a list of pointers 
each of which contains the address of a command-line argument.


So the first entry in Args holds the memory address of the first 
command-line entry, the second the second command line entry, etc.


The syntax args/item gets you to the data pointed at by the relevant 
entry in args.

So the compiler doesn't treat item as an index but as a command to 
derefence the pointer heid in the current position of args.

OK, I see. Thanks for explaining!

You can also do it with an index, but indexes are one-based. With 
pointer advancement you usually get the same effect as zero-based 
indexes

I thought I'd try the GTK+ examples. Is there somewhere I can get 
C-library.reds?

http://red.esperconsultancy.nl/Red-C-library/

Thank you Andreas!

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

Where is the recommended dir to place GTK.reds, C-library.reds & 
SDL.reds? I put them in red-system. BTW. I'm using Win 7 (x64) and 
compile with do/args %rsc.r "-v 5 %tests/hello-GTK-world.reds".

You can put all the bindings source code in %/tests directory.

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