Archiving information from a plugin

I hope this is the best mailing list for this question...

I am writing a squeak plugin and have two questions.
My plugin has internal objects that are modified by various primitives.
I would like to archive this information from one run to the next.


A) are squeak ids passed into my plugin ("oops")... are they
   only good for the single execution of the primitive (can
   I save these off in the plugin... and expect to see them
   around later?... does garbage collection move these guys?).

B) is there a prescribed way to archive information from a plugin
   at "save image" time and later restore it at "load image" time?
   My plugin can create an ascii string to store off state. I could
   have a primitive save and restore the state... but how do I have these
   primitives called. Is there an existing hook for something like this.

Thanks in advance,
Alan

If you put a method called

startUp: resuming

on the class side of your class you will have that called
when then image is restarted, the resuming flag is:

a) resuming is true,
        when the image is being restarted after a quit, possibly on a  
different platform.

b) resuming is false,
        when the image is being restarted after a (snapshot) save

A class method startUp

Gets called when the image is being restarted (after snapshot, or  
restart after quit).


For shut down
shutDown: quitting   or
shutDown on the class side

Gets called when we shutdown. I'll note if you say on the mac if you  
choose quit from the apple menu bar only the
plugin shutdownModule logic is run, no smalltalk shutdown code will  
be run.  Choosing quit from a smalltalk menu will run the shutdown  
method.

The plugins also get called in the VM when they are loaded and  
unloaded, so the plugin
could also decide to manage data at that point. See initialiseModule,  
and shutdownModule,


Also see usage of registerExternalObject: and  
unregisterExternalObject  and say  for example
MpegFile>>fileHandle

where we stick data into the external objects table and use the  
fileHandle accessor to confirm the
external address is still valid, this attempts to ensure a stale  
memory address is not used. Also see the
class ExternalAdress which nils the handle at startup time.  Remember  
Startup for your method is invoked
against your class at somepoint in the startup process, however that  
does not preclude the ability for logic
in your class to run before startUp is invoked which is what  
MpegFile>>fileHandle is guarding against by
validating what the image sees against a table that is zeroed when  
the VM restarts. This also address issues
if you force quit an image and then restart since your shutdown code  
would not have run.




On 8-Nov-05, at 10:05 AM, Alan Sibley wrote:

Yes a GC event will/could move the object. If you move the address of  
an object into C variable you cannot
expect to make another VM callback that would move or allocate  
memory. There is a call to push the address,
later pop it. But the best solution is to avoid the situation, such  
as allocating new objects before having to solidify
address of any objects.


--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

On Tue, Nov 08, 2005 at 10:05:19AM -0800, Alan Sibley wrote:
> I hope this is the best mailing list for this question...

Actually, the general purpose list might have been better, but
this is fine too.

> I am writing a squeak plugin and have two questions.
> My plugin has internal objects that are modified by various primitives.
> I would like to archive this information from one run to the next.
>
>
> A) are squeak ids passed into my plugin ("oops")... are they
>    only good for the single execution of the primitive (can
>    I save these off in the plugin... and expect to see them
>    around later?... does garbage collection move these guys?).

No, the oops can and will change any time a garbage collection
occurs. They definitely will change when you save and restart your
image, but it's probably more important for you to know that they
also can change within your primitive at any time you call a function
that allocates a new object.

There is a special stack that is used to protect objects in this
case, see #pushRemappableOop: and #popRemappableOop and look
around at other plugins to find examples of how they are used.

> B) is there a prescribed way to archive information from a plugin
>    at "save image" time and later restore it at "load image" time?
>    My plugin can create an ascii string to store off state. I could
>    have a primitive save and restore the state... but how do I have these
>    primitives called. Is there an existing hook for something like this.

For one example of how you could do this, load OSProcessPlugin from
Squeak Map and look at the methods OSProcessPlugin>>stringFromCString:
and OSProcessPlugin>>primitiveVersionString.

Dave

David T. Lewis wrote:
> No, the oops can and will change any time a garbage collection
> occurs. They definitely will change when you save and restart your
> image, but it's probably more important for you to know that they
> also can change within your primitive at any time you call a function
> that allocates a new object.

Which reminds me - Tim what happened with the code that disables GC
during primitives? Did you ever do something with it? I'm still
convinced that this is a good thing to have so the plugin writers don't
have to worry about changing oops during primitives ;-)

Cheers,
   - Andreas