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

Re: [Pharo-project] oldFileNamed

by Henrik Johansen

http://code.google.com/p/pharo/issues/detail?id=921 On Jul 3, 2009, at 2:39 00PM, Damien Cassou wrote: > 2009/7/3 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> 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) > > Please submit an issue in the tracker and provides a changeset or a > mcz with your change. I will have a look at it. > > Thank you for your report > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 3, 2009

Re: [Pharo-project] bugs with SmallDictionary #scanFor:

by Damien Cassou

2009/7/3 Cyrille Delaunay <cy.delaunay(a)gmail.com>: > SmallDictionary, unlike all subclasses of Dictionary, never used ( and > initialize ) the instance variable: 'array'. > Associations are stored with a key array ( called 'keys' ) and a value array > ( 'values' ). > Problem is that the method #scanFor: is define in Dictionary ( and not > overriden ) with this code : > scanFor: anObject > | element start finish | > finish := array size. > Â Â Â Â Â .... > 'array' is Â nil and it cause bugs for those methods : > -> #includesAssociation: > -> #associationAt: > -> #associationAt:ifAbsent: > -> #associationDeclareAt: Please have a look at http://code.google.com/p/pharo/issues/detail?id=463 and comment. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 3, 2009

Re: [Pharo-project] oldFileNamed

by Damien Cassou

2009/7/3 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > 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) Please submit an issue in the tracker and provides a changeset or a mcz with your change. I will have a look at it. Thank you for your report -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 3, 2009

Re: [Pharo-project] adding nil to sets

by Andres Valloud

Something that could be considered down the road is restructuring the collection hierarchy to, among other things, allow pluggable hashed storage strategies for hashed collections. This approach should drastically reduce the number of classes in the hashed collection class hierarchy (c.f.: what happens in VW). StÃ©phane Ducasse wrote: > Thanks ralph. > I think that this is not a so good idea to have nil as element. > > BTW: just to make sure. Our is not to hijack people from the squeak > community > (because when I scanned some emails there I thought that we were > considered as evil > and bad guys - people have a short memory). > Our goal is to build an agile Smalltalk with faster, better.... code. > And to make sure that people can reinvent the future because they can > use cool > abstractions. > > Stef > > > On Jul 3, 2009, at 8:53 AM, Ralph Boland wrote: > > >> 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 >> >> _______________________________________________ >> 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 > . > >

July 3, 2009

Re: [Pharo-project] Problem with fork

by Reinout Heeck

Hi all, this is my first post here, just joined this group so let me do a quick introduction. I have 10+ years of experience doing full-time development with VisualWorks (creating trading platforms for the European energy exchanges). Also I have near-zero experience with using Squeak or how its development process works. I'll slowly cut my teeth, starting by interacting on this mailing list. Multi threading is something I have spent a lot of quality time with, so I want to share some thoughts on the following: |semaphores tr| semaphores := Array new: 10. tr := ThreadSafeTranscript new. tr open. 1 to: 10 do: [ :index | semaphores at: index put: Semaphore new ]. 1 to: 10 do: [:i | [ tr nextPutAll: i printString, ' fork '; cr. (semaphores at: i) signal. ] fork ]. semaphores do: [:each | each wait ]. tr show: 'all forks proccesed'; cr. I have seen this pattern often (allocating a semaphore for every forked process), I usually interpret this as a signal that such code is still in its first 'make it work/make it right' stages. What a lot of people don't realize is that at its heart a semapore is a thread-safe counter/register (and if you look at the hierarchy it is implemented on you wouldn't guess that either, since the hierarchy stresses the implementation part that manages waiting processes rather than the counter aspect). So trying to take the code snippet toward 'make it abstract' territory this could be refactored to lean more on the counter aspect of semaphores and use only a single semaphore: |count sem tr| tr := ThreadSafeTranscript new. tr open. count := 10. sem := Semaphore new. 1 to: count do: [:i | [ tr nextPutAll: (i printString, ' fork\') withCRs. sem signal. ] fork]. count timesRepeat: [sem wait]. tr show: 'all forks proccesed'; cr. Now the above is about as far as you can go with the current Squeak and VisualWorks implementations so you can take it as a simple refactoring advise. However I want to press on a bit more (and go a bit off-topic for this list ;-) because I feel it still has a big problem: we need to maintain a 'count' and pass that between the two loops in the above example. In the current example this is not much of a problem but in more complex applications where the forking is done by yet other forked processes we will need to make 'count' thread-safe as well -- I find this very ugly, because you will need an extra semaphore just to make the original semaphore work as required. Furthermore you cannot add new forked processes once the second loop has started running. So here is an experiment I did a couple of years ago with VisualWorks: I altered the VM (just one line of its source ;-) so it would react properly to semaphores that have negative values in the 'excessSignals' instance variable, and I added a method #unsignal to Semaphore that would decrease the value of that ivar. In my experiments that yielded many opportunities to simplify multiprocessing code (not only for thread synchronization but also for passing around counts in a thread-safe register!). In the above code that would allow us to 'pre-load' the semaphore at the place where the threads are created with as result that the 'count' variable can be removed and the bottom loop can be removed too: |count sem tr| tr := ThreadSafeTranscript new. tr open. sem := Semaphore forMutualExclusion. "We need one excessSignal to balance the #wait below" 1 to: 10 do: [:i | sem unsignal. "outside the forked code" [ tr nextPutAll: (i printString, ' fork\') withCRs. sem signal. "balance the unsignal" ] fork]. sem wait. "no loop, no need to know the count!" tr show: 'all forks proccesed'; cr. Above was just a simple refactoring, but look at how I needed it: |sem tr| tr := ThreadSafeTranscript new. tr open. sem := Semaphore new. "no excessSignal this time" "set up a monitoring system first(!)" [ sem wait. tr show: 'all forks proccesed'; cr ] fork. "then create jobs (in my case I had only a single first job that would recursively create more jobs, not shown here)" 1 to: 10 do: [:i | sem unsignal. [ tr nextPutAll: (i printString, ' fork\') withCRs. sem signal. ] fork]. "Now that we are sure at least one job is entered balance the #wait we started out with" sem signal. Since we elided 'count' I can move the code that relied on it up in front of the thread creation code, I very much like this flavor of decoupling. I guess this illustrates that Semaphore is stuck in the 'make it work/ make it right' phase for thirty years now, and that moving it into 'make it abstract' territory will make lots of hairy multi-threading code much simpler to express... (And for those thinking this through: yes I did implement a thread- safe #add: and #valueWithReset on semaphore too ;-) I hope I didn't bore y'all and stray to far off-topic, but I did want to share this bit of insight I gained by tinkering with the semaphore implementation: semaphores are thread-safe counters at their heart. Cheers, Reinout ------- PS: big congrats with the license cleaning milestone, this is what finally pulled me into this project :-)

July 3, 2009

[Pharo-project] oldFileNamed

by Henrik Johansen

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

July 3, 2009

Re: [Pharo-project] adding nil to sets

by Igor Stasenko

2009/7/3 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > Having collections that do not naively implement addAll: falls into > that category I think. > Just in case it isn't clear by now: It WILL break compatability with > custom subclasses though. (which is why I think VW and Squeak will > never do it) > > Personally, I feel the ANSI standard failed in this regard, specifying > a behaviour for addAll: that automatically leads to implementing it > the naive way. > Instead of say, adding all the objects that you are able to add from > the collection, then raising an error with the ones you could not > Especially when using addAll: with an unordered collection as > parameter, it leads to random results as to what is added and what is > not before the error is raised... > > I agree with Ralph on the nil issue (and the implementation details if > we do make one ;) ), slowing down 99.99999% of hashable collections to > satisfy those few use-cases where there's a need for Sets which accept > nil isn't really a super option... > I am also think that (re)placing the nil-handling code in Set itself not worth it. That's why i made it as a separate class named GenericSet. > Cheers, > Henry > > On Jul 3, 2009, at 11:47 26AM, StÃ©phane Ducasse wrote: > >> Our goal is to build an agile Smalltalk with faster, better.... code. >> >> Stef >> >> >> On Jul 3, 2009, at 8:53 AM, Ralph Boland wrote: >> >>> 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 >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 3, 2009

Re: [Pharo-project] bugs with SmallDictionary #scanFor:

by Lukas Renggli

I think SmallDictionary should be removed from the core. There are no users. Lukas 2009/7/3 Cyrille Delaunay <cy.delaunay(a)gmail.com>: > SmallDictionary, unlike all subclasses of Dictionary, never used ( and > initialize ) the instance variable: 'array'. > Associations are stored with a key array ( called 'keys' ) and a value array > ( 'values' ). > Problem is that the method #scanFor: is define in Dictionary ( and not > overriden ) with this code : > scanFor: anObject > | element start finish | > finish := array size. > Â Â Â Â Â .... > 'array' is Â nil and it cause bugs for those methods : > -> #includesAssociation: > -> #associationAt: > -> #associationAt:ifAbsent: > -> #associationDeclareAt: > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

July 3, 2009

[Pharo-project] bugs with SmallDictionary #scanFor:

by Cyrille Delaunay

SmallDictionary, unlike all subclasses of Dictionary, never used ( and initialize ) the instance variable: 'array'.Associations are stored with a key array ( called 'keys' ) and a value array ( 'values' ). Problem is that the method #scanFor: is define in Dictionary ( and not overriden ) with this code : scanFor: anObject | element start finish | finish := array size. .... 'array' is nil and it cause bugs for those methods : -> #includesAssociation: -> #associationAt: -> #associationAt:ifAbsent: -> #associationDeclareAt:

July 3, 2009

Re: [Pharo-project] adding nil to sets

by Henrik Johansen

Having collections that do not naively implement addAll: falls into that category I think. Just in case it isn't clear by now: It WILL break compatability with custom subclasses though. (which is why I think VW and Squeak will never do it) Personally, I feel the ANSI standard failed in this regard, specifying a behaviour for addAll: that automatically leads to implementing it the naive way. Instead of say, adding all the objects that you are able to add from the collection, then raising an error with the ones you could not Especially when using addAll: with an unordered collection as parameter, it leads to random results as to what is added and what is not before the error is raised... I agree with Ralph on the nil issue (and the implementation details if we do make one ;) ), slowing down 99.99999% of hashable collections to satisfy those few use-cases where there's a need for Sets which accept nil isn't really a super option... Cheers, Henry On Jul 3, 2009, at 11:47 26AM, StÃ©phane Ducasse wrote: > Our goal is to build an agile Smalltalk with faster, better.... code. > > Stef > > > On Jul 3, 2009, at 8:53 AM, Ralph Boland wrote: > >> 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 >> >> _______________________________________________ >> 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 >

July 3, 2009