ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh).
Stef On 03 Apr 2014, at 21:13, Pharo4Stef <pharo4s...@free.fr> wrote: > > | context process debugger | > context := [ 20 factorial ] asContext. > > process := Process > forContext: context > priority: Processor userInterruptPriority. > [ > debugger := Smalltalk tools debugger new > process: process > controller: nil > context: context. > Transcript show: debugger stack class ; cr > ] ensure: [ process terminate] > > > When I look at some of the stuck processes > > SpecDebugger>>initializePresenter > super initializePresenter. > self flag: 'some of this logic could be moved to the stack widget'. > self flag: 'The toolbar should not be updated when the list changes, > but when an action is perormed.'. > self stack whenListChanged: [ :aList | > aList isEmpty ifFalse: [ self stack setSelectedItem: aList > first ]. > "Updating the toolbar will result in changing the button > widgets. > If the widget hasn't been opened, there will be no spec, which > leads to an error." > self spec ifNotNil: [ > self updateToolbar ] ]. > > self stack whenSelectedItemChanged: [:aContext | > self updateCodeFromContext: aContext. > self updateInspectorsFromContext: aContext. > self stack updateForSelectionChanged ]. > > self contextInspector initializeAutoRefresh. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > And initializeAutoRefresh does not exist in the latest image. > I have no idea why the debugger may work may be this method is not used at > all. > > Can somebody else confirm because I have the impression to fall into a rat > nest. > stef
