[squeak-dev] Dynamic essay project MorphLayoutArticle on Bob's SuperSwiki?

Eliot Miranda eliot.miranda at gmail.com
Thu May 3 03:25:47 UTC 2018


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 <lewis at mail.msen.com> 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 <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
>



-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180502/5bcbd774/attachment.html>


More information about the Squeak-dev mailing list