- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11018
by StÃ©phane Ducasse Oct. 25, 2009

Oct. 25, 2009

11018 ----- - Issue 1258 Number-readFrom-followUp There is no use invoking SqNumberParser with failBlock: [^ self error: ...] because this is the default behaviour... - Fix FontTest>>#testResetAfterEmphasized. aFont derivativeFonts cannot be assumed to store emphasized versions indexed by their emph code. - 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.

1 0

[Pharo-project] [update 1.1] #11017
by StÃ©phane Ducasse Oct. 24, 2009

Oct. 24, 2009

11017 ----- - 1220 followup some more #removeAll following http://code.google.com/p/pharo/issues/detail?id=1220 - Issue 1321: [Sqeak trunk] Shallow copy of BlockClosure Remove BlockClosure>postCopy

1 0

[Pharo-project] about selectorsDo: versus selectors do:
by StÃ©phane Ducasse Oct. 24, 2009

Oct. 24, 2009

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

2 1

[Pharo-project] System changes & security model
by Igor Stasenko Oct. 24, 2009

Oct. 24, 2009

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.

1 0

[Pharo-project] [update 1.1] #11016
by StÃ©phane Ducasse Oct. 24, 2009

Oct. 24, 2009

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

1 0

[Pharo-project] PackageInfo>>overrideMethods
by Igor Stasenko Oct. 24, 2009

Oct. 24, 2009

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.

1 0

[Pharo-project] About selectors returning an array
by StÃ©phane Ducasse Oct. 24, 2009

Oct. 24, 2009

> > Hi Eliot, >>>> This is experimental, not guaranteed bugfree. >>>> Indeed, you cannot #add: to nor #remove: from an Array... and >>>> elements >>>> won't be unique. >>>> My trunk image did not freeze because I analyzed senders of >>>> #selectors in >>>> it. >>>> But sure, this might break foreign code... >>>> So yes, it deserves discussion. >>>> >>>> What do others think ? >>> >>> I agree with Eliot. Keep the changes minimal - so just replace >>> "keys" with >>> "keys asSet" where necessary. >>> >>> - Bert >> >> Me too. #selectors should return a Set. >> >> Colin >> >> > > Though I found no such usage in MC1.0 :) > But I didn't inquire MC2.0, DeltaStreams, Etoys nor any other > reflexion crunching packages... > > BTW, it would be great to have universal code analysis tools spreading > over a public code database, not just my image. It dream of such > database served through web pages... > > Nicolas > Last thing, before retracting this change, I give hereafter a little rationale of my choice: There were 92 senders of selectors in trunk, I classified into three categories 1) Some senders performing add: or remove: If I recall, only 3 of them were I placed some #asSet protection. 2) Some senders expecting unique keys : but hey, selectors have unique elements because methodDictionary keys are unique... Only those aggregating with other selectors care, but most of them explicitely addAll: to an empty IdentitySet... 3) Every others did use an Array compatible message like do: includes: select: collect: asSortedCollection etc... Then I analyzed the cost of selectors: 1) Array will perform better than Set for all these selectors, but includes:. 2) Most direct senders of selector includes: SHOULD better be written includesSelector: Rationale: a single message send that will test includesKey: rather than two creating unecessarily an intermediate Set 3) 95% of senders would now uselessly perform an additional #asSet operation So my analyze was that I would personnaly buy this little optimization with the drawback of having to rewrite 5% of senders at most. But of course, I don't offer to rewritte your code, so I understand your opinion may differ :) And of course I agree that optimized code that breaks has no value. That's just a matter of tradeoffs. Nicolas

1 0

Oct. 23, 2009

11015 ----- 1272 follow up part 3 Last part of cleanup, remove basicShallowCopy Issue 1338: HostWindowTests>>testOne is failing in Windows

1 0

[Pharo-project] About built in plugins
by Fernando olivero Oct. 23, 2009

Oct. 23, 2009

Hi, just curious..does somebody know why 'B3DAcceleratorPlugin' is built in into the mac vm ? SmalltalkImage current listLoadedModules #('B3DAcceleratorPlugin 2 March 2009 (i)' 'SocketPlugin 2 March 2009 (i)' 'FloatArrayPlugin 2 March 2009 (i)' 'B2DPlugin 2 March 2009 (i)' 'InternetConfigPlugin 2 March 2009 (i)' 'FT2Plugin 24 April 2007 (e)' 'MacMenubarPlugin 2 March 2009 (i)' 'LargeIntegers v1.5 2 March 2009 (i)' 'BitBltPlugin 2 March 2009 (i)' 'SecurityPlugin 2 March 2009 (i)' 'FilePlugin 2 March 2009 (i)' 'DropPlugin 2 March 2009 (i)' 'MiscPrimitivePlugin 2 March 2009 (i)') Saludos, Fernando

2 1

Oct. 23, 2009

11014 ----- 1272 followup part one and two Perform some additional cleaning after integration of http://code.google.com/p/pharo/issues/detail?id=1272

1 0