World: r3wp

Oldes, wrap it in a struct. I call those references

If you mean a pointer to the string payload, that's what a c-string 
already is

I guess R3 is 2-byte head and 10-byte payload.
 - that is a wrong guess

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.