It seems to me that no Squeaker could plausibly have been doing
any real work in MVC in any 3.2 or 3.3a since this bug arrived more
than eight months ago, because the mere raising of a single debugger
would have put his environment into a state no reasonable person could
tolerate. And he would therefore have screamed and we would have
heard.
Consequently, I'm not too surprised that there has not been a
single response posted to this thread, other than Boris's original bug
report and my reply.
But is it really true that there are actually *no* MVC
practitioners using either Squeak 3.2 or 3.3a , no one at all, except
Boris?
Cheers,
-- Scott
At 2:46 AM -0700 7/30/02, Scott Wallace wrote:
The mvc brain-damage Boris describes
turns out to be reliably exhibited whenever a debugger is presented
and proceeded-through in an MVC project, both in 3.2 *and* 3.3a.
Even something as simple as hitting cmd-dot and then hitting the
Proceed button on the ensuing pre-debug window (in mvc) will do
it.
By going back to an image that did not
exhibit these problems and then loading updates one at a time,
checking for the bug after each update, I was able to track down
exactly where this problem entered into Squeak.
It turns out to have arrived in update
4487SyntaxErrorsOnFileIn-svp, whose preamble was:
--------------------------------------------------
Change Set:
SyntaxErrorsOnFileIn-svp
Date:
14
October 2001
Author:
Stephen Pair
BugFixing Party @ Camp Smalltalk OOPSLA 2001. Fixes bug report
from Sept 13, 2001:
If you get a syntax error during a
fileIn, you should be able to correct it in the notifier, and then
accept the corrected code from that window. If all is well, the method
gets defined, and the fileIn continues. But it doesn't. Instead, you
get... NonBooleanReceiver: proceed for truth.
--------------------------------------------------
That update may have improved things
regarding the state after syntax errors are encountered during
fileins, but it is seemingly directly responsible for breaking mvc
whenever a debugger is put up.
It appears that a simple reversion of the
single method in this update (Debugger >>
process:controller:context:isolationHead:) cures the problem, though
presumably that would re-establish the problem on file-in that the
update was intended to fix.
I attach herewith instead a proposed
workaround, with the following preamble:
--------------------------------------------------
Change Set:
debuggerFix-sw
Date:
29
July 2002
Author:
Scott Wallace
Works around a bug introduced in
update4487SyntaxErrorsOnFileIn-svp (October 2001) which had
compromised the mvc environment whenever a debugger was brought up.
The workaround here, done without any pretension to deep knowledge of
the underlying issues, is to restore the method in question (Debugger
>> process:controller:context:isolationHead:) to its former
behavior in the mvc case, while letting it work its putative magic
when in morphic.
--------------------------------------------------
Before I publish this -- or, preferably,
publish someone else's better fix -- as an update, I hope to hear some
confirmation or other commentary on this matter, and, ideally, to
receive the "real fix" from someone.
Cheers,
-- Scott
At 9:20 AM +0200 7/28/02, Boris Gaertner
wrote:
On windows 98 the new
Squeak 3.2 exhibits a quite strange
behaviour when a
debugger is opened in the MVC environment.
Please try
this.
1. create and enter an
mvc project.
2. open a
class hierarchy
browser.
3. select
StringHolder>>browseVersions.
( a lot
of other methods would do as well. )
4. Insert the
statement self halt. at the beginning
of
the
method and save the method with "accept"
5. Now, move the mouse
into the method names view
and
select "versions"
6. a small red window
with title "Halt" and three buttons
is opened. Press the
button "Resume"
7. a blue (or violet?)
VersionsBrowser is opened. It
flashes when it is
opened and this detail is maybe
important.
8. select a version. I
see the method text displayed
for a very short time,
then the text view is empty again.
There are also other
weird effects (on my computer at least)
*the system menue
shows unusual behavior.
*When the mouse
pointer leases the versions brwoser and
then enters it again,
it crosses the window border.
When it does, the
curser changes to a "drag window border"
symbol. That symbol
does not vanish again when the mouse
pointer is inside the
versions browser.
After a lot of
nonsensical actions with the mouse
Squeak seemingly comes
back to normal bahaviour.
I saw these strange
things also in a 3.2 alpha (last update: 4599)
with the virtual
machine
Squeak 3.2.2 VM
(release candidate) from May 26 2002
Compiler: gcc 2.95.2
19991024 (release)
I think that something
with the process switching or
scheduling goes wrong,
but until now I have no idea what
it
is.
Are there others out
there that can confirm my observations?
Have you any idea what
I can do to better the situation?
Greetings
Boris