The Inbox: System-ct.1149.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: System-ct.1149.mcz

commits-2
Christoph Thiede uploaded a new version of System to project The Inbox:
http://source.squeak.org/inbox/System-ct.1149.mcz

==================== Summary ====================

Name: System-ct.1149
Author: ct
Time: 29 March 2020, 1:35:58.40756 pm
UUID: 1bf6e87f-fc73-7747-af4d-df3e339a0627
Ancestors: System-ul.1148

Proposal: Add some convenience methods for debugging blocks. See examples in #debugFromContextThat:title:.

While I know that we already talked about the sense of convenience methods that are not actually used in the base system, I think that these ones actually add value and should be used in the base system. We are experiencing an ascending number of methods that implement "debugging of a specific action", such as "debug action" and "debug get-list invocation" in Morphic, or "debug test" in SUnit (see SUnit-ct.125). As they have little duplication at the moment, it is also hard to make them more convenient: For example, if you try to debug a test case that overrides #performTest in a way that it does not actually invoke the test selector; or for another example, if you try to debug the action of a morphic button that we do not support properly at the moment (e. g. the buttons in a UserDialogBox), the current approach opens a debugger on a terminated process on #newProcess. If we follow this suggestion to refactor that behavior into one place, this will allow us to be a bit smarter and mo
 re convenient, as you can see in the edge case in #debugFromContextThat:title:. My follow-up proposal would thus be to call this convenience methods from all implementors of #debugAction & Co. This commit also tries to solve the issue mentioned in [1].

However, I'm not sure whether BlockClosure is the optimal place for this. I am open for your suggestions to move this somewhere else, for example into Debugger, Process or ToolSet.

[1] http://forum.world.st/The-Inbox-Morphic-ct-1590-mcz-tp5106996p5107059.html

=============== Diff against System-ul.1148 ===============

Item was added:
+ ----- Method: BlockClosure>>debug (in category '*System-debugging') -----
+ debug
+
+ ^ self debugWithTitle: nil!

Item was added:
+ ----- Method: BlockClosure>>debugFromContextThat: (in category '*System-debugging') -----
+ debugFromContextThat: contextBlock
+
+ ^ self debugFromContextThat: contextBlock title: nil!

Item was added:
+ ----- Method: BlockClosure>>debugFromContextThat:title: (in category '*System-debugging') -----
+ debugFromContextThat: contextBlock title: title
+ "Evaluate the receiver on a new process (synchronously). Once the contextBlock criterium is satisfied, open a debugger on that process. If the criterium is never satisfied until the process terminates, offer the user to debug the receiver again without waiting for contextBlock again.
+
+ [self halt] debug.
+ [15 factorial] debugWithTitle: 'Fun with Math!!'.
+ [self inform: #foo] debugFromContextThat: [:ctxt | ctxt receiver isMorph] title: 'Debug dialog invocation'.
+ [15 factorial] debugFromContextThat: [:ctxt | ctxt selector = #+]."
+
+ | process |
+ process := self newProcess.
+ process runUntil: contextBlock.
+ process isTerminated ifTrue: [
+ ^ (self confirm: 'Did not reach the desired piece of code.\Would you like to debug the whole process again?' withCRs translated)
+ ifTrue: [self debugWithTitle: title]
+ ifFalse: [self]].
+ ^ process debugWithTitle: title!

Item was added:
+ ----- Method: BlockClosure>>debugWithTitle: (in category '*System-debugging') -----
+ debugWithTitle: title
+
+ ^ self
+ debugFromContextThat: [:ctx | ctx closure == self]
+ title: title!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-ct.1149.mcz

marcel.taeumel
Hi Christoph, hi all.

I would like to continue the discussion about this proposal based on the current Trunk #20404 and http://forum.world.st/The-Trunk-Morphic-mt-1751-mcz-tp5128614p5128621.html.

At the moment, we have a "#...ContextThat:" lookup in Processor(Scheduler) to find the signaler context of an exception. This proposal includes such a lookup for manually constructed and (explicitly) simulated processes via Process.

As a client, I think that Process class >> #forBlock:runUntil: is sufficient. Especially that check for #isTerminated with an interactive notice might not be wanted in all cases. Hmm...

Best,
Marcel



Am 29.03.2020 14:36:22 schrieb [hidden email] <[hidden email]>:

Christoph Thiede uploaded a new version of System to project The Inbox:
http://source.squeak.org/inbox/System-ct.1149.mcz

==================== Summary ====================

Name: System-ct.1149
Author: ct
Time: 29 March 2020, 1:35:58.40756 pm
UUID: 1bf6e87f-fc73-7747-af4d-df3e339a0627
Ancestors: System-ul.1148

Proposal: Add some convenience methods for debugging blocks. See examples in #debugFromContextThat:title:.

While I know that we already talked about the sense of convenience methods that are not actually used in the base system, I think that these ones actually add value and should be used in the base system. We are experiencing an ascending number of methods that implement "debugging of a specific action", such as "debug action" and "debug get-list invocation" in Morphic, or "debug test" in SUnit (see SUnit-ct.125). As they have little duplication at the moment, it is also hard to make them more convenient: For example, if you try to debug a test case that overrides #performTest in a way that it does not actually invoke the test selector; or for another example, if you try to debug the action of a morphic button that we do not support properly at the moment (e. g. the buttons in a UserDialogBox), the current approach opens a debugger on a terminated process on #newProcess. If we follow this suggestion to refactor that behavior into one place, this will allow us to be a bit smarter and mo
re convenient, as you can see in the edge case in #debugFromContextThat:title:. My follow-up proposal would thus be to call this convenience methods from all implementors of #debugAction & Co. This commit also tries to solve the issue mentioned in [1].

However, I'm not sure whether BlockClosure is the optimal place for this. I am open for your suggestions to move this somewhere else, for example into Debugger, Process or ToolSet.

[1] http://forum.world.st/The-Inbox-Morphic-ct-1590-mcz-tp5106996p5107059.html

=============== Diff against System-ul.1148 ===============

Item was added:
+ ----- Method: BlockClosure>>debug (in category '*System-debugging') -----
+ debug
+
+ ^ self debugWithTitle: nil!

Item was added:
+ ----- Method: BlockClosure>>debugFromContextThat: (in category '*System-debugging') -----
+ debugFromContextThat: contextBlock
+
+ ^ self debugFromContextThat: contextBlock title: nil!

Item was added:
+ ----- Method: BlockClosure>>debugFromContextThat:title: (in category '*System-debugging') -----
+ debugFromContextThat: contextBlock title: title
+ "Evaluate the receiver on a new process (synchronously). Once the contextBlock criterium is satisfied, open a debugger on that process. If the criterium is never satisfied until the process terminates, offer the user to debug the receiver again without waiting for contextBlock again.
+
+ [self halt] debug.
+ [15 factorial] debugWithTitle: 'Fun with Math!!'.
+ [self inform: #foo] debugFromContextThat: [:ctxt | ctxt receiver isMorph] title: 'Debug dialog invocation'.
+ [15 factorial] debugFromContextThat: [:ctxt | ctxt selector = #+]."
+
+ | process |
+ process := self newProcess.
+ process runUntil: contextBlock.
+ process isTerminated ifTrue: [
+ ^ (self confirm: 'Did not reach the desired piece of code.\Would you like to debug the whole process again?' withCRs translated)
+ ifTrue: [self debugWithTitle: title]
+ ifFalse: [self]].
+ ^ process debugWithTitle: title!

Item was added:
+ ----- Method: BlockClosure>>debugWithTitle: (in category '*System-debugging') -----
+ debugWithTitle: title
+
+ ^ self
+ debugFromContextThat: [:ctx | ctx closure == self]
+ title: title!