[squeak-dev] The Inbox: Morphic-ct.1610.mcz

Marcel Taeumel marcel.taeumel at hpi.de
Tue Dec 17 11:22:16 UTC 2019


I just documented my intentions and plans in Tools-mt.925.

Best,
Marcel
Am 16.12.2019 19:39:07 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi Marcel, thanks for your reply!

> Agreed. The current state is only intermediate to improve the previous implementation, which mixed up state between MVC and Morphic. Next step would be to make MorphicDebugger and MVCDebugger "empty" again. :-) At least we can track progress now through those subclasses. Baby steps, you know.

That sounds great! In face of "baby steps," maybe we should document this progress in the class comments? Minimizing the risks that someone relies on the existence of these classes ...

> Hmm... the debugger has a tricky role in the system. Debugger invocation should only concern ToolSet (first dispatch after unhandled exception) and Project (for framework-based process handling), not the UIManager. We can talk about this more, if you are interested in this topic. :-)

Good to know: Project, not UIManager. Makes sense :) I will keep it mind - currently, I'm still working on the Inspectors, but this might be a potential project after Christmas :-)

Best,
Christoph
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 16. Dezember 2019 19:30:34
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1610.mcz
 
Hi Christoph.

> I would generally like to get rid of the separate Debugger subclasses.

Agreed. The current state is only intermediate to improve the previous implementation, which mixed up state between MVC and Morphic. Next step would be to make MorphicDebugger and MVCDebugger "empty" again. :-) At least we can track progress now through those subclasses. Baby steps, you know.

> I think it could be good to revise the method composition here.

Make sure that all DebuggerTests pass. Add new ones. I still need to document more thoughts on this because I think the reasons for the current architecture are not clear enough to other developers. We can talk about this, if you want to brainstorm on the topic. Keeping the image responsive is really tricky. In the past, the Emergency Evaluator (before 4.6) popped up way too often. We are in a better state now, I think. But there is still more to do.

> And maybe outsource some UI specific things to the current UIManager ...

Hmm... the debugger has a tricky role in the system. Debugger invocation should only concern ToolSet (first dispatch after unhandled exception) and Project (for framework-based process handling), not the UIManager. We can talk about this more, if you are interested in this topic. :-)

Best,
Marcel





Am 16.12.2019 15:01:16 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi Marcel!

2.: As mentioned in the past, I would generally like to get rid of the separate Debugger subclasses (keep dimension of inheritance free for real features instead of implementation issues).
All the #openOn:context:label:contents:fullView: implementations share some duplication:


I think it could be good to revise the method composition here. Ideally, we could have a separate method that only performs the opening itself, and we could wrap it into #setErrorRecursionFlagDuring: by the superclass.
And maybe outsource some UI specific things to the current UIManager ...

Best,
Christoph
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 16. Dezember 2019 14:32:05
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1610.mcz
 
Hi Christoph,

hmm... I would rather not spread that recursion flag to outside Debugger class >> #openOn:... I will look into it. Thanks for those two bug reports that cause endless debuggers:

1. Generator step-over
Generator on: [:g | g yield: #foo].

2. Error in a debugger's build-with method.

Best,
Marcel
Am 16.12.2019 11:53:21 schrieb commits at source.squeak.org <commits at source.squeak.org>:
A new version of Morphic was added to project The Inbox:
http://source.squeak.org/inbox/Morphic-ct.1610.mcz

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

Name: Morphic-ct.1610
Author: ct
Time: 16 December 2019, 11:52:56.435097 am
UUID: 37c022c9-73a9-0648-ba0a-2b1fe98f86ad
Ancestors: Morphic-mt.1608

Prevent infinite debugger chains in case of a failure while building the predebugger window. Complements System-ct.1130.

To reproduce, insert an error like "1/0" into Debugger >> #buildNotifierWith:label:message:.

=============== Diff against Morphic-mt.1608 ===============

Item was changed:
----- Method: MorphicDebugger class>>openOn:context:label:contents:fullView: (in category 'opening') -----
openOn: processToDebug context: context label: title contents: contentsStringOrNil fullView: full

| debugger uiBlock |
debugger := self new
process: processToDebug context: context;
errorWasInUIProcess: (Project current spawnNewProcessIfThisIsUI: processToDebug).

uiBlock := [
full
ifTrue: [debugger openFullNoSuspendLabel: title]
ifFalse: [debugger openNotifierNoSuspendContents: contentsStringOrNil label: title].

"Try drawing the debugger tool at least once to avoid freeze."
debugger topView ifNotNil: [:window | window world displayWorld. "Not safely!!"].
].

"Schedule debugging in a deferred UI message if necessary. Note that only the ui process should execute ui code."
(Project current uiProcess isActiveProcess not or: [processToDebug isActiveProcess])
+ ifTrue: [Project current addDeferredUIMessage: [
+ Processor activeProcess setErrorRecursionFlagDuring: uiBlock]]
- ifTrue: [Project current addDeferredUIMessage: uiBlock]
ifFalse: uiBlock.

processToDebug suspend.

"Get here only if active process is not the process-to-debug. So in tests, use a helper process if you want to access this return value."
^ debugger!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191217/eb0dbb99/attachment.html>


More information about the Squeak-dev mailing list