World: r3wp

Here http://red.esperconsultancy.nl/Red-GLib/info/12c18cb30c?

Thanks Peter.

Kaj: I gave a new try on making the GTK+ binding work on Linux/ARM, 
I was able to track the crash up to the call to `gtk-append-container` 
from `gtk-window` function. The argument values passed are:

    window: 0006C000 value: 12

which results in a Runtime Error 1: access violation (segfault)

Kaj: my problem is, that I have a routine: MagickRelinquishMemory 
which should release memory from routines where some returns c-string, 
and some for example pointer to array values... So the best would 
be to accept pointer! with MagickRelinquishMemory, but still to be 
able return just c-string from some routines, if you understand me. 
I know there are workarounds, but it could be quite simple

What about implementing any-pointer! type?

Oldes: why can't use simply use type casting when required?

and is it possible to cast pointer from c-string?

Sure: 

    p: declare int-ptr!
    s: as c-string! p		;-- or use `as-c-string` defined

You can freely cast any pointer type to any other pointer type (struct 
and c-string are part of any-pointer! internal typeset).

I would prefere to be able simply define:   MagickRelinquishMemory: 
"MagickRelinquishMemory" [return: [any-pointer!]] which would accept 
c-string!, struct!, pointer! [byte!], pointer! [integer!] etc..

sorry..   MagickRelinquishMemory: "MagickRelinquishMemory" [resource 
[any-pointer!]]

You can already have it: #define any-pointer! byte-ptr!

Ah you want implicit casting...sorry.

But it's true I can use:
	MagickRelinquishMemory as-c-string query
where query is an array... just it's not so clear

You should rather use byte-ptr! (which is more "generic" than c-string!) 
as return type for MagickRelinquishMemory and cast values to byte-ptr! 
when required.

Pull request #201: Oldes, thank you very much for your changes. It 
should be ok now for merging, I will just run a few more tests before 
that.

Oldes, I had the same problem as you with the generic memory freeing 
routine in the C library, so I use this define:

#define free-any	[free as-binary ]

Which uses this in turn:

#define binary!	[pointer! [byte!]]
#define as-binary	[as binary! ]

Instead of pointer! [byte!] you could use byte-ptr! now, as Doc said

Enumeration branch from Oldes merged to float-partial branch. Thank 
to Oldes for this nice addition and quality work!

I will update the language spec document to include #enum description.

Kaj: I gave a new try on making the GTK+ binding work on Linux/ARM, 
I was able to track the crash up to the call to `gtk-append-container` 
from `gtk-window` function. The argument values passed are:

    window: 0006C000 value: 12

which results in a Runtime Error 1: access violation (segfault)

Here's the code line:

gtk-append-container  as gtk-container! window  as gtk-widget! value

Also, with this contribution comes an ImageMagick library binding!

Cool :-)

value is supposed to be a widget object, so the 12 is bogus

Good! At least we have a clue to follow.

What's the source code that generates this?

gtk-view label "Hello, Red/System GTK+ world!"

The code is executed in this case:

either any-struct? type [
	either as-logic value [

That's correct, because the label generates the widget object to 
be added to the window container

Right, I've added a lot of debug logs to GTK to follow the calls...(the 
planned stack trace feature for Red/System is climbing in priority)

So type seems to be correct, but value is not the label object. At 
a guess, could value = type ?

They're set like this, so I expect a bug there:

type: list/type
value: list/value

Right, I need to check the generated code for that part...

Guessing further, did you maybe swap type and value in the struct 
when adding 64 bits floats?

Yes I have, but the bug is older than that change.

And the swapping should be transparent.

I think there's definitely a stack offsetting bug in the ARM backend 
for typed/variadic functions.

Kaj, I've been able to reproduce a similar behavior (having 12 in 
list/value instead of an address) using a small program, I'm analyzing 
it right now.

I have fixed the bug (issue with variadic function's return value), 
but it is still crashing. It seems the real issue is that callbacks 
are not stable on ARM...I haven't found the time to properly test 
them, so I'll need to do it now. Fortunately, Andreas has joined 
the bug hunting party. :-)

Good progress

What's your experience with Red/System wrapping interface? Is it 
suitable to wrap (relatively saying) "any" C defines? I am recently 
scripting VLC a bit, to see if I can use that player instead of LED 
Studio (which is really bad chinese standard LED accompanying sw) 
for our LED screen.


So far, I am fine talking to VLC via TCP - 10 lines of Rebol code. 
But their RC (remote control interface) missess advanced playlist 
handling. I was looking into vlccore library API, and I found various 
wrappers, and e.g. Python one, is auto-generated, by going thru includes.


IIRC, Max worked on something similar for R3, but never released 
the code. Now I wonder, how difficult would it be to achieve using 
Red/System?

btw - VLC natively supports LUA, so I will also look, if it can't 
do more, than what is being exposed via RC interface ...

Red/System's way to write bindings is the best I've seen. Barring 
C features it doesn't have yet, it should be able to bind any C function. 
Mostly only 64 bits integers and importing data values are still 
missing by now