Release candidate Squeak4.4-12319 ready
Locked
12
12
Re: Release candidate Squeak4.4-12319 Test Results Cog OSX
 
|
On Thu, Dec 20, 2012 at 2:08 AM, Frank Shearar <[hidden email]> wrote:
It just needs to be executed before the image is shipped. The problem is that PackageInfo class>>named: used to find PackageInfo subclasses, back when the MC tests were written. Then the behaviour of PackageInfo was changed, so that PackageInfo subclasses have to register themselves during class initialization. But since MC was already in the base image, the class initialize method for MCMockPackageInfo was never called.
As a result, the 'MonticelloMocks' package that the MC tests use is a vanilla PackageInfo instance, which is empty. That leads to the MCSnapshotResource for a test run being empty, which causes #tearDown methods to fail to restore the mocks after a test that alters them. That's why #one is missing.
Ultimately, this isn't a problem in the code, it's in the state of the image. All you have to do is execute "MCMockPackageInfo initialize" *before* running the tests, and everything works fine. Add it to ReleaseBuilder so that the image will ship with a properly initialized mocks package.
Colin |
Re: Release candidate Squeak4.4-12319 Test Results Cog OSX
|
|
On 20 December 2012 07:39, Colin Putney <[hidden email]> wrote:
> > > On Thu, Dec 20, 2012 at 2:08 AM, Frank Shearar <[hidden email]> > wrote: >> >> So I tried an experiment last night where I manually re-added >> MCMockClassA >> #one, which failed dismally. Would adding >> "MCMockPackageInfo initialize" be the right thing to do in MCTestCase >> >> #tearDown? (That seems kind've strange; I don't see why that would >> re-add a deleted method, for instance. Unless initialising wiped out >> local changes... I'll try this out on the train to work today.) > > > It just needs to be executed before the image is shipped. The problem is > that PackageInfo class>>named: used to find PackageInfo subclasses, back > when the MC tests were written. Then the behaviour of PackageInfo was > changed, so that PackageInfo subclasses have to register themselves during > class initialization. But since MC was already in the base image, the class > initialize method for MCMockPackageInfo was never called. > > As a result, the 'MonticelloMocks' package that the MC tests use is a > vanilla PackageInfo instance, which is empty. That leads to the > MCSnapshotResource for a test run being empty, which causes #tearDown > methods to fail to restore the mocks after a test that alters them. That's > why #one is missing. Right. And the reason for THAT is because this image is derived from a 4.3 image - pre the PackageInfo change - and has never had the necessary state reset! > Ultimately, this isn't a problem in the code, it's in the state of the > image. All you have to do is execute "MCMockPackageInfo initialize" *before* > running the tests, and everything works fine. Add it to ReleaseBuilder so > that the image will ship with a properly initialized mocks package. I shall! > Colin > > > |
Re: Release candidate Squeak4.4-12319 Test Results Cog OSX
|
|
On 20 December 2012 07:52, Frank Shearar <[hidden email]> wrote:
> On 20 December 2012 07:39, Colin Putney <[hidden email]> wrote: >> >> >> On Thu, Dec 20, 2012 at 2:08 AM, Frank Shearar <[hidden email]> >> wrote: >>> >>> So I tried an experiment last night where I manually re-added >>> MCMockClassA >> #one, which failed dismally. Would adding >>> "MCMockPackageInfo initialize" be the right thing to do in MCTestCase >>> >> #tearDown? (That seems kind've strange; I don't see why that would >>> re-add a deleted method, for instance. Unless initialising wiped out >>> local changes... I'll try this out on the train to work today.) >> >> >> It just needs to be executed before the image is shipped. The problem is >> that PackageInfo class>>named: used to find PackageInfo subclasses, back >> when the MC tests were written. Then the behaviour of PackageInfo was >> changed, so that PackageInfo subclasses have to register themselves during >> class initialization. But since MC was already in the base image, the class >> initialize method for MCMockPackageInfo was never called. >> >> As a result, the 'MonticelloMocks' package that the MC tests use is a >> vanilla PackageInfo instance, which is empty. That leads to the >> MCSnapshotResource for a test run being empty, which causes #tearDown >> methods to fail to restore the mocks after a test that alters them. That's >> why #one is missing. > > Right. And the reason for THAT is because this image is derived from a > 4.3 image - pre the PackageInfo change - and has never had the > necessary state reset! But that doesn't explain why CI didn't experience/report these failures. frank >> Ultimately, this isn't a problem in the code, it's in the state of the >> image. All you have to do is execute "MCMockPackageInfo initialize" *before* >> running the tests, and everything works fine. Add it to ReleaseBuilder so >> that the image will ship with a properly initialized mocks package. > > I shall! > >> Colin >> >> >> |
Re: Release candidate Squeak4.4-12319 ready
|
|
In reply to this post by Frank Shearar-3
On 12/19/12 6:31 PM, "Frank Shearar" <[hidden email]> wrote: > Excellent! > > One thing I noticed was the ChangeSet looking wonky. Now > ReleaseBuilderFor4dot4 class >> #prepareNewBuild calls #cleanUp: on > anything that understands it, which means that, in particular, it > calls ChangeSet cleanUp: true. Nevertheless, the Simple Change Sorter > tells a different story. If you then run ChangeSet cleanUp: true > yourself, the SCS shows what I'd expect: an empty Unnamed1. > > frank > Why do not merge both Change Sorter in only one like Pharo an Cuis ? Edgar |
Re: Release candidate Squeak4.4-12319 Test Results Cog OSX
|
|
In reply to this post by Colin Putney-3
Hi,
> > Ultimately, this isn't a problem in the code, it's in the state of the > image. All you have to do is execute "MCMockPackageInfo initialize" > *before* running the tests, and everything works fine. Add it to > ReleaseBuilder so that the image will ship with a properly initialized > mocks package. > it seems this is the case. On Win 7 I get errors like the others did, regardless of setting author initials before or during the tests. If I run the above snippets before the tests I get: 3272 run, 3251 passes, 18 expected failures, 2 failures, 1 errors, 0 unexpected passes, the error in FileDirectoryTest>>testRelativeNameIfAbsoluteFor, the failures in LocaleTest>>testLocaleChanged and ReleaseTest>>testNoObsoleteClasses. I'm using this VM: Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.234] Win32 built on Dec 15 2012 13:17:01 Compiler: 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) I think there is a newer VM. Frank, have you decided on the release VM? Cheers, Herbert |
Re: Release candidate Squeak4.4-12319 Test Results Cog OSX
|
|
On 20 December 2012 10:02, Herbert König <[hidden email]> wrote:
> Hi, > > >> >> Ultimately, this isn't a problem in the code, it's in the state of the >> image. All you have to do is execute "MCMockPackageInfo initialize" *before* >> running the tests, and everything works fine. Add it to ReleaseBuilder so >> that the image will ship with a properly initialized mocks package. >> > > it seems this is the case. On Win 7 I get errors like the others did, > regardless of setting author initials before or during the tests. If I run > the above snippets before the tests I get: > 3272 run, 3251 passes, 18 expected failures, 2 failures, 1 errors, 0 > unexpected passes, > the error in FileDirectoryTest>>testRelativeNameIfAbsoluteFor, > the failures in LocaleTest>>testLocaleChanged and > ReleaseTest>>testNoObsoleteClasses. > > I'm using this VM: > Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.234] > Win32 built on Dec 15 2012 13:17:01 Compiler: 3.4.4 (cygming special, gdc > 0.12, using dmd 0.125) > > I think there is a newer VM. Frank, have you decided on the release VM? I have not. The tests run on Cog r2326 and a custom interpreter VM Dave put on squeakci.org, which is almost a 4.10.2.2614 (I think). "Almost" means that it doesn't use glibc 2.15, which is more recent than squeakci's version (and Ubuntu Lucid Lynx, for that matter). frank |
Re: Release candidate Squeak4.4-12319 ready
|
|
In reply to this post by Edgar De Cleene
On 20 December 2012 09:23, Edgar J. De Cleene <[hidden email]> wrote:
> > > > On 12/19/12 6:31 PM, "Frank Shearar" <[hidden email]> wrote: > >> Excellent! >> >> One thing I noticed was the ChangeSet looking wonky. Now >> ReleaseBuilderFor4dot4 class >> #prepareNewBuild calls #cleanUp: on >> anything that understands it, which means that, in particular, it >> calls ChangeSet cleanUp: true. Nevertheless, the Simple Change Sorter >> tells a different story. If you then run ChangeSet cleanUp: true >> yourself, the SCS shows what I'd expect: an empty Unnamed1. >> >> frank >> > > Why do not merge both Change Sorter in only one like Pharo an Cuis ? That's a question for 4.5, but they do different things. If I had to give up one, I'd rather give up the single change sorter. frank |
Re: Release candidate Squeak4.4-12319 Test Results Cog OSX
|
|
In reply to this post by Frank Shearar-3
Hi Frank, there's been a lot of churn in my VMs lately. I'm afraid I have to insist that you use at least the 2640 VM. This is the only one that both a) avoids a bad bug I introduced recently in the change class primitives, and b) has fixed stack headroom calculation and improved signal handling to eliminate occasional crashes on linux.
On Thu, Dec 20, 2012 at 2:35 AM, Frank Shearar <[hidden email]> wrote:
best, Eliot
|
Re: Release candidate Squeak4.4-12319 Test Results Cog OSX
|
|
On Fri, Dec 21, 2012 at 9:54 AM, Eliot Miranda <[hidden email]> wrote:
(and has the large integer tests fixed, and the ipv6 network support prims integrated)
best, Eliot
|
Re: [Vm-dev] Re: [squeak-dev] Release candidate Squeak4.4-12319 Test Results Cog OSX
|
|
On 21 December 2012 17:55, Eliot Miranda <[hidden email]> wrote:
> > > > > On Fri, Dec 21, 2012 at 9:54 AM, Eliot Miranda <[hidden email]> wrote: >> >> Hi Frank, >> >> there's been a lot of churn in my VMs lately. I'm afraid I have to insist that you use at least the 2640 VM. This is the only one that both a) avoids a bad bug I introduced recently in the change class primitives, and b) has fixed stack headroom calculation and improved signal handling to eliminate occasional crashes on linux. > > > (and has the large integer tests fixed, and the ipv6 network support prims integrated) I'm trying it out right now (and testing out a new build script at the same time) at http://squeakci.org/job/SqueakTrunk/75/. And look! KernelTests.Numbers.LargeNegativeIntegerTest.testMinimumNegativeIntegerArithmetic passes! Thanks very much, Eliot! frank >> On Thu, Dec 20, 2012 at 2:35 AM, Frank Shearar <[hidden email]> wrote: >>> >>> On 20 December 2012 10:02, Herbert König <[hidden email]> wrote: >>> > Hi, >>> > >>> > >>> >> >>> >> Ultimately, this isn't a problem in the code, it's in the state of the >>> >> image. All you have to do is execute "MCMockPackageInfo initialize" *before* >>> >> running the tests, and everything works fine. Add it to ReleaseBuilder so >>> >> that the image will ship with a properly initialized mocks package. >>> >> >>> > >>> > it seems this is the case. On Win 7 I get errors like the others did, >>> > regardless of setting author initials before or during the tests. If I run >>> > the above snippets before the tests I get: >>> > 3272 run, 3251 passes, 18 expected failures, 2 failures, 1 errors, 0 >>> > unexpected passes, >>> > the error in FileDirectoryTest>>testRelativeNameIfAbsoluteFor, >>> > the failures in LocaleTest>>testLocaleChanged and >>> > ReleaseTest>>testNoObsoleteClasses. >>> > >>> > I'm using this VM: >>> > Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.234] >>> > Win32 built on Dec 15 2012 13:17:01 Compiler: 3.4.4 (cygming special, gdc >>> > 0.12, using dmd 0.125) >>> > >>> > I think there is a newer VM. Frank, have you decided on the release VM? >>> >>> I have not. The tests run on Cog r2326 and a custom interpreter VM >>> Dave put on squeakci.org, which is almost a 4.10.2.2614 (I think). >>> "Almost" means that it doesn't use glibc 2.15, which is more recent >>> than squeakci's version (and Ubuntu Lucid Lynx, for that matter). >>> >>> frank >>> >> >> >> >> -- >> best, >> Eliot > > > > > -- > best, > Eliot > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |