World: r3wp

Well. I give up. I don't like languages with preprocessors since 
they are slower than languages with no preprocessor. So I send an 
original .ATG to Dockimbel, and stop my work. Looking at the RED 
spec made me sigh about the preprocessor.

And I am restarting my work on simple Oberon-like language.

I was just talking about the token portion of the Coco/R syntax rules, 
as opposed to the parse rule portion. But agreed, any Oberon-like 
language will have a simpler syntax than any REBOL-like language, 
and will have been designed with LL(1 or so) in mind.

paths seems to be tokens, too

Paths are made up of tokens, yes, just like the other block types 
except with more restrictions about what types of data may go in 
the paths. I don't (currently) know what subset of path syntax and 
semantics that Red/System supports though.

In some other REBOL-like languages there are some inherent conflicts 
between some path element types (notably dates) and the path separator 
/ itself, plus the final : on a set-path is considered part of the 
path instead of being a set-word element contained in the path, and 
the same for a leading : in a get-path not being part of a get-word 
first element (in R3). There's a fairly well-defined set of precedence 
rules, but for REBOL-like languages other than Red those rules are 
not very well documented, and they can therefore sometimes vary from 
language to language.

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