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! |
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
|
Free forum by Nabble | Edit this page |