World: r3wp

Evgeniy, function calls are not really part of the syntax in REBOL, 
or Topaz and i think even Red/System. So, yes, it is a CFG, it's 
just not like other languages (more like XML or JSON).

Doc - congrats on finishing floating support in Red/System. Now all 
to-do list items seems to be done right? So time to move on onto 
Red itself? :-)

Doc, According your slides, Red's boxed value composes of 4-byte 
head and 12-byte payload. Why so? I guess R3 is 2-byte head and 10-byte 
payload. Just curious. :-)

Pekr: thanks but only the float-partial branch is done (still some 
bugs to fix also).

Jerry: values needs space to store various flags, and type information. 
Also, payload access needs to be 32-bit aligned at least.

Why do you think that the R3 values header is 2 bytes long only?

2-byte head is just my guess. 10-byte payload is my guess too, based 
on the max limit of tuple!. With your explaination, now I know why 
4-12 is choosed. Thanks.

is it possible to get pointer value from variable declared as c-string?

R3 has 16 bytes cells, too

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