Debugger modal

in D5B4, if the debugger opens as a result of a doit, the window containing
the doit becomes modal to the debugger (if i am phrasing that correctly).

Eg, evaluating 'self halt' in a workspace or a method pane.

"Alan Reider" <[hidden email]> wrote in message
news:T2G=[hidden email]...
> in D5B4, if the debugger opens as a result of a doit, the window
containing
> the doit becomes modal to the debugger (if i am phrasing that correctly).
>
> Eg, evaluating 'self halt' in a workspace or a method pane.

Yes, that is right. It is not something specifically aimed at Debugger's per
se, but when a command is executing the initiating shell is disabled. In
general this means one does not have to worry that a further command could
be initiated while the first was running.

I have mixed feelings about this from the Debugger's point of view in that
really it is "correct" that the debugged thing be disabled, as otherwise one
can go and change the state of that thing without realising it, affecting
the debugging session. It also more closely reflects what one might expect
to see when Dolphin is running on a native-multithreaded VM, as I suspect
there would be one thread per top-level Window (Windows is really designed
to work that way, since its modal dialogs expect to take control of the
message loop), and the debugger would actually suspend the entire thread so
that the debugged shell stopped operating altogether, even repainting. On
the other hand I have found the previous (D4-style) behaviour convenient in
the past, and it is less likely to leave a disabled window as a result of a
debugging session (though the latter situation is easily corrected using the
Visual Object Finder).

I think we will review feedback from the release candidate and decide
whether to leave it as it is, or make the Debugger/debugging a special case.

Regards

Blair

On Fri, 19 Apr 2002 09:28:24 +0100, "Blair McGlashan" <[hidden email]>
wrote:

My feeling is that it is very inconvenient this way. A whole window is lost. I
am constantly checking bits of code from the browser or a workspace and then
reusing the window while debugging, eg to browse other code, do more doits,
etc. As it is now you cannot even click on the window to see what you
evaluated, move or resize it, etc.  I have never had a problem due to changing
something in the window affecting the debug. And if i wanted to do some damage
I could just open another browser anyway so i dont think locking the window is
that helpful :)

Anyway, if you do decide to leave it the way it is, please consider making the
old behavior accessible with a simple mod to the image.

Alan R

Alan,

> My feeling is that it is very inconvenient this way. A whole window is
lost.

You're right: it does put a hole in the middle of the screen.  The task bar
is a nice workaround though.  Do you use XP?  I've interacted only briefly
with XP on a friend's machine, but, I found the default look to be
***VERY*** wasteful of screen real estate.  The "sorting" of the task bar
(one button per process with pop-up menus of individual windows IIRC) is
interesting, but, might actually work against a Dolphin user trying avoid an
inactive window in the middle of the screen.


> I
> am constantly checking bits of code from the browser or a workspace and
then
> reusing the window while debugging, eg to browse other code, do more
doits,
> etc.

Same here, though I'm feeling steadily more guilty for not doing much of
this kind of thing in the form of unit tests.  With that said, I can't quite
bring myself to "test first or bust" because I fear the result will be bad
(or simply watery) tests.  Still, I have a lot of perfectly useful test
cases that would be automated if only they were captured in TestCase
subinstances - I'm working on correcting that.


> As it is now you cannot even click on the window to see what you
> evaluated,

The doIt code is visible in the debugger.  How about a command to select the
(if any) doIt in the call stack?  While making suggestions re the debugger,
one thing that I like from Squeak's debugger is the "where" command.
Arguably Squeak needs it more, but, the idea is to restore the selection of
text - basically equivalent to selecting a different line in the stack and
then returning, only quicker.


> move or resize it, etc.  I have never had a problem due to changing
> something in the window affecting the debug. And if i wanted to do some
damage
> I could just open another browser anyway so i dont think locking the
window is
> that helpful :)

Good points.

I've gone in and out of being convinced that Dolphin requires stronger
measures for preventing stray user input from being turned into
harmful/extraneous commaneds.  At present, I think that D4 is ok on that
front.  However, the cose of being wrong is high, so I'm willing to adapt if
OA deems the protection necessary.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Alan, etc.

> My feeling is that it is very inconvenient this way. A whole window is
lost.

I feel the same way.  I've already asked for an exception to be made in the
case of F11 from a workspace, but I find it a nuisance debugging my real
apps too.

I think the workspace case is specially important, though, because (as I
said before) *that's where my objects are living* so I don't like being
unable to get at them, just because one of them is being debugged.  In the
interim, I've added
    self topShell view enable.
to SmalltalkWorkspace>>debugItIfFail:, which alleviates the "pain" slightly.

BTW, I don't see any easy way to fix the debugger problem in general, but
one thing that might help a little would be to add a comment, and an
expression to evaluate, in, say, ShellView>>performCommand: which we could
navigate to under the debugger (since it's on the call stack whenever this
case occurs) that would enable the View again.

    -- chris

Frequently when closing a debugger the initiating shell stays disabled. I
can't make a test case but it happens regularly and frequently in my
debugging. Not sure what to look for, the code I'm debugging has some nested
ensures: in it and many (nested) blocks.. When I have around 4 windows
orphaned, I use the panic button ..

Alan R

Alan,

> Frequently when closing a debugger the initiating shell stays disabled. I
> can't make a test case but it happens regularly and frequently in my
> debugging. Not sure what to look for, the code I'm debugging has some
nested
> ensures: in it and many (nested) blocks.. When I have around 4 windows
> orphaned, I use the panic button ..

I can't say that I've seen this one, but, I'll take a crash over "it just
quit" (almost) any time =:0   The next time you pile up a few disabled
windows, it might be a good idea to look around with the process monitor, or
you can grab the similar goodie from my web site.  Either way, it would be
interesting to know whether you are piling up main theads, and if so, get
some idea as to why.

Things that come to mind include a semaphore that's not getting signaled, or
maybe ensured excution is broken.  It could also be that the "victims" of
this bug all have deadlocks in their code.  My process viewer got its start
looking for just that kind of problem.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Alan,

> Frequently when closing a debugger the initiating shell stays disabled.

Ha!  So somebody else *has* seen this too!

(see the "Occasional disabled window after debugger is killed?" thread)

Blair, I now wish to rescind my earlier comment that "it can probably be
safely ignored" ;-)

    -- chris

Chris, Alan,

Which OS are you guys using?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> Which OS are you guys using?

W2K sp2.

> Bill

    -- chris

W2k

On Mon, 22 Apr 2002 17:53:27 -0400, "Bill Schwab" <[hidden email]>
wrote:

>Chris, Alan,
>
>Which OS are you guys using?
>
>Have a good one,
>
>Bill