World: r4wp

Object expansion is another one of those things. When you say objects 
can't be expanded, it sounds fair enough, but when you say contexts 
can't be expanded in a language meant to create languages, that's 
a serious limitation

`system/words` virtual path support was added in today's commits, 
to be able to get/set a global variable or call a function from within 
namespaces with conflicting local names.

Example:

    e: 123
    a: context [
        e: -1
        print-line e
        print-line system/words/e
        system/words/e: 0
    ]
    print-line e

will output:
    -1
    123
    0

is there aliasing possible? e.g.

sys*: :system/words
sys*/print

No, you can't do that. You can use macros for full paths if it's 
really required. Anyway, the use of system/words should be rare.

It has been added just to make it possible to resolve conflicting 
cases.

I just need to upgrade Red/System specifications, improve the Red/System 
runtime with this new feature, and I'll be ready to merge this branch 
into master. I might also make a new global release (v0.2.6).

That would be good. I'm now only updating the bindings for releases

If some external library requires 64bit integer, but Red/System supports 
only 32 bit integers, how can I supply that number? Can I "cover" 
it with a struct?

If you need to pass a 64-bit integer as argument, currently you would 
need to split it in two integers and pass them instead. A struct 
is passed by reference, not by value (yet).

Couldn't you pack them in a float64!?

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.