Re: Issue 329 in pharo: strange behaviour when Proceeding or Stepping in a newly opened Debugger

Comment #21 on issue 329 by [hidden email]: strange behaviour when  
Proceeding or Stepping in a newly opened Debugger
http://code.google.com/p/pharo/issues/detail?id=329

I have been looking at this this week. The problem is definitely still  
there, but I've been trying to get my head around it all a bit better to  
determine the best possible fix. Broadly speaking, I still think it's  
correct to pop the process to the context that is about to be debugged  
before debugging, but I'm not totally certain the best place to do that.

I've also done a couple of small refactorings as I've been looking at all  
the senders. I was planning to take another look tonight, so if I'll post  
whatever I come up with then for other to look at tomorrow.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #22 on issue 329 by [hidden email]: strange behaviour when  
Proceeding or Stepping in a newly opened Debugger
http://code.google.com/p/pharo/issues/detail?id=329

ok, thanks for details. If you can provide a (partial) fix by tomorrow we  
can have a look at it in detail at the sprint.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #23 on issue 329 by [hidden email]: strange behaviour when  
Proceeding or Stepping in a newly opened Debugger
http://code.google.com/p/pharo/issues/detail?id=329

Ok, I've provided a partial fix in Pharo-Inbox. I did a couple of cleanups  
as I was trying to trace all the senders, which will need to be merged  
first to get a clean view of the fix:

CLEANUP 1
- Debugger instance variable 'interruptedController' is never used or set:
   - change #process:controller:context: to #process:context:
   - remove reference in #windowIsClosing
   - remove instance variable
- There are two external senders of private method  
#process:controller:context:
   - add #process:context: to class side
   - change #context: to call it
   - update external senders to use one of these class-side methods
Load:
Polymorph-Widgets-JulianFitzell.717
Text-JulianFitzell.31
Tools-JulianFitzell.963
ToolsTest-JulianFitzell.denker.31

CLEANUP 2
- Double initialization of Debugger due to "super initialize" call in  
#process:controller:context:
   - remove call; Debuggers are always created with #new which already calls  
#initialize
Load:
Tools-JulianFitzell.964

CLEANUP 3
In Debugger class>>#openInterrupt:onProcess:, use class-side instance  
creation method instead of calling #new and an initializer
Load:
Tools-JulianFitzell.965

CLEANUP 4
Recategorize overridden 'default actions' methods in MorphicUIManager into  
the correct method category.
Load:
Polymorph-Widgets-JulianFitzell.718

CLEANUP 5
Pull up a default implementation of #uiProcess to the abstract class  
UIManager, since it is sent by UIManager>>#spawnNewProcessIfThisIsUI:
Load:
UIManager-JulianFitzell.80


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #24 on issue 329 by [hidden email]: strange behaviour when  
Proceeding or Stepping in a newly opened Debugger
http://code.google.com/p/pharo/issues/detail?id=329

The fix is in a slice in Pharo-Inbox:
----------------------
Name:  
SLICE-Issue-329-strange-behaviour-when-Proceeding-or-Stepping-in-a-newly-opened-Debugger-JulianFitzell.1
Author: JulianFitzell
Time: 1 November 2012, 11:47:25.067 pm
UUID: 5ae5a822-ab46-43bc-8eb2-19938dc8db56
Ancestors:
Dependencies: Tools-JulianFitzell.966, Polymorph-Widgets-JulianFitzell.719,  
UIManager-JulianFitzell.81

Refactor code to open a Debugger.

Debugger's class-side creates a new process at higher priority than the  
active process, then yields. The higher priority process suspends the  
process to be debugged and creates the debugger. The debugger is then  
passed to UIManager to open.

The abstract UIManager behaviour is undefined, but probably could be  
somehow. The Morphic implementation creates a new UI thread if necessary,  
and adds a deferred UI message to open the debugger window.
-----------------------

The approach I took was to try to put UI-related things into UIManager and  
debugger-logic stuff in Debugger. There is more work that could be done  
here to pull UI code into UIManager. The other key thing is to have another  
process create and open the debugger; this allows the debugged process to  
be suspended first so that it can pop back to the desired context.

There at least a few issues still remaining:
- UIManager>>#openDebugger:label:contents:fullView: could do with a default  
implementation I think
- Debugger has three class-side methods for opening a debugger, and I've  
only changed one. The others are used by the debugger itself, the low space  
watcher, HDTestReport, and MorphicUIManager's #warningDefaultAction:. It's  
unclear to me so far whether these two methods need to be different or  
whether they could be combined.
- MorphicUIManager>>
#onDebug:context:title:full: has no senders. Should it  
exist?

I'm attaching a flow chart I used to keep track of the senders as well as a  
script I used for testing. The test script doesn't actually demonstrate the  
bug (you need to add Transcript commands to do that easily, but does allow  
a general check that stuff is working and that the expected side-effects  
are changing).

I'll try to keep an eye on email at work tomorrow in case you have  
questions, but I won't be able to look properly again before the weekend.

Good luck!

Attachments:
        Debugger cleanup.pdf  92.9 KB
        test script.txt  1.7 KB

_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #25 on issue 329 by [hidden email]: strange behaviour when  
Proceeding or Stepping in a newly opened Debugger
http://code.google.com/p/pharo/issues/detail?id=329

awesome! we'll have a look at it today!


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker