[Q][MVC] Debugging/Debugger related change between 3.5 to 3.6?

Boris Gaertner Boris.Gaertner at gmx.net
Mon Feb 13 20:48:10 UTC 2006


"Sungjin Chun" <chunsj at embian.com> wrote:

> Hi,
>
> Current versions( > 3.6) have problem in debugging session in MVC
> project. For example,
>
> [ #() at: 3 ] fork.
>
> like code makes squeak UI unusable. This problem does not happen in
> <= 3.5 version (But in these versions, there's other problem; the
> error/debugger window appears after some long delay).
Yes, exactly. You had to click with the mouse onto the window background
(desktop) of Squeak to bring that window up. That click onto the
background is processed by the instance of ScreenController that
is known to the sole instance of ControlManager.
>
> Now, here comes my question, what changes are happend between theses
> versions? Or what part can I refer so that I can make my image(3.8
> base MVC only image) be not corrupted with above code.
>
> Thanks in advance.
>

This is a difficult question and I still do not have a really good
answer. However, it may help to point out that MVC has a general
problem to open a window from a forked process. Try these
examples:

[ #(#aa #bb) inspect] fork

[ HierarchyBrowser newFor: Boolean ] fork

[Workspace new
    contents: 'This workspace was opened in a forked process.
This works fine under Morphic, but under MVC it does
not work properly';
    openLabel: 'Forked Workspace:'] fork

In all these cases, you have to click into the desktop area of Squeak
to bring up the window. (The desktop ares is region that is not
covered by a window. An instance of ScreenController processes
the input for that region).


- - - - - - - - - - - - -

These things are difficult and I think it will be really difficult to
implement inter-process debugging. For your special
example I found that, in Squeak 3.7 #5989, a modification
in the following *class* method of Debugger can better the situation:

openOn: process context: context label: title contents: contentsStringOrNil
fullView: bool
 "Open a notifier in response to an error, halt, or notify. A notifier view
just shows a short view of the sender stack and provides a menu that lets
the user open a full debugger."

 | controller errorWasInUIProcess |
 Smalltalk isMorphic
  ifTrue: [errorWasInUIProcess _ CurrentProjectRefactoring newProcessIfUI:
process]
  ifFalse: [controller _ ScheduledControllers activeControllerProcess ==
process
    ifTrue: [ScheduledControllers activeController]].
 [
  [ | debugger |
   debugger _ self new process: process controller: controller context:
context.
   bool ifTrue: [debugger openFullNoSuspendLabel: title]
    ifFalse: [debugger openNotifierContents: contentsStringOrNil label:
title.
     controller isNil
      ifTrue: [ScheduledControllers activeControllerProcess suspend]].
   debugger errorWasInUIProcess: errorWasInUIProcess.
   Preferences logDebuggerStackToFile ifTrue: [
    Smalltalk logError: title inContext: context to: 'SqueakDebug.log'].
   Smalltalk isMorphic
    ifFalse: [ScheduledControllers searchForActiveController "needed since
openNoTerminate (see debugger #open...) does not set up
activeControllerProcess if activeProcess (this fork) is not the current
activeControllerProcess (see #scheduled:from:)"].
  ] on: Error do: [:ex |
   self primitiveError:
    'Orginal error: ',
    title asString, '.
 Debugger error: ',
    ([ex description] on: Error do: ['a ', ex class printString]), ':'
  ]
 ] fork.
 process suspend.

You see that I propose to suspend the active
controller process if (and only if) it is not the process
to be debugged. Please try this very carefully
(that means: after you have made backups of
all your important things) and let me know
wheather if facilitates your work.

Gretings,
Boris





More information about the Squeak-dev mailing list