may be a side effect of the layout introduction and the fact that the class builder should be rewritten.
Stef On May 17, 2012, at 12:39 PM, Mariano Martinez Peck wrote: > 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 <[email protected]> > 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 >
