Smalltalk › Squeak › Squeak - Dev

Rather important bug: corrected source is not saved

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

timrowledge

Rather important bug: corrected source is not saved

Using recent 5.0 images - including one updated a day or two ago to 15632 - if I attempt to save a method with a typo the compiler catches it and provides the usual menu of likely options etc. Choosing one, as expected, lets the compile proceed and all seems well.

Except that the code saved to the changes is still wrong! Which means you have code that runs and may pass your tests, but when you save it to pass around it is *wrong*. This is a *really bad thing*. It means you can be confident that code is working and still end up distributing fatal errors!

An original 5.0-15133 image manages to get it right, so who has been mangling the compiler stuff recently? I have a 15566 update image where it goes wrong. And I have a 15603 where it fails, but that’s as precise as I can get now.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Suffers from Clue Deficit Disorder.

timrowledge

Re: Rather important bug: corrected source is not saved

> On 19-02-2016, at 4:58 PM, tim Rowledge <[hidden email]> wrote:
>
> An original 5.0-15133 image manages to get it right, so who has been mangling the compiler stuff recently? I have a 15566 update image where it goes wrong. And I have a 15603 where it fails, but that’s as precise as I can get now.

Err, a typo in a mail about a typo-bug. Whodathunk? That should read "I have a 15566 update image where it works"

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: FR: Flip Record

timrowledge

Re: Rather important bug: corrected source is not saved

In reply to this post by timrowledge

I’m attempting to follow this problem and finding myself very puzzled. In a 15632 image, where the problem occurs, ClassDescription>>#compile:classified:withStamp:notifying:logSource: compiles the input text with an option to notify the requestor when problems arise. It then logs the input text - not the potentially modified text actually used to compile, but the input text.

Under all the compile:notifying:trailer:ifFail: stuff the text gets modified if the user chooses a corrected message name, for example; at least, in the working 15566 image. In the newer one, it does*not* get corrected.

Anyone going to hold their hand up about having done something here? Come on now, nobody is going off to Vespers until we’ve sorted this out. If somebody doesn’t admit to it the whole school will be in detention for a month.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Dukedom: aristocratic birth control

timrowledge

Re: Rather important bug: corrected source is not saved

> On 22-02-2016, at 4:19 PM, tim Rowledge <[hidden email]> wrote:
>
> I’m attempting to follow this problem and finding myself very puzzled.

Right, well I’ve found at least part of the cause.

On jan 6 ‘kfr’ changed PluggableTextMorphPlus>okToStyle, such that it changes the path taken by PluggableTextMorphPlus>acceptTextInModel. Rescinding the change makes the immediate problem go away. I suspect the problem is a bit deeper into the rather complicated fudging that appears to be going on in the acceptTextInModel stuff where styled this and that are competing with the way the compiler works.

There’s a lot of ugliness to do with the source string/text/another string got from the requestor down there.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MFC: Mangle Following Command

Karl Ramberg

Re: Rather important bug: corrected source is not saved

Hi,

Method reverted in ToolBuilder-Morphic-kfr.159.

I'm not sure how this could have caused the issue you describe.

The change was put in so syntax highlighting could be optional.

Best,

Karl

Best,

Karl

On Tue, Feb 23, 2016 at 3:14 AM, tim Rowledge <[hidden email]> wrote:

> On 22-02-2016, at 4:19 PM, tim Rowledge <[hidden email]> wrote:
>
> I’m attempting to follow this problem and finding myself very puzzled.

Right, well I’ve found at least part of the cause.

On jan 6 ‘kfr’ changed PluggableTextMorphPlus>okToStyle, such that it changes the path taken by PluggableTextMorphPlus>acceptTextInModel. Rescinding the change makes the immediate problem go away. I suspect the problem is a bit deeper into the rather complicated fudging that appears to be going on in the acceptTextInModel stuff where styled this and that are competing with the way the compiler works.

There’s a lot of ugliness to do with the source string/text/another string got from the requestor down there.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MFC: Mangle Following Command

timrowledge

Re: Rather important bug: corrected source is not saved

> On 22-02-2016, at 10:31 PM, karl ramberg <[hidden email]> wrote:
>
> Hi,
> Method reverted in ToolBuilder-Morphic-kfr.159.
> I'm not sure how this could have caused the issue you describe.
> The change was put in so syntax highlighting could be optional.

Yah, I saw that ok; the problem is that the false branch that gets run when okToStyle is false completely mishandles that. I think there are deeper issues that this reveals. A lot of the code I read whilst debugging is horribly non-OOP in style

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IML: Invoke Murphy's Laws

Karl Ramberg

Re: Rather important bug: corrected source is not saved

I dread trying to figure this out ;-)

Best,

Karl

On Tue, Feb 23, 2016 at 7:38 AM, tim Rowledge <[hidden email]> wrote:

> On 22-02-2016, at 10:31 PM, karl ramberg <[hidden email]> wrote:
>
> Hi,
> Method reverted in ToolBuilder-Morphic-kfr.159.
> I'm not sure how this could have caused the issue you describe.
> The change was put in so syntax highlighting could be optional.

Yah, I saw that ok; the problem is that the false branch that gets run when okToStyle is false completely mishandles that. I think there are deeper issues that this reveals. A lot of the code I read whilst debugging is horribly non-OOP in style

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IML: Invoke Murphy's Laws