GS2 to GS3 upgrade, problem with a few classes ...

> I am using GS64 3.1.0.2 and GBS 7.5
>
> I have recompiled the source for all my classes.
>
> For about 4 classes, I get this kind of thing sometimes ...
>
>
>     Class <PPsmVw class> includes in its <instVarMap>,
>          the name instVarsInfo which is not a server instance variable name
>
> Note that this always class-side, and the instVarsInfo  name is from the
> GS3 hierarchy  and is not in the GS2
> hierarchy, so there is some reasonableness here.
>
> Howevfer, I have a number of times done a class file-out and file-in on
> these (gs fileOut/In), and I still get this.
> One other interesting thing is that all but ONE of these classes have no
> instance-side methods, and the one that does seemed fine until just
> recently (the others have been doing this for a few weeks now as I
> worked at the GS3 port).
>
>

> What does the client class PPsmVw look like?  You'd get this error if
> the client class has the instance variable, but not the server class.
>
> On 1/15/2013 12:48 PM, Dennis Smith wrote:
>> I am using GS64 3.1.0.2 and GBS 7.5
>>
>> I have recompiled the source for all my classes.
>>
>> For about 4 classes, I get this kind of thing sometimes ...
>>
>>
>>      Class <PPsmVw class> includes in its <instVarMap>,
>>           the name instVarsInfo which is not a server instance variable name
>>
>> Note that this always class-side, and the instVarsInfo  name is from the
>> GS3 hierarchy  and is not in the GS2
>> hierarchy, so there is some reasonableness here.
>>
>> Howevfer, I have a number of times done a class file-out and file-in on
>> these (gs fileOut/In), and I still get this.
>> One other interesting thing is that all but ONE of these classes have no
>> instance-side methods, and the one that does seemed fine until just
>> recently (the others have been doing this for a few weeks now as I
>> worked at the GS3 port).
>>
>>

> I am using GS64 3.1.0.2 and GBS 7.5
>
> I have recompiled the source for all my classes.
>
> For about 4 classes, I get this kind of thing sometimes ...
>
>
>     Class <PPsmVw class> includes in its <instVarMap>,
>          the name instVarsInfo which is not a server instance variable
> name
>
> Note that this always class-side, and the instVarsInfo  name is from
> the GS3 hierarchy  and is not in the GS2
> hierarchy, so there is some reasonableness here.
>
> Howevfer, I have a number of times done a class file-out and file-in
> on these (gs fileOut/In), and I still get this.
> One other interesting thing is that all but ONE of these classes have
> no instance-side methods, and the one that does seemed fine until just
> recently (the others have been doing this for a few weeks now as I
> worked at the GS3 port).
>
>

> Further to this (working the class side), if I look at say
>     System class _instVarNames
> or
>     Collection class _instVarNames
> I get
> #(#superClass #format #instVars #instVarNames #constraints #classVars
> #methodDict #poolDictionaries #categories #secondarySuperclasses #name
> #classHistory #description #migrationDestination #timeStamp #userId
> #extraDict #classCategory #subclasses)
>
> Which appears to be incorrect, since the class hierarchy is (or should
> be)   Class -> Metaclass3 -> Module -> Behavior and "Behavior" has ivars
> ...
> #(superClass format instVarsInfo instVarNames constraints classVars
> methDicts poolDictionaries categorys primaryCopy)
>
>
> What I see as _instVarNames looks a bit like the GS2.x list of names.
>
> This was a 2.x database updated via "upgradeImage -s stoneName", and
> given that I get the GS3 classes (like Metaclass3) it would seem the
> upgrade was correct.
>
> Where this creates a problem is in
>     GbxOffsetCache >> generateNamedOffsets
> which gets the list of GS ivars using "_instVarNames".

> On 01/16/2013 06:35 AM, Dennis Smith wrote:
>> Further to this (working the class side), if I look at say
>>      System class _instVarNames
>> or
>>      Collection class _instVarNames
>> I get
>> #(#superClass #format #instVars #instVarNames #constraints #classVars
>> #methodDict #poolDictionaries #categories #secondarySuperclasses #name
>> #classHistory #description #migrationDestination #timeStamp #userId
>> #extraDict #classCategory #subclasses)
>>
>> Which appears to be incorrect, since the class hierarchy is (or should
>> be)   Class -> Metaclass3 -> Module -> Behavior and "Behavior" has ivars
>> ...
>> #(superClass format instVarsInfo instVarNames constraints classVars
>> methDicts poolDictionaries categorys primaryCopy)
>>
>>
>> What I see as _instVarNames looks a bit like the GS2.x list of names.
>>
>> This was a 2.x database updated via "upgradeImage -s stoneName", and
>> given that I get the GS3 classes (like Metaclass3) it would seem the
>> upgrade was correct.
>>
>> Where this creates a problem is in
>>      GbxOffsetCache >> generateNamedOffsets
>> which gets the list of GS ivars using "_instVarNames".
> Hi Dennis,
>
> Thanks for the report, there is indeed a problem. Upgraded repositories
> can legitimately have old-style metaclasses in them, and there are cases
> in which GBS doesn't handle this correctly.
>
> I'm working on a "proper" fix, but you may be able to get past this for
> now by just turning off "confirm" in the GBS configuration. Please let
> us know whether this works for you.
>
> Regards,
>
> -Martin