World: r4wp

Yes, that should work too.

Nenad, can you give me an example, please? When the function requires 
for example (pseudo-code):
     pointer! [byte!] integer64! struct! ; data, index, metadata
how should I pass the integer64! value?

Where do you get that integer64 value from?

In your example, do you also need metadata to be passed by value?

Ok, no metadata, I was wrong. See http://www.mega-nerd.com/libsndfile/api.html#read
sf_count_t is 64 bit integer.

If you need to make some 64-bit calculations as suggested by the 
description, it is more difficult to achieve, but not impossible. 
I think that Peter has coded some 64-bit addition and subtraction 
functions that operate on two 32-bit integers.

I'm testing the namespaces branch. I can't use CONTEXT as a local 
variable anymore. Is it necessary to reserve it that strongly?

I found the issue with handling 64-bit integers in Red is the lack 
of support for unsigned integers. I only needed to  64-bit integers 
support on Windows so I used Lib calls in the end.

Actually, I wrote a small lib to perform the 64-bit arithmetic ... 
but I only needed subtract and divide.

it's at:

https://github.com/PeterWAWood/Red-System-Libs/tree/master/Int64

It wouldn't take long to add addition and multiplication if that 
would help.

All the old bindings still work with the namespaces branch, except 
I'm getting an internal compiler error on my OpenGL binding, but 
I'm not sure it's my latest code

Having the compilation in the working directory would still be nice 
for the release

CONTEXT as local variable: that shall be allowed, I'll fix it.

Compilation in working directory: I'm adding it in the todo list 
for the release.

Other keywords such as IF are also prohibited as local variables. 
I don't know if it's practical to change that

Are #enum's local to a CONTEXT?

IF and others keywords: you surely don't want to mess up your code 
(and the compiler) by redefining them. For CONTEXT, you can't use 
it inside a function body to create a namespace (would need to test 
if this case is correctly caught and raise an error), so it's ok 
to allow it as local name, no possible ambiguity.

#enum: nope, as #define, they are global. I wonder if it is worth 
(and possible) making them namespace-sensitive. 

Oldes (who implemented them), what do you think?

I think they should be local. That's what makes them fundamentally 
better than #define's

I have a lot of #define's in the bindings that I'm now migrating 
to #enum's, and that would be left behind looking out of place once 
I move the bindings into contexts

That also goes for dialects such as GTK. In a WITH context they look 
much better, but they would still not be abstracted if constants 
in them would still need to be prefixed

Added support for enums in namespaces.

You can also access locally defined enums from outside using path 
notation.

That was fast :-)

Just a note: the 0.2.3 milestone is still open on GitHub

I've updated all my bindings to use enumerations now, and found some 
bugs in the process

I'm actually behind on using the newer Red/System features...

What happens with alias detection in contexts?

For example, I have a check type = system/alias/gtk-window!

Should that become system/alias/gtk/window! in a GTK CONTEXT?

Alias: let me check that...

Aliases should work as before, they do not interact with namespaces.

So it should be: system/alias/gtk-window! unless there are bugs (I 
think we haven't tested mixing aliases with namespaces).

But system/alias/window! will lead to clashes with window!'s in different 
contexts

Milestone 0.2.3: can't find how to close it...github's UI keeps changing 
all the time, always feel lost when I have to do rare actions...

Aliases are not context-aware, they are globals.

Ok, I've just deleted the milestone instead of closing it.

I think aliases should also be context-local, then. I'm using them 
heavily as types

That would have some complications in using them as parameter types, 
though. Maybe I should try how it works out keeping them global first

Yes, that would require to add a lot of new code to existing features 
and would take probably several days to code and debug regressions. 
If we could avoid it, that would be nice.

Are aliases used (semantically) in Red the same as they are in Rebol?

I'll have to keep alias names prefixed. We'll see if I can keep that 
from leaking through in dialects

Aliases in Red/System are names for C-like structs. It's quite a 
different concept as anything that would be called an alias in REBOL

Aliases in REBOL are for words only.

In Red, I'm not sure that I will implement ALIAS support (as in REBOL), 
it seems that's a feature that has been very rarely used since the 
beginning of REBOL.

I think it needed to be in there because Amiga DOS has it :-)

Good old AmigaDOS. :-)

From the R3 documentation:

Aliases are special because they work at the symbol table level, 
allowing them to be used for refinements and dialect words as well.

So it would be the only way to translate refinements and such