World: r3wp

There is one global exports context. The separate user context is 
task-specific. Plus each module has its own context.

RobertS, I built mine using MinGW .. didn't try CygWin

Graham, you might want to read some of the docs. Helps.

For example, in the case of two modules with same function names, 
you can use a direct reference to clarify which one you're referring 
to, or bind your code to a specific module. Easy to do.

Carl, do external extensions unload on recycle if there are no extant 
references?

Also, every extension owns its own namespace, same as modules.

There's no unloading, but it's possible, however, very low on the 
todo list considering that most extensions are long-lived.  The locked 
DLL G refers to above is because the code segments are loaded. (That's 
more of an OS implementation issue, a poor one IMO.)

I've read all the docs .. as to whether I remember the content, that's 
a different issue

So, the next thing on the big todo list is: C-to-R callbacks.

Has anyone thought in detail about what is wanted for callbacks, 
or is it just a general idea that is wanted?

Not in detail ...

Also, on the list is to add BrianH's change, in fact that probably 
should be A102 by itself.

Maxim has given it some thought, but his thoughts are not task-safe.

When are tasks on the table?

Anytime you want.

Sounds like tasks should preceded callbacks then

We have tasks now. Just because they don't work properly doesn't 
mean they're not there, and certainly they need to be a consideration 
eventually.

What has to happen is to review the additions that have been made 
sense tasks were first added.

That is, classify globals into thread local or not.

And to review the existing task-related tickets.

If I bring up a GUI in Qt or something .. I'll need a way to call 
rebol from the GUI as otherwise I have no way of communicating except 
on exiting the GUi

That's a messaging request.

( Unless QT is wrapped .. like AGG is )

So, you could use a socket or IPC, etc.

You probably can't wrap Qt like AGG. It would be easier to wrap R3.

Isn't Rebol blocked by the extension though?

don't know if this has been discussed wrt callbacks, but it would 
be good to be able to call back into REBOL for purposes of controlling 
execution, say for debugging from a non REBOL editor/IDE

That's more of a reverse callback, right?

yes

I think we'll want to do that to some extent.

So, all the examples I've seen that I remember .. Rebol executes 
an imported function...and control returns Rebol.

Graham, if it's a task (OS thread), then no, it's not blocked and 
has its own stack.

But we can't do that at present ... start a thread to call our extension

I am having a slight policy problem with the delayed module model, 
which could some feedback.

Callbacks work both ways, which has been my point for a whle now. 
But, we'll need to know what we want.

G: why not?

Maybe it's the documentation I haven't read yet??

B: what's the policy problem?

kind of similar to Graham's request, but for use with WebKit running 
as an extension - it would be nice to be able to send DOM events 
back to REBOL - would this need the same kind of mechanism as with 
QT?

What we probably should do is designate a PORT type for intertask 
messaging, and make it easy to use.

a Rrexx port

Sort of... they were originally based on Amiga Ports. History.

If you are adding a module to the module list, and there is an existing 
module of that name, then the new module either overrides it, replaces 
it, or doesn't get added (possibly with an error triggered, but so 
far not). The question is which one to do in the particular circumstances. 
The factors are whether it is the same module, for whatever "same" 
means here considering it might be reloaded or still source; whether 
the versions are the same or greater; whether the existing module 
has already been made or is still source, and the same for the module 
to be added.

This is going to take some discussion. Probably not here in this 
group, because it may get rather long.

I started in the other world. We can pick up there when you like.

Probably best. But, there are also various notes here too I see.

simple example 

view [ button "Print" print "hello" button "QT" do [ test ]]


when I click on the QT button, I bring up a QT window but event processing 
stops on the Rebol side .. the Print button no longer responds

all the test function does is open up a qt window with a button and 
starts qts event handler

quick heads up: I built A101 just fine (a Win32 build cross-compiled 
on Linux) and the "go.r" demo still works. so thanks for A101, Carl!

So, the go.r demo is a heads up display?