Well, I noticed that there is a bug but I cannot reproduce it. It seems that when adding instVars to already existing classes, the slots are moved (they lost they offset). But it looks like if recompilation is not done or even worst, it is donde but it doesn't help. In my case I was creating the instVars directly from the browser when saving a method that used those yet-unexistinting instVars..

anyway, pay attention if you have a similar problem so that we can track the cause.

cheers

On Wed, May 16, 2012 at 8:57 PM, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:
would it not that the classBuilder use a different path and that it sort iv on some ways and not on the other ones.


> Hi guys. Today we had something really strange with Pharo 2.0. We are serializing FLPackage:
>
> Object subclass: #FLPackage
> � � instanceVariableNames: 'extensionMethods behaviors mustInitialize preLoadActions postLoadActions additionalObjects'
> � � classVariableNames: 'MustInitializeByDefault'
> � � poolDictionaries: ''
> � � category: 'FuelPackageLoader'
>
> That definition, where 'extensionMethods' is before 'behaviors' it works perfect. However, when just switching the oder to:
>
> Object subclass: #FLPackage
> � � instanceVariableNames: 'behaviors extensionMethods mustInitialize preLoadActions postLoadActions additionalObjects'
> � � classVariableNames: 'MustInitializeByDefault'
> � � poolDictionaries: ''
> � � category: 'FuelPackageLoader'
>
>
> The serialization of PharoCore fails because a problem with a metaclass of HTTPSocket.
>
> Any idea what can happen?
>
> thanks
>
> --
> Mariano
> http://marianopeck.wordpress.com
>





--
Mariano
http://marianopeck.wordpress.com