[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squeak-dev
Subject:    Re: [squeak-dev] The Trunk: Monticello-dtl.674.mcz
From:       "David T. Lewis" <lewis () mail ! msen ! com>
Date:       2017-12-29 1:28:23
Message-ID: 20171229012823.GA28547 () shell ! msen ! com
[Download RAW message or body]

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@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


["DebuggerOnMCStReader.png" (image/png)]
[Attachment #4 (text/plain)]




[prev in list] [next in list] [prev in thread] [next in thread]