World: r3wp

Raspberrypi shipping any day now! http://www.raspberrypi.org/Lets 
see Red on it!

Oldes: A c-string is a byte-ptr!. It can be cast to an int-ptr! if 
needed.

Kaj: I cannot compile GTK+ examples anymore using the latest GTK+ 
binding version...Where can I find the missing GLib.reds file?

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