ChunkBrowser and overlapped calls

Ian,

Does the CB fail to notice the overlap attribute in external calls?  I find
myself hoping so, because it would explain what I'm seeing :)    Sorry to
"report and run" but I'm afraid I would forget to mention it otherwise.

Have a good one,

Bill

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

Bill,

> Does the CB fail to notice the overlap attribute in external calls?

Sorry Bill, I'm not quite sure what you mean.  Could you give a bit more
detail please?

--
Ian

Ian,

> > Does the CB fail to notice the overlap attribute in external calls?
>
> Sorry Bill, I'm not quite sure what you mean.  Could you give a bit more
> detail please?

I'm finding that external call methods appear as matching if they exist in
the image and in the file, regardless of content of the method source.  I
first noticed it when scanning for overlapped calls, but it seems to apply
to comments too.  Is there a problem with parsing the external call syntax?
Appologies if this is a false alarm.

Have a good one,

Bill

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

Bill,

> I'm finding that external call methods appear as matching if they
> exist in the image and in the file, regardless of content of the
> method source.  I first noticed it when scanning for overlapped
> calls, but it seems to apply to comments too.

OK, gotcha.

The CB has an user settable option called #fullMethodComparison.  If
this option is set to true (the default) then the chunk and the image
methods will match if _either_ their source code is identical _or_ their
parse trees are identical (see ChunkBrowserMethodDefineChunk>>isMatch).
The idea is that cosmetic differences (to comment contents and method
formatting for example) that don't result in a change in functionality
can, optionally, be ignored.

It may be that the parse tree for external call methods doesn't change
in a significant way when your method is edited for overlapped calls and
the #fullMethodComparison option is masking the source code mismatch.
Try setting the option to false and see if it makes a difference.

If this is the problem then I will look into adding an extra test to
make sure that external call methods are only compared using a source
code comparison.

<aside> #fullMethodComparison is a _really_ bad name isn't it :-(  I'll
have to change that in future versions to something like
#useParseTreeComparison

--
Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:DLtqb.5119$[hidden email]...
This is a bug in StMethodNode>>=. It doesn't consider the 'tag' when
comparing the two methods, so the details of the external call are ignored.
This bug would also mean that two methods that differ only because one
invokes a primitive and one does not.  I've recorded this as #1378.

To workaround this bug use #equalTo:exceptForVariables: passing an empty
array for the second parameter. This method (well #equalTo:withMapping: that
it calls) does perform the equality test correctly, including comparing the
tags.

Thanks

Blair

Blair,

> This is a bug in StMethodNode>>=.

Thanks for looking at the problem.  I was going to try and do some
testing over the weekend, to see if I could locate the method types that
might cause difficulties, but I won't bother now!.

--
Ian

Ian,

> It may be that the parse tree for external call methods doesn't change
> in a significant way when your method is edited for overlapped calls and
> the #fullMethodComparison option is masking the source code mismatch.
> Try setting the option to false and see if it makes a difference.
>
> If this is the problem then I will look into adding an extra test to
> make sure that external call methods are only compared using a source
> code comparison.

My hunch is that Blair found the real problem.  Do you agree?  I tried the
less forgiving setting, and found out why you did the parsing :)  Thanks
again for a great tool!

Have a good one,

Bill

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

Bill,

> My hunch is that Blair found the real problem.  Do you agree?

Yes.  I tried the workaround that Blair suggested and the external
method changes that I tested all now show up as modified.  My temporary
patch ....

ChunkBrowserMethodDefineChunk>>isMatch
    ^self identity1AndIdentity2AsCompiledMethod
        ifNotNil:
            [:arg |
                arg getSource = rawText
                    or:
                        [ChunkBrowser fullMethodComparison
                            and:
                                [arg parseTree
                                    equalTo:
                                        (SmalltalkParser
                                            parseMethod: rawText
                                            in: self identity1AsClass
                                            onError: [:aString :pos |
^nil])
                                    exceptForVariables: #()]]]

--
Ian