Nicolas Cellier uploaded a new version of Graphics to project The Trunk:
http://source.squeak.org/trunk/Graphics-nice.150.mcz
==================== Summary ====================
Name: Graphics-nice.150
Author: nice
Time: 1 October 2010, 10:39:00.499 pm
UUID: 20a16c7e-0232-4fd1-a522-23999bb77504
Ancestors: Graphics-ar.149
Remove #hashMappedBy: and #identityHashMappedBy:
=============== Diff against Graphics-ar.149 ===============
Item was removed:
- ----- Method: Point>>hashMappedBy: (in category 'comparing') -----
- hashMappedBy: map
- "My hash is independent of my oop."
-
- ^self hash!
Item was removed:
- ----- Method: Rectangle>>hashMappedBy: (in category 'comparing') -----
- hashMappedBy: map
- "My hash is independent of my oop."
-
- ^self hash!
Nicolas Cellier uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-nice.386.mcz
==================== Summary ====================
Name: Collections-nice.386
Author: nice
Time: 1 October 2010, 10:37:30.237 pm
UUID: 14bfeb25-a255-4838-87d4-4c4dccac4b2d
Ancestors: Collections-nice.385
Remove #hashMappedBy: and #identityHashMappedBy:
=============== Diff against Collections-nice.385 ===============
Item was removed:
- ----- Method: Array>>hashMappedBy: (in category 'comparing') -----
- hashMappedBy: map
- "Answer what my hash would be if oops changed according to map."
-
- self size = 0 ifTrue: [^self hash].
- ^(self first hashMappedBy: map) + (self last hashMappedBy: map)!
Item was removed:
- ----- Method: Interval>>hashMappedBy: (in category 'comparing') -----
- hashMappedBy: map
- "My hash is independent of my oop."
-
- ^self hash!
Item was removed:
- ----- Method: LookupKey>>hashMappedBy: (in category 'comparing') -----
- hashMappedBy: map
- "Answer what my hash would be if oops changed according to map."
-
- ^key hashMappedBy: map!
Item was removed:
- ----- Method: LookupKey>>identityHashMappedBy: (in category 'comparing') -----
- identityHashMappedBy: map
- "Answer what my hash would be if oops changed according to map."
-
- ^ key identityHashMappedBy: map!
Item was removed:
- ----- Method: String>>hashMappedBy: (in category 'comparing') -----
- hashMappedBy: map
- "My hash is independent of my oop."
-
- ^self hash!
Item was removed:
- ----- Method: WeakKeyAssociation>>hashMappedBy: (in category 'comparing') -----
- hashMappedBy: map
- "Answer what my hash would be if oops changed according to map."
-
- ^self key hashMappedBy: map!
Item was removed:
- ----- Method: WeakKeyAssociation>>identityHashMappedBy: (in category 'comparing') -----
- identityHashMappedBy: map
- "Answer what my hash would be if oops changed according to map."
-
- ^ self key identityHashMappedBy: map!
On 2010/10/01 17:01, commits(a)source.squeak.org wrote:
> A new version of Morphic was added to project The Inbox:
> http://source.squeak.org/inbox/Morphic-spd.459.mcz
>
> ==================== 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.
frank
A new version of Morphic was added to project The Inbox:
http://source.squeak.org/inbox/Morphic-spd.469.mcz
==================== Summary ====================
Name: Morphic-spd.469
Author: spd
Time: 1 October 2010, 2:20:39.508 pm
UUID: a68c21fa-d7d3-46da-82ea-53077512621a
Ancestors: Morphic-laza.468
LineMorph class>>from:to:color:width: changed to return a LineMorph
=============== Diff against Morphic-laza.468 ===============
Item was changed:
----- Method: LineMorph class>>from:to:color:width: (in category 'instance creation') -----
from: startPoint to: endPoint color: lineColor width: lineWidth
+ ^ self vertices: {startPoint. endPoint}
- ^ PolygonMorph vertices: {startPoint. endPoint}
color: Color black borderWidth: lineWidth borderColor: lineColor!
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.
http://code.google.com/p/pharo/issues/detail?id=3022
Thanks for the idea and initial code!
Bye
T.
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
On 01.10.2010, at 14:31, commits(a)source.squeak.org wrote:
> A new version of SUnit was added to project The Inbox:
> http://source.squeak.org/inbox/SUnit-spd.82.mcz
Anyone interested in porting SUnit 4.0?
http://www.squeaksource.com/SUnit.html
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
var := MyTestResource new.
with
var := MyTestResource new; setUp.
since #new's call of #initialize no longer calls #setUp.
3) There are changes to #testSelectors, #allTestSelectors, #sunitAllSelectors (which is now deprecated) and #sunitSelectors (which is now in protocol 'private', does not guarantee order, is now trivial to inline and may in future be deprecated). Associated changes to #buildSuiteFromSelectors, with deletion of #buildSuiteFromLocal/AllSelectors, integrate suite building with #shouldInheritSelectors and a new method, #lookupHierarchyRoot, giving more consistent test inheritance behaviour, and better performance in hierarchies with many selectors and fewer test selectors. Any utilities that called #buildSuiteFromLocal/AllSelectors explicitly can eliminate both calls, and the boolean test that decides which call to send, in favour just calling #buildSuiteFromSelectors.
4) In all normal-usage cases, TestResources now ask their requesting test or candidate-resource to signal their failure, thus providing more informative logging.
- Bert -