World: r4wp

IN block word is used in the R3 GUI. It does the same context walk 
that Doc says WITH does, but only to retrieve a word.

The bug with RESOLVE is unrelated. Not sure if that is what you're 
talking about though.

What we need is to be able to rebind a block of code into several 
context in one time

*at one

I used several BIND in sequences. Not neat

Yes, I wondered how a language for constructing languages could make 
this omission

I show you some code. Follow the rebounds :-)

is: func [
		[catch]
		{Current face inherits from a block!}
		spec [block!]
		/local locals old when init
	][
		either all [
			find spec set-word!	; locals founds
			not empty? exclude  ; new ones (not found in the current face)

    first locals: construct copy spec ; copy: because [construct] modifies 
    the block (R2 bug ?)
				first face
		][

   ; Would be simpler, faster and safer using R3 (objects can be expanded)
			; rebuild face with new locals 

   ; (make face spec : can't be used here because of the special bounding 
   rules)

   when: face/when					; prevent copy/deep of when and init blocks
			init: face/init
			face/when: face/init: none
			set locals none

   resolve* locals face			; initialize locals with current face (if 
   intersect)

   face: make old: face locals		; rebuild current face with new locals
			face/when: when
			face/init: init
			do-safe bind bind spec face self; run style constructor 

   bind bind init face self		; rebound current face constructor (which 
   is currently running)

   error? set old :bound-err		; prevent old object from being used anymore
			old: none
		][
			; no new locals

   do-safe bind bind spec face self		; just run style's constructor 
		]
		if error throw-exit
	]

Brian, there was a blog about having RESOLVE, I think, walking a 
list of contexts, but Carl eventually decided that it wasn't needed 
"due to R3's new binding capablities"

Maybe it was about BIND directly

Probably. I'm having trouble imagining a use for RESOLVE doing that.

Maybe it could be used for some kind of multiple-prototyping of objects. 
Something like this:

>> resolve/extend context [] reduce [context [a: 1] context [a: 2 
b: 3]]
== make object! [
    a: 1
    b: 3
]

I haven't followed R3 contexts and binding evolutions, but as Red 
will use a slightly different model (more statical), I guess we'll 
come up with different solutions than with R2/R3.

Oh yeah, sorry to taint your thread Dock

WITH makes more sense for Red. DO IN is inherently more dynamic and 
runtime, while WITH can be more static.

Steeve: no problem ;)

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 :-)