Weird issue with removing instance vars from class def: instance vars jumbled
I guess this has happened to other people. In Pharo 20 and while using Seaside, I was adding, removing , changing components which were making a component and it happened that if I had, let say: a b c d e f turned into a c f Well, c kind of pointed to a b in existing instances and f to old c etc; No matter how much I unregister and reregisted my app, this continued. I got out of the problem by filing out the code and filing it in back, which recomplied the whole component. Weird. I can understand that some existing bytecode wasn't updated when rearranging instvars but for someone new to the game, this would really be weird. Clues? Phil
phil@highoctane.be wrote:
I guess this has happened to other people.
In Pharo 20 and while using Seaside, I was adding, removing , changing components which were making a component and it happened that if I had, let say:
a b c d e f
turned into
a c f
Well, c kind of pointed to a b in existing instances and f to old c etc;
No matter how much I unregister and reregisted my app, this continued. I got out of the problem by filing out the code and filing it in back, which recomplied the whole component.
How do you go with just a "Compiler recompileAll" on its own ?
Weird.
I can understand that some existing bytecode wasn't updated when rearranging instvars but for someone new to the game, this would really be weird.
Clues?
Phil
Can I do that on a given class? Compiler recompileAll would take ages I guess...
On Oct 1, 2013, at 9:02 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Can I do that on a given class? Compiler recompileAll would take ages I guess...
Yes: Object compileAll (we should make the API consistent⦠on CompiledMethod is is #recompile, Compiler has recompileAll, on the whole system (Smalltalk image) it is missingâ¦.) Marcus
Still, why does it occur ? Normal ? I experienced that on a class with quite a number of instVars.
On Oct 1, 2013, at 9:34 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Still, why does it occur ? Normal ? I experienced that on a class with quite a number of instVars.
This seems to be a bug. When you remove / add inst vars, the offset of all those behind need to change (and all in the subclass). This is done by the ClassBuilder by recompiling (there is code somewhere to do it more intelligently, by using bytecode level IR to patch the offsets, but this is not yet active). We need some reproducible case to fix the problem⦠because normally the class builder does the right thing, I wonder in which case there is a problem. Marcus
Am 01.10.2013 um 09:37 schrieb Marcus Denker <marcus.denker@inria.fr>:
On Oct 1, 2013, at 9:34 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Still, why does it occur ? Normal ? I experienced that on a class with quite a number of instVars.
This seems to be a bug. When you remove / add inst vars, the offset of all those behind need to change (and all in the subclass). This is done by the ClassBuilder by recompiling (there is code somewhere to do it more intelligently, by using bytecode level IR to patch the offsets, but this is not yet active).
We need some reproducible case to fix the problem⦠because normally the class builder does the right thing, I wonder in which case there is a problem.
I have the same opinion that the behavior changed quite a bit. E.g. I can't remember that it was allowed to have shadowed instance variabels. Nowadays there is not even a warning. Norbert
On Oct 1, 2013, at 10:13 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 01.10.2013 um 09:37 schrieb Marcus Denker <marcus.denker@inria.fr>:
On Oct 1, 2013, at 9:34 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Still, why does it occur ? Normal ? I experienced that on a class with quite a number of instVars.
This seems to be a bug. When you remove / add inst vars, the offset of all those behind need to change (and all in the subclass). This is done by the ClassBuilder by recompiling (there is code somewhere to do it more intelligently, by using bytecode level IR to patch the offsets, but this is not yet active).
We need some reproducible case to fix the problem⦠because normally the class builder does the right thing, I wonder in which case there is a problem.
I have the same opinion that the behavior changed quite a bit. E.g. I can't remember that it was allowed to have shadowed instance variabels. Nowadays there is not even a warning.
Yes, that was a mistake I introduced. In Pharo2 development phase, I merged some classes. For that the first step was to move ivars from the subclass to the superclass. The resulting change was not mergable, not even with a chagneset. (I think raising an Error in the ClassBuilder is wrong, it needed to be a Warning, I (wrongly) just removed it). This has been fixed in Pharo3 with the new class builder. As it's a complete reimplemenation, there is no back port. And doing that chagne again in Pharo2 did not seem that important, but if someone fixes it we of course will include it. Marcus
I think that I may have reordered some instVars as well in the process. They look like in alphabetical order when autogenerated from the refactorings menu (instvar accessors). Also, I regenerated them more than once and removed some manually. (Which makes me think that a "unselect all" from that menu would be welcome...) I'll look for a reproducable sample. Working on that tomorrow. Phil
participants (4)
-
btc＠openinworld.com -
Marcus Denker -
Norbert Hartl -
phil＠highoctane.be