[squeak-dev] find original change set

Christoph Thiede christoph.thiede at student.hpi.uni-potsdam.de
Tue Mar 9 17:33:24 UTC 2021


Hi all,

oldest thread I've been replying to so far ever. :D

While refactoring the VersionBrowser's annotations, I just found out that
ChangeRecord>>#originalChangeSetForSelector: is broken because, in my fresh
Trunk image, all ~1800 MethodChangeRecord instances have nil as
currentMethod. The comment in the relevant setter is kind of confusing ...:

MethodChangeRecord>>noteNewMethod: newMethod
	"NEVER do this. It is evil."
	currentMethod := nil.

Why is this?

After searching the mailing archive for a while, I did not only find the
attached message describing the same problem but also an obsolete fragment
from the ReleaseBuilder:

"The pointer to currentMethod is not realy needed (anybody care to fix this)
and often holds on to obsolete bindings"
MethodChangeRecord allInstancesDo: [:each | each noteNewMethod: nil].

But with regard to the present bug, I dare to say: currentMethod is needed
again, because without, #originalChangeSetForSelector: won't be able to
identify the correct method by its position in the changes file.

So why is currentMethod evil? I assume it just would blow up your image
significantly. But I'd like to repair the changeset search.

There are only two other users of currentMethod, #compileAll:from: and
#invokePhase1, which are both defined on ClassChangeRecord and do not have
any eventual senders in the Trunk, so they could probably be deprecated? If
this is correct, my proposal would be as follows:
Remove the currentMethod inst var from MethodChangeRecord, add a position
instvar instead, and adjust #noteNewMethod: and #containsMethodAtPosition:
accordingly.

Does this sound reasonable to you?
It is safe to assume that the position of a CompiledMethod instance will not
change again unless the sources file is updated?

I would be glad about your help!

Best,
Christoph



-----
Carpe Squeak!
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html


More information about the Squeak-dev mailing list