Bert Freudenberg uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-bf.391.mcz ==================== Summary ==================== Name: Tools-bf.391 Author: bf Time: 16 December 2011, 1:07:07.748 pm UUID: 0cb588ab-a21a-40f1-839d-6059e89573a3 Ancestors: Tools-cao.390 Workaround: disable logging of user-interrupt to ensure interruptability (real fix to come after 4.3 release) =============== Diff against Tools-cao.390 =============== Item was changed: ----- Method: Debugger class>>openInterrupt:onProcess: (in category 'opening') ----- openInterrupt: aString onProcess: interruptedProcess "Open a notifier in response to an interrupt. An interrupt occurs when the user types the interrupt key (cmd-. on Macs, ctrl-c or alt-. on other systems) or when the low-space watcher detects that memory is low." | debugger | <primitive: 19> "Simulation guard" debugger := self new. debugger process: interruptedProcess controller: ((Smalltalk isMorphic not and: [ScheduledControllers activeControllerProcess == interruptedProcess]) ifTrue: [ScheduledControllers activeController]) context: interruptedProcess suspendedContext. debugger externalInterrupt: true. + Preferences logDebuggerStackToFile ifTrue: + [(aString includesSubString: 'Space') & (aString includesSubString: 'low') + ifTrue: [Smalltalk logError: aString inContext: debugger interruptedContext to: 'LowSpaceDebug.log'] + "logging disabled for 4.3 release, see + http://lists.squeak.org/pipermail/squeak-dev/2011-December/162503.html" + "ifFalse: [Smalltalk logSqueakError: aString inContext: debugger interruptedContext]"]. + - Preferences logDebuggerStackToFile ifTrue: - [(aString includesSubString: 'Space') & - (aString includesSubString: 'low') ifTrue: [ - Smalltalk logError: aString inContext: debugger interruptedContext to:'LowSpaceDebug.log'] - ifFalse: [Smalltalk logSqueakError: aString inContext: debugger interruptedContext]]. Preferences eToyFriendly ifTrue: [World stopRunningAll]. ^ debugger openNotifierContents: nil label: aString ! |
On 12/16/2011 12:07, [hidden email] wrote:
> Bert Freudenberg uploaded a new version of Tools to project The Trunk: > http://source.squeak.org/trunk/Tools-bf.391.mcz > > ==================== Summary ==================== > > Name: Tools-bf.391 > Author: bf > Time: 16 December 2011, 1:07:07.748 pm > UUID: 0cb588ab-a21a-40f1-839d-6059e89573a3 > Ancestors: Tools-cao.390 > > Workaround: disable logging of user-interrupt to ensure interruptability (real fix to come after 4.3 release) -1. Disabling *all* debug logs is a rather high price to pay in my book. You will not be able to get *any* debug logs out of 4.3. If this issue is considered a serious problem (personally I think it's a rather obscure use case to require interrupting 10000 factorial to have a sub-second response) then how about simply evaluating "Preferences disable: #logDebuggerStackToFile" instead of hardcoding it out? At the very least, those people not having the above use case can re-enable their debug logging. Or even better, now that we know the cause of the problem how about recommending that the person who originally reported the problem simply turn off their logging locally? Cheers, - Andreas |
On 16.12.2011, at 14:09, Andreas Raab wrote: > On 12/16/2011 12:07, [hidden email] wrote: >> Bert Freudenberg uploaded a new version of Tools to project The Trunk: >> http://source.squeak.org/trunk/Tools-bf.391.mcz >> >> ==================== Summary ==================== >> >> Name: Tools-bf.391 >> Author: bf >> Time: 16 December 2011, 1:07:07.748 pm >> UUID: 0cb588ab-a21a-40f1-839d-6059e89573a3 >> Ancestors: Tools-cao.390 >> >> Workaround: disable logging of user-interrupt to ensure interruptability (real fix to come after 4.3 release) > > -1. Disabling *all* debug logs is a rather high price to pay in my book. You will not be able to get *any* debug logs out of 4.3. Only logging of user interrupts is disabled. A feature that was only added recently. - Bert - > If this issue is considered a serious problem (personally I think it's a rather obscure use case to require interrupting 10000 factorial to have a sub-second response) then how about simply evaluating "Preferences disable: #logDebuggerStackToFile" instead of hardcoding it out? At the very least, those people not having the above use case can re-enable their debug logging. > > Or even better, now that we know the cause of the problem how about recommending that the person who originally reported the problem simply turn off their logging locally? > > Cheers, > - Andreas > |
I disagree that it is obscure.
It is very easy for a beginner to mistakenly get Smalltalk into a tight loop. I have done it myself, and I have loaded others' code that made Squeak uninterruptible. The user interrupt should be a selling point for Squeak, not a discouragement. Unfortunately, beginners, no matter how clueful, are likely to be discouraged by a broken promise, rather than seek out advice to turn off logging in their image. FWIW, I haven't tested Bert's patch, but I think the proposal to comment out one line is appropriately minimal for a pre-release code freeze. David |
In reply to this post by Bert Freudenberg
On 12/16/2011 14:22, Bert Freudenberg wrote:
> > On 16.12.2011, at 14:09, Andreas Raab wrote: > >> On 12/16/2011 12:07, [hidden email] wrote: >>> Bert Freudenberg uploaded a new version of Tools to project The Trunk: >>> http://source.squeak.org/trunk/Tools-bf.391.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Tools-bf.391 >>> Author: bf >>> Time: 16 December 2011, 1:07:07.748 pm >>> UUID: 0cb588ab-a21a-40f1-839d-6059e89573a3 >>> Ancestors: Tools-cao.390 >>> >>> Workaround: disable logging of user-interrupt to ensure interruptability (real fix to come after 4.3 release) >> >> -1. Disabling *all* debug logs is a rather high price to pay in my book. You will not be able to get *any* debug logs out of 4.3. > > Only logging of user interrupts is disabled. A feature that was only added recently. You're right, my apologies. Cheers, - Andreas |
In reply to this post by dcorking
On 12/16/2011 15:11, David Corking wrote:
> I disagree that it is obscure. > > It is very easy for a beginner to mistakenly get Smalltalk into a > tight loop. I have done it myself, and I have loaded others' code that > made Squeak uninterruptible. My point about this situation being obscure related exclusively to the example of 10000 factorial. If you have had other code that has similar issues I would encourage you to try it out to see if the workaround Bert has been posting actually addresses it. I kinda doubt it. Bert's workaround works for situation where there is a problem with printing the call stack (as exercised with 10000 factorial); but these situations are extremely rare. It is more likely that in the situations where you've found Squeak to be non-interruptable, some other issue (such as selecting the 'wrong' process) is the cause of your problems. > The user interrupt should be a selling point for Squeak, not a > discouragement. Unfortunately, beginners, no matter how clueful, are > likely to be discouraged by a broken promise, rather than seek out > advice to turn off logging in their image. Certainly. But I'm questioning your assumption that most cases of non-interruptability of Squeak would be caused by logging delays. My claim is that under "normal" operations these delays are practically non-existent. > FWIW, I haven't tested Bert's patch, but I think the proposal to > comment out one line is appropriately minimal for a pre-release code > freeze. Then please, go ahead and test it. If you find that your various situations under which you've seen non-interruptability are solved by it, you can color me impressed :-) Cheers, - Andreas |
Free forum by Nabble | Edit this page |