<br><br><div class="gmail_quote">On Thu, Dec 2, 2010 at 8:40 AM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@angband.za.org">frank.shearar@angband.za.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 2010/12/01 17:33, Eliot Miranda wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<br>
On Wed, Dec 1, 2010 at 7:10 AM, Frank Shearar<br></div><div><div></div><div class="h5">
<<a href="mailto:frank.shearar@angband.za.org" target="_blank">frank.shearar@angband.za.org</a> <mailto:<a href="mailto:frank.shearar@angband.za.org" target="_blank">frank.shearar@angband.za.org</a>>> wrote:<br>
<br>
On 2010/11/21 15:47, Frank Shearar wrote:<br>
<br>
On 2010/11/13 17:35, Frank Shearar wrote:<br>
<br>
Hi,<br>
<br>
I've been chasing down a strange bug these past few days:<br>
<a href="http://bugs.squeak.org/view.php?id=7569" target="_blank">http://bugs.squeak.org/view.php?id=7569</a><br>
<br>
The executive summary is this: when viewing a method in the<br>
debugger<br>
that refers to an instvar deleted after the Debugger<br>
instantiated, the<br>
CodePane shows the correct source for a fraction of a<br>
second, and then<br>
goes blank.<br>
<br>
What I'd expected to see was the source of the method<br>
rendered as per<br>
usual, and the reference to the missing instvar coloured red, to<br>
indicate a problem. (Just like what you'd see if you opened<br>
up a Browser<br>
on the method.)<br>
<br>
The CodePane goes blank because the Debugger's contents<br>
instvar is<br>
nilled out.<br>
<br>
CodeHolder>>setContentsToForceRefresh nils the instvar because<br>
CodeHolder>>didCodeChangeElsewhere returns true.<br>
<br>
That method returns true because the Debugger's<br>
currentCompiledMethod<br>
instvar and the compiled method according to "aClass<br>
compiledMethodAt:<br>
aSelector" aren't the same object.<br>
<br>
And now I'm a bit stuck. I know the behaviour I'd expect, I<br>
know why the<br>
bug's happening, but how do I fix it? Does CodeHolder (or<br>
Debugger) need<br>
a better way of knowing whether the viewed method's changed?<br>
(For<br>
instance, comparing the two CompiledMethods' asCommaString shows<br>
identical contents.)<br>
<br>
<br>
OK, I got a bit further. The Debugger's absolutely right in<br>
saying that<br>
the code has changed elsewhere. As soon as you delete the<br>
instvar, the<br>
entire class is recompiled and, in particular, the method<br>
referencing<br>
the deleted instvar changes.<br>
<br>
In my tests my method #bar looks like this:<br>
<br>
bar<br>
self halt.<br>
baz := 1.<br>
<br>
with bytecodes<br>
<br>
17 <70> self<br>
18 <D0> send: halt<br>
19 <87> pop<br>
20 <76> pushConstant: 1<br>
21 <60> popIntoRcvr: 0<br>
22 <78> returnSelf<br>
<br>
After deleting the instvar baz, bar's bytecodes look like this:<br>
<br>
21 <70> self<br>
22 <D0> send: halt<br>
23 <87> pop<br>
24 <76> pushConstant: 1<br>
25 <82 C1> popIntoLit: baz<br>
27 <78> returnSelf<br>
<br>
I can't argue with that. It does mean that the Debugger's job is<br>
harder.<br>
In this particular case, nilling out the Debugger's contents is the<br>
wrong thing to do, because it's surprising. You see the code,<br>
see the<br>
reference to the defunct instvar... and then your source is gone!<br>
<br>
We fall into this hole because for most CodeHolders, when the code's<br>
changed, self hasUnacceptedEdits will return true, and you'll<br>
get that<br>
red border around your code. In this case, there aren't<br>
unaccepted edits<br>
because the user hasn't changed code. Instead, the Debugger has<br>
what I<br>
suppose one might call a stale copy of the method (in contextStack).<br>
<br>
So what should the correct behaviour be? How about a message<br>
that says<br>
"Oops, this method has changed underneath your feet. Would you<br>
like to<br>
revert back to the context that called it?"<br>
<br>
<br>
I have something that works but, seeing as this is the Debugger, I'd<br>
appreciate someone else having a look.<br>
<br>
It's in Tools-fbs.283, in the Inbox.<br>
<br>
<br>
Looks good to me, but it might be wise to check that selectedContext is<br>
not nil. Theres' an assumption that contextStackTop is always valid and<br>
I can imagine that changing. Something like<br>
<br>
contents<br>
"Depending on the current selection, different information is retrieved.<br>
Answer a string description of that information. This information is the<br>
method in the currently selected context."<br>
<br>
^contents ifNil:<br>
[self selectedContext<br>
ifNotNil: [self selectedMessage]<br>
ifNil: [String new]]<br>
<br>
BTW, Personally I don't like the top context being shown when nothing is<br>
selected in stack list Is contextStackTop really necessary?<br>
</div></div></blockquote>
<br>
I wondered that myself, as I hacked on this.<br>
<br>
With your change you will still see the top context when nothing's selected, at least once you have selected something. (But at first, if the debugger pops up and you hit "debug", then the code pane's blank.)<br>
<br>
And you'll see that top context precisely because there's no concept of "nothing selected" - contextStackIndex = 0 means "show contextStackTop", and contextStackIndex > 0 means "you've selected something in the list of contexts".<br>
</blockquote><div><br></div><div>Right. And IMO that's a bug.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Both your version and mine at least address <a href="http://bugs.squeak.org/view.php?id=7569" target="_blank">http://bugs.squeak.org/view.php?id=7569</a><br><font color="#888888">
<br>
frank<br>
<br>
</font></blockquote></div><br>