On Tue, Jul 2, 2019 at 7:46 PM David T. Lewis <lewis at mail.msen.com> wrote:

> tl;dr Is there any reason NOT to move/merge Morphic-pre.1491 and
> Morphic-cmfcmf.1490 from inbox to trunk?
>

Yes, this:

> I have not tested these, ...

I haven't had a chance either Dave, but given they're both less than a week
old, I don't understand what your hurry is.

> but based on the well-documented commit notices
> for Morphic-pre.1491 and Morphic-cmfcmf.1490, both should be moved/merged
> to trunk.

No, commit notices are not a substitute for testing and peer review.


> Descending from Morphic-pre.1489, we have Morphic-pre.1490 that was moved
> from inbox to treated, and we also have Morphic-cmfcmf.1490 still in inbox.
> Parallel to that, we also have inbox Morphic-pre.1491, with inbox
> Morphic-ct.1492
> descended from it, and Morphic-ct.1492 depending on inbox Tools-ct.851 (and
> presumably also Compiler-ct.407 and Tests-ct.412.
>

Woops, I guess you missed Morphic-cmm.1489, which has been there since
May.  Interesting...



>
> I have not tested these, but based on the well-documented commit notices
> for Morphic-pre.1491 and Morphic-cmfcmf.1490, both should be moved/merged
> to trunk.
>
> The other inbox packages from Christoph Thiede appear to still be under
> discussion on the list.
>
> In the interest of reducing bit rot in the inbox, can anyone think of a
> good reason that Morphic-pre.1491 and Morphic-cmfcmf.1490 should not go
> into trunk now?
>

They won't rot if you test them first.  Otherwise if there's a problem you
could end up bringing cruft into the actual trunk, like your last trunk
commit, which had to be rolled back.

 - Chris


>
> Thanks,
> Dave
>
>
> On Sun, Jun 30, 2019 at 10:08:05AM +0000, commits at source.squeak.org wrote:
> > A new version of Morphic was added to project The Inbox:
> > http://source.squeak.org/inbox/Morphic-cmfcmf.1490.mcz
> >
> > ==================== Summary ====================
> >
> > Name: Morphic-cmfcmf.1490
> > Author: cmfcmf
> > Time: 30 June 2019, 12:04:13.370226 pm
> > UUID: ab2320d7-f8f4-df46-a786-ec28230e912c
> > Ancestors: Morphic-pre.1489
> >
> > When wrapping a Morph into a flex shell, first add the flex shell to the
> Morph's owner (and thus to the Morph's world) before making the Morph a
> submorph of the flex shell.
> > This avoids unnecessarily sending outOfWorld: to the Morph when adding
> it to the new flex shell (which doesn't have a world after creation) and
> intoWorld: when adding the flex shell to the Morph's owner right thereafter.
> >
> > =============== Diff against Morphic-pre.1489 ===============
> >
> > Item was changed:
> >   ----- Method: Morph>>addFlexShell (in category 'rotate scale and
> flex') -----
> >   addFlexShell
> >       "Wrap a rotating and scaling shell around this morph."
> >
> >       | oldHalo myWorld flexMorph anIndex |
> > -
> >       oldHalo:= self halo.
> >       myWorld := self world.
> >       self owner
> >               ifNil: [flexMorph := self newTransformationMorph asFlexOf:
> self]
> >               ifNotNil: [:myOwner |
> >                       anIndex := myOwner submorphIndexOf: self.
> > +                     "Avoid triggering outOfWorld: on self by first
> adding flexMorph to myOwner and only then making myself a submorph of
> flexMorph via asFlexOf:"
> > +                     flexMorph := self newTransformationMorph.
> > -                     flexMorph := self newTransformationMorph asFlexOf:
> self.
> >                       myOwner addMorph: flexMorph asElementNumber:
> anIndex.
> > +                     flexMorph asFlexOf: self.
> >                       myWorld ifNotNil: [myWorld
> startSteppingSubmorphsOf: flexMorph]].
> >       self transferStateToRenderer: flexMorph.
> >       oldHalo ifNotNil: [oldHalo setTarget: flexMorph].
> >
> >       ^ flexMorph!
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190703/34b3d7d3/attachment.html>