There will be no new features added to the 4.3 release of Squeak as of today.
Between today and the code freeze deadline in three weeks (at the next SOB meeting) the emphasis is on bug fixes. If you have been working on features in the Squeak Trunk, please take this opportunity to sort out any lingering bugs. Thank you, Chris |
Cool! I'm looking forward for a stable 4.3.
I could not find a "http://source.squeak.org/squeak43" repository. Does it mean that there will be no real trunk for the next days? Is it a good idea? :) Best regards, Marcel |
On Wed, 16 Nov 2011, Marcel Taeumel wrote:
> Cool! I'm looking forward for a stable 4.3. > > I could not find a "http://source.squeak.org/squeak43" repository. Does it > mean that there will be no real trunk for the next days? Is it a good idea? > :) That repository will be created right before the release of Squeak 4.3. Levente > > Best regards, > Marcel > > -- > View this message in context: http://forum.world.st/4-3-Release-Schedule-Feature-freeze-today-tp4076710p4077579.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > |
In reply to this post by Chris Cunnington
Could someone update the alpha download? It would be useful to have a
current version for testing. Cheers, - Andreas On 11/16/2011 16:24, Chris Cunnington wrote: > There will be no new features added to the 4.3 release of Squeak as of today. > Between today and the code freeze deadline in three weeks (at the next SOB meeting) the emphasis is on bug fixes. > If you have been working on features in the Squeak Trunk, please take this opportunity to sort out any lingering bugs. > > Thank you, > > Chris > > > > |
In reply to this post by Levente Uzonyi-2
Why that late? I'm just curious if it wouldn't be better to do some "branching" right after feature-freeze. Bugfixes would have to be added to both repositories, trunk + 4.3, though. Hmm... maybe it's not that easy with Monticello/Squeaksource. Marcel |
Hi.
Can you add One more thing? Installer class>>gemsource ^ self monticello http: 'http://http://seaside.gemstone.com/ss' Installer class>>gs ^ self gemsource Installer class>>squeaksource3 ^ self monticello http: 'http://ss3.gemstone.com/' Installer class>>ss3 ^ self squeaksource3 Installer class>>swasource ^ self monticello http: 'http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource' Installer class>>swa ^ self swasource Best -Tobias |
In reply to this post by Chris Cunnington
Hi Tobias,
As release manager, those look like worthwhile late additions me. But the person doing the adding would be you. You could submit those to the Inbox and it would be up to the image builders. Chris |
In reply to this post by marcel.taeumel (old)
On 18.11.2011, at 07:50, Marcel Taeumel wrote: > > Levente Uzonyi-2 wrote: >> >> That repository will be created right before the release of Squeak 4.3. >> > > Why that late? I'm just curious if it wouldn't be better to do some > "branching" right after feature-freeze. Bugfixes would have to be added to > both repositories, trunk + 4.3, though. Hmm... maybe it's not that easy with > Monticello/Squeaksource. We don't want to branch for release. Release work happens on trunk. The reasoning is that this way, *everyone* is testing and refining the release. If we branched, then there would only be a few people testing and working on that branch. The price we pay is that adding new features will have to wait for a few weeks (2 weeks of feature freeze, another 2 [perhaps less?] of code freeze). Given the small number of active developers this is a good trade-off. Best of all, everyone will want the release out of the door ASAP so Happy Hacking can commence again ;) - Bert - |
In reply to this post by Chris Cunnington
Am 2011-11-18 um 13:51 schrieb Chris Cunnington: > Hi Tobias, > > As release manager, those look like worthwhile late additions me. But the person doing the adding would be you. > You could submit those to the Inbox and it would be up to the image builders. Done. Note that squeaksource3/ss3 was already there. BEst -TObias |
In reply to this post by Chris Cunnington
On 11/19/11 5:57 AM, "H. Hirzel" <[hidden email]> wrote: > From: Andreas Raab <[hidden email]> > 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 > <[hidden email]> > > 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 |
In reply to this post by Chris Cunnington
|
In reply to this post by Edgar De Cleene
2011/11/19 Edgar J. De Cleene <[hidden email]>:
> > > > On 11/19/11 5:57 AM, "H. Hirzel" <[hidden email]> wrote: > >> From: Andreas Raab <[hidden email]> >> 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 >> <[hidden email]> >> >> 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" <[hidden email]> wrote: > 2011/11/19 Edgar J. De Cleene <[hidden email]>: >> >> >> >> On 11/19/11 5:57 AM, "H. Hirzel" <[hidden email]> wrote: >> >>> From: Andreas Raab <[hidden email]> >>> 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 >>> <[hidden email]> >>> >>> 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 |
In reply to this post by Nicolas Cellier
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 |
In reply to this post by Nicolas Cellier
2011/11/19 Nicolas Cellier <[hidden email]>: 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 True! That's already changed. Alex |
On Mon, 5 Dec 2011, Alexander Lazarević wrote:
> 2011/11/19 Nicolas Cellier <[hidden email]>: >>> 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 > |
In reply to this post by laza
On Mon, 5 Dec 2011, Alexander Lazarević wrote:
> 2011/11/19 Nicolas Cellier <[hidden email]>: >>> 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 <[hidden email]>: > 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 |
Free forum by Nabble | Edit this page |