The Trunk: Tools-bf.391.mcz

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:
-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:

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

On 12/16/2011 14:22, Bert Freudenberg wrote:
You're right, my apologies.

Cheers,
   - Andreas

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