[Cuis-dev] Handy ReferenceFinder extension and a question...

[Phil B]

A couple of (hopefully) final thoughts:

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 at 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.

2) While we're talking about `0 at 0` right now, this was really just the test
case.  (No, I wouldn't spend this much time just on `0 at 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.

On Mon, Mar 9, 2020 at 11:06 PM Phil B <pbpublist at gmail.com> wrote:

> 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:
>
> 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)
>
> 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 at 0` code.  However, in others it seemed
> reasonable.  For example, something like the following makes sense:
> rect:=`0 at 0 corner: 20 at 20`. "i.e. this is a literal but won't return the
> literal 0 at 0 instance"
> rect origin == `0 at 0`. "no"
>
> 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'
>
> On Mon, Mar 9, 2020 at 4:07 PM Phil B <pbpublist at gmail.com> wrote:
>
>> Juan,
>>
>> On Mon, Mar 9, 2020 at 3:30 PM Juan Vuletich <juan at jvuletich.org> wrote:
>>
>>>
>>> Hi Phil,
>>>
>>> I tried your code, and the references I see to objects equal to `0 at 0`
>>> are from CompiledMethods. Do you want to change those?
>>>
>>
>> Yes, both ivars and compiled method literals should be changed.
>>
>>
>>> Why?
>>>
>>
>> I was using `0 at 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'.
>>
>> In the case of 0 at 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 at 0 so there isn't static code that can be
>> changed/recompiled 3) they were injected into the image via the VM.
>>
>> What object do you want to make the methods point to?
>>>
>>
>> In this case, the literal `0 at 0`
>>
>>
>>> Isn't it enough to just recompile the methods?
>>>
>>
>> No, that won't address the cases described above.
>>
>>
>>>
>>> Or you are referring to objects other than CompiledMethods? Which, then?
>>>
>>
>> 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 :-)
>>
>>
>>>
>>> Thanks,
>>>
>>> --
>>> Juan Vuletich
>>>
>>>
>> 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.
>>
>> Thanks,
>> Phil
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200309/0a2dfd5b/attachment.htm>