* http://ftp.squeak.org/4.4/Squeak4.4-12319.tgz
* http://ftp.squeak.org/4.4/Squeak4.4-12319.zip This just * remerges Eliot's findA... fix * corrects (finally! thanks to Klaus for the reminder!) the URL to Andreas Raab's Community Supported Packages link frank |
3272 run, 3228 passes, 18 expected failures, 16 failures, 10 errors, 0 unexpected passes
LocaleTest>>#testLocaleChanged MCChangeNotificationTest>>#testCoreMethodModified MCFileInTest>>#testStWriter MCPackageTest>>#testUnload MCPatchTest>>#testPatchContents MCSnapshotBrowserTest>>#testNoSelection MCSnapshotTest>>#testCreation MCStWriterTest>>#testOrganizationDefinition MCWorkingCopyTest>>#testBackport MCWorkingCopyTest>>#testOptimizedLoad MCWorkingCopyTest>>#testRepeatedMerge MCWorkingCopyTest>>#testSelectiveBackport MCWorkingCopyTest>>#testSimpleMerge MCWorkingCopyTest>>#testSnapshotAndLoad SocketTest>>#testSocketReuse SocketTest>>#testUDP MCChangeNotificationTest>>#testExtMethodModified MCSnapshotBrowserTest>>#testCategorySelected MCSnapshotBrowserTest>>#testClassSelected MCSnapshotBrowserTest>>#testClassSideClassSelected MCSnapshotBrowserTest>>#testComment MCSnapshotBrowserTest>>#testMethodIsCleared MCSnapshotBrowserTest>>#testMethodSelected MCSnapshotBrowserTest>>#testProtocolIsCleared MCSnapshotBrowserTest>>#testProtocolSelected MCStWriterTest>>#testInitializerDefinition Image ----- /Users/eglenpaling/Documents/Smalltalk/Squeak 4.4 Testing/Squeak4.4-12317 Cog/Squeak4.4-12317.image Squeak4.4 latest update: #12317 Current Change Set: Unnamed Image format 6505 (32 bit) Virtual Machine --------------- /Users/eglenpaling/Documents/Smalltalk/Build/VMs/Cog 4.0.2637.app/Contents/MacOS/Croquet Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.238] Croquet Cog 4.0.2637 Mac OS X built on Dec 17 2012 19:54:57 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3) platform sources revision VM: r2637 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins CoInterpreter VMMaker.oscog-eem.238 uuid: a3d10eab-6079-4c91-99f6-3dcf58d1446f Dec 17 2012 StackToRegisterMappingCogit VMMaker.oscog-eem.234 uuid: 66acafd1-cad0-4f20-b786-ab8f48201d82 Dec 17 2012 Operating System/Hardware ------------------------- Mac OS 1068 intel |
On 19 December 2012 19:42, glenpaling <[hidden email]> wrote:
> 3272 run, 3228 passes, 18 expected failures, 16 failures, 10 errors, 0 > unexpected passes > LocaleTest>>#testLocaleChanged > MCChangeNotificationTest>>#testCoreMethodModified > MCFileInTest>>#testStWriter > MCPackageTest>>#testUnload > MCPatchTest>>#testPatchContents > MCSnapshotBrowserTest>>#testNoSelection > MCSnapshotTest>>#testCreation > MCStWriterTest>>#testOrganizationDefinition > MCWorkingCopyTest>>#testBackport > MCWorkingCopyTest>>#testOptimizedLoad > MCWorkingCopyTest>>#testRepeatedMerge > MCWorkingCopyTest>>#testSelectiveBackport > MCWorkingCopyTest>>#testSimpleMerge > MCWorkingCopyTest>>#testSnapshotAndLoad > SocketTest>>#testSocketReuse > SocketTest>>#testUDP > > > MCChangeNotificationTest>>#testExtMethodModified > MCSnapshotBrowserTest>>#testCategorySelected > MCSnapshotBrowserTest>>#testClassSelected > MCSnapshotBrowserTest>>#testClassSideClassSelected > MCSnapshotBrowserTest>>#testComment > MCSnapshotBrowserTest>>#testMethodIsCleared > MCSnapshotBrowserTest>>#testMethodSelected > MCSnapshotBrowserTest>>#testProtocolIsCleared > MCSnapshotBrowserTest>>#testProtocolSelected > MCStWriterTest>>#testInitializerDefinition How exactly do you run the tests? Download image, fire it up, open TestRunner, run tests... and nothing else? When you run the tests, I'll bet MCMethodDefinitionTest>>testLoadAndUnload brings up a FITBM asking for initials, and that breaks all these tests. http://bugs.squeak.org/view.php?id=7700 will fix this, when it's done. frank |
In reply to this post by Frank Shearar-3
3272 run, 3222 passes, 23 expected failures, 16 failures, 11 errors, 0 unexpected passes
LocaleTest>>#testLocaleChanged MCChangeNotificationTest>>#testCoreMethodModified MCFileInTest>>#testStWriter MCPackageTest>>#testUnload MCPatchTest>>#testPatchContents MCSnapshotBrowserTest>>#testNoSelection MCSnapshotTest>>#testCreation MCStWriterTest>>#testOrganizationDefinition MCWorkingCopyTest>>#testBackport MCWorkingCopyTest>>#testOptimizedLoad MCWorkingCopyTest>>#testRepeatedMerge MCWorkingCopyTest>>#testSelectiveBackport MCWorkingCopyTest>>#testSimpleMerge MCWorkingCopyTest>>#testSnapshotAndLoad ProcessTest>>#testAtomicSuspend Win32VMTest>>#testWinVM3ButtonMousePreference FileDirectoryTest>>#testRelativeNameIfAbsoluteFor MCChangeNotificationTest>>#testExtMethodModified MCSnapshotBrowserTest>>#testCategorySelected MCSnapshotBrowserTest>>#testClassSelected MCSnapshotBrowserTest>>#testClassSideClassSelected MCSnapshotBrowserTest>>#testComment MCSnapshotBrowserTest>>#testMethodIsCleared MCSnapshotBrowserTest>>#testMethodSelected MCSnapshotBrowserTest>>#testProtocolIsCleared MCSnapshotBrowserTest>>#testProtocolSelected MCStWriterTest>>#testInitializerDefinition Image ----- D:\Documents and Settings\palingg\My Documents\Programming\Smalltalk\Squeak 4.4\Squeak4.4-12319 interp\Squeak4.4-12319.image Squeak4.4 latest update: #12319 Current Change Set: Unnamed Virtual Machine --------------- D:\Documents and Settings\palingg\My Documents\Programming\Smalltalk\Squeak 4.4\SqueakVM-Win32-4.1.1-bin\Squeak4.1.1.exe Squeak3.10.2 of 11 February 2010 [latest update: #9314] Win32 built on Jul 27 2010 20:35:19 Compiler: 2.95.2 19991024 (release) Operating System Details ------------------------ Operating System: Microsoft Windows XP (Build 2600 Service Pack 3) Registered Owner: Registered Company: SP major version: 3 SP minor version: 0 Suite mask: 100 Product type: 1 |
In reply to this post by Frank Shearar-3
Since you mentioned it a few days ago, I've been setting the author initials before running the tests. Other than CI, has anyone had a successful run of these tests? |
In reply to this post by Frank Shearar-3
I stuck the release candidate into the Squeak 4.3 All-In-One release to run on it's interpreter VM
Test Runner 3272 run, 3222 passes, 23 expected failures, 17 failures, 10 errors, 0 unexpected passes LocaleTest>>#testLocaleChanged MCChangeNotificationTest>>#testCoreMethodModified MCFileInTest>>#testStWriter MCPackageTest>>#testUnload MCPatchTest>>#testPatchContents MCSnapshotBrowserTest>>#testNoSelection MCSnapshotTest>>#testCreation MCStWriterTest>>#testOrganizationDefinition MCWorkingCopyTest>>#testBackport MCWorkingCopyTest>>#testOptimizedLoad MCWorkingCopyTest>>#testRepeatedMerge MCWorkingCopyTest>>#testSelectiveBackport MCWorkingCopyTest>>#testSimpleMerge MCWorkingCopyTest>>#testSnapshotAndLoad ProcessTest>>#testAtomicSuspend SocketTest>>#testSocketReuse SocketTest>>#testUDP MCChangeNotificationTest>>#testExtMethodModified MCSnapshotBrowserTest>>#testCategorySelected MCSnapshotBrowserTest>>#testClassSelected MCSnapshotBrowserTest>>#testClassSideClassSelected MCSnapshotBrowserTest>>#testComment MCSnapshotBrowserTest>>#testMethodIsCleared MCSnapshotBrowserTest>>#testMethodSelected MCSnapshotBrowserTest>>#testProtocolIsCleared MCSnapshotBrowserTest>>#testProtocolSelected MCStWriterTest>>#testInitializerDefinition Image ----- /Users/eglenpaling/Documents/Smalltalk/Squeak 4.4 Testing/Squeak-4.3-All-in-One with 4.4RC inserted.app/Contents/Resources/Squeak4.4-12317.image Squeak4.4 latest update: #12317 Current Change Set: Unnamed Virtual Machine --------------- /Users/eglenpaling/Documents/Smalltalk/Squeak 4.4 Testing/Squeak-4.3-All-in-One with 4.4RC inserted.app/Contents/MacOS/Squeak VM Opt Squeak3.8.1 of '28 Aug 2006' [latest update: #6747] 4.3 Mac Carbon 4.2.4b1 28-Mar-10 >45CAAEAC-5A1E-4327-9702-7973E3473FDE< Operating System/Hardware ------------------------- Mac OS 1068 intel |
In reply to this post by Frank Shearar-3
> * http://ftp.squeak.org/4.4/Squeak4.4-12319.zip
Fixes the NetNameResolver problem on localhost; thanks ! Stef |
In reply to this post by Frank Shearar-3
> How exactly do you run the tests? Download image, fire it up, open
> TestRunner, run tests... and nothing else? Go to Help | About this System and then select the "SUnit" category. > When you run the tests, I'll bet > MCMethodDefinitionTest>>testLoadAndUnload brings up a FITBM asking for > initials, and that breaks all these tests. Why do you say that's breaking the tests? If you "Do It" on one of the failed MC tests it opens the debugger showing the failed assertion even though initials have already been set. These tests weren't failing in 4.3 anyone know what happened? > http://bugs.squeak.org/view.php?id=7700 will fix this, when it's done. The way to handle this is for the "automation" (i.e., CI or whatever) to handle the appropriate UIManager notification (sorry can't remember what its called at the moment). |
In reply to this post by Stéphane Rollandin
On 19 December 2012 21:05, Stéphane Rollandin <[hidden email]> wrote:
>> * http://ftp.squeak.org/4.4/Squeak4.4-12319.zip > > > Fixes the NetNameResolver problem on localhost; thanks ! 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 |
In reply to this post by Chris Muller-3
On 19 December 2012 21:15, Chris Muller <[hidden email]> wrote:
>> How exactly do you run the tests? Download image, fire it up, open >> TestRunner, run tests... and nothing else? > > Go to Help | About this System and then select the "SUnit" category. > >> When you run the tests, I'll bet >> MCMethodDefinitionTest>>testLoadAndUnload brings up a FITBM asking for >> initials, and that breaks all these tests. > > Why do you say that's breaking the tests? If you "Do It" on one of > the failed MC tests it opens the debugger showing the failed assertion > even though initials have already been set. If the author initials aren't set, you get a FITBM asking for it. The proper cleanup and restoration of MC's test state will thus not happen. In particular, MCMockClassA does not get its #one method back, which later tests expect. > These tests weren't failing in 4.3 anyone know what happened? People usually don't run tests without author initials? Certainly these tests have ALWAYS passed on CI, but CI sets the author initials. I have yet to see evidence to contradict my hypothesis. >> http://bugs.squeak.org/view.php?id=7700 will fix this, when it's done. > > The way to handle this is for the "automation" (i.e., CI or whatever) > to handle the appropriate UIManager notification (sorry can't remember > what its called at the moment). You can supply answers to the UIManager queries. One hacky way to solve 7700 is to set the initials if not set, and restore them after the test. Or one could use a dynamic variable, or wrap the #perform: that runs the test with these answering things, or something else. At any rate, unless someone can come up with an alternative hypothesis, or a way to falsify mine, I don't think this is reason to delay 4.4's release. frank |
>> Why do you say that's breaking the tests? If you "Do It" on one of
>> the failed MC tests it opens the debugger showing the failed assertion >> even though initials have already been set. > > If the author initials aren't set, you get a FITBM asking for it. The > proper cleanup and restoration of MC's test state will thus not > happen. In particular, MCMockClassA does not get its #one method back, > which later tests expect. > >> These tests weren't failing in 4.3 anyone know what happened? > > People usually don't run tests without author initials? Certainly > these tests have ALWAYS passed on CI, but CI sets the author initials. > > I have yet to see evidence to contradict my hypothesis. Eh, well I just opened the 4.3 release image and ran tests. It asked for my initials at the beginning and then ran all tests. Those MC tests didn't fail. I don't think we can release without understanding what's going on with them in 4.4. Would someone volunteer? I'm currently looking at Dave's SqueakMap patch is needed now but not before and making sure we can, in fact, deploy packages for 4.4 that will show up in SqueakMaps 4.4 list. |
On 19 December 2012 22:15, Chris Muller <[hidden email]> wrote:
>>> Why do you say that's breaking the tests? If you "Do It" on one of >>> the failed MC tests it opens the debugger showing the failed assertion >>> even though initials have already been set. >> >> If the author initials aren't set, you get a FITBM asking for it. The >> proper cleanup and restoration of MC's test state will thus not >> happen. In particular, MCMockClassA does not get its #one method back, >> which later tests expect. >> >>> These tests weren't failing in 4.3 anyone know what happened? >> >> People usually don't run tests without author initials? Certainly >> these tests have ALWAYS passed on CI, but CI sets the author initials. >> >> I have yet to see evidence to contradict my hypothesis. > > Eh, well I just opened the 4.3 release image and ran tests. It asked > for my initials at the beginning and then ran all tests. Those MC > tests didn't fail. I don't think we can release without understanding > what's going on with them in 4.4. Yes, but did you _fill in_ the initials? At any rate, theories aside, it _is_ the case that the MCMethodDefinitionTest >> #tearDown doesn't restore state correctly. Note that this is #testLoadAndUnload test is the test that pops up the prompt. Subsequent tests fail because, for at least some of them, MCMockClassA >> #one no longer exists. (MCMethodDefinitionTest >> #testLoadAndUnload removes it.) > Would someone volunteer? I'm currently looking at Dave's SqueakMap > patch is needed now but not before and making sure we can, in fact, > deploy packages for 4.4 that will show up in SqueakMaps 4.4 list. Yes, please. I would like some countervailing evidence and/or alternate hypotheses. Nevertheless, these tests definitely run on CI, and definitely pass. Have always passed, in fact. It was only glenpaling's recent findings that brought these tests to my/our attention. frank |
On 19 December 2012 22:44, Frank Shearar <[hidden email]> wrote:
> On 19 December 2012 22:15, Chris Muller <[hidden email]> wrote: >>>> Why do you say that's breaking the tests? If you "Do It" on one of >>>> the failed MC tests it opens the debugger showing the failed assertion >>>> even though initials have already been set. >>> >>> If the author initials aren't set, you get a FITBM asking for it. The >>> proper cleanup and restoration of MC's test state will thus not >>> happen. In particular, MCMockClassA does not get its #one method back, >>> which later tests expect. >>> >>>> These tests weren't failing in 4.3 anyone know what happened? >>> >>> People usually don't run tests without author initials? Certainly >>> these tests have ALWAYS passed on CI, but CI sets the author initials. >>> >>> I have yet to see evidence to contradict my hypothesis. >> >> Eh, well I just opened the 4.3 release image and ran tests. It asked >> for my initials at the beginning and then ran all tests. Those MC >> tests didn't fail. I don't think we can release without understanding >> what's going on with them in 4.4. > > Yes, but did you _fill in_ the initials? > > At any rate, theories aside, it _is_ the case that the > MCMethodDefinitionTest >> #tearDown doesn't restore state correctly. > Note that this is #testLoadAndUnload test is the test that pops up the > prompt. Subsequent tests fail because, for at least some of them, > MCMockClassA >> #one no longer exists. (MCMethodDefinitionTest >> > #testLoadAndUnload removes it.) OK right. It's something more than just author initials. Taking the RC, it doesn't matter if you set the author initials or not. Right, sorry Glen, you're quite right. My hypothesis is wrong. frank >> Would someone volunteer? I'm currently looking at Dave's SqueakMap >> patch is needed now but not before and making sure we can, in fact, >> deploy packages for 4.4 that will show up in SqueakMaps 4.4 list. > > Yes, please. I would like some countervailing evidence and/or > alternate hypotheses. > > Nevertheless, these tests definitely run on CI, and definitely pass. > Have always passed, in fact. It was only glenpaling's recent findings > that brought these tests to my/our attention. > > frank |
In reply to this post by Frank Shearar-3
Test run on Mac OS X 10.7.5: Failures: LargeNegativeIntegerTest>>#testMinimumNegativeIntegerArithmetic LocaleTest>>#testLocaleChanged MCChangeNotificationTest>>#testCoreMethodModified
MCFileInTest>>#testStWriter MCPackageTest>>#testUnload MCPatchTest>>#testPatchContents MCSnapshotBrowserTest>>#testNoSelection
MCSnapshotTest>>#testCreation MCStWriterTest>>#testOrganizationDefinition MCWorkingCopyTest>>#testBackport
MCWorkingCopyTest>>#testOptimizedLoad MCWorkingCopyTest>>#testRepeatedMerge MCWorkingCopyTest>>#testSelectiveBackport
MCWorkingCopyTest>>#testSimpleMerge MCWorkingCopyTest>>#testSnapshotAndLoad SocketTest>>#testSocketReuse SocketTest>>#testUDP
Errors: MCChangeNotificationTest>>#testExtMethodModified
MCSnapshotBrowserTest>>#testCategorySelected MCSnapshotBrowserTest>>#testClassSelected MCSnapshotBrowserTest>>#testClassSideClassSelected
MCSnapshotBrowserTest>>#testComment MCSnapshotBrowserTest>>#testMethodIsCleared MCSnapshotBrowserTest>>#testMethodSelected
MCSnapshotBrowserTest>>#testProtocolIsCleared MCSnapshotBrowserTest>>#testProtocolSelected MCStWriterTest>>#testInitializerDefinition
I get the same results with Eliots latest Cog VM and the John's "Squeak 5.7.4.1.app" interpreter VM. Colin |
In reply to this post by Frank Shearar-3
On Wed, Dec 19, 2012 at 11:36 AM, Frank Shearar <[hidden email]> wrote: * http://ftp.squeak.org/4.4/Squeak4.4-12319.tgz We seem to have a resurgence of #migrateOldRegistries problem. (See http://forum.world.st/The-Inbox-Collections-cwp-484-mcz-td4643977.html)
If you open the MC browser, it shows Collections as clean. But if you select Collections, the trunk repository and click changes, it turns out that the package is dirty. Colin |
In reply to this post by Frank Shearar-3
In looking at where one test fails I see that
MCSnapshotResource current snapshot definitions is empty in the 4.4 image while it has a bunch of entries in the 4.3 image. Cheers, Bob On 12/19/12 5:44 PM, Frank Shearar
wrote:
On 19 December 2012 22:15, Chris Muller [hidden email] wrote:Why do you say that's breaking the tests? If you "Do It" on one of the failed MC tests it opens the debugger showing the failed assertion even though initials have already been set.If the author initials aren't set, you get a FITBM asking for it. The proper cleanup and restoration of MC's test state will thus not happen. In particular, MCMockClassA does not get its #one method back, which later tests expect.These tests weren't failing in 4.3 anyone know what happened?People usually don't run tests without author initials? Certainly these tests have ALWAYS passed on CI, but CI sets the author initials. I have yet to see evidence to contradict my hypothesis.Eh, well I just opened the 4.3 release image and ran tests. It asked for my initials at the beginning and then ran all tests. Those MC tests didn't fail. I don't think we can release without understanding what's going on with them in 4.4.Yes, but did you _fill in_ the initials? At any rate, theories aside, it _is_ the case that the MCMethodDefinitionTest >> #tearDown doesn't restore state correctly. Note that this is #testLoadAndUnload test is the test that pops up the prompt. Subsequent tests fail because, for at least some of them, MCMockClassA >> #one no longer exists. (MCMethodDefinitionTest >> #testLoadAndUnload removes it.)Would someone volunteer? I'm currently looking at Dave's SqueakMap patch is needed now but not before and making sure we can, in fact, deploy packages for 4.4 that will show up in SqueakMaps 4.4 list.Yes, please. I would like some countervailing evidence and/or alternate hypotheses. Nevertheless, these tests definitely run on CI, and definitely pass. Have always passed, in fact. It was only glenpaling's recent findings that brought these tests to my/our attention. frank |
In reply to this post by Frank Shearar-3
4.4 MCSnapshotResource mockPackageName ==> 'MonticelloMocks'
4.3 MCSnapshotResource mockPackageName ==> #'Tests-Monticello-Mocks' which seems to be due to 'From Squeak4.4 of 18 December 2012 [latest update: #12305] on 19 December 2012 at 9:43:45 pm'! !MCMockPackageInfo methodsFor: 'as yet unclassified' stamp: 'cwp 8/1/2003 20:31'! packageName ^ 'MonticelloMocks'! ! No such method exists in 4.3, so some code pieces the package name together. Cheers, BOb |
On Wed, Dec 19, 2012 at 9:44 PM, Bob Arning <[hidden email]> wrote:
4.4 MCSnapshotResource mockPackageName ==> 'MonticelloMocks' Yeah. This goes back to some changes made to PackageInfo last year. PackageInfo subclasses are no longer detected in by PackageInfo class>>named:, they have to be explicitly registered. If I execute "MCMockPackageInfo initialize" all the errors go away, and I get only 3 failures:
LocaleTest>>#testLocaleChanged SocketTest>>#testSocketReuse SocketTest>>#testUDP Colin |
Well, that's cool. I also get 3 failures, only
they are:
FileStreamTest>>#testPositionPastEndIsAtEnd LargeNegativeIntegerTest>>#testMinimumNegativeIntegerArithmetic LocaleTest>>#testLocaleChanged Cheers, Bob On 12/19/12 9:55 PM, Colin Putney
wrote:
|
In reply to this post by Colin Putney-3
On 20 December 2012 02:55, Colin Putney <[hidden email]> wrote:
> > > > On Wed, Dec 19, 2012 at 9:44 PM, Bob Arning <[hidden email]> wrote: >> >> 4.4 MCSnapshotResource mockPackageName ==> 'MonticelloMocks' >> >> 4.3 MCSnapshotResource mockPackageName ==> #'Tests-Monticello-Mocks' >> >> which seems to be due to >> >> 'From Squeak4.4 of 18 December 2012 [latest update: #12305] on 19 December >> 2012 at 9:43:45 pm'! >> >> !MCMockPackageInfo methodsFor: 'as yet unclassified' stamp: 'cwp 8/1/2003 >> 20:31'! >> packageName >> ^ 'MonticelloMocks'! ! >> >> >> No such method exists in 4.3, so some code pieces the package name >> together. > > > Yeah. This goes back to some changes made to PackageInfo last year. > PackageInfo subclasses are no longer detected in by PackageInfo > class>>named:, they have to be explicitly registered. If I execute > "MCMockPackageInfo initialize" all the errors go away, and I get only 3 > failures: 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.) > LocaleTest>>#testLocaleChanged > SocketTest>>#testSocketReuse > SocketTest>>#testUDP And these are expected: the top test's broken, and the bottom two do break on some platforms. frank |
Free forum by Nabble | Edit this page |