On Thu, Dec 28, 2017 at 01:17:18AM -0500, David T. Lewis wrote:
> Hi Eliot,
> 
> On Wed, Dec 27, 2017 at 09:41:49PM -0800, Eliot Miranda wrote:
> > Hi David,
> > 
> > > On Dec 27, 2017, at 9:37 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > > 
> > > Hi David,
> > > 
> > >    compiledCodeClassNames  is a mistake.  There are no restrictions on the number of subclasses of CompiledCode.  What tells us if a class is that if code is its format which is expressed in the type information in its class definition, /not/ its name.
> > > 
> > > _,,,^..^,,,_ (phone)
> > 
> > If your intent is to ease moving Code between Spur and prior versions then
> > a) provide some special case for importing prior code, but do not impose that restriction on the current versions. 
> > 
> > b) Both the prior version and Spur express the compiled codeness of a class in the class's format, with the name being merely incidental.  One can back port the work to express that through the class definition.
> > 
> 
> The failure occurs when reading an MCZ into a V3 image, when MCStReader>>classDefinitionFrom: 
> creates a new MCClassDefinition from the information provided in a PseudoClass instance. The
> PseudoClass does not contain the necessary information about compiled codeness.
> 
> This code path does not seem to be followed in a Spur image, I'm not entirely sure why.
> 
> > Restricting the code loader by recognizing specific class names puts toad blicks in the way of future code.  It is worse than isKindOf:
> >
> 
> I agree but don't have a better solution to offer. It would be possible to
> use to the actual class to which the PseudoClass refers, but I fear this
> would not work in the case of a MCClassDefinition for a class that does not
> yet exist in the image.
> 

Here is an example of the failure: When reading an MCZ (Browse button on
an MCFileRepositoryInspector), the reader is loading definitions from the
snapshot/source.st member of the Zip archive. The MCMczReader has failed
(for whatever reason) to load the definitions from snapshot.bin, and has
fallen back on extracting the definitions from snapshot/source.st.

When it reaches a class definition in the source.st stream, the MCStReader
creates an MCClassDefinition. At some point in this process it needs a way
to handle the special case of a class of type #bytes that really should
be #compiledMethod instead.

I put a halt into MCStReader>>classDefinitionFrom: to illustrate where
this is happening, see attached debugger picture.

For actual classes, the typeOfClass is derived from instSpec, which is
derived from the class format number. But no such information is available
from the PseudoClass representation of the class definition that was loaded
from snapshot/source.st.

I'm sure there must be some better way to handle this, but I don't know
how to do it.

Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DebuggerOnMCStReader.png
Type: image/png
Size: 112826 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171228/4c8820f4/attachment-0001.png>