- Pharo-dev - lists.pharo.org

[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

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

by Niko Schwarz

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 >

Oct. 24, 2009

[Pharo-project] PackageInfo>>overrideMethods

by Igor Stasenko

In both Pharo & Squeak has no senders: overrideMethods ^ self extensionMethods select: [:ea | self isOvverideMethod: ea] as well as #isOvverideMethod: not implemented, which makes this method fail to work , even if it would be called by anyone. -- Best regards, Igor Stasenko AKA sig.

Oct. 24, 2009