October 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Clean up the #sort: and sortBy: mess.
by Niko Schwarz Oct. 20, 2009

Oct. 20, 2009

Hi list, this is a copy of a proposal that I dumped into the bugtracker as http://code.google.com/p/pharo/issues/detail?id=1346. An OrderedCollection returns a copy on #sortBy:, while an ArrayedCollection returns a changed self on #sort:. ArrayedCollection does understand #sortBy:, while OrderedCollection does not understand #sort:. In VW and Squeak, OrderedCollection understands sort:, and it sorts inline. I'd like to propose two things (1) Add sort: to OrderedCollection, LinkedList and Heap (all of them understand at: put: since this weekend. and then (2) remove sortBy: I understand that point 2 might be controversial. I'd like to argue for it as follows: the naming sort vs. sortBy: is more than misleading, they appear to be synonyms, but they really do different things. The principle of the least surprise tells me that we should not have such behavior in the system. I'd like to argue that we want to erase the possible source of confusion, that is change sortBy: such that it either does the same as sort: or goes away. I'd like to leave #sort: the way it is because at any rate, we need to have an in-place sort, so why not keep the sort that sorts in- place. I'd argue it should go away, such that code that currently calls sortBy: does not call a method with changed semantics, which is difficult to debug. A DNU is easy to debug: you just change it to the now appropriate call. For me the most reasonable options are these: - rename #sortBy: to #copySortedBy: - remove #sortBy: Out of these, I'd vote for removing, since #copySortedBy: is not really shorter than 'copy sort:'. Cheers, Niko

1 0

[Pharo-project] scriptloader>>loadComanche
by Torsten Bergmann Oct. 20, 2009

Oct. 20, 2009

>#loadSeaside30 does not work anymore Ohh ... not again! >ScriptLoader should not be used for loading external packages :) We already had this discussion and agreed that we at least keep the Seaside loading since "ScriptLoader loadSeaside30" is widely communicated already! >We clearly need a universe like tools so that people can publish and >maintain their add-ons. Yes, but we should be pragmatic for Seaside since it is the "flagship" until we have the infrastructur set up. Maybe we should delete it from the core but we can the loading support in the dev images. What do you all think? Bye T. -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02

4 3

[Pharo-project] New Pharo and pharo-web based on core 10491
by Damien Cassou Oct. 20, 2009

Oct. 20, 2009

RC1: http://pharo-project.org/pharo-download -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

1 0

[Pharo-project] String lines/linesDo: cr/crlf/?
by stephan＠stack.nl Oct. 20, 2009

Oct. 20, 2009

What behaviour should I expect from String:linesDo:? The linesDo: in String expects a cr as lineSeparator. lines in *magritte-model-accessing is more flexible, it also accepts crlf. There is no test for this behaviour. In a cross-platform environment (development on OS-X and windows, deployment on linux) I prefer the lines behaviour when reading and writing files. Stephan

1 0

[Pharo-project] [update] #11003 and 11004
by StÃ©phane Ducasse Oct. 20, 2009

Oct. 20, 2009

11003 ----- Issue 1272: Strange copy return values for some SequenceableCollection subclasses Issue 1272: Strange copy return values for some SequenceableCollection subclasses - Part 2 Stef and Jorge

1 0

[Pharo-project] [update] #10487
by Adrian Lienhard Oct. 20, 2009

Oct. 20, 2009

10483 - 10487 ----- - Issue 1310: Make all tests green - Issue 1330: Better performance for tests Test result: 7168 run, 7150 passes, 18 expected failures, 0 failures, 0 errors, 0 unexpected passes ___________________ http://www.adrian-lienhard.ch/

9 24

Re: [Pharo-project] About TestCase >> assert:
by Dale Henrichs Oct. 20, 2009

Oct. 20, 2009

Nicolas, many very good points. Just to add food for thought... double dispatching is a technique that has the benefit of avoiding isXXXX messages completely allowing for maximum flexibility and if the message isn't understood, immediate feedback that the programmer has done something wrong (which can be fixed by implementing the appropriate dispatch method) ... better than an assertion failures perhaps... Of course, double dispatching is not without it's drawbacks. I prefer double dispatching to implementing isXXX messages, but then I'd like to eliminate Booleans, too:) Dale ----- "Nicolas Cellier" <nicolas.cellier.aka.nice(a)gmail.com> wrote: | 2009/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: | > | >> I think Smalltalk quality is based on a completly different plane | > | | First, my reference about quality is not Squeak, I rather mean st-80 | from ParcPlace :) | At least it used to have | - more generous class and method comments | - less bugs and obscure code (certainly because less code too !) | - a certain homogeneity (less programmers ?) | | So were is the Smalltalk quality ? | - the ability to test code as soon as written | - the ability to write small and simple code, | - the ability to write readable code, | - the ability to extend code | Are these essential properties in the quality standards used in static | typing ? | | > You mean not checkable documentation, absence of documentation, | > lack of static typing to document (because what would be good is to | > have a pluggable type system) | > | | I agree, lack of type can be seen as a weakness for documenting APIs. | As a workaround, we use funny parameter names (anArrayOfStrings). | Or we add a method comment (hem... at least we should). | I agree, all these comments will become false when code is changed, | and the quality will decrease... | As false as an outdated assertion... but silent... Maybe it's worse ? | Browsing senders, or inspecting the signature of message sent to, or | inserting a halt is sometimes our solutions... | I agree, this is not ideal. | | So yes, assertions as a public declaration of API could be good for | documenting. | And a good description of assertion failure can also provide | informative feedback to the user (more than a Debugger ?) | | What I do not like is defensive assertions as a potential barrier to | extendability, because they correspond to a static view of code, a | snapshot of current state. | Smalltalk state does and will change. The image is living, and class | structure not written on stone. | Rapidly changing code is definitely not accepted as a quality | standard... | | In a rapidly changing image, assertions could be a supplementary drag | against change... | Suppose I have a method accepting a String parameter P: p. | [p isString] assertWithDescription: 'method xxx only accept a | String as parameter P'. | Now maybe the method would have worked with a Text. I have been too | restrictive: | [p isCharacters] assertWithDescription: 'method xxx only accept | characters'. | Now someone introduce WideString, and my code only work with | ByteString. | [p isCharacters and: [p asString isByteString]] | assertWithDescription: 'method xxx only accept byte characters'. | Yes, but the method does not work with empty String, I add: | [p notEmpty] assertWithDescription: 'method xxx only accept non | empty strings'. | Nor does it with some control characters: | self assertPHasValidCharacters: p. | Fortunately someone then correct the WideString case, now I can | retract isByteString. | Unfortunately, p will be stored in an inst. var. with many public | interfaces... | Each time, I have to change all the false assertions in all senders | of | the core method that are in the public API... | And maybe some of these public APIs are driven by other public APIs | (you meet this in Smalltalk, didn't you?) | To avoid this I create a specific method | assertPIsValid: p | | sender | | sender := thisContext sender homeContext selector. | [p isCharacters] assertWithDescription: 'method ' , sender , ' | only accept characters'. | [p asString isByteString] assertWithDescription: 'method ' , | sender , ' only accept byte characters'. | [p notEmpty] assertWithDescription: 'method ' , sender , ' only | accept non empty strings'. | self assertPHasValidCharacters: p from: sender. | | But now, I can't see the assumption from within public API. I have to | browse implementors of assertPIsValid:, so I loose the immediate | documentation... | | And one day, a brilliant programmer decide a ReadStream on characters | would also be a good parameter P, with a minor change in the core | method... | Arghh, I don't want to advance the stream yet and do all my static | checks... | | In order to maximize extendability, can't we use extensible | assertions | like sending a message? | If we end up with | [p isAGoodParameterPForMyMessage] assert. | then I don't buy it ;) | | Maybe you have some better ideas about optional types as a | specification... | Semi-automatic RoelTyper like helper tools? | | Nicolas | | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] [ANN] Pharo Core 1.0rc1
by Marcus Denker Oct. 19, 2009

Oct. 19, 2009

http://gforge.inria.fr/frs/download.php/24363/PharoCore-1.0-10491rc1.zip The zip contains a new sources file. Marcus

4 9

[Pharo-project] HostWindowTests>>testOne is failing in Windows
by Mariano Martinez Peck Oct. 19, 2009

Oct. 19, 2009

Hi adrian: I run all Pharo core tests in a Windows box and I get only one failure and 18 expected failures :) The only failure is HostWindowTests>>testOne. The assert with problem is: self shouldnt: [ hwindow open ] raise: Error. And the error raised is 'My subclass should have overridden #defaultWindowType' This is because in DisplayHostWindow>>open windowProxy is a HostWindowProxy and this class, the implementation of defaultWindowType is: defaultWindowType "set up my attributes to be a default window - a titlebar, usual decorations etc" ^self subclassResponsibility I opened a bug ticket: http://code.google.com/p/pharo/issues/detail?id=1338 Best, Mariano

1 1

Oct. 19, 2009

Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: October 19, 2009 3:00:19 PM GMT+02:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, stephane ducasse <stephane.ducasse(a)gmail.com > > > Subject: Fwd: [squeak-dev] The Trunk: Collections-nice.167.mcz > > Salut bis, > > Minor change to be integrated in pharo... > > Nicolas > > ---------- Forwarded message ---------- > From: <commits(a)source.squeak.org> > Date: 2009/10/19 > Subject: [squeak-dev] The Trunk: Collections-nice.167.mcz > To: squeak-dev(a)lists.squeakfoundation.org > > > Nicolas Cellier uploaded a new version of Collections to project The > Trunk: > http://source.squeak.org/trunk/Collections-nice.167.mcz > > ==================== Summary ==================== > > Name: Collections-nice.167 > Author: nice > Time: 19 October 2009, 12:32:29 pm > UUID: 95819d6c-2419-0244-bce5-75e402e44ec3 > Ancestors: Collections-ar.166 > > http://bugs.squeak.org/view.php?id=7362 > use self class instead of Text, so that we can subclass Text > > =============== Diff against Collections-ar.166 =============== > > Item was changed: > ----- Method: Text>>reversed (in category 'converting') ----- > reversed > > "Answer a copy of the receiver with element order reversed." > > ^ self class string: string reversed runs: runs reversed. > > " It is assumed that self size = runs size holds. "! > > Item was changed: > ----- Method: Text>>copyFrom:to: (in category 'copying') ----- > copyFrom: start to: stop > "Answer a copied subrange of the receiver." > > | realStart realStop | > stop > self size > ifTrue: [realStop := self size] "handle > selection at end of string" > ifFalse: [realStop := stop]. > start < 1 > ifTrue: [realStart := 1] "handle > selection before start of string" > ifFalse: [realStart := start]. > + ^self class > - ^Text > string: (string copyFrom: realStart to: realStop) > runs: (runs copyFrom: realStart to: realStop)!

2 1