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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20020731/4db90ac9/attachment.htm