Looks like a Cog issue, I was able to reproduce it:
When I download "PharoCore-1.2.zip" from https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/126/ (which is a Pharo 1.2 Core #12303 image) and I directly start the image with the latest Win32 Cog VM from Eliot then I'm not able to go through update #12304 via the update mechanism as I already wrote in [1]. I get this error: => ClassBuilder(Object)>>doesNotUnderstand: #reshapeClass:toSuper: When I use the standard VM I'm able to update correctly to the latest version pharo core 1.2 #12307 Maybe Eliot is able to reproduce and fix it. Until then I switch to standard VM. Thx Torsten [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/039747.html -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de |
Thanks torsten.
Stef On Jan 17, 2011, at 1:21 PM, Torsten Bergmann wrote: > Looks like a Cog issue, I was able to reproduce it: > > When I download "PharoCore-1.2.zip" from > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/126/ > > (which is a Pharo 1.2 Core #12303 image) and I directly start the image > with the latest Win32 Cog VM from Eliot then I'm not able > to go through update #12304 via the update mechanism > as I already wrote in [1]. I get this error: > > => ClassBuilder(Object)>>doesNotUnderstand: #reshapeClass:toSuper: > > When I use the standard VM I'm able to update correctly > to the latest version pharo core 1.2 #12307 > > Maybe Eliot is able to reproduce and fix it. Until then I switch > to standard VM. > > Thx > Torsten > > > [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/039747.html > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > |
In reply to this post by Torsten Bergmann
On Mon, Jan 17, 2011 at 4:21 AM, Torsten Bergmann <[hidden email]> wrote: Looks like a Cog issue, I was able to reproduce it: Yes, the StackToRegisterMappingCogit gets confused by the initial assignment of nil in oldClass subclasses do: [:oldSubclass | | newSubclass | copyOfOldTraitComposition := copyOfOldClassTraitComposition := nil.
assuming the nil is a temp initialization rather than merely an operand, and hence gets confused about the stack layout (is off by one) and ends up sending reshapeClass:toSuper: to the first temp (which is nil) instead of the receiver. The fix is probably to duplicate the implementation of BlockLocalTempCounter in the block scanning part of the code generator and hence to accurately count the number of temps in a block. This will have to wait for the weekend :/
By the way it looks to me that making copyOfOldTraitComposition & copyOfOldClassTraitComposition local temps in each of the do: blocks won't change the semantics and will remove the need to initialize them explicitly.
|
On 18 January 2011 07:51, Eliot Miranda <[hidden email]> wrote:
> On Mon, Jan 17, 2011 at 4:21 AM, Torsten Bergmann <[hidden email]> wrote: >> >> Looks like a Cog issue, I was able to reproduce it: >> >> When I download "PharoCore-1.2.zip" from >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/126/ >> >> (which is a Pharo 1.2 Core #12303 image) and I directly start the image >> with the latest Win32 Cog VM from Eliot then I'm not able >> to go through update #12304 via the update mechanism >> as I already wrote in [1]. I get this error: >> >> => ClassBuilder(Object)>>doesNotUnderstand: #reshapeClass:toSuper: > > Thanks, Torsten! > Yes, the StackToRegisterMappingCogit gets confused by the initial assignment > of nil in > oldClass subclasses do: [:oldSubclass | | newSubclass | > copyOfOldTraitComposition := copyOfOldClassTraitComposition := nil. > assuming the nil is a temp initialization rather than merely an operand, and > hence gets confused about the stack layout (is off by one) and ends up > sending reshapeClass:toSuper: to the first temp (which is nil) instead of > the receiver. The fix is probably to duplicate the implementation > of BlockLocalTempCounter in the block scanning part of the code generator > and hence to accurately count the number of temps in a block. This will > have to wait for the weekend :/ -1 bug. which is good :) > By the way it looks to me that making copyOfOldTraitComposition & > copyOfOldClassTraitComposition local temps in each of the do: blocks won't > change the semantics and will remove the need to initialize them explicitly. > >> >> When I use the standard VM I'm able to update correctly >> to the latest version pharo core 1.2 #12307 >> >> Maybe Eliot is able to reproduce and fix it. Until then I switch >> to standard VM. >> >> Thx >> Torsten >> >> >> [1] >> http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/039747.html >> -- >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > > -- Best regards, Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |