status of inbox Kernel-ct.1363
Locked
status of inbox Kernel-ct.1363
 
|
Hi all,
again a good and difficult to analyze contribution. We mostly send runSimulated:contextAtEachStep: to thisContext, except in one case in base image: MessageTally tallySends: [3.14159 printString] This is effectively broken in trunk, and repaired after applying Kernel-ct.1363. Before I merge this, additional advice is welcome, this is a tough subject, breaking the Debugger would be the last thing we want to do. |
Re: status of inbox Kernel-ct.1363
|
Hi Nicolas, ct.1363 depends on ct.1362, the latter being easier to review. Maybe Christoph (ct) can point us to the "request" he mentioned in the message in 1363. Yet, it looks like Eliot (indirectly) approved this already: http://forum.world.st/The-Inbox-Kernel-ct-1362-mcz-tp5124354.html ..? Or at least he planned to look at this. (Let's hope that the words "branch commit" do not hide more dependencies. Not sure what it means here.) Best, Marcel
|
Re: status of inbox Kernel-ct.1363
|
|
With the merge commit that would make 3 commits for a single method. My plan is to cherry pick the change on top of trunk with proper comment. With our tools, ownership is preserved anyway :) Le jeu. 15 avr. 2021 à 11:05, Marcel Taeumel <[hidden email]> a écrit :
|
Re: status of inbox Kernel-ct.1363
|
|
I mean authorship... Le jeu. 15 avr. 2021 à 11:50, Nicolas Cellier <[hidden email]> a écrit :
|
Re: status of inbox Kernel-ct.1363
|
|
I see only a minor problem with this version:
it breaks testRunSimulatedContextAtEachStep. This test did profit by polymorphism of asContext to use a Context instead of a Block(Closure). But Context does no understand asContextWithSender: Maybe more a problem of the test itself than of the proposed change. Le jeu. 15 avr. 2021 à 11:52, Nicolas Cellier <[hidden email]> a écrit : > > I mean authorship... > > Le jeu. 15 avr. 2021 à 11:50, Nicolas Cellier <[hidden email]> a écrit : >> >> With the merge commit that would make 3 commits for a single method. My plan is to cherry pick the change on top of trunk with proper comment. With our tools, ownership is preserved anyway :) >> >> Le jeu. 15 avr. 2021 à 11:05, Marcel Taeumel <[hidden email]> a écrit : >>> >>> Hi Nicolas, >>> >>> ct.1363 depends on ct.1362, the latter being easier to review. Maybe Christoph (ct) can point us to the "request" he mentioned in the message in 1363. Yet, it looks like Eliot (indirectly) approved this already: http://forum.world.st/The-Inbox-Kernel-ct-1362-mcz-tp5124354.html ..? Or at least he planned to look at this. >>> >>> (Let's hope that the words "branch commit" do not hide more dependencies. Not sure what it means here.) >>> >>> Best, >>> Marcel >>> >>> Am 15.04.2021 10:48:09 schrieb Nicolas Cellier <[hidden email]>: >>> >>> Hi all, >>> again a good and difficult to analyze contribution. >>> We mostly send runSimulated:contextAtEachStep: to thisContext, except >>> in one case in base image: >>> >>> MessageTally tallySends: [3.14159 printString] >>> >>> This is effectively broken in trunk, and repaired after applying Kernel-ct.1363. >>> Before I merge this, additional advice is welcome, this is a tough >>> subject, breaking the Debugger would be the last thing we want to do. >>> >>> |
Re: status of inbox Kernel-ct.1363
|
|
Hi all,
sorry for the late reply, this must somehow have escaped my attention.
Yes, Kernel-ct.1363 depends on Kernel-ct.1362 and (hopefully?) improves the understandability of the method. Eliot has requested this in the thread of Kernel-ct.1362.
> it breaks testRunSimulatedContextAtEachStep. True. Blocks should indeed be supported I think. Then we need indeed "current := aBlock asContext. current privSender: self." instead of #asContextWithSender:. Shall add a third version to
do this or does the merger want to do this? :-)
Best,
Christoph
Von: Squeak-dev <[hidden email]> im Auftrag von Nicolas Cellier <[hidden email]>
Gesendet: Montag, 19. April 2021 16:29:04 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] status of inbox Kernel-ct.1363 I see only a minor problem with this version:
it breaks testRunSimulatedContextAtEachStep. This test did profit by polymorphism of asContext to use a Context instead of a Block(Closure). But Context does no understand asContextWithSender: Maybe more a problem of the test itself than of the proposed change. Le jeu. 15 avr. 2021 à 11:52, Nicolas Cellier <[hidden email]> a écrit : > > I mean authorship... > > Le jeu. 15 avr. 2021 à 11:50, Nicolas Cellier <[hidden email]> a écrit : >> >> With the merge commit that would make 3 commits for a single method. My plan is to cherry pick the change on top of trunk with proper comment. With our tools, ownership is preserved anyway :) >> >> Le jeu. 15 avr. 2021 à 11:05, Marcel Taeumel <[hidden email]> a écrit : >>> >>> Hi Nicolas, >>> >>> ct.1363 depends on ct.1362, the latter being easier to review. Maybe Christoph (ct) can point us to the "request" he mentioned in the message in 1363. Yet, it looks like Eliot (indirectly) approved this already: http://forum.world.st/The-Inbox-Kernel-ct-1362-mcz-tp5124354.html ..? Or at least he planned to look at this. >>> >>> (Let's hope that the words "branch commit" do not hide more dependencies. Not sure what it means here.) >>> >>> Best, >>> Marcel >>> >>> Am 15.04.2021 10:48:09 schrieb Nicolas Cellier <[hidden email]>: >>> >>> Hi all, >>> again a good and difficult to analyze contribution. >>> We mostly send runSimulated:contextAtEachStep: to thisContext, except >>> in one case in base image: >>> >>> MessageTally tallySends: [3.14159 printString] >>> >>> This is effectively broken in trunk, and repaired after applying Kernel-ct.1363. >>> Before I merge this, additional advice is welcome, this is a tough >>> subject, breaking the Debugger would be the last thing we want to do. >>> >>>
Carpe Squeak!
|
Re: status of inbox Kernel-ct.1363
|
In reply to this post by Nicolas Cellier
Nicolas Cellier wrote
> I see only a minor problem with this version: > > it breaks testRunSimulatedContextAtEachStep. > This test did profit by polymorphism of asContext to use a Context > instead of a Block(Closure). > But Context does no understand asContextWithSender: Hi, how about adding Context >> asContextWithSender: aContext ^self privSender: aContext It would complement the `Context >> asContext` nicely :) ----- ^[^ Jaromir -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
^[^ Jaromir
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |