> -----Original Message----
> Stephen Pair wrote:
> > You need to store the frame size in order to know what size 
> context to 
> > recreate, then you need to add a way of instantiating an empty 
> > ContextPart of the appropriate size (large or small frame).  Add a 
> > method for primitive 71 to do this and be careful when 
> using it.  And 
> > of course, you'll also be serializing the home context, 
> receiver and 
> > all of the other instance variables (you have to be able to 
> serialize 
> > a MethodContext as well as a BlockContext).
> 
> And if you have references to outer vars - e.g. Transcript - 
> you have to serialize them, too... or a problem... ;-)

Yep, but that's no different from serializing any object (you have to
decide what to do with each object's slots)...and not only that, but you
need to be sure that if the block accesses any of the receiver's
instance variables that the shape of the receiver is the same before and
after serialization (otherwise you run the risk of crashing your image).
You could do a few check on the block and refuse to serialize it if it
looks to complex (i.e. if it does access any receiver vars or any
globals).

> Stephan
> 
> > 
> > Then you also need to be able to serialize compiled methods.  For 
> > this, you'll need to store the number of literals in 
> addition to the 
> > rest of its state and use #newMethod:header: when 
> materializing.  When 
> > bringing the all of this back into the image, your 
> BlockContext will 
> > be referring to a compiled method that doesn't exist in any method 
> > dictionary, but it will be perfectly useable in (for example) a 
> > SortedCollection.
> > 
> > Now, of course, it's debatable how appropriate it is to 
> have compiled 
> > methods lying around in your image that do not exist in any method 
> > dictionary.  You could also conceivably store information about the 
> > class and selector where the compiled method is installed 
> and try to 
> > match that up when materializing the block.  The class could be 
> > determined by looking at the reciever of the block's home 
> context, but 
> > unfortunately, I don't think the selector is readily available.
> > 
> > - Stephen
> > 
> > 
> >>-----Original Message-----
> >>From: squeak-dev-admin at lists.squeakfoundation.org
> >>[mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> >>Behalf Of Aaron J Reichow
> >>Sent: Thursday, October 24, 2002 10:33 AM
> >>To: squeak-dev at lists.squeakfoundation.org
> >>Subject: RE: Serilizing blocks
> >>
> >>
> >>On Thu, 24 Oct 2002, Stephen Pair wrote:
> >>
> >>
> >>>There's nothing that prevents you from serializing blocks.
> >>
> >>It's just
> >>
> >>>that it's a little more work.
> >>
> >>Well, no inherent problem to doing so. But, SmartRefStream
> >>won't let you do it, and because of that, there seems to be 
> >>problems putting blocks in to Magma and MinneStore.  Authors 
> >>of both have stated that blocks will be storable in their 
> >>databases when Squeak has real block closures.
> >>
> >>If it's possible, how can it be done?
> >>
> >>Regards,
> >>Aaron
> >>
> >>  Aaron Reichow  ::  UMD ACM Pres  ::
> >>http://www.d.umn.edu/~reic0024/ "one has a > moral 
> >>responsibility to disobey unjust laws"  :: m. l. king jr.
> >>
> >>
> >>
> >>
> > 
> > 
> > 
> > 
> 
> 
> -- 
> 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
> 
> 
>