commits | 1 Oct 01:55 2010

Daily Commit Log

Changes to Trunk ( in the last 24 hours:

Name: Collections-nice.385
Ancestors: Collections-ul.384

Improve comment of Heap. Please feel free to improve me.
As the class comment did start with a bit misleading comparison against SortedCollection, provides an
optional #fullySort operation to fully sort the Heap and restore comparison ground - hope I didn't spoil
announced O(n log n) efficiency.
Of course, #fullySort has no interest for priority queues, but a Heap could be of more general use.


Name: HelpSystem-Core-tbn.53
Ancestors: HelpSystem-Core-tbn.52

Custom help books are now able to define where subbooks should be placed/displayed

See also and thanx to Enrico Spinielli for the
idea and initial implementation.


Name: HelpSystem-Core-tbn.54
(Continue reading)

Edgar J. De Cleene | 1 Oct 13:55 2010

Re: Re: [Pharo-project] MorphoPhysics for both Pharo and Squeak

On 9/28/10 10:23 AM, "Igor Stasenko" <siguctua <at>> wrote:

> On 28 September 2010 16:15, HwaJong Oh <daliot.oh <at>> wrote:
>> Compatibility fix made on MorphoPhysics. It can now be loaded on both Squeak
>> and Pharo. Before this fix, it was only for Squeak only.
>> Here is the installation instruction.
>> 1. install LazyRabbit :
>> 2. install MorphoPhysics :
>>   (no need to load MorphoPhysicsEtoyPlugin , MorphoPhysicsSeasidePlugin.
>> MorphoPhysics is good enough)
>> 3. open a workspace, and follow the example method MindMapMP class >>
>> esug2010PresentationExample
> I think your project would be a good addition to FunSqueak image.
> Edgar?
>> Sorry for not using Metacello. I will learn to use it later.
>> -HwaJong Oh-
>> --
>> View this message in context:
>> 84.html
>> Sent from the Pharo Smalltalk mailing list archive at
(Continue reading)

commits | 1 Oct 02:00 2010

The Trunk: System-eem.381.mcz

Eliot Miranda uploaded a new version of System to project The Trunk:

==================== Summary ====================

Name: System-eem.381
Author: eem
Time: 1 October 2010, 5:13:05.666 am
UUID: fe56800a-cea9-49b7-b807-5e48494053c4
Ancestors: System-ul.380

Answer methodClassName for class comment chnages so
that the change list includes class comments in "select
changes for this class" et al.

=============== Diff against System-ul.380 ===============

Item was changed:
  ----- Method: ChangeRecord>>methodClassName (in category 'access') -----
+ 	| tokens |
- 	| text tokens |
  	(class isNil
  	and: [type = #doIt
+ 	and: [(tokens := Scanner new scanTokens: self text) size >= 3
+ 	and: [(tokens includes: #'.') not "exclude multi-statement doits"
- 	and: [((text := self text) includes: $.) not "exclude multi-statement doits"
- 	and: [(tokens := Scanner new scanTokens: text) size >= 4
  	and: [tokens first isSymbol
  	and: [tokens first isKeyword not
(Continue reading)

Michal | 1 Oct 14:19 2010

shout converting := to left-arrow?

It has been mentioned several times that we could have our cake and
eat it too if := was visually converted to the left arrow by something
like shout, but preserved in the source file. Has anybody done
anything like this yet? 

(Or any other solution which gives a visual left arrow for those of us
who are attached to it, but preserves := in source files)

The reason for this question is that I need to use a non-patched font
and I am attached to the left arrow :)


Enrico Spinielli | 1 Oct 16:00 2010

Re: Help is now able to define where subbooks are placed

all thanks go to you for having thought/designed/implemented _and_ for
following HelpSystem up!

Well done

On Fri, Oct 1, 2010 at 00:19, Torsten Bergmann <astares <at>> wrote:
> Hi Enrico,
> found the time this evening to integrate your idea
> that custom help books should be able to define
> where subbooks should be placed/displayed:
>    #pages
>       ^(firstPage MyAppSubTutorial secondPage thirdPage)
> Just update your Squeak image to #10565 and you dont
> need to workaround this problem using a custom
> builder anymore.
> It is now also mentioned in the help systems help
> itself. See chapter "STEP 7 - TIPS AND TRICKS".
> I've also opened an issue together with the
> changeset for Pharo 1.2 so that it will be
> integrated in one of the next pharo updates.
(Continue reading)

commits | 1 Oct 02:00 2010

The Inbox: SUnit-spd.82.mcz

A new version of SUnit was added to project The Inbox:

==================== Summary ====================

Name: SUnit-spd.82
Author: spd
Time: 1 October 2010, 10:31:26.892 am
UUID: 6332b14d-4ac9-4fdb-bffb-8e225050f415
Ancestors: SUnit-nice.81

* TestCase now uses class>>suiteClass instead of referencing the class name directly 
* TestSuite now uses #resultClass instead of referencing the class name directly
* merged 'Accessing' protocol into 'accessing'

=============== Diff against SUnit-nice.81 ===============

Item was changed:
  ----- Method: TestCase class>>buildSuite (in category 'building suites') -----
  	| suite |
+ 	suite := self suiteClass new.
- 	suite := TestSuite new.
  	^ self isAbstract
  		ifTrue: [
  			suite name: self name asString.
  			self allSubclasses
  				do: [:each | each isAbstract
  						ifFalse: [each addToSuiteFromSelectors: suite]].
(Continue reading)

Henrik Johansen | 1 Oct 16:36 2010

Re: [squeak-dev] Multiple finalizers per single object

I sort of disagree, in that it's neat to have a way for objects to be notified when other objects die, without
that object necessarily having to know about all objects that may be interested in its death.
(Like, in Leventes case which triggered their creation in the first place, objects which are weakly
registered to one or more announcers)

I don't really see the benefit in constraining an existing, flexible mechanic to only cover the common use case.

If multiple finalizers are removed, at least so should 
Object>>toFinalizeSend:to:with: (and potentially other spots, I haven't checked exactly) leaving
Object >> finalize as the only place where finalization actions take place. (Which is where the actions
Igor are talking about should be happening in the first place)


On Sep 23, 2010, at 10:36 27PM, Chris Muller wrote:

> I agree that multiple finalizers per object seems unnecessary and, as
> you pointed out, potentially confusing, if not also conflicting.
> TSTTCPW seems appropriate in this case.
> On Thu, Sep 23, 2010 at 3:23 PM, Igor Stasenko <siguctua@...> wrote:
>> Hello,
>> i'd like to raise this subject once more, because i don't like it (or
>> don't understand?).
>> In all scenarios, where i met the need to use finalization, a single
>> finalizer is sufficient.
>> Moreover, there is always a single object who controls a weak
(Continue reading)

Bert Freudenberg | 1 Oct 16:40 2010

Re: The Inbox: SUnit-spd.82.mcz

On 01.10.2010, at 14:31, commits <at> wrote:

> A new version of SUnit was added to project The Inbox:

Anyone interested in porting SUnit 4.0?

In 4.0, SUnit has been refactored.

1) TestResult now double-dispatches via the exception (see #sunitAnnounce:toResult:). This makes it
easier for users to plugin specific behaviour.

2) TestResource #setUp and #tearDown is now consistent with TestCase #setUp and #tearDown.
TestResource>>setUp is _not_ called by TestResource>>initialize; the framework calls
TestResource>>setUp separately. If TestResource>>setUp is entered then a call of
TestResource>>tearDown is ensured, just as for TestCase. (TestResource>>uninitialize, introduced
in in SUnit 3.2 in an earlier attempt to address this problem, is now deleted.)

IMPORTANT: it has always been the case that TestCase>>tearDown code may require
someVar isNil or: [someVar doTearDownStuff].
guards to handle the possibility that the test fails in early #setUp before someVar has been assigned (the
symptom of not having the guard is that the run shows two errors for the same test in that case). The above
change to TestResult means that some resource #tearDown code may now also require these guards. These
cases are usually very obvious to spot and fix, so we have accepted this side effect of the change.

Otherwise, framework behaviour and API are unaffected by this change. However in the very rare case that a
user has written a programmatic script for manipulating TestResources, they would need to replace any
(Continue reading)

commits | 1 Oct 02:00 2010

The Inbox: System-spd.355.mcz

A new version of System was added to project The Inbox:

==================== Summary ====================

Name: System-spd.355
Author: spd
Time: 1 October 2010, 1:06:53.037 pm
UUID: 0d476cb0-127d-4563-a895-d2757ce29b52
Ancestors: System-dtl.354

REFACTOR: Added intention revealing helper method to AppRegistry class>>register:
register: aProviderClass 
        default := nil.  "so it'll ask for a new default..." 

        self askForNewDefaultOnNextRequest. 

=============== Diff against System-dtl.354 ===============

Item was added:
+ ----- Method: AppRegistry class>>askForNewDefaultOnNextRequest (in category 'as yet
unclassified') -----
+ askForNewDefaultOnNextRequest
(Continue reading)

Frank Shearar | 1 Oct 19:48 2010

Re: The Inbox: Morphic-spd.459.mcz

On 2010/10/01 17:01, commits <at> wrote:
> A new version of Morphic was added to project The Inbox:
> ==================== Summary ====================
> Name: Morphic-spd.459
> Author: spd
> Time: 1 October 2010, 1:00:45.712 pm
> UUID: 1b989596-7d30-40b3-aadb-dde767cbd704
> Ancestors: Morphic-ar.458
> LineMorph class>>from:to:color:width: changed to return a LineMorph
> =============== Diff against Morphic-ar.458 ===============

I know precious little about Morphic, but I'm a bit confused:

1. Most of the commit seems to have nothing to do with LineMorphs.

2. LineMorph class>>from:to:color:width: now returns a PolygonMorph, not 
a LineMorph. (LineMorph subclasses PolygonMorph.
3. Morphic-ar.458's pretty old. My not-quite-up-to-date image is on 
Morphic-laza.468 already.