<div dir="ltr">A couple of (hopefully) final thoughts:<div><br></div><div>1) I just thought of an additional way those CompiledMethod changes could have gotten in there: if you ever changed the literal instance that `0@0` references, all the existing CompiledMethod instances would point to the 'old' version. And if you ever change it in the future without recompiling *everything*, we'd have these dangling instances again.</div><div><br></div><div>2) While we're talking about `0@0` right now, this was really just the test case. (No, I wouldn't spend this much time just on `0@0` ;-) Bigger picture, I'm thinking of the other cruft and crap (in terms of live but forgotten objects) that has accumulated in the image over the decades that no one ever seems to think about. So this is a first stab at trying to identify and clean up one aspect of it.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 9, 2020 at 11:06 PM Phil B <<a href="mailto:pbpublist@gmail.com">pbpublist@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I was just re-reading this and realized that you might think I was glossing over your question (and a logical followup) which wasn't my intent:<div><br></div><div>While a number of the results are CompiledMethod, if you scroll down the results about 20-30% of the way through you'll see a lot of ContentPack forms show up... so it's more than *just* CompiledMethod. (i.e. if it were only CompiledMethod instances and in all cases it looked like a recompile would do the trick... sure, I would just do that)</div><div><br></div><div>As far as why we're seeing CompiledMethod at all, I only spot checked the results. In some cases it wasn't clear why, given the method source code which had backticked `0@0` code. However, in others it seemed reasonable. For example, something like the following makes sense:</div><div>rect:=`0@0 corner: 20@20`. "i.e. this is a literal but won't return the literal 0@0 instance"<br>rect origin == `0@0`. "no"<br></div><div><br></div><div>So the logical followup question is why some of the methods don't seem to match the source code? Just a guess: maybe when they were last recompiled something was broken with the literal syntax? (I'm pretty sure my code is good because everything I checked failed a #== test which is what I wanted) Since there seemed to be plenty of cases where method recompilation wouldn't address the issue, I just said 'meh, whatever... let's do it this way instead'</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 9, 2020 at 4:07 PM Phil B <<a href="mailto:pbpublist@gmail.com" target="_blank">pbpublist@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Juan,<div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 9, 2020 at 3:30 PM Juan Vuletich <<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div bgcolor="#ffffff"><br>
Hi Phil,<br>
<br>
I tried your code, and the references I see to objects equal to
`0@0` are from CompiledMethods. Do you want to change those?</div></blockquote><div><br></div><div>Yes, both ivars and compiled method literals should be changed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff"> Why?</div></blockquote><div><br></div><div>I was using `0@0` as a test case for saying 'OK, I've turned some sort of instance to a literal. Now for whatever reason, there are instances hanging around that aren't using the literal... let's go find/fix them'.</div><div><br></div><div>In the case of 0@0 there are at least three ways I can imagine these instances getting out there: 1) they are long-lived instances that were created before we had the literal syntax or 2) they were created by code that performed some computation to create a point that just ended up resulting in 0@0 so there isn't static code that can be changed/recompiled 3) they were injected into the image via the VM.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff">
What object do you want to make the methods point to?</div></blockquote><div><br></div><div>In this case, the literal `0@0`</div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff"> Isn't it
enough to just recompile the methods?<br></div></blockquote><div><br></div><div>No, that won't address the cases described above.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff">
<br>
Or you are referring to objects other than CompiledMethods? Which,
then?<br></div></blockquote><div><br></div><div>Everything, everywhere: any instance of an object that I want to find and/or replace. Basically what I'm doing is turning ReferenceFinder into grep for the image :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff">
<br>
Thanks,<br>
<pre cols="72">--
Juan Vuletich</pre></div></blockquote><div><br></div><div>Just as an update: not being aware of any better way, I tried adding a couple of helper methods to my 'enhanced' ReferenceFinder and it surprisingly worked on the first try. So far no corruption/strangeness to report.</div><div><br></div><div>Thanks,</div><div>Phil</div></div></div>
</blockquote></div>
</blockquote></div>