World: r3wp

Are extensions imported into the global namespace?

only if the commands are in the export list.

Are extensions imported into the global namespace if they appear 
in the extension's export list?

the equivalent of it, yes IIRC

that's a drag

That's what makes in-place updating and manual conflict resolution 
possible.

no... just dont export them and do this:

lib: import %r3-test-extension.dll

lib/my-command arg arg arg

That's the other part of the design.

its nice that the extensions use a module to negotiate the access 
of a lib.

can we force an extension not to export anything?

Sure.

IMPORT/only does that.

I am not aware of whether external extensions can be unloaded. I 
would hope so, because they can in theory be upgraded.

It's not a problem with host-embedded extensions because they are 
not dlls in the first place.

I notice that as long as my r3 instance is running, the dll I imported 
has a file lock on it.

Did you remove all references to the extension? If there are any 
references, the dll shouldn't be unloaded. There's no unimport function, 
so try LOAD-EXTENSION, then throwing away what it returns, then recycling.

LOAD-EXTENSION doesn't import, it just loads.

I unset the function I imported

It is still referenced in system/modules if it is imported. Start 
over, just LOAD-EXTENSION (ignoring what it returns) and recycle. 
See if the DLL is still locked.

Fot that matter, unsetting the function wouldn't work unless you 
unset it in both the user context and the exports context.

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.