I serialized an object in #40539. When I materialized in the same image, the object is fine. When I materialized in another $40555 image, one of the values is in the wrong inst var! Fuel has not changed - the same packages are loaded. What could be causing this? Is it a bug?
Sean P. DeNigris wrote
When I materialized in another $40555 image, one of the values is in the wrong inst var!
Same in both images: VsVendor instanceVariables. VsVendor instVarIndexFor: #name. VsVendor instVarIndexFor: #aliases. Different between images: VsVendor slots. "#name and #aliases are reversed" Could this be the source of the error? NB: the source image had the slots reversed compared to the inst var indexes, the file-in target had the slots in the same order as the inst var indexes. If it helps, here's a fileout of the class and the fuel file: VsVendor.st <http://forum.world.st/file/n4811630/VsVendor.st> vendor.st <http://forum.world.st/file/n4811630/vendor.st> ----- Cheers, Sean -- View this message in context: http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811630.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Sean P. DeNigris wrote
the file-in target had the slots in the same order as the inst var indexes.
One more observation: if I serialize in the second image (the one that originally materialized), and materialize in a fresh image, the object is faithfully created i.e. the same as the serialized object. ----- Cheers, Sean -- View this message in context: http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 13 Mar 2015, at 02:24, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sean P. DeNigris wrote
the file-in target had the slots in the same order as the inst var indexes.
One more observation: if I serialize in the second image (the one that originally materialized), and materialize in a fresh image, the object is faithfully created i.e. the same as the serialized object.
Hi Sean This definitely sounds like a problem related to slots. Fuel materializes instance variables by name and not by index, so what you describe shouldnât be possible. Iâll see what I can find. Cheers, Max
----- Cheers, Sean -- View this message in context: http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 13 Mar 2015, at 07:37, Max Leske <maxleske@gmail.com> wrote:
On 13 Mar 2015, at 02:24, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sean P. DeNigris wrote
the file-in target had the slots in the same order as the inst var indexes.
One more observation: if I serialize in the second image (the one that originally materialized), and materialize in a fresh image, the object is faithfully created i.e. the same as the serialized object.
Hi Sean
This definitely sounds like a problem related to slots. Fuel materializes instance variables by name and not by index, so what you describe shouldnât be possible. Iâll see what I can find.
Well, that was actually wrong. Fuel does use indeces, not names during materialization.
Cheers, Max
I wasnât able to reproduce your problem. I see the problem when I materialize your file but when I try to recreate the situation everything works. Have you tried the same with two fresh images (of the same version respectively)? I even tried switching around instance variables to see if I could see a difference in ordering when using #instanceVariables et al but no luck. It really looks like you serialized an instance of a class with switched instance variables. What I donât understand, is how you got to the situation where âself slotsâ didnât have the same ordering as âself instanceVariablesâ.
----- Cheers, Sean -- View this message in context: http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 13 Mar 2015, at 08:39, Max Leske <maxleske@gmail.com> wrote:
On 13 Mar 2015, at 07:37, Max Leske <maxleske@gmail.com> wrote:
On 13 Mar 2015, at 02:24, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sean P. DeNigris wrote
the file-in target had the slots in the same order as the inst var indexes.
One more observation: if I serialize in the second image (the one that originally materialized), and materialize in a fresh image, the object is faithfully created i.e. the same as the serialized object.
Hi Sean
This definitely sounds like a problem related to slots. Fuel materializes instance variables by name and not by index, so what you describe shouldnât be possible. Iâll see what I can find.
Well, that was actually wrong. Fuel does use indeces, not names during materialization.
Cheers, Max
I wasnât able to reproduce your problem. I see the problem when I materialize your file but when I try to recreate the situation everything works. Have you tried the same with two fresh images (of the same version respectively)?
I even tried switching around instance variables to see if I could see a difference in ordering when using #instanceVariables et al but no luck. It really looks like you serialized an instance of a class with switched instance variables.
What I donât understand, is how you got to the situation where âself slotsâ didnât have the same ordering as âself instanceVariablesâ.
AFAICT that can only happen if thereâs an error during class modification, since this ClassDescription>>superclass: aSuperclass layout: aLayout layout := aLayout. self superclass: aSuperclass methodDictionary: MethodDictionary new format: aLayout format. self halt. instanceVariables := layout instanceVariables asArray is (in practice) the only place where âinstanceVariablesâ is set.
----- Cheers, Sean -- View this message in context: http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html <http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
ClassDescription>>superclass: aSuperclass layout: aLayout layout := aLayout.
self superclass: aSuperclass methodDictionary: MethodDictionary new format: aLayout format. self halt. instanceVariables := layout instanceVariables asArray
is (in practice) the only place where âinstanceVariablesâ is set.
We need to remove the instanceVariables from ClassDescription and rely on the layout object. This is on my list for Pharo5⦠#instanceVariables does not even return variables, but strings⦠And it is fun that #instanceVariables and #instVarNames are similarly named yet different... Marcus
On 13 Mar 2015, at 09:01, Marcus Denker <marcus.denker@inria.fr> wrote:
ClassDescription>>superclass: aSuperclass layout: aLayout layout := aLayout.
self superclass: aSuperclass methodDictionary: MethodDictionary new format: aLayout format. self halt. instanceVariables := layout instanceVariables asArray
is (in practice) the only place where âinstanceVariablesâ is set.
We need to remove the instanceVariables from ClassDescription and rely on the layout object. This is on my list for Pharo5â¦
Cool!
#instanceVariables does not even return variables, but stringsâ¦
And it is fun that #instanceVariables and #instVarNames are similarly named yet differentâ¦
Yes, itâs very confusing at the moment...
Marcus
Le 13/3/15 09:01, Marcus Denker a écrit :
ClassDescription>>superclass: aSuperclass layout: aLayout layout := aLayout.
self superclass: aSuperclass methodDictionary: MethodDictionary new format: aLayout format. self halt. instanceVariables := layout instanceVariables asArray
is (in practice) the only place where âinstanceVariablesâ is set.
We need to remove the instanceVariables from ClassDescription and rely on the layout object. This is on my list for Pharo5â¦
#instanceVariables does not even return variables, but stringsâ¦
And it is fun that #instanceVariables and #instVarNames are similarly named yet different...
Marcus I remember that I added some protocols and I paid attention that it was clear that we would either manipulate a string or the instance variable because I was thinking that one day we would get first class variable. Now it was probably not done everywhere. Stef
Marcus
On 13 Mar 2015, at 08:39, Max Leske <maxleske@gmail.com> wrote:
On 13 Mar 2015, at 07:37, Max Leske <maxleske@gmail.com> wrote:
On 13 Mar 2015, at 02:24, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sean P. DeNigris wrote
the file-in target had the slots in the same order as the inst var indexes.
One more observation: if I serialize in the second image (the one that originally materialized), and materialize in a fresh image, the object is faithfully created i.e. the same as the serialized object.
Hi Sean
This definitely sounds like a problem related to slots. Fuel materializes instance variables by name and not by index, so what you describe shouldnât be possible. Iâll see what I can find.
Well, that was actually wrong. Fuel does use indeces, not names during materialization.
And again I have to correct myself: I was right the first time around, Fuel *does* use indices but *after* determining those indices from the variable names (so the serialized object only holds the variable names, not their indices). In addition, all operations concerning instance variables are done through #instanceVariables. We never use #instVarNames or others, so I really canât see how this could have happened.
Cheers, Max
I wasnât able to reproduce your problem. I see the problem when I materialize your file but when I try to recreate the situation everything works. Have you tried the same with two fresh images (of the same version respectively)?
I even tried switching around instance variables to see if I could see a difference in ordering when using #instanceVariables et al but no luck. It really looks like you serialized an instance of a class with switched instance variables.
What I donât understand, is how you got to the situation where âself slotsâ didnât have the same ordering as âself instanceVariablesâ.
----- Cheers, Sean -- View this message in context: http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html <http://forum.world.st/BUG-Strange-Fuel-Result-tp4811628p4811631.html> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
participants (5)
-
Marcus Denker -
Max Leske -
Sean DeNigris -
Sean P. DeNigris
-
stepharo