- Pharo-dev - lists.pharo.org

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

[Pharo-project] [ANN] 10353
by StÃ©phane Ducasse July 3, 2009

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

[Pharo-project] Fwd: [ANN] 10352
by StÃ©phane Ducasse July 3, 2009

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

[Pharo-project] proposed fix for issue 913
by Dale Henrichs July 3, 2009

July 3, 2009

http://code.google.com/p/pharo/issues/detail?id=913 I wasn't able to directly reproduce the problem in my tests, but upon code inspection it was obvious that an empty Dictionary should be returned by BytecodeEncoder>>blockExtentsToTempRefs instead of nil. None of the senders would be adversely affected by the change. Of course the changes are in the Compiler package, so it's worth having an extra set of eyes take a look. Dale

2 1

[Pharo-project] creation of ReadWriteStream with #on:
by Cyrille Delaunay July 3, 2009

July 3, 2009

Hi, ReadWriteStream inherits from WriteStream which hinerits from PositionableStream. When you create a ReadWriteStream with #on: you use the default definition in PositionableStream : PositionableStream class >> on: aCollection "Answer an instance of me, streaming over the elements of aCollection." ^self basicNew on: aCollection #on: is not overriden in the instance side of ReadWriteStream and therefore it's the definition of WriteStream that is called : WriteStream >> on: aCollection super on: aCollection. readLimit := 0. writeLimit := aCollection size. Put the readLimit at 0 make sense for a WriteStream ( with witch your not supposed to read ) but when you create a ReadWriteStream on a collection you would be able to read what is already in the collection, no? I wonder why #on: has not been overriden in the instance side of ReadWriteStream ? Maybe it's not a good idea to create a ReadWriteStream with a collection that already includes elements ?

4 7

[Pharo-project] oldFileNamed
by Henrik Johansen July 3, 2009

July 3, 2009

Forgetting the wish for new File accessing implementations for a moment, is there a reason why the current StandardFileStream >> oldFileNamed: (and oldFileFullyNamed) is implemented: ^(self isAFileNamed: fileName) ifTrue: [self new open: fileName forWrite: true] ifFalse: [(FileDoesNotExistException fileName: fileName) signal] instead of : ^(self new open: fullName forWrite: true) ifNil: ["File does not exist..." (FileDoesNotExistException fileName: fullName) signal] ? Feels abit silly to open a file to see if it exists, then close it, then open it again before returning it... (It also causes an unneccessary rehash of StandardFileStream registry on success) Cheers, Henry

2 2

July 3, 2009

> can other people check so that we can close it. :) > Thanks marco. > > Stef > > Begin forwarded message: > >> From: codesite-noreply(a)google.com >> Date: July 3, 2009 10:33:34 AM CEDT >> To: stephane.ducasse(a)gmail.com >> Subject: Issue 513 in pharo: UTF8 and file names >> >> >> Comment #7 on issue 513 by MarcoTaugammaSchmidt: UTF8 and file names >> http://code.google.com/p/pharo/issues/detail?id=513 >> >> This bug should be closed? It works for me... >> >> >> -- >> You received this message because you are listed in the owner >> or CC fields of this issue, or because you starred this issue. >> You may adjust your issue notification preferences at: >> http://code.google.com/hosting/settings > > > >

1 0