Here are the results of running the tests in a 10802 image:
2828 run, 2810 passes, 6 expected failures, 12 failures, 0 errors, 0 unexpected passes
The failed tests:
BecomeTest>>#testBecomeIdentityHash DecompilerTests>>#testDecompileLoopWithMovingLimit DecompilerTests>>#testDecompilerInClassesMAtoMM DecompilerTests>>#testDecompilerInClassesSNtoSZ FileStreamTest>>#testPositionPastEndIsAtEnd MCDictionaryRepositoryTest>>#testCreationMethods MCDirectoryRepositoryTest>>#testCreationMethods MCPackageTest>>#testUnload PackageDependencyTest>>#testMorphic PackageDependencyTest>>#testSUnitGUI TestURI>>#testDirWithHash
I've looked at two of them and.. I have no idea. Especially curious for me are the FileStreamTest and BecomeTest. Strange, the code hasn't changed since 4.1...
The possible outcomes for Squeak 4.2 are:
a) I override #shouldPass to mark these tests as "expected failures". b) Volunteers fix the remaining tests within the next couple of days. c) Release 4.2 with yellow tests. d) Delay the 4.2 release and hope volunteers fix the remaining tests. e) ???
My top preference is (b) of course, but if that does not happen, then (c) or (a).
- Chris
On 12/22/2010 6:06 PM, Chris Muller wrote:
I've looked at two of them and.. I have no idea. Especially curious for me are the FileStreamTest and BecomeTest. Strange, the code hasn't changed since 4.1...
Most likely these are differences in the VMs (i.e., Cog vs. Interpreter). You might want to try the tests with regular interp vs. cog and see if there's a difference.
Cheers, - Andreas
Here are the failures using the 2202 VM:
'DecompilerTests>>#testDecompileLoopWithMovingLimit DecompilerTests>>#testDecompilerInClassesMAtoMM DecompilerTests>>#testDecompilerInClassesSNtoSZ MCDictionaryRepositoryTest>>#testCreationMethods MCDirectoryRepositoryTest>>#testCreationMethods MCPackageTest>>#testUnload MirrorPrimitiveTests>>#testMirrorAt MirrorPrimitiveTests>>#testMirrorInstVarAt MorphicUIBugTest>>#testShowAllBinParts PackageDependencyTest>>#testMorphic PackageDependencyTest>>#testSUnitGUI ReleaseTest>>#testSwapMouseButtonsPreference SMDependencyTest>>#test2 StandardSystemFontsTest>>#testRestoreDefaultFonts TestURI>>#testDirWithHash '
On Wed, Dec 22, 2010 at 7:26 PM, Chris Muller asqueaker@gmail.com wrote:
Here are the failures using the 2202 VM:
'DecompilerTests>>#testDecompileLoopWithMovingLimit DecompilerTests>>#testDecompilerInClassesMAtoMM DecompilerTests>>#testDecompilerInClassesSNtoSZ MCDictionaryRepositoryTest>>#testCreationMethods MCDirectoryRepositoryTest>>#testCreationMethods MCPackageTest>>#testUnload MirrorPrimitiveTests>>#testMirrorAt MirrorPrimitiveTests>>#testMirrorInstVarAt
AFAIA the normal VM doesn't support the mirror primitives yet.
MorphicUIBugTest>>#testShowAllBinParts PackageDependencyTest>>#testMorphic PackageDependencyTest>>#testSUnitGUI ReleaseTest>>#testSwapMouseButtonsPreference SMDependencyTest>>#test2 StandardSystemFontsTest>>#testRestoreDefaultFonts TestURI>>#testDirWithHash '
On Wed, 22 Dec 2010, Chris Muller wrote:
Here are the results of running the tests in a 10802 image:
2828 run, 2810 passes, 6 expected failures, 12 failures, 0 errors, 0 unexpected passes
The failed tests:
BecomeTest>>#testBecomeIdentityHash
It has some chance to fail, but it fails more often on Cog. I think the last assert should be removed.
DecompilerTests>>#testDecompileLoopWithMovingLimit
http://bugs.squeak.org/view.php?id=7093
DecompilerTests>>#testDecompilerInClassesMAtoMM DecompilerTests>>#testDecompilerInClassesSNtoSZ
These two have possible fixes in the Inbox.
FileStreamTest>>#testPositionPastEndIsAtEnd
This is with an older version of CogVM. This is fixed in the svn repo.
MCDictionaryRepositoryTest>>#testCreationMethods MCDirectoryRepositoryTest>>#testCreationMethods
These don't fail on windows.
MCPackageTest>>#testUnload
This fails randomly. If you run it alone, then it doesn't. If we could save the context of the failing test and open the debugger with that context later, then it would be a lot easier to fix such issues.
PackageDependencyTest>>#testMorphic PackageDependencyTest>>#testSUnitGUI
Two dependencies to be resolved.
TestURI>>#testDirWithHash
A possible fix is in the Inbox.
I've looked at two of them and.. I have no idea. Especially curious for me are the FileStreamTest and BecomeTest. Strange, the code hasn't changed since 4.1...
The possible outcomes for Squeak 4.2 are:
a) I override #shouldPass to mark these tests as "expected failures". b) Volunteers fix the remaining tests within the next couple of days. c) Release 4.2 with yellow tests. d) Delay the 4.2 release and hope volunteers fix the remaining tests. e) ???
My top preference is (b) of course, but if that does not happen, then (c) or (a).
I think we should wait for the new VMs, before releasing the new images.
Levente
- Chris
I think too, that it would be good to coordinate with Matthew F. To be sure the Croquet stuff is operational in 4.2.
Ken, from my iPhone
On 2010-12-22, at 23:15, Levente Uzonyi leves@elte.hu wrote:
On Wed, 22 Dec 2010, Chris Muller wrote:
Here are the results of running the tests in a 10802 image:
2828 run, 2810 passes, 6 expected failures, 12 failures, 0 errors, 0 unexpected passes
The failed tests:
BecomeTest>>#testBecomeIdentityHash
It has some chance to fail, but it fails more often on Cog. I think the last assert should be removed.
DecompilerTests>>#testDecompileLoopWithMovingLimit
http://bugs.squeak.org/view.php?id=7093
DecompilerTests>>#testDecompilerInClassesMAtoMM DecompilerTests>>#testDecompilerInClassesSNtoSZ
These two have possible fixes in the Inbox.
FileStreamTest>>#testPositionPastEndIsAtEnd
This is with an older version of CogVM. This is fixed in the svn repo.
MCDictionaryRepositoryTest>>#testCreationMethods MCDirectoryRepositoryTest>>#testCreationMethods
These don't fail on windows.
MCPackageTest>>#testUnload
This fails randomly. If you run it alone, then it doesn't. If we could save the context of the failing test and open the debugger with that context later, then it would be a lot easier to fix such issues.
PackageDependencyTest>>#testMorphic PackageDependencyTest>>#testSUnitGUI
Two dependencies to be resolved.
TestURI>>#testDirWithHash
A possible fix is in the Inbox.
I've looked at two of them and.. I have no idea. Especially curious for me are the FileStreamTest and BecomeTest. Strange, the code hasn't changed since 4.1...
The possible outcomes for Squeak 4.2 are:
a) I override #shouldPass to mark these tests as "expected failures". b) Volunteers fix the remaining tests within the next couple of days. c) Release 4.2 with yellow tests. d) Delay the 4.2 release and hope volunteers fix the remaining tests. e) ???
My top preference is (b) of course, but if that does not happen, then (c) or (a).
I think we should wait for the new VMs, before releasing the new images.
Levente
- Chris
Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800
I think too, that it would be good to coordinate with Matthew F. To be sure the Croquet stuff is operational in 4.2.
Yes, this was actually mentioned in the last meeting report -
http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december- 21-2010/
If I understood correctly, he will continue to track Trunk and doesn't feel that an incomplete merge in 4.2 will be a problem. He did mention the "FloatMath plugin issue" and that it would be good to have that solved in 4.2, but I have not been paying attention to this discussion.
-- Jecel
On 2010/12/23 02:06, Chris Muller wrote:
Here are the results of running the tests in a 10802 image:
2828 run, 2810 passes, 6 expected failures, 12 failures, 0 errors,0 unexpected passes
The failed tests:
BecomeTest>>#testBecomeIdentityHash DecompilerTests>>#testDecompileLoopWithMovingLimit DecompilerTests>>#testDecompilerInClassesMAtoMM DecompilerTests>>#testDecompilerInClassesSNtoSZ FileStreamTest>>#testPositionPastEndIsAtEnd MCDictionaryRepositoryTest>>#testCreationMethods MCDirectoryRepositoryTest>>#testCreationMethods MCPackageTest>>#testUnload PackageDependencyTest>>#testMorphic PackageDependencyTest>>#testSUnitGUI TestURI>>#testDirWithHash
I've looked at two of them and.. I have no idea. Especially curious for me are the FileStreamTest and BecomeTest. Strange, the code hasn't changed since 4.1...
The possible outcomes for Squeak 4.2 are:
a) I override #shouldPass to mark these tests as "expected failures". b) Volunteers fix the remaining tests within the next couple of days.
I have fixes for TestURI, DecompilerTests>>#testDecompilerInClasses* awaiting review in the Inbox.
It would be especially good for a non-Windows check of the fix I proposed for TestURI, because the fix was uncommenting something that someone had commented out for presumably good reason. (There's no comment indicating what that reason might be though.)
frank
I am afraid I broke #testSUnitGUI when I improved the resize behavior of the Test Runner. Therefore I want to fix it. I used LayoutFrame for this which currently is in Morphic. Therefore SUnitGUI suddenly depends on Morphic which it should not because it uses ToolBuilder.
I think the right fix is to move LayoutFrame out of Morphic because it is not at all specific to Morphic. It is perfectly usable in MVCs UIs. And I guess it is also used there. The only question is where to move it? I think the best place would be the Graphics-Primitives class category in the Graphics package. This is where Point and Rectangle are. I tried it and it fixes the dependency test without breaking others. What do you think? I would like some feedback before I commit it to the inbox.
Cheers, Bernhard
Am 23.12.2010 um 03:06 schrieb Chris Muller:
Here are the results of running the tests in a 10802 image:
2828 run, 2810 passes, 6 expected failures, 12 failures, 0 errors, 0 unexpected passes
The failed tests:
BecomeTest>>#testBecomeIdentityHash DecompilerTests>>#testDecompileLoopWithMovingLimit DecompilerTests>>#testDecompilerInClassesMAtoMM DecompilerTests>>#testDecompilerInClassesSNtoSZ FileStreamTest>>#testPositionPastEndIsAtEnd MCDictionaryRepositoryTest>>#testCreationMethods MCDirectoryRepositoryTest>>#testCreationMethods MCPackageTest>>#testUnload PackageDependencyTest>>#testMorphic PackageDependencyTest>>#testSUnitGUI TestURI>>#testDirWithHash
I've looked at two of them and.. I have no idea. Especially curious for me are the FileStreamTest and BecomeTest. Strange, the code hasn't changed since 4.1...
The possible outcomes for Squeak 4.2 are:
a) I override #shouldPass to mark these tests as "expected failures". b) Volunteers fix the remaining tests within the next couple of days. c) Release 4.2 with yellow tests. d) Delay the 4.2 release and hope volunteers fix the remaining tests. e) ???
My top preference is (b) of course, but if that does not happen, then (c) or (a).
- Chris
Dear Squeakers,
I went ahead with my proposal to move LayoutFrame from Morphic to Graphics and published new versions of both packages to the inbox. From the commit comment:
- moved LayoutFrame from Morphic-Layout to Graphics-Primitives because it is not specific to Morphic, i.e. it has no references to it and is perfectly usable - and used - by MVC only UIs. This also fixes PackageDependencyTest>>#testSUnitGUI.
Graphics-bp.173 should be loaded before Morphic-bp.505.
I kindly ask you core developers to consider moving it to the trunk.
Happy New Year!
Bernhard
Am 23.12.2010 um 19:37 schrieb Bernhard Pieber:
I am afraid I broke #testSUnitGUI when I improved the resize behavior of the Test Runner. Therefore I want to fix it. I used LayoutFrame for this which currently is in Morphic. Therefore SUnitGUI suddenly depends on Morphic which it should not because it uses ToolBuilder.
I think the right fix is to move LayoutFrame out of Morphic because it is not at all specific to Morphic. It is perfectly usable in MVCs UIs. And I guess it is also used there. The only question is where to move it? I think the best place would be the Graphics-Primitives class category in the Graphics package. This is where Point and Rectangle are. I tried it and it fixes the dependency test without breaking others. What do you think? I would like some feedback before I commit it to the inbox.
Dear core developers,
Are there any objections to move this to the trunk?
Cheers, Bernhard
Am 01.01.2011 um 17:05 schrieb Bernhard Pieber:
Dear Squeakers,
I went ahead with my proposal to move LayoutFrame from Morphic to Graphics and published new versions of both packages to the inbox. From the commit comment:
- moved LayoutFrame from Morphic-Layout to Graphics-Primitives because it is not specific to Morphic, i.e. it has no references to it and is perfectly usable - and used - by MVC only UIs. This also fixes PackageDependencyTest>>#testSUnitGUI.
Graphics-bp.173 should be loaded before Morphic-bp.505.
I kindly ask you core developers to consider moving it to the trunk.
Happy New Year!
Bernhard
Am 23.12.2010 um 19:37 schrieb Bernhard Pieber:
I am afraid I broke #testSUnitGUI when I improved the resize behavior of the Test Runner. Therefore I want to fix it. I used LayoutFrame for this which currently is in Morphic. Therefore SUnitGUI suddenly depends on Morphic which it should not because it uses ToolBuilder.
I think the right fix is to move LayoutFrame out of Morphic because it is not at all specific to Morphic. It is perfectly usable in MVCs UIs. And I guess it is also used there. The only question is where to move it? I think the best place would be the Graphics-Primitives class category in the Graphics package. This is where Point and Rectangle are. I tried it and it fixes the dependency test without breaking others. What do you think? I would like some feedback before I commit it to the inbox.
I haven't looked at the "code" (oh wait, there shouldn't be any code iwth this right?).
It sounds like the right thing to do. Anyone else object?
On Wed, Jan 5, 2011 at 3:30 PM, Bernhard Pieber bernhard@pieber.com wrote:
Dear core developers,
Are there any objections to move this to the trunk?
Cheers, Bernhard
Am 01.01.2011 um 17:05 schrieb Bernhard Pieber:
Dear Squeakers,
I went ahead with my proposal to move LayoutFrame from Morphic to Graphics and published new versions of both packages to the inbox. From the commit comment:
- moved LayoutFrame from Morphic-Layout to Graphics-Primitives because it is not specific to Morphic, i.e. it has no references to it and is perfectly usable - and used - by MVC only UIs. This also fixes PackageDependencyTest>>#testSUnitGUI.
Graphics-bp.173 should be loaded before Morphic-bp.505.
I kindly ask you core developers to consider moving it to the trunk.
Happy New Year!
Bernhard
Am 23.12.2010 um 19:37 schrieb Bernhard Pieber:
I am afraid I broke #testSUnitGUI when I improved the resize behavior of the Test Runner. Therefore I want to fix it. I used LayoutFrame for this which currently is in Morphic. Therefore SUnitGUI suddenly depends on Morphic which it should not because it uses ToolBuilder.
I think the right fix is to move LayoutFrame out of Morphic because it is not at all specific to Morphic. It is perfectly usable in MVCs UIs. And I guess it is also used there. The only question is where to move it? I think the best place would be the Graphics-Primitives class category in the Graphics package. This is where Point and Rectangle are. I tried it and it fixes the dependency test without breaking others. What do you think? I would like some feedback before I commit it to the inbox.
On 06.01.2011, at 01:08, Chris Muller wrote:
I haven't looked at the "code" (oh wait, there shouldn't be any code iwth this right?).
It sounds like the right thing to do. Anyone else object?
We are in code freeze. This is a non-critical fix. You as release manager need to decide.
- Bert -
Agreed, it is non-critical. I would prefer to defer this until 4.3.
I am making a list of 4.3 "to-do right-away items"...
On Thu, Jan 6, 2011 at 5:44 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 06.01.2011, at 01:08, Chris Muller wrote:
I haven't looked at the "code" (oh wait, there shouldn't be any code iwth this right?).
It sounds like the right thing to do. Anyone else object?
We are in code freeze. This is a non-critical fix. You as release manager need to decide.
- Bert -
On Thu, 6 Jan 2011, Bert Freudenberg wrote:
On 06.01.2011, at 01:08, Chris Muller wrote:
I haven't looked at the "code" (oh wait, there shouldn't be any code iwth this right?).
It sounds like the right thing to do. Anyone else object?
We are in code freeze. This is a non-critical fix. You as release manager need to decide.
It's more like feature freeze and it fixes a failing test, so I'd definitely add it. :)
Levente
- Bert -
Am 06.01.2011 um 19:01 schrieb Levente Uzonyi:
On Thu, 6 Jan 2011, Bert Freudenberg wrote: On 06.01.2011, at 01:08, Chris Muller wrote:
I haven't looked at the "code" (oh wait, there shouldn't be any code iwth this right?).
It sounds like the right thing to do. Anyone else object?
We are in code freeze. This is a non-critical fix. You as release manager need to decide.
It's more like feature freeze and it fixes a failing test, so I'd definitely add it. :)
Right, exactly. It was meant as a fix for a failing test for the 4.2 release. See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156081....
I don't understand why this does not fail in Squeak4.2-10856-beta.zip. Hmmm.
Cheers, Bernhard
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bernhard Pieber -
Bert Freudenberg -
Chris Muller -
Chris Muller -
Eliot Miranda -
Frank Shearar -
Jecel Assumpcao Jr. -
Ken G. Brown -
Levente Uzonyi