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! |
tl;dr Is there any reason NOT to move/merge Morphic-pre.1491 and
Morphic-cmfcmf.1490 from inbox to trunk? 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. 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? Thanks, Dave On Sun, Jun 30, 2019 at 10:08:05AM +0000, [hidden email] 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! > > |
+1 for moving both Morphic-pre.1491 and Morphic-cmfcmf.1490 to trunk. Best, Marcel
|
In reply to this post by David T. Lewis
On Tue, Jul 2, 2019 at 7:46 PM David T. Lewis <[hidden email]> wrote: tl;dr Is there any reason NOT to move/merge Morphic-pre.1491 and 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.
Woops, I guess you missed Morphic-cmm.1489, which has been there since May. Interesting...
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
|
Hi Chris, I tested both Morphic-pre.1491 and Morphic-cmfcmf.1490. They are fine. That's why I gave "+1" in my previous answer. :-) They can both go into Trunk. Best, Marcel
|
On Thu, Jul 4, 2019 at 1:13 AM Marcel Taeumel <[hidden email]> wrote:
> > Hi Chris, > > I tested both Morphic-pre.1491 and Morphic-cmfcmf.1490. They are fine. That's why I gave "+1" in my previous answer. :-) They can both go into Trunk. Okay. My comments were not about the content of those submissions, just the suggestion of moving them to trunk without testing. Thanks, Chris > > Best, > Marcel > > Am 03.07.2019 23:37:18 schrieb Chris Muller <[hidden email]>: > > On Tue, Jul 2, 2019 at 7:46 PM David T. Lewis <[hidden email]> 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, [hidden email] 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! >> > >> > >> |
Free forum by Nabble | Edit this page |