Yes, you most likely right.
I did some preliminary hacking and got it to partly work, but I don't know
the real issues the image segment loading and converting entails.

Best,
Karl

On Wed, May 2, 2018 at 7:00 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Karl,
>
> On Mon, Apr 30, 2018 at 11:17 AM, karl ramberg <karlramberg at gmail.com>
> wrote:
>
>> This change set make the project ALMOST load in a 32 bit 6.0 Squeak image.
>> But there are some conversion issues I have not figured out.
>>
>
> Looking at this change:
>
> ObjectScanner>>scanFrom: aByteStream
> "Sieze control of the fileIn.  Put myself in as the context.  If any
> UniClasses (for just one instance) are defined, they will do it through me,
> and I will look for conflicting class names.  If so, install the old name
> as a class var of me, so the compile will work.  Tell my SmartRefStream
> about renaming the class."
>
> | valWithOddName47 scannerNamed53 chunkNamed117 |
> pvt3SmartRefStrm := SmartRefStream on: aByteStream.
> aByteStream ascii.
> [aByteStream atEnd] whileFalse:
> [aByteStream skipSeparators.
> valWithOddName47 := (aByteStream peekFor: $!)
> ifTrue: [chunkNamed117 := aByteStream nextChunk. "debug"
> chunkNamed117 = 'ImageSegment new'
> ifTrue:[ chunkNamed117 := 'NativeImageSegment new'].
> scannerNamed53 := Compiler evaluate: chunkNamed117
> for: self logged: false.
> scannerNamed53 class == self class
> ifTrue: ["I already am the scanner for this file"]
> ifFalse: [scannerNamed53 scanFrom: aByteStream]]
> ifFalse: [chunkNamed117 := aByteStream nextChunk.
> chunkNamed117 := self lookAhead: chunkNamed117.
> Compiler evaluate: chunkNamed117 for: self logged: true].
> aByteStream skipStyleChunk].
> ^ valWithOddName47
>
>
> you introduced the lines:
>
> chunkNamed117 = 'ImageSegment new'
> ifTrue:[ chunkNamed117 := 'NativeImageSegment new'].
>
> I think this is not going to work.  The issue being at this point we won't
> know whether we have a legacy image segment or a native image segment.  If
> you look at the hierarchy, there is
>     ImageSegment
>         NativeImageSegment
>         LegacyImageSegment
> and intentionally all the list vars are in ImageSegment so that when the
> scan of the actual binary data, embedded in the .pr file occurs, we can use
> something like (legacy ifTrue: [LegacyImageSegment] ifFalse:
> [NativeImageSegment]) adoptInstance: themageSegment to become the right
> kind of image segment.  So the way to proceed is to make ImageSegment
> intelligent enough to get you as far as the point where the kind of image
> segment, V3 or Spur, is apparent, and then make the switch.
>
> HTH
>
>
>>
>> NOTE: Image will probably crash. USE WITH CARE
>>
>>
>> Best,
>> Karl
>>
>> On Mon, Apr 30, 2018 at 3:37 PM, H. Hirzel <hannes.hirzel at gmail.com>
>> wrote:
>>
>>> Unfortunately the dynamic essay MorphLayoutArticle.019.pr did not load
>>> in a fairly recent Squeak 6.0a trunk image.
>>>
>>> an OrderedCollection(ImageSegment(Object)>>doesNotUnderstand:
>>> #scanFrom: ObjectScanner>>scanFrom: [] in [] in
>>> MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing:
>>> BlockClosure>>on:do: [] in
>>> MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: []
>>> in [] in MorphicUIManager>>displayProgress:at:from:to:during:
>>> BlockClosure>>on:do: [] in
>>> MorphicUIManager>>displayProgress:at:from:to:during:
>>> BlockClosure>>ensure:
>>> MorphicUIManager>>displayProgress:at:from:to:during:
>>> ProgressInitiationException>>defaultResumeValue
>>> ProgressInitiationException(Exception)>>resume
>>> ProgressInitiationException>>defaultAction
>>> UndefinedObject>>handleSignal: Context>>handleSignal:
>>> Context>>handleSignal: Context>>handleSignal:
>>> ProgressInitiationException(Exception)>>signal
>>> ProgressInitiationException>>display:at:from:to:during:
>>> ProgressInitiationException class>>display:at:from:to:during:
>>> ByteString(String)>>displayProgressAt:from:to:during:
>>> ByteString(String)>>displayProgressFrom:to:during:
>>> MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing:
>>> MultiByteBinaryOrTextStream(PositionableStream)>>fileIn
>>> MultiByteBinaryOrTextStream>>fileInProject
>>> MultiByteBinaryOrTextStream>>fileInObjectAndCodeForProject [] in [] in
>>> ProjectLoading class>>fileInName:archive:morphOrList:
>>> BlockClosure>>on:do: [] in ProjectLoading
>>> class>>fileInName:archive:morphOrList: BlockClosure>>ensure:
>>> ProjectLoading class>>fileInName:archive:morphOrList: ProjectLoading
>>> class>>openName:stream:fromDirectory:withProjectView:clearOriginFlag:
>>> ProjectLoading class>>openName:stream:fromDirectory:withProjectView:
>>> [] in ProjectLoading class>>openOn: BlockClosure>>on:do: [] in
>>> ByteString(String)>>displaySequentialProgress: [] in [] in
>>> MorphicUIManager>>displayProgress:at:from:to:during:
>>> BlockClosure>>on:do: [] in
>>> MorphicUIManager>>displayProgress:at:from:to:during:
>>> BlockClosure>>ensure:
>>> MorphicUIManager>>displayProgress:at:from:to:during:
>>> ProgressInitiationException>>defaultResumeValue
>>> ProgressInitiationException(Exception)>>resume
>>> ProgressInitiationException>>defaultAction
>>> UndefinedObject>>handleSignal:
>>> ProgressInitiationException(Exception)>>signal
>>> ProgressInitiationException>>display:at:from:to:during:
>>> ProgressInitiationException class>>display:at:from:to:during:
>>> ProgressInitiationException class>>display:from:to:during:
>>> ByteString(String)>>displaySequentialProgress: ProjectLoading
>>> class>>openOn: [] in ExternalDropHandler class>>defaultProjectHandler
>>> ExternalDropHandler>>handle:in:dropEvent:
>>> PasteUpMorph>>handleDroppedItem:event: [] in PasteUpMorph>>dropFiles:
>>> BlockClosure>>ensure: PasteUpMorph>>dropFiles:
>>> PasteUpMorph(Morph)>>handleDropFiles: DropFilesEvent>>sentTo:
>>> PasteUpMorph(Morph)>>handleEvent:
>>> MorphicEventDispatcher>>dispatchEvent:withHandler:withMorph:
>>> MorphicEventDispatcher>>dispatchDefault:with:
>>> MorphicEventDispatcher>>dispatchEvent:with:
>>> PasteUpMorph(Morph)>>processEvent:using: [] in
>>> PasteUpMorph>>processEvent:using: BlockClosure>>ensure:
>>> PasteUpMorph>>processEvent:using: PasteUpMorph(Morph)>>processEvent:
>>> [] in [] in [] in HandMorph>>sendEvent:focus:clear:
>>> BlockClosure>>ensure:
>>> DropFilesEvent(MorphicEvent)>>becomeActiveDuring: [] in [] in
>>> HandMorph>>sendEvent:focus:clear: BlockClosure>>ensure:
>>> HandMorph>>becomeActiveDuring: [] in HandMorph>>sendEvent:focus:clear:
>>> BlockClosure>>ensure: PasteUpMorph>>becomeActiveDuring:
>>> HandMorph>>sendEvent:focus:clear: HandMorph>>sendEvent:focus:
>>> HandMorph>>handleEvent: HandMorph>>processEvents [] in
>>> WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>>do:
>>> WorldState>>handsDo: WorldState>>doOneCycleNowFor:
>>> WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in
>>> MorphicProject>>spawnNewProcess [] in BlockClosure>>newProcess)
>>>
>>> On 4/30/18, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>>> > Hi Tim
>>> >
>>> > Implementing your suggestion [1] worked to make
>>> > MorphLayoutArticle.019.pr load into
>>> > Squeak 3.8.1, see screen shot.
>>> >
>>> > What I aiming at next  at is to load it into Squeak 6.0a trunk. I
>>> > assume this should be possible quite easily because of the
>>> > enhancements done last year [2][3].
>>> >
>>> > Regards
>>> > Hannes
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > [1] Extend #initKnownRenames
>>> >
>>> > SmartRefStream>>initKnownRenames
>>> >       renamed
>>> >           at: #AlansTextPlusMorph put: #TextPlusMorph;
>>> >               at: #FlasherMorph put: #Flasher;
>>> >               yourself
>>> >
>>> > made MorphLayoutArticle.019.pr to load.
>>> >
>>> >
>>> > [2] 6502 format
>>> > http://wiki.squeak.org/squeak/6502
>>> >
>>> > ImageFormat of the interpreter Virtual Machine.
>>> > May be loaded transparently into Squeak 6.0a through the help of
>>> > LegacyImageSegment.
>>> >
>>> > [3]
>>> > http://wiki.squeak.org/squeak/6579
>>> > LegacyImageSegment
>>> > A new class introduced in March 2017 in Squeak 6.0a to enable the
>>> > loading of the older 6502 image segment format type .
>>> >
>>> > More see Smalltalk imageFormatVersion  http://wiki.squeak.org/squeak/
>>> 873
>>> >
>>> >
>>> > On 4/30/18, Tm Jhnsn <digit at sonic.net> wrote:
>>> >> Hi Hannes,
>>> >>
>>> >> In 5.1 there is SmartRefStream>>#initKnownRenames which includes:
>>> >>
>>> >> at: #AlansTextPlusMorph put: #TextPlusMorph;
>>> >>
>>> >> HTH,
>>> >> Tim
>>> >>
>>> >>
>>> >> On 4/30/2018 7:33 AM, H. Hirzel wrote:
>>> >>> Hi Bob
>>> >>>
>>> >>> It still loads fine in Squeak 3.2. Thank you.
>>> >>>
>>> >>> In Squeak 3.8.1 the SmartRefStream needs a new class for
>>> >>>
>>> >>>       AlansTextPlusMorph
>>> >>>
>>> >>>
>>> >>> SmartRefStream>>
>>> >>> alansTextPlusMorphbosfcebbmsopssrsggshtt0
>>> >>>
>>> >>>     ^ PutNewClassHere
>>> >>>
>>> >>>
>>> >>> Any suggestions what I should put as a new class?
>>> >>>
>>> >>> Regards
>>> >>> Hannes
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 4/30/18, Bob Arning <arning315 at comcast.net> wrote:
>>> >>>> Here is the latest one I have. It loaded fine in 3.2.
>>> >>>>
>>> >>>>
>>> >>>> On 4/29/18 10:20 PM, H. Hirzel wrote:
>>> >>>>> Hello
>>> >>>>>
>>> >>>>> Is there a backup-copy/mirror available of the
>>> >>>>>
>>> >>>>>                   MorphLayoutArticle
>>> >>>>>
>>> >>>>> project which was on Bob's SuperSwiki? [1]
>>> >>>>>
>>> >>>>> Regards
>>> >>>>> Hannes
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> ----------------------------------
>>> >>>>> [1]
>>> >>>>> http://wiki.squeak.org/squeak/2141
>>> >>>>>
>>> >>>>> How to lay out submorphs
>>> >>>>>
>>> >>>>> Please read the excellent dynamic essay project MorphLayoutArticle
>>> >>>>> (broken link) on Bob's SuperSwiki.
>>> >>>>>
>>> >>>>> Every Morph now has the capability to layout it's submorphs.
>>> >>>>> (Previously, only the AlignmentMorph could implement layout
>>> policies.
>>> >>>>> AlignmentMorph is still available because of compatibility reasons
>>> and
>>> >>>>> some utility methods it implements.
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>>
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180502/407f3f58/attachment.html>