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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Dennis smith-4
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).


--
Dennis Smith                                  +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada                     http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

--
GemStone-Smalltalk mailing list
Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
  [hidden email]
Archive: http://forum.world.st/Gemstone-Customers-f1461796.html
Reply | Threaded
Open this post in threaded view
|

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

Lisa Almarode-2
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).
>
>

--
GemStone-Smalltalk mailing list
Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
  [hidden email]
Archive: http://forum.world.st/Gemstone-Customers-f1461796.html
Reply | Threaded
Open this post in threaded view
|

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

Dennis smith-4
Ths instance variables (which are on the class side!!) are part of the
Class hierarchy, and are in fact (there were a number of ivars noted)
in "Behavior".

So what it would SEEM like is that the class is somehow still not in the
proper GS3 hierarchy??



On 2013-01-15 4:28 PM, Lisa Almarode wrote:

> 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).
>>
>>

--
Dennis Smith                                  +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada                     http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

--
GemStone-Smalltalk mailing list
Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
  [hidden email]
Archive: http://forum.world.st/Gemstone-Customers-f1461796.html
Reply | Threaded
Open this post in threaded view
|

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

Dennis smith-4
In reply to this post by Dennis smith-4
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 2013-01-15 3: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).
>
>

--
Dennis Smith                                  +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada                     http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

--
GemStone-Smalltalk mailing list
Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
  [hidden email]
Archive: http://forum.world.st/Gemstone-Customers-f1461796.html
Reply | Threaded
Open this post in threaded view
|

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

Martin McClure-3
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
--
GemStone-Smalltalk mailing list
Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
  [hidden email]
Archive: http://forum.world.st/Gemstone-Customers-f1461796.html
Reply | Threaded
Open this post in threaded view
|

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

Dennis smith-4
Thanks martin -- did that (turned off confirm) this morning :)

Nothing like hiding a problem :)  but works for me!


On 2013-01-16 5:57 PM, Martin McClure wrote:

> 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

--
Dennis Smith                                  +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada                     http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

--
GemStone-Smalltalk mailing list
Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
  [hidden email]
Archive: http://forum.world.st/Gemstone-Customers-f1461796.html
Reply | Threaded
Open this post in threaded view
|

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

Martin McClure-3
On 01/16/2013 02:59 PM, Dennis Smith wrote:
> Thanks martin -- did that (turned off confirm) this morning :)
>
> Nothing like hiding a problem :)  but works for me!

Glad to hear it. As far as I can tell, there are no ill effects from
doing this, it's just a nuisance warning from an over-strict consistency
check.

Regards,

-Martin
--
GemStone-Smalltalk mailing list
Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
  [hidden email]
Archive: http://forum.world.st/Gemstone-Customers-f1461796.html