World: r3wp

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.

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.