Update / Retest:

Page 1183: Etoys ProjectLoading tests in 5.2
http://wiki.squeak.org/squeak/1183

lists 10 projects (*.pr files) from SqueakLand which load fine! This
is due to recent work on project loading.

The file  MorphLayoutArticle.pr still gives problems.

Loading MorphLayoutArticle.pr (Test 11 on page 1183) brings up with an
emergency evaluator. After reverting the last method with it the
project shows up (see screen shot) but the project is frozen.

An earlier analysis by Karl shows that the following morphs are involved

Player5 -- 1 instance, named yellowRectangle
Player6067 -- 1 instance, named greenRect
Player6466 -- 1 instance, named Parent1
Player65 -- 1 instance, named Parent2
Player59 -- 1 instance, named yellowRect
Player8 -- 1 instance, named redRect

Further analysis is needed.

--Hannes







On 5/6/18, karl ramberg <karlramberg at gmail.com> wrote:
> The drawing error was because of wrong color depth. When I change to 16 bit
> before loading project it comes up fine :-)
>
> Now I have to look at the code that mangles the GeeMailMorph so badly
>
> Best,
> Karl
>
>
> On Thu, May 3, 2018 at 9:12 PM, karl ramberg <karlramberg at gmail.com> wrote:
>
>> I have added the stuff I had in the change set.
>> I downloaded the latest VM
>>   squeak.cog.spur_win64x64_201805030152.zip
>> <https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur_win64x64_201805030152.zip>
>>
>> I still get a drawing error with the opened project when loaded.
>> It's like resolution is screwed and screen is displayed in 4 quadrants.
>> See attached screen shot.
>> I'm on windows.
>>
>> Best,
>> Karl
>>
>> On Thu, May 3, 2018 at 4:48 AM, 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.
>>>>
>>>> NOTE: Image will probably crash. USE WITH CARE
>>>>
>>>
>>> Using all of your change set except ObjectScanner>>#scanFrom:, and the
>>> changes I committed to trunk today I was able to load
>>> MorphLayoutArticle.019.pr into a 64-bit Spur image (thanks Bert!!).  The
>>> image locks up due to a drawing error in
>>> GeeMailMorph(ScrollPane)>>innerBounds
>>> where UndefinedObject doesn't understand #-.  So things are close.  May
>>> I
>>> suggest that you add RenamedSourceClassReader in System-Object Storage,
>>> and
>>> move the other segment-specific scanning methods
>>> (ClassCategoryReader>>#scanFromNoCompile:[forSegment:]) too?
>>>
>>> This is cool :-)
>>>
>>>
>>> BTW, there was a compiler bug with the native image segment loading code
>>> in 64-bit Spur.  This is fixed if you grab the last 64-bit Spur VMs from
>>> Travis.
>>>
>>>
>>>>
>>>> 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 --------------
A non-text attachment was scrubbed...
Name: TestResultOfLoading_MorphicLayout.pr_Screenshot_2018-06-28.png
Type: image/png
Size: 49399 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180628/96675b4d/attachment-0001.png>