Chris Muller wrote:
> Hmm, well your good question sent me on a big chase that led me to
> enlightenment, thank you.  The short answer is "no".  The long answer
> follows.

I'm actually slightly relieved because it means I didn't miss anything 
stupidly simple ;-) I spent a *lot* of brainpower on this problem in 
particular and I found it to be a really hard one.

> To my surprise and disappointment, it appears support for Blocks is not
> as robust as I had thought.  It appears that blocks referencing inst
> vars or "self" cannot be valued after rematerializing.  Blocks that
> refer merely to their own arguments or globals or class-variables _can_
> be valued after rematerializing.

Right. This is the classic situation because args are bound as offsets 
to the home context (which is usually serialized along with the block) 
and class vars are bound to actual objects (part of the literal frame of 
the compiled method).

> It looks real close in the fully-expanded explorer, but "self value"
> printed 26258680 in the Transcript instead of "hello world".  What
> the..?  Debugging into it shows: 
> 
>   DoIt
> 	^ [Transcript cr; show: unknown0]
> 
> So the inst var did not get "hooked up" or something.

I think you're just getting lucky. My example (see comment in 
ClassDescription>>updateInstancesFrom:) which illustrates the same 
problem crashes fairly reliably.

> I've never had a need to store complex blocks, since they exist in the
> context of a method, and methods are typically stored in the
> code-maangement system (i.e., change sets or Monticello) then it seems
> storing Blocks -> MethodContexts -> CompiledMethods could lead to
> serious confusion anyway.  e.g., you could make a change to the block
> in the code and but persisted block would still be performing the old
> code..  It would seem better to use an alternative like MessageSends
> that logically calls the most up-to-date methods.

Yes. Alternatively, if we had a "literal object/class" syntax this would 
be very simple, too.

> Whew!  Sorry for this deluge, but if anyone has any suggestions for
> improving this I would be grateful.

Heh. I know *exactly* how you are feeling. I think the cleanest solution 
would be if Magma would simply detect any blocks that try to access 
iVars and raise an error if you try to store one. If this is done early 
on, people can compensate by using accessor messages (which is usually 
simple). But this may not be possible if there is other people's code 
involved.

Alternatively, you could store the iVar shape (at the very least the 
minimum number of iVars so that you don't crash the VM when executing 
the block) and raise an error if you read in a block which attempts to 
access such iVars.

Cheers,
   - Andreas