[4.2] Inbox status

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 12/25/10 2:56 AM, "Levente Uzonyi" <[hidden email]> 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 <[hidden email]> wrote:
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.html

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