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

[Pharo-project] [ANN] 10355 , 6 and 7
by StÃ©phane Ducasse July 4, 2009

July 4, 2009

Hi Issue 59 is now integrated. Thanks pavel to provide a new version that fast :) Issue 59: 7109 ChangesOrganizer-pk (M4825) http://code.google.com/p/pharo/issues/detail?can=2&q=59 Stef

1 0

[Pharo-project] [ANN] 10354
by StÃ©phane Ducasse July 4, 2009

July 4, 2009

Hi guys lukas smallLint rules found some _ left. Now we can do that at the AST level :) - issue 604 closed :) Stef

1 0

[Pharo-project] SLICE-MovingPointersToExceptNewVersion
by Alexandre Bergel July 4, 2009

July 4, 2009

A new version of the slide has been produced (SLICE- MovingPointersToExceptNewVersion- Alexandre_Bergel.1), in the PharoInbox. The previous attempt (SLICE-MovingPointersToExcept- Alexandre_Bergel.1) should be ignored. - deprecated methods pointersTo:, pointersTo:except:, pointersToItem:of - added test in ToolsTest-PointerFinder - change all send to Utilities to PointerFinders Pair programmed with Andreas Leidig ISSUE #899 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

[Pharo-project] [ANN] new image on the server
by StÃ©phane Ducasse July 4, 2009

July 4, 2009

Hi guys I updated a new core image 10353 - Issue 893: InputEventSensor>>commandKeyPressed - Issue 892: FTPClient does not work anymore Final license cleaning - Network-Url-GabrielOmarCotelli.7 HTTPUrl>>retrieveContentArgs:) - Morphic-GabrielOmarCotelli.326 TransformMorph >> numberOfItemsPotentiallyInViewWith: PluggableListMorph >> numSelectionsInView WorldState class >> deferredExecutionTimeLimit WorldState >> runStepMethodsIn: - Cleaning of PMM methods Object >> isTrait Set class >> rehashAllSets Set class >> new CodeLoader class >> exportCodeSegment:classes:keepSource: FloatTest >> testInfinity3 (deleted) FloatTest >> testZero2 (deleted) - super initialize second half - Issue 135 Thanks alain. - Issue876 - Pre-requisite for http://bugs.squeak.org/view.php?id=3374 aka http://code.google.com/p/pharo/issues/detail?id=876 - Issue876 - Fix and test http://bugs.squeak.org/view.php?id=3374 aka http://code.google.com/p/pharo/issues/detail?id=876 Mind the order: load the Pre-requisite Part1 first... - Issue 890: Mantis 6535: keyBlock and sortBlock are lost when creating a collection of the same species. Test And Fix for KeyedSet to avoid loosing blocks issue http://code.google.com/p/pharo/issues/detail?id=890 Mantis http://bugs.squeak.org/view.php?id=6535 - Issue 890: Mantis 6535: keyBlock and sortBlock are lost when creating a collection of the same species. Tests and Fix for avoiding loosing sortBlock - Part1 issue http://code.google.com/p/pharo/issues/detail?id=890 Mantis http://bugs.squeak.org/view.php?id=6535 - Issue 890: Mantis 6535: keyBlock and sortBlock are lost when creating a collection of the same species. Tests and Fix for avoiding loosing sortBlock - Part2 issue http://code.google.com/p/pharo/issues/detail?id=890 Mantis http://bugs.squeak.org/view.php?id=6535 - Issue 890: Mantis 6535: keyBlock and sortBlock are lost when creating a collection of the same species. Tests and Fix for avoiding loosing sortBlock - Part3 issue http://code.google.com/p/pharo/issues/detail?id=890 Mantis http://bugs.squeak.org/view.php?id=6535 - Issue 879 Fix and Test for http://code.google.com/p/pharo/issues/detail?id=879 ANSI FLoat characterizaton messages are lacking. Additons to Float class: #denormalized #emax #emin #epsilon #fmax #fmin #fminDenormalized #fminNormalized #radix Additions to Float: #predecessor #successor These last two are not ANSI but VERY convenient - Issue 67: guessLineEndFix - Issue 923: remove the check when defining methods on the class side. Now you do not get this isScarySelector invoke and the Parser is not called twice. Issue 922: Should remove inst var and class var checks. it was a good idea but we will achieve the same with smallLint - Replacing _ by :=

1 0

Re: [Pharo-project] about issue 59
by StÃ©phane Ducasse July 4, 2009

July 4, 2009

Thanks a **lot**. On Jul 4, 2009, at 9:20 AM, Pavel Krivanek wrote: > Finished... see http://code.google.com/p/pharo/issues/detail?id=59 > > so, some comments: > > This patch must be done in *three* separate updates > - the first one loads the ChangesOrganizer class. This class > contains class variables from the ChangeSorter and class-side > methods for changes management. As the postinstallation step the > attached code must be evaluated. It switches the class variables > dictionary from ChangeSorter to ChangesOrganizer > - the second update will load the second changeset. This changeset > switches the usages of ChangeSorter to ChangesOrganizer in methods > that use it for general changes manipulation. > - as the final step the latest changeset removes all class variables > from the ChangeSorter and modifies some methods to delegate its > functionality to ChangesOrganizer. We step must be done in time when > no other class uses the ChangeSorter for changes management. It can > break the update otherwise. > > I hope that this quite radical update will not end with the > headache... > > Cheers, > -- Pavel > > On Fri, Jul 3, 2009 at 9:41 PM, stephane ducasse <stephane.ducasse(a)free.fr > > wrote: > Thanks this is a really fast answer :) > > I'm cleaning the _ ;) > Stef > > > > On Jul 3, 2009, at 9:35 PM, Pavel Krivanek wrote: > > Hi Stef, > > I'll prepare and upload the updated version for latest Pharo > tomorrow. Look at some other issue for now. > > Cheers, > -- Pavel > > On Fri, Jul 3, 2009 at 9:29 PM, stephane ducasse <stephane.ducasse(a)free.fr > > wrote: > Hi pavel > > I'm trying to understand what I should do for integrating this fix > but this is not clear to me. > http://code.google.com/p/pharo/issues/detail?id=59 > > could you help me? > > Stef > > >

1 0

[Pharo-project] Deprecation
by StÃ©phane Ducasse July 4, 2009

July 4, 2009

From elliot On Fri, Jul 3, 2009 at 2:41 PM, Ken Causey <ken <at> kencausey.com> wrote: I would like to suggest that we develop a formal deprecation policy. It could be as simple as deprecate in one release, remove in the next. I just think we need to be consistent about it and remove no individual methods without following it. How this relates to the idea of repackaging and removing whole categories of classes, I'm not so sure. It would be good to add a date, version and selector Deprecation as in self deprecated: 'use Foo>>mumble' on: '2009/6/3' in: 'Croquet1.0beta' Move the preference check into Deprecation defaultAction. This would allow logging to collect a set of selectors used in a particular run, e.g. deprecations := Deprecation deprecationsWhile: [self runMyTests] as in the attached

1 0

[Pharo-project] adding nil to sets
by Ralph Boland July 4, 2009

July 4, 2009

Please note the change of topic; adding the ability to add nil to sets won't make sets faster and may well make them slower so has nothing to to with the FasterSets package. Since I am here allow me to state my opinion on the matter. We should not add the ability to add nil to Sets. While I admit I don't know for sure, I believe the number of instances where we need to add nil to a set is rare. For the rare cases in which it is needed we should create a class SetSupportingNils which has two instance variables: containsNil: a boolean set to true iff the SetSupportingNils instance contains nil. set: an instance of Set or one of its subclasses and used to store any object added to the SetSupportingNils instance except of course nil. This means that SetSupportingNils would need to recognize any message that Sets or its subclasses can understand. Any message not understood by SetSupportingNils would be forwarded to its set instance variable. My proposal is not very efficient when adding nil to a set is needed but it requires no modifications to Set or any of its subclasses. That a rarely used class is somewhat inefficient is acceptable. Issue: I suppose we need a BagSupportingNils class too. Are there any other classes we need? Can they be combined into one class? Regards, Ralph Boland

7 11

[Pharo-project] FasterSets improvements
by Ralph Boland July 3, 2009

July 3, 2009

2009/7/1 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > I took some time to check this yesterday, my comments on the code itself are > basically the same as what Lucas posted in the issue tracker. > Works as advertised, but should probably clean out the "gunk" which is > unused after it's integrated. > > Some feedback on possible improvements: > - What it does, is basically speed up the adds to the new array in a grow > that might happen Why not take this all to the logical conclusion, and > instead optimize an addAll: method to be used in grow, that assumes elements > are not in set (and themselves are not duplicates)? F.ex. it could also add > to tally just once, instead of one increase per element as the noCompareAdd: > does. (an add method with no tally add, no = object check, and no > growCheck). > > - The usual addAll: method can be sped up in a similar way, by performing > one grow operation before adding elements if necessary (pessimistically > assuming all elements are unique), then use an add method which does not > check for grow need at all. (an add method with tally add and = object > check, but no growCheck) > If desirable, you could also shrink the capacity after adds are done, to > match the real amount of new elements. > > Adding (1 to: 1200000) to a new Set with such an addAll: method took 1/2 to > 1/3rd the time of the regular addAll: method, even with the lower grow cost > of FasterSets. (Lower gains if Set is presized, and if hash-calculation is > bigger part of cost) > I considered this when I created FasterSets. I didn't do this because I was being conservative. I didn't want FasterSets rejected because it did things that weren't wanted. I am surprised though at the amount of performance gain you see. As things stand I see no reason for not including FasterSets other than the potential of breaking packages that subclass Set and then override methods crucial to FasterSets. My vote is obviously for fixing any packages that get broken rather than rejecting FasterSets. > Note: If you want to stay ANSI-compatible, one tricky point in such an > optimization is adding all objects in collection up to a nil element, then > raising an error. (ie: must produce equivalent results to add: performed of > each of collections elements in sequence ) > > Cheers, > Henry > > I created FasterSets for adding to Squeak and did not consider Pharo but of course am delighted to have it considered for Pharo. You can of course make whatever improvements you want. I encourage though that you create a FasterSets2 containing all the improvements and leave the original FasterSets alone. I am still interested in having FasterSets included in Squeak and I do not know if the powers that be will want the additional improvements or not so I prefer that both versions exist. One thing that I have in my code is a method called nastyAddNew: which adds an element to a set without checking if the element is already there. If the element is already there of course it gets added again and your set contains two copies of the element; thus your set is corrupted. This problem explains the 'nasty' part of the name nastyAddNew. I also have a method addNew: which reports an error if the object is already in the set. nastyAddNew: can be used in set operations such as copy and intersection making these operations faster and can also be used externally by brave users. If improvements to FasterSets are being contemplated then I suggest that adding methods addNew: and nastyAddNew: be considered. If nastyAddNew: is added I see no point in making it private because some users will use it anyway. I am not necessarily voting for their inclusion because we are then giving the user the opportunity to corrupt his data. Of course I do use them in my current project. thus, for my current project at least, I am a brave user. Regards, Ralph Boland

5 19

July 3, 2009

Hi guys some more :) (this is good when I do not have to fix my house). - Issue 924: Cursor Class cannot be initialized! - Issue 925: Replace _ by := on all the packages Stef PS: lukas wrote a couple of nice SmallLint rules to check instanceVariables classVariables _ use :)

1 0

July 3, 2009

> > Hi guys > > We got some fun with lukas and did: > > Issue 923: remove the check when defining methods on the class side. > Now you do not get > this isScarySelector invoke and the Parser is not called twice. > > Issue 922: Should remove inst var and class var checks. > it was a good idea but we will achieve the same with smallLint'. > > > Stef and Lukas pre sprinting > > > >

1 0