Also note that after some time the project was no longer frozen and it
was possible to exit the project.

On 6/28/18, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> 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: MorphicLayoutArticle_Screenshot_2018-06-28.png
Type: image/png
Size: 113404 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180628/5dbca6c4/attachment-0001.png>