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

Re: [Pharo-project] (a = b) => (a hash = b hash)

by Nicolas Cellier

http://bugs.squeak.org/view.php?id=3380 http://bugs.squeak.org/view.php?id=3488 2009/10/24 Andrew P. Black <black(a)cs.pdx.edu>: > The golden rule of hashing is (a = b) => (a hash = b hash). Â Right? > > Look at this: > > (1 to: 10) species Â ---> Â Array > #(1 2 3 4 5 6 7 8 9 10) species Â ---> Â Array > > (1 to: 10) = Â #(1 2 3 4 5 6 7 8 9 10) Â ---> Â true > > However, > > (1 to: 10) hash = #(1 2 3 4 5 6 7 8 9 10) hash Â ---> Â false. > > I believe that the last is a bug. > > Â Â Â Â Andrew > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 24, 2009

Re: [Pharo-project] Thread-safe collections

by Schwab,Wilhelm K

John, No examples, just a growing surprise at the things that have been allowed to stand for many years, combined with respect for Object Arts. When in doubt, I assume they knew what they were doing, and making weaklings thread-safe seems reasonable, if not just plain necessary. My current concern is not over finalization specificially, but other weak collections. You mention #forMutualExcusion. My understanding is that a semaphore so configured will allow a process to deadlock itself. We have Mutex, and it is probably a better choice?? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Friday, October 23, 2009 8:25 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections Not sure what you are looking for a couple of years back I chased down a bug or two in the finalization logic See WeakArray>>FinalizationSemaphore and WeakRegistry accessLock := Semaphore forMutualExclusion. Both attempt to ensure finalization occurs in thread safe manners, this doesn't mean someone introduced something bad in the last 5 years or so. An example? On 2009-10-23, at 5:44 PM, Schwab,Wilhelm K wrote: > Stef, > > Dolphin's weak collections are typically (I suspect allways) thread > safe, which I have attributed to the constant struggle with > finalization - it seems natural (to me at least) for them to be > protected. Some quick browsing leads me to think that this is not > true in Pharo. Am I missing something, or do we also need some > thread-safe weaklings? > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Friday, October 23, 2009 2:46 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Thread-safe collections > > I would really like to see some packages getting implementing around > the idea of a couple of robust and well tested thread safe > collections. > > Stef > > On Oct 23, 2009, at 2:16 AM, Schwab,Wilhelm K wrote: > >> Sig, >> >> One can always construct examples in which protecting the entire loop >> is the better option. That's not the scenario of interest. >> Just as shared queues are useful, shared sets and dictionaries have >> value for sporadic access scenarios. Doing it your way, everyone >> writes their own incompletely protected (read buggy/dangerous) ad- >> hoc implementations of these common collections. >> >> I favor having solid implementations that are complete and as correct >> as we can get them, leaving people to optimize as you suggest when it >> makes sense to do so. >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- >> project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko >> Sent: Thursday, October 22, 2009 5:23 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Thread-safe collections >> >> 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> Hello all, >>> >>> I just looked around for thread-safe collections, and found nothing >>> that looks like a shared dictionary. The squeak-dev archives >>> contain the obligatory newbie posts (wanting all collections to be >>> thread >>> safe) and the expected replies, some of which are overly dismissive >>> of the idea. Something that protects things like >>> #at:ifAbsentPut: and friends is _really_ useful. Am I missing an >>> existing implementation? >>> >> >> Imo, there's only one shared collection which is useful - shared >> queue. :) If you need more kinds of thread-safe collections, it >> probably indicating that the concurrent code (or model) which you >> designed is in pretty bad shape. >> >> Just compare two following snippets: >> >> 1 to: 100 do: [:i | collection threadSafeAt: i put: something]. >> >> and: >> >> semaphore critical: [ 1 to: 100 do: [:i | collection at: i put: >> something] ]. >> >> What you think, which one is better? >> >> >>> Bill >>> >>> >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 24, 2009

[Pharo-project] System changes & security model

by Igor Stasenko

I trying to make a clean-room prototype of new Package system (yeah yeah..:) The idea is following: the package(s) is in control! I.e. each change to package contents should pass validity checks before getting applied. This would allow us to enforce some policy, which could help to maintain a code in system in good shape. For instance, the most wanted feature, as to me, is to ask package if it: - allows extending other packages by extension methods - allows extensions to be added to package own classes the problem with current kernel, that it never asks anyone if it allowed to do something or not.. instead, the code applies change, and only then using SystemChangeNotifier to broadcast the event of change to any interesting parties.. Such approach hinders any attempts to build a secure system, because once change is made, it could be too late to revert it and its very easy to bypass any system facilities which normally could prevent the user from doing wrong things (like removing Delay class or one of its critical methods ;). And there is a SystemEditor, which unfortunately, not ready for use with Traits :( but afaik, it don't providing any means to validate the changes before applying. Or does? Maybe its worth to create another notification which can notify the interesting parties before the change will be applied? What you think? -- Best regards, Igor Stasenko AKA sig.

Oct. 24, 2009

Re: [Pharo-project] question about results of MessageTally

by StÃ©phane Ducasse

fun :) I did not pay attention to that either. Stef On Oct 24, 2009, at 12:08 PM, Adrian Lienhard wrote: > Hi Jannik, > > Interesting question! > > You left out an important part oft the tally: the part about GC > activity. > > For the large dictionary I get: > > **GCs** > full 9 totalling 1,696ms (1.0% uptime), avg 188.0ms > incr 3776 totalling 186,310ms (94.0% uptime), avg 49.0ms > > That is, 95% of time is spent in GC! A lot of incremental GC cycles > are triggered because for each at:put: a new association instance is > created. The larger the dictionary, the larger is the new memory space > and hence the incremental GC takes longer to complete. In the above > tally the average was 49ms compared to > > incr 275 totalling 1,113ms (58.0% uptime), avg 4.0ms > > for the smaller dictionary. Therefore, the ratio between actual method > execution time and GC time differs significantly between the two runs. > As a result, a lot of branches of the tally are below a total of 1% > runtime in the second case. Message tally has a threshold that cuts > off branches with less than 1% runtime. Therefore you see less > details. > > Cheers, > Adrian > > > On Oct 24, 2009, at 07:21 , Laval Jannik wrote: > >> Hi, >> >> when I use MassageTally>>spyOn: on the creation of a Dictionary, >> results have not the same details according to the size of >> Dictionary. >> >> For example: >> === >> |n| >> MessageTally spyOn:[ >> n := Dictionary new. >> 1 to: 400000 do:[:each | n at: each put:each]. >> ] >> === >> >> returns this results: >> >> ==== >> - 1745 tallies, 1751 msec. >> >> **Tree** >> -------------------------------- >> Process: (40s) 1964: nil >> -------------------------------- >> 45.8% {802ms} Dictionary(Set)>>atNewIndex:put: >> |43.6% {763ms} Dictionary(Set)>>fullCheck >> | |39.4% {690ms} Dictionary(Set)>>grow >> | | |27.2% {476ms} Dictionary>>noCheckAdd: >> | | | |25.2% {441ms} Dictionary(Set)>>findElementOrNil: >> | | | | |23.6% {413ms} Dictionary>>scanFor: >> | | | | |1.6% {28ms} primitives >> | | | |2.0% {35ms} primitives >> | | |9.2% {161ms} primitives >> | | |3.0% {53ms} Array(SequenceableCollection)>>do: >> | |2.4% {42ms} primitives >> | |1.8% {32ms} SmallInteger(Magnitude)>>max: >> |2.2% {39ms} primitives >> 22.4% {392ms} Association class>>key:value: >> |18.9% {331ms} Association class(LookupKey class)>>key: >> | |16.3% {285ms} Association(LookupKey)>>key: >> | |2.6% {46ms} primitives >> |1.9% {33ms} Association>>value: >> |1.6% {28ms} primitives >> 4.4% {77ms} Dictionary(Set)>>findElementOrNil: >> |2.3% {40ms} primitives >> |2.1% {37ms} Dictionary>>scanFor: >> 1.9% {33ms} primitives >> ==== >> >> But, if I do: >> === >> |n| >> MessageTally spyOn:[ >> n := Dictionary new. >> 1 to: 4000000 do:[:each | n at: each put:each]. >> ] >> === >> >> results are: >> ==== >> - 179772 tallies, 180312 msec. >> >> **Tree** >> -------------------------------- >> Process: (40s) 1964: nil >> -------------------------------- >> 3.1% {5590ms} Dictionary(Set)>>atNewIndex:put: >> |2.8% {5049ms} Dictionary(Set)>>fullCheck >> | 2.3% {4147ms} Dictionary(Set)>>grow >> | 1.3% {2344ms} Dictionary>>noCheckAdd: >> 1.0% {1803ms} Association class>>key:value: >> ==== >> >> Where are the rest of the process ? >> Does anybody understand this behavior ? can you explain ? >> >> >> Cheers, >> Jannik >> >> >> _______________________________________________ >> 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

Oct. 24, 2009

Re: [Pharo-project] question about results of MessageTally

by Adrian Lienhard

Hi Jannik, Interesting question! You left out an important part oft the tally: the part about GC activity. For the large dictionary I get: **GCs** full 9 totalling 1,696ms (1.0% uptime), avg 188.0ms incr 3776 totalling 186,310ms (94.0% uptime), avg 49.0ms That is, 95% of time is spent in GC! A lot of incremental GC cycles are triggered because for each at:put: a new association instance is created. The larger the dictionary, the larger is the new memory space and hence the incremental GC takes longer to complete. In the above tally the average was 49ms compared to incr 275 totalling 1,113ms (58.0% uptime), avg 4.0ms for the smaller dictionary. Therefore, the ratio between actual method execution time and GC time differs significantly between the two runs. As a result, a lot of branches of the tally are below a total of 1% runtime in the second case. Message tally has a threshold that cuts off branches with less than 1% runtime. Therefore you see less details. Cheers, Adrian On Oct 24, 2009, at 07:21 , Laval Jannik wrote: > Hi, > > when I use MassageTally>>spyOn: on the creation of a Dictionary, > results have not the same details according to the size of Dictionary. > > For example: > === > |n| > MessageTally spyOn:[ > n := Dictionary new. > 1 to: 400000 do:[:each | n at: each put:each]. > ] > === > > returns this results: > > ==== > - 1745 tallies, 1751 msec. > > **Tree** > -------------------------------- > Process: (40s) 1964: nil > -------------------------------- > 45.8% {802ms} Dictionary(Set)>>atNewIndex:put: > |43.6% {763ms} Dictionary(Set)>>fullCheck > | |39.4% {690ms} Dictionary(Set)>>grow > | | |27.2% {476ms} Dictionary>>noCheckAdd: > | | | |25.2% {441ms} Dictionary(Set)>>findElementOrNil: > | | | | |23.6% {413ms} Dictionary>>scanFor: > | | | | |1.6% {28ms} primitives > | | | |2.0% {35ms} primitives > | | |9.2% {161ms} primitives > | | |3.0% {53ms} Array(SequenceableCollection)>>do: > | |2.4% {42ms} primitives > | |1.8% {32ms} SmallInteger(Magnitude)>>max: > |2.2% {39ms} primitives > 22.4% {392ms} Association class>>key:value: > |18.9% {331ms} Association class(LookupKey class)>>key: > | |16.3% {285ms} Association(LookupKey)>>key: > | |2.6% {46ms} primitives > |1.9% {33ms} Association>>value: > |1.6% {28ms} primitives > 4.4% {77ms} Dictionary(Set)>>findElementOrNil: > |2.3% {40ms} primitives > |2.1% {37ms} Dictionary>>scanFor: > 1.9% {33ms} primitives > ==== > > But, if I do: > === > |n| > MessageTally spyOn:[ > n := Dictionary new. > 1 to: 4000000 do:[:each | n at: each put:each]. > ] > === > > results are: > ==== > - 179772 tallies, 180312 msec. > > **Tree** > -------------------------------- > Process: (40s) 1964: nil > -------------------------------- > 3.1% {5590ms} Dictionary(Set)>>atNewIndex:put: > |2.8% {5049ms} Dictionary(Set)>>fullCheck > | 2.3% {4147ms} Dictionary(Set)>>grow > | 1.3% {2344ms} Dictionary>>noCheckAdd: > 1.0% {1803ms} Association class>>key:value: > ==== > > Where are the rest of the process ? > Does anybody understand this behavior ? can you explain ? > > > Cheers, > Jannik > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 24, 2009

Re: [Pharo-project] [update] #10492 (1.0rc1)

by StÃ©phane Ducasse

Yes a good deprecation is needed. Stef On Oct 24, 2009, at 11:13 AM, Adrian Lienhard wrote: > Sounds ok. At the same time as integrating the change, all senders of > asNumber in the image need to be checked and adapted to the new > semantics if necessary. IIRC MC was not properly working after the > change. Also, users and maintainers of external packages should be > made aware of the change since it may break their code. > > Adrian > > On Oct 24, 2009, at 10:46 , StÃ©phane Ducasse wrote: > >> Thanks niko >> >> So does everybody agree with >> asNumber raising an error >> and >> squeezeOutNumber >> >> I like the proposal. >> >> Stef >> >> On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote: >> >>> Hi all, I made a follow-up patch like discussed on the workshop. Now >>> porting becomes as easy as changing "asNumber" to >>> "squeezeOutNumber". >>> >>> Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2 >>> >>> >>> This slice adds squeezeNumberOutOfString: to Number, as discussed in >>> the Pharo workshop. On the way, it >>> fixes an issue in SqNumberParser, where it would return itself >>> rather >>> than the result of the failblack, when >>> parsing fails. >>> >>> Also, a test is added to test and document the new squeezing number >>> out of strings behavior. >>> >>> Example usage: >>> >>> self assert: '123blabla' squeezeOutNumber equals: 123. >>> self assert: 'blabla123' squeezeOutNumber equals: 123. >>> self assert: 'blabla12blabla' squeezeOutNumber equals: 12. >>> self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < 0.0001. >>> self assert: '.1' squeezeOutNumber > 0. >>> >>> Cheers, >>> >>> Niko >>> >>> On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard <adi(a)netstyle.ch> >>> wrote: >>>> 10492 (this is the stream of the branch 1.0rc1) >>>> ----- >>>> >>>> - Issue 1320: [squeak trunk] Sort the conflicts. This is required >>>> when >>>> merging a distant version, like Pharo for example... >>>> - Issue 1338: HostWindowTests>>testOne is failing in Windows >>>> - Issue 1345: Revert Number class>>readFrom: (was integrated with >>>> issue 1258) >>>> >>>> ___________________ >>>> http://www.adrian-lienhard.ch/ >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 24, 2009

[Pharo-project] [update 1.1] #11016

by StÃ©phane Ducasse

11016 ----- - Issue 1359: PseudoClass>> DNU includesSelector: - Issue 1358: Dictionary select: answer a shallow copy | original even | original := Dictionary new. original at: #one put: 1. original at: #two put: 2. even := original select: [:value |value even]. even at: #two put: #two. self assert: (original at: #two) = 2

Oct. 24, 2009

Re: [Pharo-project] [update] #10492 (1.0rc1)

by Adrian Lienhard

Sounds ok. At the same time as integrating the change, all senders of asNumber in the image need to be checked and adapted to the new semantics if necessary. IIRC MC was not properly working after the change. Also, users and maintainers of external packages should be made aware of the change since it may break their code. Adrian On Oct 24, 2009, at 10:46 , StÃ©phane Ducasse wrote: > Thanks niko > > So does everybody agree with > asNumber raising an error > and > squeezeOutNumber > > I like the proposal. > > Stef > > On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote: > >> Hi all, I made a follow-up patch like discussed on the workshop. Now >> porting becomes as easy as changing "asNumber" to "squeezeOutNumber". >> >> Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2 >> >> >> This slice adds squeezeNumberOutOfString: to Number, as discussed in >> the Pharo workshop. On the way, it >> fixes an issue in SqNumberParser, where it would return itself rather >> than the result of the failblack, when >> parsing fails. >> >> Also, a test is added to test and document the new squeezing number >> out of strings behavior. >> >> Example usage: >> >> self assert: '123blabla' squeezeOutNumber equals: 123. >> self assert: 'blabla123' squeezeOutNumber equals: 123. >> self assert: 'blabla12blabla' squeezeOutNumber equals: 12. >> self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < 0.0001. >> self assert: '.1' squeezeOutNumber > 0. >> >> Cheers, >> >> Niko >> >> On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >>> 10492 (this is the stream of the branch 1.0rc1) >>> ----- >>> >>> - Issue 1320: [squeak trunk] Sort the conflicts. This is required >>> when >>> merging a distant version, like Pharo for example... >>> - Issue 1338: HostWindowTests>>testOne is failing in Windows >>> - Issue 1345: Revert Number class>>readFrom: (was integrated with >>> issue 1258) >>> >>> ___________________ >>> http://www.adrian-lienhard.ch/ >>> >>> >>> _______________________________________________ >>> 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

Oct. 24, 2009

[Pharo-project] about selectorsDo: versus selectors do:

by StÃ©phane Ducasse

nicolas following the includesSelectors: fix I imagine that replacing all the selectors do: by selectorsDo: will avoid creating unnecessary intermediate collection. I checked and there are some places where we could fix that. Stef

Oct. 24, 2009

Re: [Pharo-project] [update] #10492 (1.0rc1)

by StÃ©phane Ducasse

Thanks niko So does everybody agree with asNumber raising an error and squeezeOutNumber I like the proposal. Stef On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote: > Hi all, I made a follow-up patch like discussed on the workshop. Now > porting becomes as easy as changing "asNumber" to "squeezeOutNumber". > > Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2 > > > This slice adds squeezeNumberOutOfString: to Number, as discussed in > the Pharo workshop. On the way, it > fixes an issue in SqNumberParser, where it would return itself rather > than the result of the failblack, when > parsing fails. > > Also, a test is added to test and document the new squeezing number > out of strings behavior. > > Example usage: > > self assert: '123blabla' squeezeOutNumber equals: 123. > self assert: 'blabla123' squeezeOutNumber equals: 123. > self assert: 'blabla12blabla' squeezeOutNumber equals: 12. > self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < 0.0001. > self assert: '.1' squeezeOutNumber > 0. > > Cheers, > > Niko > > On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> 10492 (this is the stream of the branch 1.0rc1) >> ----- >> >> - Issue 1320: [squeak trunk] Sort the conflicts. This is required >> when >> merging a distant version, like Pharo for example... >> - Issue 1338: HostWindowTests>>testOne is failing in Windows >> - Issue 1345: Revert Number class>>readFrom: (was integrated with >> issue 1258) >> >> ___________________ >> http://www.adrian-lienhard.ch/ >> >> >> _______________________________________________ >> 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

Oct. 24, 2009