ChunkBrowser "bug"

Ian,

I have at times had problems loading old chunks, but never quite
understood it.  Now I think I see what is happening.  This is in D5 with
  a perhaps out of date version of your goodies.

The real problem is that I sometimes forget to change a semicolon to a
period when removing messages from a cascade.  D5 will allow one to save
something like

ouch
    100 timesRepeat:[
        nil
           if;
            I;
            only;
            had;
            a;
    ].

Suppose the above lurks in the image.  The CB gets into trouble when the
  Smalltalk parser decides it is (rightly) entitled to read another
message before the block closes.  It gets ugly because the CB chunk list
text is based on the results on the parsing, which leads to errors in
the list updates, which I have seen lead to memory read violations.

A helpful workaround/fix would be to trap the error in a way that makes
it reasonably obvious and would allow access to a command to launch a
CHB on the offending method.

As always, thanks for the chunk browser!!

Have a good one,

Bill


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

Bill,

> The CB gets into trouble when the
> Smalltalk parser decides it is (rightly) entitled to read another
> message before the block closes.  It gets ugly because the CB chunk list
> text is based on the results on the parsing, which leads to errors in
> the list updates, which I have seen lead to memory read violations.

You could run the CB with the option #compareMethodsUsingParser: set to false.

Which is how I use it, btw.  I have nothing against "intelligent" comparison,
but I prefer something more literal-minded as the default.

    -- chris

Bill,

Thanks for the bug report.


> A helpful workaround/fix would be to trap the error in a way that makes
> it reasonably obvious and would allow access to a command to launch a
> CHB on the offending method.

That's a bit difficult.  The bit that is causing the problem is where
the CB decides on the icon to display for the chunk (unable to compare,
match or differ).  I've rewritten the method to avoid the error raised
when either the current image or the chunk won't parse correctly, but it
still can't do much more than report back that the comparison failed.

Note that even though the chunk contains an illegal cascade the CB will,
as will Dolphin itself, still compile and restore it.

If you change the ChunkBrowserMethodDefineChunk>>isMatch method it
should solve the problem.



ChunkBrowserMethodDefineChunk>>isMatch
        "Answers nil if no comparison is possible, true if the current image
matches the chunk and
        false if it doesn't. If the source code is not identical then it has
the option of a further
        test for equality using a parse tree"

        | compiledMethod currentTree chunkTree |
        compiledMethod := self identity1AndIdentity2AsCompiledMethod.
        compiledMethod
                ifNil:
                        ["unable to compare as method not available"
                        ^nil].
        compiledMethod getSource = rawText
                ifTrue:
                        ["chunk source is the same as image so must match"
                        ^true].
        ChunkBrowser compareMethodsUsingParser
                ifFalse:
                        ["don't want to compare using parser and the sources differs"
                        ^false].
        (currentTree := compiledMethod parseTreeNoError)
                ifNil:
                        ["failed to parse current and sources differs"
                        ^false].
        (chunkTree := SmalltalkParser parseMethod: rawText in: self
identity1AsClass)
                ifNil:
                        ["failed to parse chunk and source differs"
                        ^false].
        ^currentTree = chunkTree

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Ian, Chris,

> Thanks for the bug report.

Thanks for the fix/workarounds!

Have a good one,

Bill


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