Dynamic essay project MorphLayoutArticle on Bob's SuperSwiki?

Hi Karl,

On Mon, Apr 30, 2018 at 11:17 AM, karl ramberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

Hi Eliot,

Marcel had developed a way for a Morphic project to drop into a debugger
in MVC, which worked when the MVC project (or other non-Morphic project)
was a parent of the Morphic project. This is good, but it required that
you, as a Morphic developer, think ahead to open a non-Morphic project
and then work in a Morphic project that is a child of that project.

The changes discussed in the thread below allow the emergency evaluator
to first look for a non-Morphic project (usually MVC) that is a parent
of the current project. If found, use that to host the debugger, otherwise
search all known projects for any project that is not Morphic and use
that to host the debugger, and if all that fails, drop into the traditional
emergency evaluator.

For your case, try just opening an MVC project anywhere in your project
hierarchy. Assuming the mechanism below works as advertised, you will
be able to work in a Morphic project and have it drop into that MVC
debugger when things go wrong. If the error is such that it breaks
MVC also, then you will then find yourself back in the old emergency
evaluator.

There are no preferences involved, just make sure there is some MVC
project opened in your image, and hopefully it will just work.

Dave

On Wed, May 02, 2018 at 08:25:47PM -0700, Eliot Miranda wrote:
> Hi David,
>
> see below on the thread about loading od projects.  Currently the system
> freezes with drawing errors.  I'm reminded that you were developing changes
> to exit a project on drawing errors.  That would make debugging a lot
> easier.  Specifically I mean the following message.  But I can't find a
> preference that causes drawing errors to exit the project.  Did I
> misunderstand?  If you have such code could you post it here?  If not, how
> much effort would it be to get drawing errors to exit a sub-project if a
> suitable preference were set?
>
>
> On Thu, Dec 14, 2017 at 7:00 PM, David T. Lewis <[hidden email]> wrote:
>
> > Marcel,
> >
> > Much better, thanks :-)
> >
> > After moving the EmergencyRecoveryRequested recursion guard reset from
> > #finalExitActions: to #enter:revert:saveForRevert: the Morphic and ST80
> > dependencies are gone. The end result is a total of three changed methods
> > in Project, plus the new EmergencyRecoveryRequested class variable.
> >
> > Since they are no longer needed, I moved the Morphic and ST80 parts from
> > inbox to treated inbox. All of the remaining changes are in the inbox
> > as System-dtl.985.
> >
> > To summarize the changes: The original behavior of seaching for a parent
> > MVCProject or MorphicProject to host the emergency evaluator works as
> > originally designed. If no project is found, then search for any suitable
> > project elsewhere in the project hierarchy. If that is not found then
> > fall back on the traditional emergency evaluator. If error handling fails
> > in the project for emergency evaluation, the also fall back on the
> > traditional emergency evaluator.
> >
> > I expect this to work with other kinds of Project such as
> > SqueakShellProject
> > or EtoysProject, although I have not tested these so well.
> >
> > Dave
> >
> >
> > On Thu, Dec 14, 2017 at 12:50:06PM -0500, David T. Lewis wrote:
> > > Hi Marcel,
> > >
> > > Oh - now I understand what you mean (d'oh!). You are right. I will follow
> > > up on your suggestion of putting it in #enter:revert:saveForRevert: (but
> > > maybe not today).
> > >
> > > Thanks,
> > > Dave
> > >
> > >
> > > > Hi Dave,
> > > >
> > > > #finalExitActions: should not contain such critical code. That's what I
> > > > meant. :) I see it more like a "Template Method" that does nothing
> > serious
> > > > by default.
> > > >
> > > > Maybe we could reset????EmergencyRecoveryRequested in
> > > > #enter:revert:saveForRevert: so that #finalExitActions: becomes free
> > > > again. :-)
> > > >
> > > > Best,
> > > > Marcel
> >
>
>
>
> On Wed, May 2, 2018 at 7:48 PM, Eliot Miranda <[hidden email]>
> wrote:
>
> > Hi Karl,
> >
> > On Mon, Apr 30, 2018 at 11:17 AM, karl ramberg <[hidden email]>
> > 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 <[hidden email]>
> >> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot

Hi Karl,

On Mon, Apr 30, 2018 at 11:17 AM, karl ramberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

I have added the stuff I had in the change set. 

I downloaded the latest VM   

  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 <[hidden email]> wrote:

Hi Karl,

On Mon, Apr 30, 2018 at 11:17 AM, karl ramberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

Hello Karl

Good to read about the progress which was possible in a short time.

Where in the code do you set the color depth?

Regards
Hannes

On 5/6/18, karl ramberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>>
>>> Hi Karl,
>>>
>>> On Mon, Apr 30, 2018 at 11:17 AM, karl ramberg <[hidden email]>
>>> 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 <[hidden email]>
>>>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>
>>>
>>>
>>>
>>
>