I went through Squeak's Inbox today and cleared out some of my own old stuff and reviewed some of the contributions from others. I encourage other core developers to make a similar final pass on the Inbox.
Bottom line: Unless I've overlooked some final crucial fix, I don't intend to integrate any of the remaining Inbox items into 4.2. Everything I looked at were "enhancements" which can be lobbied-for and integrated into 4.3.
4.2 will not be a perfect release, but our development does not stop. My focus at this time is on getting it out the door so we will have a new baseline and can start talking about things in the context of "4.3".
- Chris
On Wed, 22 Dec 2010, Chris Muller wrote:
I went through Squeak's Inbox today and cleared out some of my own old stuff and reviewed some of the contributions from others. I encourage other core developers to make a similar final pass on the Inbox.
I reviewed all existing package versions in the Inbox, and wrote a summary about them, but it's not complete yet. Hopefully I'll be able to finish it today.
Bottom line: Unless I've overlooked some final crucial fix, I don't intend to integrate any of the remaining Inbox items into 4.2. Everything I looked at were "enhancements" which can be lobbied-for and integrated into 4.3.
I see your point about strictly freezing the features, but I think we shouldn't postpone the inclusion/rejection of existing Inbox contributions just because (we) core developers didn't have time to review/discuss them so far.
4.2 will not be a perfect release, but our development does not stop. My focus at this time is on getting it out the door so we will have a new baseline and can start talking about things in the context of "4.3".
That's right, but I think we will have enough time till the new VMs are ready, so we shouldn't rush either.
Levente
- Chris
Hi,
I finished reviewing the Inbox. Hopefully I didn't miss anything. I tried to group the related packages and write a short description for them. I also added some notes. Note that this is _my_ opinion about the contributions:
We should reject these: ======================= - Change String >> #isAllDigits to return false on empty string. Packages: Collections-hk.360 CollectionsTests-hk.163 Notes: String >> #isAllDigits could use #allSatisfy:.
- Derive the authorInitials directly from the authorName Packages: System-ar.329 Notes: It turned out to be a bad idea in Pharo: http://code.google.com/p/pharo/issues/detail?id=3395 .
- Add MCPackageManager class >> #obsoletePackageInfos Packages: Monticello-bp.406
- Dynamic building of TheWorldMainDockingBar (with pragmas or specification methods) Packages: Morphic-kb.428 Morphic-phite.428 Morphic-phite.429 Morphic-kb.431 Morphic-phite.431 Notes: The developement of these solutions stalled. In the meanwhile other features were added, like per project docking bar.
- Installer scripts to load OB and RB Packages: Morphic-hjh.438 Notes: These scripts are now obsolete and there's a working Metacello Configuration
We may add these: ================= - Add String >> #asCamelCase Collections-topa.366 CollectionsTests-topa.166
- Pretty Print changes Packages: Compiler-cmm.131 Compiler-cmm.132 Notes: we should create a configurable pretty printer which uses the visitor pattern (ParseNodeEnumerator?)
- Add #forward: and #turn: to Morph Packages: EToys-rjh.76 Notes: should we update the old EToys version in the Trunk?
- Add a menu item each to the world menu and the docking bar which refer to SystemNavigation>>browseMyChanges. Packages: Morphic-cbr.458 Notes: Doesn't seem to be very useful to me.
- Network changes from the EToys repository Packages: Network-ul.100 Notes: - CogVM doesn't seem to support the new network code - when the new network code is used, SocketStream seems to be broken - ConnectionQueue's multiple port numbers is not supported by the old network code
- Use #authorName instead of #authorInitials in MC Packages: Monticello-ar.394 Notes: We shouldn't derive the initials from the author name.
- Enable annotation panes by default Packages: System-tfel.386 Notes: it's just a postscript with: Preferences setPreference: #annotationPanes toValue: true.
We should add these: ==================== - Add Singleton class Packages: Kernel-cmm.518 Kernel-cmm.519
- ToolBuilerize MC Packages: Monticello-nice.404 Notes: If we want to support MVC and/or SimpleMorphic, then we probably want to do this.
- LineMorph class>>from:to:color:width: should return a LineMorph instead of a PolygonMorph Packages: Morphic-spd.469
- Fixes for Latin1Environment from EToys Packages: Multilingual-sn.131
- Fixed category for PackageInfo>>name Packages: PackageInfo-Base-bp.45
- SUnit cleanup Packages: SUnit-spd.82
- Added intention revealing helper method to AppRegistry class>>register: Packages: System-spd.355 Notes: Can't be directly merged, because the package also changes unrelated methods (MC bug?)
- Tests for String >> #asSound Packages: Tests-wiz.75
- Remove obsolete PackageInfos from PackageDepencencyTest Packages: Tests-bp.99 Tests-bp.100
- Allow the debugger to have no selected context: Packages: Tools-fbs.286 Tools-fbs.287 Notes: We should refactor this part of the system later.
- Split the too-long-running decompiling of the P and S classes Packages: Tests-fbs.104 Notes: We may also increase the timeouts by overriding LongTestCase >> #defaultTimeout
- Use FloatMathPlugin + Signaling NaNs Packages: Exceptions-ar.31 Kernel-mtf.527 Kernel-ar.528 Kernel-ar.529 Kernel-ul.530 KernelTests-ar.169 KernelTests-ar.170 Note: There are two failing tests, because earlier "Float infinity sin" returned NaN, but it raises an error with the new code.
To be reviewed/discussed: ========================= - Fix and unify the behavior of Class >> #declare: and Class >> #addClassVarName: Packages: Kernel-spd.444 KernelTests-spd.149 Notes: Can't be directly merged, because the packages also change unrelated methods (MC bug?).
- Clean up CompiledMethod's closures protocol Packages: Kernel-mha.498 Kernel-mha.499 Kernel-mha.500 KernelTests-mha.163 KernelTests-mha.164 KernelTests-mha.167
- Add toggle-full-screen button to the docking bar Packages: Morphic-rhi.439 Notes: Andreas added this feature to the Extras menu recently.
- Preserve translucency when rotating a Morph on 32-bit deep displays. Packages: Morphic-cmm.442
- Some URL tests Packages: NetworkTests-fbs.19 Notes: the tests send #handlesScheme: which is not in the image
- Some project related URL mangling (see the discussion in the version comment) Packages: System-cao.374 Notes: I couldn't reproduce the problem.
I didn't list the recent fixes of Frank Shearar (fbs), but I think we should add those to the Trunk.
Cheers, Levente
On Thu, 23 Dec 2010, Levente Uzonyi wrote:
On Wed, 22 Dec 2010, Chris Muller wrote:
I went through Squeak's Inbox today and cleared out some of my own old stuff and reviewed some of the contributions from others. I encourage other core developers to make a similar final pass on the Inbox.
I reviewed all existing package versions in the Inbox, and wrote a summary about them, but it's not complete yet. Hopefully I'll be able to finish it today.
Bottom line: Unless I've overlooked some final crucial fix, I don't intend to integrate any of the remaining Inbox items into 4.2. Everything I looked at were "enhancements" which can be lobbied-for and integrated into 4.3.
I see your point about strictly freezing the features, but I think we shouldn't postpone the inclusion/rejection of existing Inbox contributions just because (we) core developers didn't have time to review/discuss them so far.
4.2 will not be a perfect release, but our development does not stop. My focus at this time is on getting it out the door so we will have a new baseline and can start talking about things in the context of "4.3".
That's right, but I think we will have enough time till the new VMs are ready, so we shouldn't rush either.
Levente
- Chris
On 12/25/10 2:56 AM, "Levente Uzonyi" leves@elte.hu wrote:
Notes: should we update the old EToys version in the Trunk?
What if we unload all Etoys in trunk and instead load the Etoys derived from Etoys4 .image ?
Edgar
Hi Levente,
LU> Hi,
LU> I finished reviewing the Inbox.
thanks for doing so.
LU> We should reject these: LU> ======================= - Change String >>> #isAllDigits to return false on empty string. LU> Packages: LU> Collections-hk.360 LU> CollectionsTests-hk.163 LU> Notes: String >> #isAllDigits could use #allSatisfy:.
As it turned out out to be a philosophical question and might break some code, just remove it.
Cheers,
Herbert
Hi,
On 25 December 2010 05:56, Levente Uzonyi leves@elte.hu wrote:
To be reviewed/discussed:
...
- Clean up CompiledMethod's closures protocol
Packages: Kernel-mha.498 Kernel-mha.499 Kernel-mha.500 KernelTests-mha.163 KernelTests-mha.164 KernelTests-mha.167
well, let's discuss them indeed.
I have made those changes to CompiledMethod because the code in that protocol was completely dead and useless, and because I needed some meta-programming (introspective) facilities around closures/blocks.
The solution is far from perfect, especially because BlockClosure instances are inherently "run-time" entities, instead of static ones like CompiledMethod or BlockMethod. Still, I think the somewhat orphaned support for meta-programming with closures is a bit sad given the otherwise complete coverage of such constructs in Smalltalk.
So, how about it?
Best,
Michael
On 2010/12/25 04:56, Levente Uzonyi wrote:
Hi,
I finished reviewing the Inbox. Hopefully I didn't miss anything. I tried to group the related packages and write a short description for them. I also added some notes. Note that this is _my_ opinion about the contributions:
<snip>
- Some URL tests
Packages: NetworkTests-fbs.19 Notes: the tests send #handlesScheme: which is not in the image
This is cruft: you can delete it. #handlesScheme: was a proposal I submitted for having packages that defined their own URLs not overwrite each others' changes, in Network-fbs.80. We went with a simpler option, Network-fbs.85, that uses explicit registration:
Url registerUrlClass: HttpUrl forScheme: 'http'.
frank
Hi Levente,
Thanks for reviewing the inbox contributions!
Am 25.12.2010 um 05:56 schrieb Levente Uzonyi:
We should reject these:
snip
- Add MCPackageManager class >> #obsoletePackageInfos Packages: Monticello-bp.406
I wonder why you would reject this method? I found it useful for checking which PackageInfos would be deleted by doing MCWorkingCopy flushObsoletePackageInfos. MCPackageManager>>#flushObsoletePackageInfos should probably be rewritten to use obsoletePackageInfos in order to avoid code duplication.
We should add these:
snip
- Remove obsolete PackageInfos from PackageDepencencyTest Packages: Tests-bp.99
Note that this requires an aggessive cleanUp before. Otherwise you have failing tests.
Cheers, Bernhard
Am 01.01.2011 um 17:46 schrieb Bernhard Pieber:
Am 25.12.2010 um 05:56 schrieb Levente Uzonyi:
We should add these:
snip
- Remove obsolete PackageInfos from PackageDepencencyTest Packages: Tests-bp.99
Note that this requires an aggessive cleanUp before. Otherwise you have failing tests.
I would like to make this remark a little clearer. Levente proposed adding Tests-bp.100 to the trunk. This version contains an preamble to flushObsoletePackageInfos. Bert quite convincingly argued against adding this to the trunk because there is a small chance we might flush still needed PackageInfos in people's images. See: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-November/154868....
Bert suggested to do this during the release process instead.
So the right steps in my opinion are: 1. The release manager for 4.2 perpares a release image. 2. He calls Smalltalk cleanUp: true. This breaks the PackageDependencyTest. 3. He merges Tests-bp.99. The PackageDependencyTest should be fixed again. 4. He uploads the release image to ftp.squeak.org.
Did I make myself clear? Did I miss something?
Cheers, Bernhard
squeak-dev@lists.squeakfoundation.org