* 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
-- View this message in context: http://forum.world.st/Release-candidate-Squeak4-4-12319-ready-tp4660105p4660... Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 19 December 2012 19:42, glenpaling slp5591@me.com 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
Frank Shearar-3 wrote
On 19 December 2012 19:42, glenpaling <
slp5591@
> wrote:
3272 run, 3228 passes, 18 expected failures, 16 failures, 10 errors, 0
snip
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
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?
-- View this message in context: http://forum.world.st/Release-candidate-Squeak4-4-12319-ready-tp4660105p4660... Sent from the Squeak - Dev mailing list archive at Nabble.com.
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).
On 19 December 2012 21:15, Chris Muller asqueaker@gmail.com 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 ma.chris.m@gmail.com 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 frank.shearar@gmail.com wrote:
On 19 December 2012 22:15, Chris Muller ma.chris.m@gmail.com 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 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 ma.chris.m@gmail.com 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
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 arning315@comcast.net 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:
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:
On Wed, Dec 19, 2012 at 9:44 PM, Bob Arning <arning315@comcast.net mailto:arning315@comcast.net> 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:
LocaleTest>>#testLocaleChanged SocketTest>>#testSocketReuse SocketTest>>#testUDP
Colin
On 20 December 2012 02:55, Colin Putney colin@wiresong.com wrote:
On Wed, Dec 19, 2012 at 9:44 PM, Bob Arning arning315@comcast.net 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
On Thu, Dec 20, 2012 at 2:08 AM, Frank Shearar frank.shearar@gmail.comwrote:
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.
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
On 20 December 2012 07:39, Colin Putney colin@wiresong.com wrote:
On Thu, Dec 20, 2012 at 2:08 AM, Frank Shearar frank.shearar@gmail.com 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
On 20 December 2012 07:52, Frank Shearar frank.shearar@gmail.com wrote:
On 20 December 2012 07:39, Colin Putney colin@wiresong.com wrote:
On Thu, Dec 20, 2012 at 2:08 AM, Frank Shearar frank.shearar@gmail.com 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
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
On 20 December 2012 10:02, Herbert König herbertkoenig@gmx.net 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
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 frank.shearar@gmail.comwrote:
On 20 December 2012 10:02, Herbert König herbertkoenig@gmx.net 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
On Fri, Dec 21, 2012 at 9:54 AM, Eliot Miranda eliot.miranda@gmail.comwrote:
Hi Frank,
there's been a lot of churn in my VMs lately. I'm afraid I have toinsist 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)
On Thu, Dec 20, 2012 at 2:35 AM, Frank Shearar frank.shearar@gmail.comwrote:
On 20 December 2012 10:02, Herbert König herbertkoenig@gmx.net 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
On 21 December 2012 17:55, Eliot Miranda eliot.miranda@gmail.com wrote:
On Fri, Dec 21, 2012 at 9:54 AM, Eliot Miranda eliot.miranda@gmail.com 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 frank.shearar@gmail.com wrote:
On 20 December 2012 10:02, Herbert König herbertkoenig@gmx.net 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
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
-- View this message in context: http://forum.world.st/Release-candidate-Squeak4-4-12319-ready-tp4660105p4660... Sent from the Squeak - Dev mailing list archive at Nabble.com.
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
-- View this message in context: http://forum.world.st/Release-candidate-Squeak4-4-12319-ready-tp4660105p4660... Sent from the Squeak - Dev mailing list archive at Nabble.com.
Fixes the NetNameResolver problem on localhost; thanks !
Stef
On 19 December 2012 21:05, Stéphane Rollandin lecteur@zogotounga.net wrote:
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
On 12/19/12 6:31 PM, "Frank Shearar" frank.shearar@gmail.com 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
On 20 December 2012 09:23, Edgar J. De Cleene edgardec2005@gmail.com wrote:
On 12/19/12 6:31 PM, "Frank Shearar" frank.shearar@gmail.com 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
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
On Wed, Dec 19, 2012 at 11:36 AM, Frank Shearar frank.shearar@gmail.comwrote:
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
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
squeak-dev@lists.squeakfoundation.org
-
Bob Arning -
Chris Muller -
Chris Muller -
Colin Putney -
Edgar J. De Cleene -
Eliot Miranda -
Frank Shearar -
glenpaling -
Herbert König -
Stéphane Rollandin