On 11/19/11 5:57 AM, "H. Hirzel" hannes.hirzel@gmail.com wrote:
From: Andreas Raab andreas.raab@gmx.de Date: Thu, 17 Nov 2011 20:32:58 +0100 Subject: [squeak-dev] Re: 4.3 Release Schedule: Feature freeze today To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
Could someone update the alpha download? It would be useful to have a current version for testing.
Cheers,
- Andreas
I have some ready, I interim nominate Squeak4.3gamma-11793 3081 run, 3050 passes, 7 expected failures, 20 failures, 2 errors, 2 unexpected passes Failures DependencyBrowserTest>>#testClassList ExceptionTests>>#testHandlerFromAction MCFileInTest>>#testStWriter MCMczInstallerTest>>#testInstallFromFile MCMczInstallerTest>>#testInstallFromStream MirrorPrimitiveTests>>#testMirrorAt MirrorPrimitiveTests>>#testMirrorInstVarAt PackageDependencyTest>>#testExceptions PackageDependencyTest>>#testMonticello PackageDependencyTest>>#testNetwork PackageDependencyTest>>#testST80 PackageDependencyTest>>#testSystem PackageDependencyTest>>#testToolBuilder PackageDependencyTest>>#testToolBuilderMVC PackageDependencyTest>>#testToolBuilderSUnit ProcessTest>>#testAtomicSuspend RWBinaryOrTextStreamTest>>#testExisiting ReleaseTest>>#testNoObsoleteClasses SocketTest>>#testSocketReuse SocketTest>>#testUDP SystemChangeFileTest>>#testClassAdded WeakSetInspectorTest>>#testSymbolTableM6812
Errors CompiledMethodTest>>#testPerformCanExecutelongMethodWithTemps CompiledMethodTest>>#testPerformInSuperclassCanExecutelongMethodWithTemps
And when running the test , the debugger shows something related to primitive socket (sorry , no external log to attach)
We need a Welcome Window showing what is new and About Squeak should say is 4.3 and not 4.2
I uploaded for all test
Wait some minutes
Edgar
2011/11/19 Edgar J. De Cleene edgardec2005@gmail.com:
On 11/19/11 5:57 AM, "H. Hirzel" hannes.hirzel@gmail.com wrote:
From: Andreas Raab andreas.raab@gmx.de Date: Thu, 17 Nov 2011 20:32:58 +0100 Subject: [squeak-dev] Re: 4.3 Release Schedule: Feature freeze today To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
Could someone update the alpha download? It would be useful to have a current version for testing.
Cheers, - Andreas
I have some ready, I interim nominate Squeak4.3gamma-11793 3081 run, 3050 passes, 7 expected failures, 20 failures, 2 errors, 2 unexpected passes Failures
DependencyBrowserTest>>#testClassList
"Warning! When Collections' dependencies change, this test may start to fail!" OK, the usual dependency weakness, see below
ExceptionTests>>#testHandlerFromAction
Only the documentation is new, not the failure. IMO it should be classified as expected.
MCFileInTest>>#testStWriter
This one fails only once, when I replay, it passes. IMO the test should be rewritten.
MCMczInstallerTest>>#testInstallFromFile MCMczInstallerTest>>#testInstallFromStream
They didn't fail for me...
MirrorPrimitiveTests>>#testMirrorAt MirrorPrimitiveTests>>#testMirrorInstVarAt
These should be expected with a non-cog VM no?
PackageDependencyTest>>#testExceptions PackageDependencyTest>>#testMonticello PackageDependencyTest>>#testNetwork PackageDependencyTest>>#testST80 PackageDependencyTest>>#testSystem PackageDependencyTest>>#testToolBuilder PackageDependencyTest>>#testToolBuilderMVC PackageDependencyTest>>#testToolBuilderSUnit
I never had these tests working correctly in my images... I just have to try and diff/merge a Pharo MC subpackage, this creates a new package info (like Multilingual-Languages)... This then breaks all dependency tests (some 'Multilingual' dependencies have disappeared and some 'Multilingual-Languages' have appeared) All this by the sole effect of browsing diffs - without performing any change in the image... That's pretty weak
ProcessTest>>#testAtomicSuspend
?? VM problem ??
RWBinaryOrTextStreamTest>>#testExisiting
Seems like a new test documenting an old API problem I hate RWBinaryOrTextStream anyway, the name stinks.
ReleaseTest>>#testNoObsoleteClasses
It remains to see where these obsolete references come from... Does this happen in a pure 4.2 trunk updated to latest ?
SocketTest>>#testSocketReuse
This one happens to me on a Mac because I have some OS security pop up.
SocketTest>>#testUDP
It sounds like a VM problem...
SystemChangeFileTest>>#testClassAdded
We should correct this one. Note that I don't much like the usage of file 'temp.changes', i sometimes happen to have such files in use...
WeakSetInspectorTest>>#testSymbolTableM6812
Doesn't appear here...
Errors CompiledMethodTest>>#testPerformCanExecutelongMethodWithTemps CompiledMethodTest>>#testPerformInSuperclassCanExecutelongMethodWithTemps
The last one is expected on non cog-VM (maybe the test should be protected with a shouldnt:raise: to transform the error into a failure). I can't remember why the first would fail??? it doesn't for me, either in VM4.2.5 not in COG.
Nicolas
And when running the test , the debugger shows something related to primitive socket (sorry , no external log to attach)
We need a Welcome Window showing what is new and About Squeak should say is 4.3 and not 4.2
I uploaded for all test
Wait some minutes
Edgar
On 11/19/11 11:55 AM, "Nicolas Cellier" nicolas.cellier.aka.nice@gmail.com wrote:
2011/11/19 Edgar J. De Cleene edgardec2005@gmail.com:
On 11/19/11 5:57 AM, "H. Hirzel" hannes.hirzel@gmail.com wrote:
From: Andreas Raab andreas.raab@gmx.de Date: Thu, 17 Nov 2011 20:32:58 +0100 Subject: [squeak-dev] Re: 4.3 Release Schedule: Feature freeze today To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
Could someone update the alpha download? It would be useful to have a current version for testing.
Cheers, - Andreas
I have some ready, I interim nominate Squeak4.3gamma-11793 3081 run, 3050 passes, 7 expected failures, 20 failures, 2 errors, 2 unexpected passes Failures
DependencyBrowserTest>>#testClassList
"Warning! When Collections' dependencies change, this test may start to fail!" OK, the usual dependency weakness, see below
ExceptionTests>>#testHandlerFromAction
Only the documentation is new, not the failure. IMO it should be classified as expected.
MCFileInTest>>#testStWriter
This one fails only once, when I replay, it passes. IMO the test should be rewritten.
MCMczInstallerTest>>#testInstallFromFile MCMczInstallerTest>>#testInstallFromStream
They didn't fail for me...
MirrorPrimitiveTests>>#testMirrorAt MirrorPrimitiveTests>>#testMirrorInstVarAt
These should be expected with a non-cog VM no?
PackageDependencyTest>>#testExceptions PackageDependencyTest>>#testMonticello PackageDependencyTest>>#testNetwork PackageDependencyTest>>#testST80 PackageDependencyTest>>#testSystem PackageDependencyTest>>#testToolBuilder PackageDependencyTest>>#testToolBuilderMVC PackageDependencyTest>>#testToolBuilderSUnit
I never had these tests working correctly in my images... I just have to try and diff/merge a Pharo MC subpackage, this creates a new package info (like Multilingual-Languages)... This then breaks all dependency tests (some 'Multilingual' dependencies have disappeared and some 'Multilingual-Languages' have appeared) All this by the sole effect of browsing diffs - without performing any change in the image... That's pretty weak
ProcessTest>>#testAtomicSuspend
?? VM problem ??
RWBinaryOrTextStreamTest>>#testExisiting
Seems like a new test documenting an old API problem I hate RWBinaryOrTextStream anyway, the name stinks.
ReleaseTest>>#testNoObsoleteClasses
It remains to see where these obsolete references come from... Does this happen in a pure 4.2 trunk updated to latest ?
SocketTest>>#testSocketReuse
This one happens to me on a Mac because I have some OS security pop up.
SocketTest>>#testUDP
It sounds like a VM problem...
SystemChangeFileTest>>#testClassAdded
We should correct this one. Note that I don't much like the usage of file 'temp.changes', i sometimes happen to have such files in use...
WeakSetInspectorTest>>#testSymbolTableM6812
Doesn't appear here...
Errors CompiledMethodTest>>#testPerformCanExecutelongMethodWithTemps CompiledMethodTest>>#testPerformInSuperclassCanExecutelongMethodWithTemps
The last one is expected on non cog-VM (maybe the test should be protected with a shouldnt:raise: to transform the error into a failure). I can't remember why the first would fail??? it doesn't for me, either in VM4.2.5 not in COG.
Nicolas
And when running the test , the debugger shows something related to primitive socket (sorry , no external log to attach)
We need a Welcome Window showing what is new and About Squeak should say is 4.3 and not 4.2
I uploaded for all test
Wait some minutes
Edgar
Nico you 're right.
All test was in Mac 4.2.5. Running with Squeak 5.8b4 I have a crash
More test with different VM
Image ----- /Users/edgar/AtlantisSqueak/imagesZip/Squeak4.3alpha-11722 Folder/Squeak4.3gamma-11793.image Squeak4.2 latest update: #11793 Current Change Set: Unnamed1
Virtual Machine --------------- /Applications/Cog 2.app/Contents/MacOS/Croquet Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.78] Croquet Cog 3.0.0 Mac OS X built on Jun 17 2011 13:29:23 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3) CoInterpreter VMMaker.oscog-eem.78 uuid: 412444c6-36dc-48be-b5cd-a6ebc4ade0bb Jun 17 2011 StackToRegisterMappingCogit VMMaker-oscog.51 uuid: d213bf61-5898-475b-8a5c-e4a9bdad2415 Jun 17 2011
3081 run, 3057 passes, 5 expected failures, 19 failures, 0 errors, 0 unexpected passes
Failures
AllocationTest>>#testOneGigAllocation BecomeTest>>#testBecomeIdentityHash DependencyBrowserTest>>#testClassList ExceptionTests>>#testHandlerFromAction FileStreamTest>>#testPositionPastEndIsAtEnd MCFileInTest>>#testStWriter MCMczInstallerTest>>#testInstallFromFile MCMczInstallerTest>>#testInstallFromStream PackageDependencyTest>>#testExceptions PackageDependencyTest>>#testMonticello PackageDependencyTest>>#testNetwork PackageDependencyTest>>#testST80 PackageDependencyTest>>#testSystem PackageDependencyTest>>#testToolBuilder PackageDependencyTest>>#testToolBuilderMVC PackageDependencyTest>>#testToolBuilderSUnit RWBinaryOrTextStreamTest>>#testExisiting ReleaseTest>>#testNoObsoleteClasses SystemChangeFileTest>>#testClassAdded
Edgar
2011/11/19 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
SystemChangeFileTest>>#testClassAdded
We should correct this one.
I still have some bits that I hopefully find time tonight to commit. When was that codefreeze exactly?
Note that I don't much like the usage of file 'temp.changes', i sometimes happen to have such files in use...
True! That's already changed.
Alex
On Mon, 5 Dec 2011, Alexander Lazarević wrote:
2011/11/19 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
SystemChangeFileTest>>#testClassAdded
We should correct this one.
I still have some bits that I hopefully find time tonight to commit. When was that codefreeze exactly?
Tomorrow, but we have plenty of bugs to fix.
Levente
Note that I don't much like the usage of file 'temp.changes', i sometimes happen to have such files in use...
True! That's already changed.
Alex
On Mon, 5 Dec 2011, Alexander Lazarević wrote:
2011/11/19 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
SystemChangeFileTest>>#testClassAdded
We should correct this one.
This is a tricky issue. The test is failing, because SmalltalkImage >> #event: doesn't log class additions, the code is commented out. The reason why it's commented out is (probably) because otherwise the class creation is logged twice. The reason for the double logging is that Browser >> #defineClass:notifying: forces logging while it evaluates the class definition, so a DoIt is also written to the changes file. Changing the evaluation code to
class := oldClass subclassDefinerClass evaluate: defString notifying: aController logged: false.
solves this issue. But what will happen when you create a class in a workspace? It will be logged twice. Once by the class addition and once by the DoIt.
I think double logging is not a real issue. It may slow things down a bit when you're recovering from the changes, and make your changes file a bit larger, but it's better to log it twice, than none, which is the current case, when you create a class from code.
So, I suggest uncommenting the logging of class additions in SmalltalkImage >> #event:, then turning off logging in Browser >> #defineClass:notifying:. Any objections?
Levente
I still have some bits that I hopefully find time tonight to commit. When was that codefreeze exactly?
Note that I don't much like the usage of file 'temp.changes', i sometimes happen to have such files in use...
True! That's already changed.
Alex
Hi Levente!
2011/12/8 Levente Uzonyi leves@elte.hu:
I think double logging is not a real issue. It may slow things down a bit when you're recovering from the changes, and make your changes file a bit larger, but it's better to log it twice, than none, which is the current case, when you create a class from code.
So, I suggest uncommenting the logging of class additions in SmalltalkImage
#event:, then turning off logging in Browser >> #defineClass:notifying:.
Any objections?
You are right. I left this out to avoid duplicate entries in the changes file, as it used to be that way since I guess 3.6. And I had the concern, that on a fileIn there would be duplicate entries as well, but that doesn't seem to be happening. (I guess a comment would have helped here :}
So I guess it's ok to uncomment that code as well.
Alex
squeak-dev@lists.squeakfoundation.org