Getters gone mad

From time to time I have strange effects that go undiscovered for a while. And I seem to remember I've posted this to the old VAST Forum a few years ago.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/T0bd2YCe1RkJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Joachim,

I have seen a symptom like this. It took a while, but I was able to determine exactly what had gone wrong in our case. It may be your problem is from some other cause, however.

We discovered that if one were to load a different edition of the class definition from the changes browser, the existing compiled methods would not be recompiled to reflect the different instance variables and slots that the class change entailed.


I hope this is what is affecting you, as I would not want there to be a second cause of this!
       Richard

On Tuesday, July 17, 2012 8:46:21 PM UTC+2, [hidden email] wrote:

From time to time I have strange effects that go undiscovered for a while. And I seem to remember I've posted this to the old VAST Forum a few years ago.

So sometimes getters return the contents of a wrong instance variable. The source code looks good, and simply entering a blank character to the method and recompiling it heals the problem. I haven't been able to reproduce the problem reliably, but I suspect its has to do with the "Rename Variable As... with Accessors" refactoring. I haven't tried this time, but next time I'll try reloading the methods from envy into a new image to see if this is problem persists. Not sure what exactly that would tell me about my Refactoring theory. So far I haven't seen the same problem with setters... All I can tell is that in an inspector, the contents of an affected inst var is okay, but sending the sender returns the contents of another inst var. The getter of the other inst var is not necessarily returning the value of the affected inst var...

Has anybody seen this as well? This effect shows up every three or four months or so, so I'd say it's rare, but it is "interesting".

BTW: Is there an easy way to see what inst var a method refers to? Inspecting a CompiledMethod doesn't show (art least not in a way that jumps right at me) what I was looking for. Do I need to read the byte codes? If so, how can I do that (I know the Browsers were updated to show them, but  forgot how to load/activate that).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/4jTL4mKvXwYJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Richard,

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/ap039IT1XHMJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Joachim and Richard -

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/uzEljz9zmIMJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Unfortunately, John, I no longer remember exactly how to recreate the problem.  I just tried the obvious approach, but it works correctly, properly recompiling the methods when loading a changed class definition (in my example, I reverse the instance variables).

On Tuesday, 17 July 2012 22:07:48 UTC+2, John O'Keefe wrote:

Joachim and Richard -

Not fixed (for sure) and not reported (as far as I can tell).

It would certainly help if we could get a reproducible scenario.

John

On Tuesday, July 17, 2012 3:51:05 PM UTC-4, [hidden email] wrote:

Richard,

I am glad I am not alone. 

Do you know if that was ever fixed or at least reported to IBM or Instantiations? Finding out what's wrong can be hard in such situations...

It is very well possible that I did something like "Load Alternatives" or such on a merge, but this specific project needs little merging because there aren't many developers involved. But I do refactor a lot, maybe that is why I suspect it is related to renaming accessors with variables...

Do you remember what you did to find out about the missing recompile? I figure this can take a lot of time... ;-)

Joachim

Am Dienstag, 17. Juli 2012 21:19:20 UTC+2 schrieb Richard Sargent:

Joachim,

I have seen a symptom like this. It took a while, but I was able to determine exactly what had gone wrong in our case. It may be your problem is from some other cause, however.

We discovered that if one were to load a different edition of the class definition from the changes browser, the existing compiled methods would not be recompiled to reflect the different instance variables and slots that the class change entailed.


I hope this is what is affecting you, as I would not want there to be a second cause of this!
       Richard

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/PoWyxTmDtJYJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.