Duane Maxwell wrote:
> 
> Actually, while you're mucking around in there, I'd kinda like the ability
> to make the VM close external plugins in order to make the debugging on
> them easier.  At the moment, to test a new version of a plugin, we have to
> quit and restart the VM.

It doesn't seem to be so easy to get rid of an already installed shared
lib on Linux (don't know for other platforms):
If I'm removing a plugin module while Squeak is running, a previously
called function from this module is further available though. A file
'sync' doesn't change this behavior.

Therefore it seems to be necessary to browse all calls to e.g. a module
like 'LargeIntegers' by searching for methods containing lines like
	<primitive: 'primDigitAddWith' module:'LargeIntegers'>
by
	Smalltalk browseMethodsWithSourceString: '''LargeIntegers''' 
, and then?

Currently I don't know, how the cache mechanism for the function pointer
works, which is also given as a parameter (in an array) to
Interpreter>>primitiveExternalCall (look there)...
It would be necessary to clear all these pointers in the whereever
cache: then they would be recomputed automatically with next call of the
corresponding function in a renewed module (at least I suppose this for
Linux).


> 
> If a shared library could be closed and reopened from within the VM, you
> could do some really interesting stuff under certain enlightened platforms,
> such as translate, compile and test a plugin without ever leaving the
> Squeak environment.  Under UNIX the external stuff could be done with a
> plugin that calls "system()", on the Mac this could be done with the
> AppleScript plugin and CodeWarrior.

This would be very neat. I think one challenge is to ensure same
semantics on all platforms...


Stephan

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3