March 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11288

by Marcus Denker

11288 ----- Issue 2195: fix the toolbuilder GUI Issue 1011: Monticello snapshot browser does not display class side definitions Issue 2192: x11FontLegalNotices Issue 2193: SequenceableCollection>>reverse -> reversed Issue 2189: MCPTest/ MethodNames gives DNU -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 23, 2010

Re: [Pharo-project] Here's my problems...

by Marcus Denker

On Mar 19, 2010, at 2:12 PM, Igor Stasenko wrote: > So far so good.. > found DNU: > Utilities noteMethodSubmission: #Comment forClass: cls > > while filing in the .st code > Hmm... the class SetElement does not exisit and is not defined in the changeset? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 23, 2010

Re: [Pharo-project] Implementing MethodWrappers in Smalltalk

by Lukas Renggli

>> I used #at:put: because we put-back the identical compiled methods as >> fast as possible, even while the tests are running. > > how do you do that ?Â Â your fork for each to run the tests ? After the wrapper is hit for the first time it replaces itself with the original method. For this basic kind of coverage we don't need to count and like this we can avoid speed penalty if a method is executed many times. >> Triggering >> notifications while running might also cause undesired side effects. >> Also note that code doing reflection (iterating over pragmas, >> literals, ...) might break if you are not super careful. > > Ok, thanks for the note :) >> There are also MethodWrappers from the RB engine that come with an >> integration into OB. > > Any point here ? classname ? http://www.squeaksource.com/MethodWrappers The implementation is ugly, this is code that was written before there was #run:withArguments:, however it has a protocol compatible with other Smalltalk platforms. http://source.lukas-renggli.ch/omnibrowser/OB-Wrapper Provides a simple integration into OB to wrap a set of classes with any defined wrapper. Lukas >> I wouldn't include the extra package, after all the implementation is >> pretty simple and also very specific. For a different use-case the >> implementation would probably look completely different. Check the >> mailing list, we had some discussions and did various iterations back >> when this was integrated. >> > > Ok, perfect. > > Thanks! > > Mariano > >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.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 > -- Lukas Renggli http://www.lukas-renggli.ch

March 23, 2010

Re: [Pharo-project] Implementing MethodWrappers in Smalltalk

by Mariano Martinez Peck

On Mon, Mar 22, 2010 at 6:20 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > 1) For a generic approach to method wrappers, which of those two ways > would > > you use ? should I care about notifying, adding to localSelectors, etc? > > Or at is just temporal, I don't care ? > > which are the pros and cons you see with each alternative ? > > I used #at:put: because we put-back the identical compiled methods as > fast as possible, even while the tests are running. how do you do that ? your fork for each to run the tests ? > Triggering > notifications while running might also cause undesired side effects. > Also note that code doing reflection (iterating over pragmas, > literals, ...) might break if you are not super careful. > > Ok, thanks for the note :) > > 2) Do you think it make sense to the package ObjectsAsMethodsWrap in > > PharoCore as a "library" to create lightweight proxies ? It is just 4 > > classes and it would be cool to change TestCoverage to that > implementation. > > Then, you only don't have the library, but also some real examples. Of > > course, this can be done if we eleiminate the 30% of slowleness. > > I guess it is slower because it is very generic and does block activations. > > > so...what do you think ? > > There are also MethodWrappers from the RB engine that come with an > integration into OB. > Any point here ? classname ? > > I wouldn't include the extra package, after all the implementation is > pretty simple and also very specific. For a different use-case the > implementation would probably look completely different. Check the > mailing list, we had some discussions and did various iterations back > when this was integrated. > > Ok, perfect. Thanks! Mariano > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2010

Re: [Pharo-project] Major shrinks

by Mariano Martinez Peck

On Tue, Mar 23, 2010 at 10:29 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Mariano, > > Great to see further progress on this! I'll take a closer look at your > script this evening. But what I wonder is why PharoCore 1.1 is so big I asked that myself. I even think I already asked that in mailing list. Honestly, I don't know. > and you only get down to 9MB (is this the size on disk?)? > yes. > > In a PharoCore 1.0 running #cleanUpForRelease, #cleanUpForProduction, > deleting the class ScriptLoader and all changesets I get an image that is > 8.1MB on disk. > yes. Ahh be aware....cleanUpForProduction in 1.1 is cool: he kill himself (unload the package ScriptLoader) at the end of the cleanUp ;) > > Cheers, > Adrian > > > On Mar 23, 2010, at 10:15 , Mariano Martinez Peck wrote: > > > Hi folks. I was playing a bit trying to shrink a little a PharoCore > image. > > My idea was to think a shrink that was be acceptable for the most common > > scenario: a runtime (production) environment where. Of course, some of > the > > things I do in the shrinks has side effects, but most of the times, you > can > > deal with that in such scenarios. > > > > Some of the things came from my mind, others from an OLD version of > > SystemDictionary >> majorShrink, others from Pavel's PharoKernel, etc. > > > > So...I will post the little code here. I am not completely sure about the > > side effects of each piece, so if you know, please let me know :) > > > > On the other hand, I wanted to ask you if you think something of this > make > > sense to be part of ScriptLoader >> cleanUpForProduction > > > > Taking a PharoCore 1.1 11277 of 13 MB I get an image of 9 MB...so 4 > MB > > less and I can still even browse code. > > When running the image before the shrink I get 25MB in use and with the > > image shrinked I get 20MB. > > > > Cheers > > > > Mariano > > > > > > > > > > > > "Compact all MethodDictionary instances" > > > > | oldInstances newInstances | > > oldInstances := MethodDictionary allInstances. > > newInstances := oldInstances collect: > > [ :md | > > (MethodDictionary new: md size) > > compactCopyFrom: md; > > yourself]. > > > > oldInstances elementsForwardIdentityTo: newInstances. > > > > > > > > "To put all all classes with the default category. Still can browse and > > recompile the whole image. > > Most production enviroments don't care about categories...this make sense > > when developing." > > > > Smalltalk allClassesAndTraitsDo: [:each | each zapOrganization ]. > > > > > > "Different cleanUps" > > > > TextStyle > > allSubInstancesDo: [:ts | ts > > newFontArray: (ts fontArray > > copyFrom: 1 > > to: (2 min: ts fontArray size))]. > > > > "Clean all Monticello related stuff. You won't be able to browse packages > > for example" > > > > MCWorkingCopyBrowser allInstancesDo: [:each | each flushAllCaches ]. > > MCWorkingCopy allInstancesDo:[:wc| SystemChangeNotifier uniqueInstance > > noMoreNotificationsFor: wc. wc unregister]. > > SystemChangeNotifier uniqueInstance noMoreNotificationsFor: > > MCPackageManager. > > SystemChangeNotifier uniqueInstance noMoreNotificationsFor: > MCWorkingCopy. > > > > "Most application don't need sound" > > > > SoundService default: nil. > > SoundService unregister: DummySoundSystem. > > > > SystemChangeNotifier uniqueInstance noMoreNotificationsFor: (Smalltalk > at: > > #RecentMessageSet). > > > > TranscriptStream newTranscript: ThreadSafeTranscript new. > > > > ImageSegment classPool at: #RecentlyRenamedClasses put: Dictionary new. > > ExternalSettings classPool at: #RegisteredClients put: Set new. > > > > Locale classPool at: #LocaleChangeListeners put: nil. > > > > "Clean all the changes" > > > > ChangeSet resetCurrentToNewUnnamedChangeSet. > > ChangeSet current initialize. > > ChangeSet classPool > > at: #AllChangeSets > > put: (OrderedCollection with: ChangeSet current). > > > > Symbol rehash. > > > > 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ]. > > _______________________________________________ > > 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 >

March 23, 2010

Re: [Pharo-project] Major shrinks

by Adrian Lienhard

Hi Mariano, Great to see further progress on this! I'll take a closer look at your script this evening. But what I wonder is why PharoCore 1.1 is so big and you only get down to 9MB (is this the size on disk?)? In a PharoCore 1.0 running #cleanUpForRelease, #cleanUpForProduction, deleting the class ScriptLoader and all changesets I get an image that is 8.1MB on disk. Cheers, Adrian On Mar 23, 2010, at 10:15 , Mariano Martinez Peck wrote: > Hi folks. I was playing a bit trying to shrink a little a PharoCore image. > My idea was to think a shrink that was be acceptable for the most common > scenario: a runtime (production) environment where. Of course, some of the > things I do in the shrinks has side effects, but most of the times, you can > deal with that in such scenarios. > > Some of the things came from my mind, others from an OLD version of > SystemDictionary >> majorShrink, others from Pavel's PharoKernel, etc. > > So...I will post the little code here. I am not completely sure about the > side effects of each piece, so if you know, please let me know :) > > On the other hand, I wanted to ask you if you think something of this make > sense to be part of ScriptLoader >> cleanUpForProduction > > Taking a PharoCore 1.1 11277 of 13 MB I get an image of 9 MB...so 4 MB > less and I can still even browse code. > When running the image before the shrink I get 25MB in use and with the > image shrinked I get 20MB. > > Cheers > > Mariano > > > > > > "Compact all MethodDictionary instances" > > | oldInstances newInstances | > oldInstances := MethodDictionary allInstances. > newInstances := oldInstances collect: > [ :md | > (MethodDictionary new: md size) > compactCopyFrom: md; > yourself]. > > oldInstances elementsForwardIdentityTo: newInstances. > > > > "To put all all classes with the default category. Still can browse and > recompile the whole image. > Most production enviroments don't care about categories...this make sense > when developing." > > Smalltalk allClassesAndTraitsDo: [:each | each zapOrganization ]. > > > "Different cleanUps" > > TextStyle > allSubInstancesDo: [:ts | ts > newFontArray: (ts fontArray > copyFrom: 1 > to: (2 min: ts fontArray size))]. > > "Clean all Monticello related stuff. You won't be able to browse packages > for example" > > MCWorkingCopyBrowser allInstancesDo: [:each | each flushAllCaches ]. > MCWorkingCopy allInstancesDo:[:wc| SystemChangeNotifier uniqueInstance > noMoreNotificationsFor: wc. wc unregister]. > SystemChangeNotifier uniqueInstance noMoreNotificationsFor: > MCPackageManager. > SystemChangeNotifier uniqueInstance noMoreNotificationsFor: MCWorkingCopy. > > "Most application don't need sound" > > SoundService default: nil. > SoundService unregister: DummySoundSystem. > > SystemChangeNotifier uniqueInstance noMoreNotificationsFor: (Smalltalk at: > #RecentMessageSet). > > TranscriptStream newTranscript: ThreadSafeTranscript new. > > ImageSegment classPool at: #RecentlyRenamedClasses put: Dictionary new. > ExternalSettings classPool at: #RegisteredClients put: Set new. > > Locale classPool at: #LocaleChangeListeners put: nil. > > "Clean all the changes" > > ChangeSet resetCurrentToNewUnnamedChangeSet. > ChangeSet current initialize. > ChangeSet classPool > at: #AllChangeSets > put: (OrderedCollection with: ChangeSet current). > > Symbol rehash. > > 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ]. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2010

Re: [Pharo-project] Major shrinks

by Mariano Martinez Peck

On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > What I do on my build server is to unload the tests: > > (MCWorkingCopy allManagers > inject: Gofer new > into: [ :gofer :each | > ((each packageName endsWith: 'Test') or: [ each > packageName endsWith: 'Tests' ]) > ifTrue: [ gofer package: each packageName ]. > gofer ]) > unload. > > ScriptLoader >> cleanUpForProduction do that but similary: #(#Tests #CollectionsTests #CompilerTests #FreeTypeTests #GraphicsTests #KernelTests #MorphicTests #MultilingualTests #NetworkTests #ToolsTest) do: [ :each | (MCPackage named: each) unload ]. "unload SUnit" Smalltalk globals at: #TestCase ifPresent: [ :class | SystemChangeNotifier uniqueInstance noMoreNotificationsFor: class ]. #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named: each) unload ]. Maybe we you should change it ? > > Hi folks. I was playing a bit trying to shrink a little a PharoCore > image. > > My idea was to think a shrink that was be acceptable for the most common > > scenario: a runtime (production) environment where. Of course, some of > the > > things I do in the shrinks has side effects, but most of the times, you > can > > deal with that in such scenarios. > > Shouldn't most of the code you publish be part of the <cleanup> protocol? > > You refere to the "new" cleanUp protocol ? The thing is that not everything is a cleanUp, but a shrink. Suppose the code that zap all the organizations...that's not a cleanUp. So, maybe yes, but not all of them. Cheers Mariano > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2010

Re: [Pharo-project] Major shrinks

by Lukas Renggli

What I do on my build server is to unload the tests: (MCWorkingCopy allManagers inject: Gofer new into: [ :gofer :each | ((each packageName endsWith: 'Test') or: [ each packageName endsWith: 'Tests' ]) ifTrue: [ gofer package: each packageName ]. gofer ]) unload. > Hi folks. I was playing a bit trying to shrink a little a PharoCore image. > My idea was to think a shrink that was be acceptable for the most common > scenario: a runtime (production) environment where. Of course, some of the > things I do in the shrinks has side effects, but most of the times, you can > deal with that in such scenarios. Shouldn't most of the code you publish be part of the <cleanup> protocol? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 23, 2010

[Pharo-project] Major shrinks

by Mariano Martinez Peck

Hi folks. I was playing a bit trying to shrink a little a PharoCore image. My idea was to think a shrink that was be acceptable for the most common scenario: a runtime (production) environment where. Of course, some of the things I do in the shrinks has side effects, but most of the times, you can deal with that in such scenarios. Some of the things came from my mind, others from an OLD version of SystemDictionary >> majorShrink, others from Pavel's PharoKernel, etc. So...I will post the little code here. I am not completely sure about the side effects of each piece, so if you know, please let me know :) On the other hand, I wanted to ask you if you think something of this make sense to be part of ScriptLoader >> cleanUpForProduction Taking a PharoCore 1.1 11277 of 13 MB I get an image of 9 MB...so 4 MB less and I can still even browse code. When running the image before the shrink I get 25MB in use and with the image shrinked I get 20MB. Cheers Mariano "Compact all MethodDictionary instances" | oldInstances newInstances | oldInstances := MethodDictionary allInstances. newInstances := oldInstances collect: [ :md | (MethodDictionary new: md size) compactCopyFrom: md; yourself]. oldInstances elementsForwardIdentityTo: newInstances. "To put all all classes with the default category. Still can browse and recompile the whole image. Most production enviroments don't care about categories...this make sense when developing." Smalltalk allClassesAndTraitsDo: [:each | each zapOrganization ]. "Different cleanUps" TextStyle allSubInstancesDo: [:ts | ts newFontArray: (ts fontArray copyFrom: 1 to: (2 min: ts fontArray size))]. "Clean all Monticello related stuff. You won't be able to browse packages for example" MCWorkingCopyBrowser allInstancesDo: [:each | each flushAllCaches ]. MCWorkingCopy allInstancesDo:[:wc| SystemChangeNotifier uniqueInstance noMoreNotificationsFor: wc. wc unregister]. SystemChangeNotifier uniqueInstance noMoreNotificationsFor: MCPackageManager. SystemChangeNotifier uniqueInstance noMoreNotificationsFor: MCWorkingCopy. "Most application don't need sound" SoundService default: nil. SoundService unregister: DummySoundSystem. SystemChangeNotifier uniqueInstance noMoreNotificationsFor: (Smalltalk at: #RecentMessageSet). TranscriptStream newTranscript: ThreadSafeTranscript new. ImageSegment classPool at: #RecentlyRenamedClasses put: Dictionary new. ExternalSettings classPool at: #RegisteredClients put: Set new. Locale classPool at: #LocaleChangeListeners put: nil. "Clean all the changes" ChangeSet resetCurrentToNewUnnamedChangeSet. ChangeSet current initialize. ChangeSet classPool at: #AllChangeSets put: (OrderedCollection with: ChangeSet current). Symbol rehash. 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ].

March 23, 2010

Re: [Pharo-project] bug in the code of CompiledMethod >> =

by StÃ©phane Ducasse

> On Mon, Mar 22, 2010 at 2:54 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > You might also want to check last code published in trunk. > > I saw that. You're eliminating closeTo: for float comparison which seems fine to me :) Thanks Nicolas! > However, it is indicative that a recompile all is necessary after redefining the number scanning facilities. I guess that this is part of the standard release build process. If not, we should add it. I saw the following but I could not see the float issue you mentioned. Where it is? analogousCodeTo: aMethodProperties | bs | (aMethodProperties isKindOf: MethodProperties) ifTrue: [^aMethodProperties analogousCodeTo: self]. (bs := self basicSize) ~= aMethodProperties basicSize ifTrue: [^false]. 1 to: bs do: [:i| ((self basicAt: i) analogousCodeTo: (aMethodProperties basicAt: i)) ifFalse: [^false]]. ^true hasAtLeastTheSamePropertiesAs: aMethodProperties "Answer if the recever has at least the same properties as the argument. N.B. The receiver may have additional properties and still answer true." aMethodProperties keysAndValuesDo: [:k :v| (v isKindOf: Pragma) "ifTrue: [Pragmas have already been checked]" ifFalse: [ (self includes: k->v) ifFalse: [^false]]]. ^true On Mar 22, 2010, at 10:54 PM, Nicolas Cellier wrote: > You might also want to check last code published in trunk. > > Nicolas > > 2010/3/22 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> On Mon, Mar 22, 2010 at 2:25 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> eliot >>> >>> Your changes fixed some of the problems. Now I tried to fix the test >>> testAnalogousCodeTo in MethodPropertiesTest and >>> the expression returns false. >>> >>> (#zork->'hello') analogousCodeTo: (#zork->'hello') -> false >>> >>> (#zork->'hello') = (#zork->'hello') -> true >> >> For me >> #(#zork -> 'hello') size 3 >> In Pharo is it true that >> #(#zork -> 'hello') size 1 >> ??!?! >> In that case I would implement analogousCodeTo: in Association, e.g. >> analogousCodeTo: anObject >> ^anObject class == self class >> and: [key = anObject key >> and: [value = anObject value]] >> >> But if Association isn't a literal I would simply check >> MethodPropertiesTests. It could be obsolete. >>> >>> Stef >>> >>> On Mar 22, 2010, at 6:20 PM, Eliot Miranda wrote: >>> >>>> Oops. Find attached. >>>> >>>> 2010/3/22 Cyrille Delaunay <cy.delaunay(a)gmail.com> >>>> try in a Pharo-1.0-10515-rc3 image : >>>> >>>> |set| >>>> set := Set new. >>>> Collection withAllSubclasses do: [:aClass | >>>> set addAll: aClass methods >>>> ]. >>>> >>>> It will raise an exception telling: "MessageNotUnderstood: >>>> ByteSymbol>>analogousCodeTo:". >>>> Indeed, in the code of CompiledMethod >> = , the message >>>> 'analogousCodeTo:' is send to a >>>> symbol. >>>> >>>> >>>> I opened an Issue: >>>> http://code.google.com/p/pharo/issues/detail?id=2185 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> <Object-analogousCodeTo.st>_______________________________________________ >>>> 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

March 23, 2010