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

[Pharo-project] SLICE-Mantis-KernelNumber-Fix-Mining-nice.1.mcz

by nicolas cellier

I push here some more or less important fixes. These are limited to one or two method per fix and should not take very long to review. Cheers Nicolas This gathers several Tests and Fixes from Mantis for Kernel-Number ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=6781 0.0 raisedTo: -1.0 unexpected result The patch correct Number >> #raisedTo: and uses [^self class one] so that Float >> #raisedTo; can be removed (99% identical code). ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=6729 -Infinity closeTo: Infinity self deny: (Float infinity negated closeTo: Float infinity) ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=6695 Float storeStringBase: does not store the radix self assert: (20.0 storeStringBase: 16) = '16r14.0' compare to this: (20 storeStringBase: 16) Note: in base 10, radix is not prepended (same as Integer). ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=6697 Number>>storeOn:base: default implementation is wrong Default implementation does omit the radix prefix when it should not! Change it to subclassResponsibility, since every subclass will have a different one... ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=6990 0.0 significandAsInteger is too big ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=7114 SmallInteger minVal highBitOfMagnitude Try it, it should not raise an Error... ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=5640 additional tests and fixes for Number>>printShowingDecimalPlaces: http://bugs.squeak.org/view.php?id=7028 printShowingDecimalPlaces: is broken in 3.10 Try (-0.9 printShowingDecimalPlaces: 1) for example... Where is the minus sign? Fix included in 3.10 is incorrect and not complete ------------------------------------------------------------

Oct. 11, 2008

Re: [Pharo-project] Pharo image size: 10.9MB

by StÃ©phane Ducasse

did you clean the changesets? yes in cleaningCS :) Also the Utilities cleanseOtherworldlySteppers > Preferences setDefaultFonts: #( > (setSystemFontTo: 'Accuny' 10) > (setListFontTo: 'Accuny' 10) > (setMenuFontTo: 'Accuny' 10) > (setFlapsFontTo: 'Accuny' 12) > (setEToysFontTo: 'Accuny' 10) > (setPaintBoxButtonFontTo: 'Accuny' 10) > (setWindowTitleFontTo: 'Accuny' 15) > (setBalloonHelpFontTo: 'Accuny' 10) > (setCodeFontTo: 'Accuny' 10) > (setButtonFontTo: 'Accuny' 8)). > TextConstants associations do: [ :association | > ((association value isKindOf: TextStyle) > and: [ association key ~= #Accuny ] > and: [ (TextStyle defaultFamilyNames includes: association key) > not ]) > ifTrue: [ TextConstants removeKey: association key ]]. > TextConstants at: #DefaultFixedTextStyle put: (TextConstants at: > #Accuny). > > (Flaps classPool at: #SharedFlapTabs) removeAllSuchThat: [ :each | > (#(Tools Pharo) includes: each labelString) not ]. > NaturalLanguageFormTranslator classPool at: #CachedTranslations put: > nil. > NaturalLanguageTranslator resetCaches. > PartsBin clearThumbnailCache. > PaintBoxMorph initialize. > PaintBoxMorph classPool at: #ColorChart put: nil; at: #Prototype > put: nil. > Utilities classPool at: #ScrapsBook put: nil. > Project allInstancesDo: [ :each | each setThumbnail: nil ]. > InternalThreadNavigationMorph clearThumbnailCache. > ScriptingSystem stripGraphicsForExternalRelease. > ProjectHistory currentHistory initialize. > Utilities zapUpdateDownloader. > Smalltalk forgetDoIts. > Behavior flushObsoleteSubclasses. > CommandHistory allInstancesDo: #initialize. > ScriptLoader new cleaningCS. > RequiredSelectors initialize. > ProvidedSelectors initialize. > LocalSends initialize. > SendCaches initializeAllInstances. > Utilities cleanseOtherworldlySteppers. > Smalltalk organization removeEmptyCategories. > SystemBrowser removeObsolete. > TheWorldMenu removeObsolete. > AppRegistry removeObsolete. > FileServices removeObsolete. > SystemNavigation default obsoleteBehaviors. > MCFileBasedRepository flushAllCaches. > MCDefinition clearInstances. > Undeclared removeUnreferencedKeys. > Smalltalk flushClassNameCache. > 3 timesRepeat: [ Smalltalk garbageCollect. Symbol > compactSymbolTable ]. > Set rehashAllSets. > Smalltalk garbageCollect. > > > ___________________ > 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. 11, 2008

Re: [Pharo-project] Pharo image size: 10.9MB

by StÃ©phane Ducasse

excellent! I would be also curious about the size of the strings. And yes - we need to have a cleanup process as proposed/examplified by keith For the default fonts: do we have a process to reload the non default fonts? Stef On Oct 11, 2008, at 8:11 PM, Adrian Lienhard wrote: > I've been looking into how the current 13.4MB a Pharo image uses are > spent... I expected that at least half of it is used by classes > (compiled methods). But this is not the case. Actually, only about > 1/4th are classes. As it turned out, almost the same amount of > memory is used by forms (actually bitmaps)! > > If you want to know which are the largest 10 forms try this: > > (Form allInstances asSortedCollection: [ :e1 :e2 | e1 bits size >= > e2 bits size ]) from: 1 to: 10 do: [ :each | each asMorph > openInWorld ] > > ...among which for example are 4 different color pickers. In total > there are around 450 forms, most from EToys. I've manually traced > down where the larger forms come from and have cleaned up those that > were possible (many are only referenced by caches). The number of > forms is at 320 now. > > In the process I produced the script below, which among other stuff > removes all but the default font. Also, it actually removes the > flaps from the system instead of only hiding them. Here a history of > image sizes: > > Squeak 3.9: 15.6 MB > Pharo 10091: 13.4MB (before cleanup) > Pharo 10091: 10.9MB (after cleanup) > > Main conclusion: the system needs cleanup not only of the code > (where the mess is more directly visible), but also of the object > memory. Furthermore, I expect removing EToys will have an nice > impact on the image size. Also removing Sound will release some > memory because of sound samples. > > If anybody has suggestions to further reduce the image size (<10MB > would be a nice target for the first release...), please let me know. > > Cheers, > Adrian > > > > Preferences setDefaultFonts: #( > (setSystemFontTo: 'Accuny' 10) > (setListFontTo: 'Accuny' 10) > (setMenuFontTo: 'Accuny' 10) > (setFlapsFontTo: 'Accuny' 12) > (setEToysFontTo: 'Accuny' 10) > (setPaintBoxButtonFontTo: 'Accuny' 10) > (setWindowTitleFontTo: 'Accuny' 15) > (setBalloonHelpFontTo: 'Accuny' 10) > (setCodeFontTo: 'Accuny' 10) > (setButtonFontTo: 'Accuny' 8)). > TextConstants associations do: [ :association | > ((association value isKindOf: TextStyle) > and: [ association key ~= #Accuny ] > and: [ (TextStyle defaultFamilyNames includes: association key) > not ]) > ifTrue: [ TextConstants removeKey: association key ]]. > TextConstants at: #DefaultFixedTextStyle put: (TextConstants at: > #Accuny). > > (Flaps classPool at: #SharedFlapTabs) removeAllSuchThat: [ :each | > (#(Tools Pharo) includes: each labelString) not ]. > NaturalLanguageFormTranslator classPool at: #CachedTranslations put: > nil. > NaturalLanguageTranslator resetCaches. > PartsBin clearThumbnailCache. > PaintBoxMorph initialize. > PaintBoxMorph classPool at: #ColorChart put: nil; at: #Prototype > put: nil. > Utilities classPool at: #ScrapsBook put: nil. > Project allInstancesDo: [ :each | each setThumbnail: nil ]. > InternalThreadNavigationMorph clearThumbnailCache. > ScriptingSystem stripGraphicsForExternalRelease. > ProjectHistory currentHistory initialize. > Utilities zapUpdateDownloader. > Smalltalk forgetDoIts. > Behavior flushObsoleteSubclasses. > CommandHistory allInstancesDo: #initialize. > ScriptLoader new cleaningCS. > RequiredSelectors initialize. > ProvidedSelectors initialize. > LocalSends initialize. > SendCaches initializeAllInstances. > Utilities cleanseOtherworldlySteppers. > Smalltalk organization removeEmptyCategories. > SystemBrowser removeObsolete. > TheWorldMenu removeObsolete. > AppRegistry removeObsolete. > FileServices removeObsolete. > SystemNavigation default obsoleteBehaviors. > MCFileBasedRepository flushAllCaches. > MCDefinition clearInstances. > Undeclared removeUnreferencedKeys. > Smalltalk flushClassNameCache. > 3 timesRepeat: [ Smalltalk garbageCollect. Symbol > compactSymbolTable ]. > Set rehashAllSets. > Smalltalk garbageCollect. > > > ___________________ > 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. 11, 2008

[Pharo-project] Pharo image size: 10.9MB

by Adrian Lienhard

I've been looking into how the current 13.4MB a Pharo image uses are spent... I expected that at least half of it is used by classes (compiled methods). But this is not the case. Actually, only about 1/4th are classes. As it turned out, almost the same amount of memory is used by forms (actually bitmaps)! If you want to know which are the largest 10 forms try this: (Form allInstances asSortedCollection: [ :e1 :e2 | e1 bits size >= e2 bits size ]) from: 1 to: 10 do: [ :each | each asMorph openInWorld ] ...among which for example are 4 different color pickers. In total there are around 450 forms, most from EToys. I've manually traced down where the larger forms come from and have cleaned up those that were possible (many are only referenced by caches). The number of forms is at 320 now. In the process I produced the script below, which among other stuff removes all but the default font. Also, it actually removes the flaps from the system instead of only hiding them. Here a history of image sizes: Squeak 3.9: 15.6 MB Pharo 10091: 13.4MB (before cleanup) Pharo 10091: 10.9MB (after cleanup) Main conclusion: the system needs cleanup not only of the code (where the mess is more directly visible), but also of the object memory. Furthermore, I expect removing EToys will have an nice impact on the image size. Also removing Sound will release some memory because of sound samples. If anybody has suggestions to further reduce the image size (<10MB would be a nice target for the first release...), please let me know. Cheers, Adrian Preferences setDefaultFonts: #( (setSystemFontTo: 'Accuny' 10) (setListFontTo: 'Accuny' 10) (setMenuFontTo: 'Accuny' 10) (setFlapsFontTo: 'Accuny' 12) (setEToysFontTo: 'Accuny' 10) (setPaintBoxButtonFontTo: 'Accuny' 10) (setWindowTitleFontTo: 'Accuny' 15) (setBalloonHelpFontTo: 'Accuny' 10) (setCodeFontTo: 'Accuny' 10) (setButtonFontTo: 'Accuny' 8)). TextConstants associations do: [ :association | ((association value isKindOf: TextStyle) and: [ association key ~= #Accuny ] and: [ (TextStyle defaultFamilyNames includes: association key) not ]) ifTrue: [ TextConstants removeKey: association key ]]. TextConstants at: #DefaultFixedTextStyle put: (TextConstants at: #Accuny). (Flaps classPool at: #SharedFlapTabs) removeAllSuchThat: [ :each | (#(Tools Pharo) includes: each labelString) not ]. NaturalLanguageFormTranslator classPool at: #CachedTranslations put: nil. NaturalLanguageTranslator resetCaches. PartsBin clearThumbnailCache. PaintBoxMorph initialize. PaintBoxMorph classPool at: #ColorChart put: nil; at: #Prototype put: nil. Utilities classPool at: #ScrapsBook put: nil. Project allInstancesDo: [ :each | each setThumbnail: nil ]. InternalThreadNavigationMorph clearThumbnailCache. ScriptingSystem stripGraphicsForExternalRelease. ProjectHistory currentHistory initialize. Utilities zapUpdateDownloader. Smalltalk forgetDoIts. Behavior flushObsoleteSubclasses. CommandHistory allInstancesDo: #initialize. ScriptLoader new cleaningCS. RequiredSelectors initialize. ProvidedSelectors initialize. LocalSends initialize. SendCaches initializeAllInstances. Utilities cleanseOtherworldlySteppers. Smalltalk organization removeEmptyCategories. SystemBrowser removeObsolete. TheWorldMenu removeObsolete. AppRegistry removeObsolete. FileServices removeObsolete. SystemNavigation default obsoleteBehaviors. MCFileBasedRepository flushAllCaches. MCDefinition clearInstances. Undeclared removeUnreferencedKeys. Smalltalk flushClassNameCache. 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ]. Set rehashAllSets. Smalltalk garbageCollect. ___________________ http://www.adrian-lienhard.ch/

Oct. 11, 2008

Re: [Pharo-project] Pharo Harvesting Infrastructure

by StÃ©phane Ducasse

for me this is the 15th but I'm cheating :) I want the gifts before :)) Stef >>> I will take the time to reply. RIght now I'm busy with friends >>> for my birthday :) >> >> hehe. I'll be celebrating my birthday later today too. Have fun! >> > No way. It's my birthday, too. :)) > > Norbert

Oct. 11, 2008

Re: [Pharo-project] Pharo Harvesting Infrastructure

by Norbert Hartl

On Sat, 2008-10-11 at 08:37 -0700, Matthew Fulmer wrote: > On Sat, Oct 11, 2008 at 04:55:52PM +0200, St?phane Ducasse wrote: > > I will take the time to reply. RIght now I'm busy with friends > > for my birthday :) > > hehe. I'll be celebrating my birthday later today too. Have fun! > No way. It's my birthday, too. :)) Norbert

Oct. 11, 2008

Re: [Pharo-project] Pharo Harvesting Infrastructure

by Matthew Fulmer

On Sat, Oct 11, 2008 at 04:55:52PM +0200, St?phane Ducasse wrote: > I will take the time to reply. RIght now I'm busy with friends > for my birthday :) hehe. I'll be celebrating my birthday later today too. Have fun! -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Oct. 11, 2008

Re: [Pharo-project] Pharo Harvesting Infrastructure

by StÃ©phane Ducasse

I will take the time to reply. RIght now I'm busy with friends for my birthday :) Stef On Oct 11, 2008, at 10:52 AM, Matthew Fulmer wrote: > Hi. I found a bug in Pharo, and I started wondering how to > determine where it came from. I checked a few methods in the > debugger to see if they had recently been modified, but that was > no help. I checked the change sorter to see if it had any idea > what had been recently installed, but it was choked by > Monticello updates. > > Then I opened a new Pharo Image in order to try each update one > by one (whatever Monticello you guys use to load your changes is > *really* slow. I gotta fix you guys up with MC1.6). But before I > did that, I noticed on the right of the screen is something that > looks like a change log. And at the bottom, it said: > > (full list of changes: print "ScriptLoader new logContents") > > So I tried it in my 10091 image, and sure enough, it printed up > a changelog. So I went to see what this mysterious class > ScriptLoader is. I found a whole lot of methods. Some looked > auto-generated. Some seemed to be convenience methods for > loading MC packages from Pharo and PharoInbox. It looks kind of > like Installer, which I am more familiar with. > > I'm rather curious now about how you manage Pharo. I took a look > at http://code.google.com/p/pharo/wiki/HowToContribute and > wondered what happens after that. I now imagine it involves > ScriptBuilder building the update, and then something uploading > it. What is the mechanism? > > How is Pharo tested? is it regularly tested by someone using > TestRunner, or something fancier? > > What are all the auto-generated methods in ScriptLoader for? > > How do you typically trace a bug from image to problem package > to update to issue? > > I'm interested because keith and I are building a build server > that is able to build images, build packages, load packages, run > tests, build VM's and such, all automated and with an easy > interface. So far, we have the easy interface (Installer), but > are still working on making it do more. > > So I'm interested in learning how it works here, so that we can > at least end up with something as good as this > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2008

Re: [Pharo-project] About trait mop

by StÃ©phane Ducasse

OK for me. >>>>> the point is that since Compiled Method are copied >> >> But even non-aliased methods are copied... Indeed. >> >> >>> so c3 is really different from c2 >>> and c3 is not defined in Trait2 but this is realy because there is >>> D that C3 exists. >>> so tell me what you think. >> >> The problem with making the origin D is that then the relationship >> "all methods that have the origin class D are local methdos in >> class D" is not true anymore. >> marcus >> I think it is more important to have this true for classes then for >> Traits. > > I agree with Marcus. > The origin of a method for me means the behavior (trait or class) in > which a method is originally defined. That is, if I want to modify > the method without overriding it, this is the place to do it. > Therefore, even though D introduces a new name for the method, the > method still originates in Trait2. > > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2008

Re: [Pharo-project] Re: #2

by StÃ©phane Ducasse

excellent! Stef On Oct 10, 2008, at 9:28 PM, nicolas cellier wrote: > nicolas cellier <ncellier@...> writes: > >> >> ## is questionable: we can accept such a syntax, but what for >> exactly? >> >> If no valuable reason, shouldn't we better enforce syntaxic check >> in Parser and >> signal malformed statements as an error as would any other Smalltalk? >> >> Quite sure that NewCompiler already fix all this stuff. >> What are the plans about its integration? >> Waiting for Eliot's COG? >> > > Anyway, even with NewCompiler, #isLiteralSymbol: and also #numArgs > need fixes. > These two are probably related to alternate syntax experiments. > Google this one: > alternate syntax site:lists.squeakfoundation.org > > Since bugs are hanging around for too long, it is high time to > correct. > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-April/005341.ht… > http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-March/075166.ht… > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-May/117145.html > > and also: > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-July/119095.html > > Pharo is the ideal place to commit these changes. > I will give it a try. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2008