- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50458 Home: https://github.com/pharo-project/pharo-core

Nov. 22, 2015

[pharo-project/pharo-core] b27de6: 50458

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: b27de6aabe954041aca71fc9aeadba1fddcdde66 https://github.com/pharo-project/pharo-core/commit/b27de6aabe954041aca71fc9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-22 (Sun, 22 Nov 2015) Changed paths: M Collections-Sequenceable.package/OrderedDictionary.class/instance/comparing/=.st A Collections-Tests.package/DictionaryTest.class/instance/requirements/otherDictionaryClasses.st A Collections-Tests.package/DictionaryTest.class/instance/test - comparing/testOtherDictionaryEquality.st A Collections-Tests.package/OrderedDictionaryTest.class/instance/accessing/otherOrderedDictionaryClasses.st M Collections-Tests.package/OrderedDictionaryTest.class/instance/tests/testEqualsDictionary.st A Collections-Tests.package/OrderedDictionaryTest.class/instance/tests/testEqualsOtherOrderedDictionaries.st M Collections-Unordered.package/Dictionary.class/instance/comparing/=.st M Collections-Unordered.package/SmallDictionary.class/instance/comparing/=.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50457.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50458.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50457.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50458.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50458 16760 Dictionary>>= breaks when comparing identity and non-identity dictionaries https://pharo.fogbugz.com/f/cases/16760 http://files.pharo.org/image/50/50458.zip

Nov. 22, 2015

Re: [Pharo-dev] A plea for responsive coding

by Tudor Girba

Then why do you âcomplain" about the code being slow? :) Seriously, how do you store the PNG file in the method? Here is an example of how to store the form of a PNG: form := PNGReadWriter formFromFileNamed: aPngFile. iconName := aPngFile basenameWithoutExtension. methodSource := iconName , Character cr asString , '^ self icons at: #', iconName, 'ifAbsentPut: [', form storeString, ']'. targetClass class compile: methodSource classified: âiconsâ. This will compile the picture in a âiconNameâ method in a âtargetClassâ. The code also relies on an âiconsâ getter in the âtargetClassâ that should cache these forms. Like this, you only load the form once. Is this enough for you? Cheers, Doru > On Nov 22, 2015, at 2:56 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > because making something work for me comes way before making something work fast. > > On Sun, Nov 22, 2015 at 3:50 PM stepharo <stepharo(a)free.fr> wrote: > But why don't you manipulate Forms instead of PNGs. Converting from PNGs to Forms should be done only once. > > Stef > > Le 22/11/15 11:53, Dimitris Chloupis a Ã©crit : >> here is the tricky part , I am willing to bet that the slow down happens because of the stepping of the seconds indicator. >> >> The one thing I forgot to mention is that I dont load my images from external files, the images are already converted to method sources , strings , with Peter's IconFactory library. Still the PNGReader class tries to convert those string streams to forms and is where most of the time is consumed. The reason I chose this approach was in hope of a speed up so pharo does not waste time opening and closing files. >> >> In the stepping of the seconds indicator I recreate the form in each step , depending on the seconds. I could optomise that part by having all images of the animation loaded into seperate forms during initialisation and just use the reference of the correct form during stepping that should speed things up a lot. >> >> Overall 170ms for opening that GUI is not so bad for a dynamic GC language. Taking into account that this is mostly pharo code , unlike python that it would be using a C lib to speed things up. I am a happy Morphic customer :) >> >> On Sun, Nov 22, 2015 at 12:39 PM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> Le 22/11/2015 11:27, Dimitris Chloupis a Ã©crit : >> > tried with ChronosManager >> > >> > [ ChronosManager open ] bench >> > >> > 5.6 per second >> > >> > it opened around 30 instances and Morphic was crawling. >> > >> > I profiled it and it reports that it spends a total 170ms which is >> > consistent with bench. Around 50ms is spent only for loading the image >> > of the secondary panel and from what I have seen loading the images and >> > the font accounts around 90% of the time spent and then rest 10% is >> > actually morphic + logic. >> >> If I understand you well, what you have is: >> >> - ChronosManager takes 170ms to open, including external resources >> loading time (which is SSD/HD dependent). >> >> - The whole world performance degrades with many ChronosManager >> instances loaded? (Moving one around probably forces others to refresh >> as well). >> >> What could be nice is to profile rendering time as well (but, if your >> first render time is included in the 10% of 170ms you quote, then it is >> probably fine). >> >> Would you like to try benchmarking rendering one ChronosManager instance >> when you have 30 instances opened / only one instance opened? >> >> > So from the looks of it , it looks like Morphic does not perform well >> > with loaded images and external files. >> >> This is a clear win if you cache those (i.e. have a LRU cache holding >> forms and fonts, filled upon first load, reused over subsequent loads). >> >> Thierry >> >> > >> > >> > On Sun, Nov 22, 2015 at 11:34 AM Thierry Goubier >> > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> > >> > Hi all, >> > >> > I would like to ask you, all of you, something significant when doing >> > GUI coding: >> > >> > Pay attention to performance! >> > >> > With the current state of our technology (Morphic, Bloc, whatever comes >> > next) your target should be one hundred milliseconds (100 ms), for >> > opening / redisplaying the widget. >> > >> > Why? >> > >> > - Because, in 10ms, Morphic can open and layout dozens of Morphs on a >> > low-end machine (1.4GHz Celeron). >> > >> > - Because most of you work on 3GHz+ i7 Macbook Pro (so, at 10x the cpu >> > performance of that said Celeron). >> > >> > - Because you are not to reproduce the past: that your current tools are >> > slow is no excuse. >> > >> > - Because you now have well designed core widgets (FT) that behaves in >> > O(1) and opens fully loaded in 10's of milliseconds >> > >> > So, profile and clean your code! Eliminate unneeded caches! Clean your >> > architectures! Avoid or mark slow code and bottlenecks! >> > >> > And bring numbers when you want to criticize the performance of a >> > subsystem... >> > >> > Thierry >> > >> >> > -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Nov. 22, 2015

Re: [Pharo-dev] A plea for responsive coding

by Dimitris Chloupis

sorry Stef I dont understand what you trying to say. As I already said I am not even using PNGs, they are converted to stream strings that then are converted to forms. By the time my objects are initialised those images are already stream strings and during initialisation are converted to forms that are then are just used by the GUI. During render time I just reference those forms. The only exception was the seconds timer that i made it create a new form on each morphic step because at the time I cared only to make it work and I was not aware that it could bring down Morphic with multiple instances of it. The tool I am creating however is not meant to be run in multiple instances and I plan to make multiple timers managed by a single GUI since I am not a fan of doing GUI the traditional ways of multiple windows hell which is also a pharo syndrome. Bottom line is that at the time I released ChronosManager v0.1 I did not notice any slow downs. V0.2 will contain this fix. And remember you were the one that asked me why I did not named the first version, 1 , now you know :D On Sun, Nov 22, 2015 at 4:24 PM stepharo <stepharo(a)free.fr> wrote: > This is not a point to make thing fast this is make things right :) > PNG are not graphical pharo objects, only forms. > > Stef > > > Le 22/11/15 14:56, Dimitris Chloupis a Ã©crit : > > because making something work for me comes way before making something > work fast. > > On Sun, Nov 22, 2015 at 3:50 PM stepharo <stepharo(a)free.fr> wrote: > >> But why don't you manipulate Forms instead of PNGs. Converting from PNGs >> to Forms should be done only once. >> >> Stef >> >> Le 22/11/15 11:53, Dimitris Chloupis a Ã©crit : >> >> here is the tricky part , I am willing to bet that the slow down happens >> because of the stepping of the seconds indicator. >> >> The one thing I forgot to mention is that I dont load my images from >> external files, the images are already converted to method sources , >> strings , with Peter's IconFactory library. Still the PNGReader class tries >> to convert those string streams to forms and is where most of the time is >> consumed. The reason I chose this approach was in hope of a speed up so >> pharo does not waste time opening and closing files. >> >> In the stepping of the seconds indicator I recreate the form in each step >> , depending on the seconds. I could optomise that part by having all images >> of the animation loaded into seperate forms during initialisation and just >> use the reference of the correct form during stepping that should speed >> things up a lot. >> >> Overall 170ms for opening that GUI is not so bad for a dynamic GC >> language. Taking into account that this is mostly pharo code , unlike >> python that it would be using a C lib to speed things up. I am a happy >> Morphic customer :) >> >> On Sun, Nov 22, 2015 at 12:39 PM Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> Le 22/11/2015 11:27, Dimitris Chloupis a Ã©crit : >>> > tried with ChronosManager >>> > >>> > [ ChronosManager open ] bench >>> > >>> > 5.6 per second >>> > >>> > it opened around 30 instances and Morphic was crawling. >>> > >>> > I profiled it and it reports that it spends a total 170ms which is >>> > consistent with bench. Around 50ms is spent only for loading the image >>> > of the secondary panel and from what I have seen loading the images and >>> > the font accounts around 90% of the time spent and then rest 10% is >>> > actually morphic + logic. >>> >>> If I understand you well, what you have is: >>> >>> - ChronosManager takes 170ms to open, including external resources >>> loading time (which is SSD/HD dependent). >>> >>> - The whole world performance degrades with many ChronosManager >>> instances loaded? (Moving one around probably forces others to refresh >>> as well). >>> >>> What could be nice is to profile rendering time as well (but, if your >>> first render time is included in the 10% of 170ms you quote, then it is >>> probably fine). >>> >>> Would you like to try benchmarking rendering one ChronosManager instance >>> when you have 30 instances opened / only one instance opened? >>> >>> > So from the looks of it , it looks like Morphic does not perform well >>> > with loaded images and external files. >>> >>> This is a clear win if you cache those (i.e. have a LRU cache holding >>> forms and fonts, filled upon first load, reused over subsequent loads). >>> >>> Thierry >>> >>> > >>> > >>> > On Sun, Nov 22, 2015 at 11:34 AM Thierry Goubier >>> > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >>> > >>> > Hi all, >>> > >>> > I would like to ask you, all of you, something significant when >>> doing >>> > GUI coding: >>> > >>> > Pay attention to performance! >>> > >>> > With the current state of our technology (Morphic, Bloc, whatever >>> comes >>> > next) your target should be one hundred milliseconds (100 ms), for >>> > opening / redisplaying the widget. >>> > >>> > Why? >>> > >>> > - Because, in 10ms, Morphic can open and layout dozens of Morphs >>> on a >>> > low-end machine (1.4GHz Celeron). >>> > >>> > - Because most of you work on 3GHz+ i7 Macbook Pro (so, at 10x the >>> cpu >>> > performance of that said Celeron). >>> > >>> > - Because you are not to reproduce the past: that your current >>> tools are >>> > slow is no excuse. >>> > >>> > - Because you now have well designed core widgets (FT) that >>> behaves in >>> > O(1) and opens fully loaded in 10's of milliseconds >>> > >>> > So, profile and clean your code! Eliminate unneeded caches! Clean >>> your >>> > architectures! Avoid or mark slow code and bottlenecks! >>> > >>> > And bring numbers when you want to criticize the performance of a >>> > subsystem... >>> > >>> > Thierry >>> > >>> >>> >>> >> >

Nov. 22, 2015

Re: [Pharo-dev] A plea for responsive coding

by stepharo

This is not a point to make thing fast this is make things right :) PNG are not graphical pharo objects, only forms. Stef Le 22/11/15 14:56, Dimitris Chloupis a Ã©crit : > because making something work for me comes way before making something > work fast. > > On Sun, Nov 22, 2015 at 3:50 PM stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > But why don't you manipulate Forms instead of PNGs. Converting > from PNGs to Forms should be done only once. > > Stef > > Le 22/11/15 11:53, Dimitris Chloupis a Ã©crit : >> here is the tricky part , I am willing to bet that the slow down >> happens because of the stepping of the seconds indicator. >> >> The one thing I forgot to mention is that I dont load my images >> from external files, the images are already converted to method >> sources , strings , with Peter's IconFactory library. Still the >> PNGReader class tries to convert those string streams to forms >> and is where most of the time is consumed. The reason I chose >> this approach was in hope of a speed up so pharo does not waste >> time opening and closing files. >> >> In the stepping of the seconds indicator I recreate the form in >> each step , depending on the seconds. I could optomise that part >> by having all images of the animation loaded into seperate forms >> during initialisation and just use the reference of the correct >> form during stepping that should speed things up a lot. >> >> Overall 170ms for opening that GUI is not so bad for a dynamic GC >> language. Taking into account that this is mostly pharo code , >> unlike python that it would be using a C lib to speed things up. >> I am a happy Morphic customer :) >> >> On Sun, Nov 22, 2015 at 12:39 PM Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 22/11/2015 11:27, Dimitris Chloupis a Ã©crit : >> > tried with ChronosManager >> > >> > [ ChronosManager open ] bench >> > >> > 5.6 per second >> > >> > it opened around 30 instances and Morphic was crawling. >> > >> > I profiled it and it reports that it spends a total 170ms >> which is >> > consistent with bench. Around 50ms is spent only for >> loading the image >> > of the secondary panel and from what I have seen loading >> the images and >> > the font accounts around 90% of the time spent and then >> rest 10% is >> > actually morphic + logic. >> >> If I understand you well, what you have is: >> >> - ChronosManager takes 170ms to open, including external >> resources >> loading time (which is SSD/HD dependent). >> >> - The whole world performance degrades with many ChronosManager >> instances loaded? (Moving one around probably forces others >> to refresh >> as well). >> >> What could be nice is to profile rendering time as well (but, >> if your >> first render time is included in the 10% of 170ms you quote, >> then it is >> probably fine). >> >> Would you like to try benchmarking rendering one >> ChronosManager instance >> when you have 30 instances opened / only one instance opened? >> >> > So from the looks of it , it looks like Morphic does not >> perform well >> > with loaded images and external files. >> >> This is a clear win if you cache those (i.e. have a LRU cache >> holding >> forms and fonts, filled upon first load, reused over >> subsequent loads). >> >> Thierry >> >> > >> > >> > On Sun, Nov 22, 2015 at 11:34 AM Thierry Goubier >> > <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com> >> <mailto:thierry.goubier@gmail.com >> <mailto:thierry.goubier@gmail.com>>> wrote: >> > >> > Hi all, >> > >> > I would like to ask you, all of you, something >> significant when doing >> > GUI coding: >> > >> > Pay attention to performance! >> > >> > With the current state of our technology (Morphic, >> Bloc, whatever comes >> > next) your target should be one hundred milliseconds >> (100 ms), for >> > opening / redisplaying the widget. >> > >> > Why? >> > >> > - Because, in 10ms, Morphic can open and layout dozens >> of Morphs on a >> > low-end machine (1.4GHz Celeron). >> > >> > - Because most of you work on 3GHz+ i7 Macbook Pro (so, >> at 10x the cpu >> > performance of that said Celeron). >> > >> > - Because you are not to reproduce the past: that your >> current tools are >> > slow is no excuse. >> > >> > - Because you now have well designed core widgets (FT) >> that behaves in >> > O(1) and opens fully loaded in 10's of milliseconds >> > >> > So, profile and clean your code! Eliminate unneeded >> caches! Clean your >> > architectures! Avoid or mark slow code and bottlenecks! >> > >> > And bring numbers when you want to criticize the >> performance of a >> > subsystem... >> > >> > Thierry >> > >> >> >

Nov. 22, 2015

R: A plea for responsive coding

by Lorenzo Schiavina

+1 Lorenzo Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Dimitris Chloupis Inviato: domenica 22 novembre 2015 14:56 A: Pharo Development List Oggetto: Re: [Pharo-dev] A plea for responsive coding because making something work for me comes way before making something work fast. On Sun, Nov 22, 2015 at 3:50 PM stepharo <stepharo(a)free.fr> wrote: But why don't you manipulate Forms instead of PNGs. Converting from PNGs to Forms should be done only once. Stef Le 22/11/15 11:53, Dimitris Chloupis a Ã©crit : here is the tricky part , I am willing to bet that the slow down happens because of the stepping of the seconds indicator. The one thing I forgot to mention is that I dont load my images from external files, the images are already converted to method sources , strings , with Peter's IconFactory library. Still the PNGReader class tries to convert those string streams to forms and is where most of the time is consumed. The reason I chose this approach was in hope of a speed up so pharo does not waste time opening and closing files. In the stepping of the seconds indicator I recreate the form in each step , depending on the seconds. I could optomise that part by having all images of the animation loaded into seperate forms during initialisation and just use the reference of the correct form during stepping that should speed things up a lot. Overall 170ms for opening that GUI is not so bad for a dynamic GC language. Taking into account that this is mostly pharo code , unlike python that it would be using a C lib to speed things up. I am a happy Morphic customer :) On Sun, Nov 22, 2015 at 12:39 PM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: Le 22/11/2015 11:27, Dimitris Chloupis a Ã©crit : > tried with ChronosManager > > [ ChronosManager open ] bench > > 5.6 per second > > it opened around 30 instances and Morphic was crawling. > > I profiled it and it reports that it spends a total 170ms which is > consistent with bench. Around 50ms is spent only for loading the image > of the secondary panel and from what I have seen loading the images and > the font accounts around 90% of the time spent and then rest 10% is > actually morphic + logic. If I understand you well, what you have is: - ChronosManager takes 170ms to open, including external resources loading time (which is SSD/HD dependent). - The whole world performance degrades with many ChronosManager instances loaded? (Moving one around probably forces others to refresh as well). What could be nice is to profile rendering time as well (but, if your first render time is included in the 10% of 170ms you quote, then it is probably fine). Would you like to try benchmarking rendering one ChronosManager instance when you have 30 instances opened / only one instance opened? > So from the looks of it , it looks like Morphic does not perform well > with loaded images and external files. This is a clear win if you cache those (i.e. have a LRU cache holding forms and fonts, filled upon first load, reused over subsequent loads). Thierry > > > On Sun, Nov 22, 2015 at 11:34 AM Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi all, > > I would like to ask you, all of you, something significant when doing > GUI coding: > > Pay attention to performance! > > With the current state of our technology (Morphic, Bloc, whatever comes > next) your target should be one hundred milliseconds (100 ms), for > opening / redisplaying the widget. > > Why? > > - Because, in 10ms, Morphic can open and layout dozens of Morphs on a > low-end machine (1.4GHz Celeron). > > - Because most of you work on 3GHz+ i7 Macbook Pro (so, at 10x the cpu > performance of that said Celeron). > > - Because you are not to reproduce the past: that your current tools are > slow is no excuse. > > - Because you now have well designed core widgets (FT) that behaves in > O(1) and opens fully loaded in 10's of milliseconds > > So, profile and clean your code! Eliminate unneeded caches! Clean your > architectures! Avoid or mark slow code and bottlenecks! > > And bring numbers when you want to criticize the performance of a > subsystem... > > Thierry >

Nov. 22, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50457 Home: https://github.com/pharo-project/pharo-core

Nov. 22, 2015

[pharo-project/pharo-core] a4ba46: 50457

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a4ba46aa059cc15f4892e91086abcdec33c4c677 https://github.com/pharo-project/pharo-core/commit/a4ba46aa059cc15f4892e910… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-22 (Sun, 22 Nov 2015) Changed paths: M Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/buildAddSelectedPackageInSelectedGroupButton.st M Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/item creation/buildRemoveSelectedPackageFromSelectedGroupButton.st M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/setUp.st R Nautilus.package/AbstractNautilusUI.class/instance/accessing/selectedGroup_.st R Nautilus.package/AbstractNautilusUI.class/instance/accessing/showHierarchySilently_.st R Nautilus.package/AbstractNautilusUI.class/instance/build ui/buildSeparator.st R Nautilus.package/AbstractNautilusUI.class/instance/private/popUpTestsResult_.st R Nautilus.package/AbstractNautilusUI.class/instance/private/renamePackage_.st R Nautilus.package/AbstractNautilusUI.class/instance/private/updatePackageView.st R Nautilus.package/AbstractNautilusUI.class/instance/system announcements/classAdded_.st R Nautilus.package/NautilusUI.class/class/initialize/initializeCache.st A Nautilus.package/NautilusUI.class/class/menu/packagesFixMenu_.st M Nautilus.package/NautilusUI.class/definition.st A Nautilus.package/NautilusUI.class/instance/accessing/basicSelectPackage_.st A Nautilus.package/NautilusUI.class/instance/accessing/groups.st A Nautilus.package/NautilusUI.class/instance/accessing/packages.st A Nautilus.package/NautilusUI.class/instance/accessing/selectedFromPackageGroupView_.st A Nautilus.package/NautilusUI.class/instance/accessing/selectedGroup_.st A Nautilus.package/NautilusUI.class/instance/accessing/selectedPackageWithoutChangingSelection_.st A Nautilus.package/NautilusUI.class/instance/accessing/selectedPackage_.st A Nautilus.package/NautilusUI.class/instance/accessing/selectedProtocol.st A Nautilus.package/NautilusUI.class/instance/accessing/showHierarchy_.st A Nautilus.package/NautilusUI.class/instance/build ui lists/buildFirstColumn_.st R Nautilus.package/NautilusUI.class/instance/category-method methods/selectedMethodWithoutAsking_.st A Nautilus.package/NautilusUI.class/instance/class/addClassIn_.st A Nautilus.package/NautilusUI.class/instance/class/addTraitIn_.st A Nautilus.package/NautilusUI.class/instance/events handling/keyPressedOnList_shifted_.st A Nautilus.package/NautilusUI.class/instance/events handling/keyPressedOnTree_target_.st M Nautilus.package/NautilusUI.class/instance/initialization/initialize.st A Nautilus.package/NautilusUI.class/instance/menu pragmas/packageFixPragma.st A Nautilus.package/NautilusUI.class/instance/menus behavior/addClassCategory.st R Nautilus.package/NautilusUI.class/instance/menus behavior/findAllMethod.st M Nautilus.package/NautilusUI.class/instance/menus behavior/fullBrowse.st A Nautilus.package/NautilusUI.class/instance/menus behavior/removeGroups.st A Nautilus.package/NautilusUI.class/instance/menus behavior/removePackages.st M Nautilus.package/NautilusUI.class/instance/menus behavior/renameCategory.st A Nautilus.package/NautilusUI.class/instance/menus behavior/restrictedBrowsePackages_.st A Nautilus.package/NautilusUI.class/instance/menus/menu_shifted_.st A Nautilus.package/NautilusUI.class/instance/package filter/buildPackageSearch.st A Nautilus.package/NautilusUI.class/instance/package filter/class_matchPackagePatternString_.st A Nautilus.package/NautilusUI.class/instance/package filter/createPackagePattern_.st A Nautilus.package/NautilusUI.class/instance/package filter/ensureSafePackagePattern_.st A Nautilus.package/NautilusUI.class/instance/package filter/fixPackagePattern_ex_.st A Nautilus.package/NautilusUI.class/instance/package filter/packageMatchPattern_.st A Nautilus.package/NautilusUI.class/instance/package filter/packagePattern.st A Nautilus.package/NautilusUI.class/instance/package filter/packagePatternString.st A Nautilus.package/NautilusUI.class/instance/package filter/packagePatternString_.st A Nautilus.package/NautilusUI.class/instance/package filter/packageSearchUpdate_.st A Nautilus.package/NautilusUI.class/instance/package filter/package_matchPackagePattern_.st A Nautilus.package/NautilusUI.class/instance/package filter/updatePackages.st A Nautilus.package/NautilusUI.class/instance/package filter/useLastPackagePatternString.st A Nautilus.package/NautilusUI.class/instance/package filter/useLastPackagePatternStringForClass_.st A Nautilus.package/NautilusUI.class/instance/package/addPackageBasedOn_.st A Nautilus.package/NautilusUI.class/instance/package/addPackagesAsGroup_.st A Nautilus.package/NautilusUI.class/instance/package/alertCategoryName_exitstsAlreadyIn_.st A Nautilus.package/NautilusUI.class/instance/package/category_existsIn_.st A Nautilus.package/NautilusUI.class/instance/package/fileOutPackages_.st A Nautilus.package/NautilusUI.class/instance/private dispatch/fullBrowseFromPackage_.st A Nautilus.package/NautilusUI.class/instance/private dispatch/fullBrowseFromTag_.st A Nautilus.package/NautilusUI.class/instance/private dispatch/registerSelectionGroup_.st A Nautilus.package/NautilusUI.class/instance/private dispatch/registerSelectionPackage_.st A Nautilus.package/NautilusUI.class/instance/private dispatch/removeClassCategory_.st A Nautilus.package/NautilusUI.class/instance/private dispatch/removePackageCategory_.st A Nautilus.package/NautilusUI.class/instance/private dispatch/renameClassCategory_.st A Nautilus.package/NautilusUI.class/instance/private dispatch/renamePackageCategory_.st A Nautilus.package/NautilusUI.class/instance/private/addClassCategoryBasedOn_.st A Nautilus.package/NautilusUI.class/instance/private/basicRemoveClasses_.st A Nautilus.package/NautilusUI.class/instance/private/basicRenamePackage_.st A Nautilus.package/NautilusUI.class/instance/private/basicShowHierarchy.st A Nautilus.package/NautilusUI.class/instance/private/clearPackageSelections.st M Nautilus.package/NautilusUI.class/instance/private/isSelectedPackage_.st A Nautilus.package/NautilusUI.class/instance/private/listClearSelection.st A Nautilus.package/NautilusUI.class/instance/private/listSelectItem_.st R Nautilus.package/NautilusUI.class/instance/private/nextButtonState.st R Nautilus.package/NautilusUI.class/instance/private/previousButtonState.st A Nautilus.package/NautilusUI.class/instance/private/renamePackage_.st A Nautilus.package/NautilusUI.class/instance/private/runPackagesTestsNotifying_.st A Nautilus.package/NautilusUI.class/instance/private/selectPackageFor_.st A Nautilus.package/NautilusUI.class/instance/private/updateGroupView.st A Nautilus.package/NautilusUI.class/instance/private/updatePackageGroupAndClassList.st A Nautilus.package/NautilusUI.class/instance/private/updatePackageView.st A Nautilus.package/NautilusUI.class/instance/source code area/defaultClassDescriptor.st A Nautilus.package/NautilusUI.class/instance/system announcements/classAdded_.st A Nautilus.package/NautilusUI.class/instance/test creation/buildTestPackageNameFrom_.st R Nautilus.package/NautilusUI.class/instance/widget method/methodsForCategoriesInGroup_.st R Nautilus.package/NautilusUI.class/instance/widget method/methodsForCategoryInGroup_.st R Nautilus.package/PackageTreeNautilusUI.class/class/menu/packagesFixMenu_.st M Nautilus.package/PackageTreeNautilusUI.class/definition.st R Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/basicSelectPackage_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/groups.st R Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/packages.st R Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/selectedFromPackageGroupView_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/selectedGroup_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/selectedPackageWithoutChangingSelection_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/selectedPackage_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/selectedProtocol.st R Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/showHierarchy_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/build ui lists/buildFirstColumn_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/class/addClassIn_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/class/addTraitIn_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/events handling/keyPressedOnList_shifted_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/events handling/keyPressedOnTree_target_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/initialization/initialize.st R Nautilus.package/PackageTreeNautilusUI.class/instance/menu pragmas/packageFixPragma.st R Nautilus.package/PackageTreeNautilusUI.class/instance/menus behavior/addClassCategory.st R Nautilus.package/PackageTreeNautilusUI.class/instance/menus behavior/fullBrowse.st R Nautilus.package/PackageTreeNautilusUI.class/instance/menus behavior/removeGroups.st R Nautilus.package/PackageTreeNautilusUI.class/instance/menus behavior/removePackages.st R Nautilus.package/PackageTreeNautilusUI.class/instance/menus behavior/renameCategory.st R Nautilus.package/PackageTreeNautilusUI.class/instance/menus behavior/restrictedBrowsePackages_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/menus/menu_shifted_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/buildPackageSearch.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/class_matchPackagePatternString_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/createPackagePattern_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/ensureSafePackagePattern_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/fixPackagePattern_ex_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/packageMatchPattern_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/packagePattern.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/packagePatternString.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/packagePatternString_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/packageSearchUpdate_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/package_matchPackagePattern_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/updatePackages.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/useLastPackagePatternString.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/useLastPackagePatternStringForClass_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package/addPackageBasedOn_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package/addPackagesAsGroup_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package/alertCategoryName_exitstsAlreadyIn_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package/category_existsIn_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/package/fileOutPackages_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private dispatch/fullBrowseFromPackage_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private dispatch/fullBrowseFromTag_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private dispatch/registerSelectionGroup_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private dispatch/registerSelectionPackage_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private dispatch/removeClassCategory_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private dispatch/removePackageCategory_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private dispatch/renameClassCategory_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private dispatch/renamePackageCategory_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/addClassCategoryBasedOn_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/basicRemoveClasses_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/basicRenamePackage_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/basicShowHierarchy.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/clearPackageSelections.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/isSelectedPackage_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/listClearSelection.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/listSelectItem_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/renamePackage_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/runPackagesTestsNotifying_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/selectPackageFor_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/updateGroupView.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/updatePackageGroupAndClassList.st R Nautilus.package/PackageTreeNautilusUI.class/instance/private/updatePackageView.st R Nautilus.package/PackageTreeNautilusUI.class/instance/source code area/defaultClassDescriptor.st R Nautilus.package/PackageTreeNautilusUI.class/instance/system announcements/classAdded_.st R Nautilus.package/PackageTreeNautilusUI.class/instance/test creation/buildTestPackageNameFrom_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50456.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50457.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50456.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50457.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Announcements.package/ClassParentRenamed.class/README.md A System-Announcements.package/ClassParentRenamed.class/class/instance creation/classParentOf_renamedFrom_to_.st A System-Announcements.package/ClassParentRenamed.class/definition.st A System-Announcements.package/ClassParentRenamed.class/instance/accessing/classAffected.st A System-Announcements.package/ClassParentRenamed.class/instance/accessing/classAffected_.st A System-Announcements.package/ClassParentRenamed.class/instance/accessing/parentNewName.st A System-Announcements.package/ClassParentRenamed.class/instance/accessing/parentNewName_.st A System-Announcements.package/ClassParentRenamed.class/instance/accessing/parentOldName.st A System-Announcements.package/ClassParentRenamed.class/instance/accessing/parentOldName_.st A System-Announcements.package/SystemAnnouncer.class/instance/triggering/classParentOf_renamedFrom_to_.st M System-Support.package/SystemDictionary.class/instance/renaming/renameClass_from_to_.st Log Message: ----------- 50457 17071 merge all methods of PackageTreeNautilusUI into NautilusUI https://pharo.fogbugz.com/f/cases/17071 17064 Add new SystemAnnouncement for "parent class name changed" https://pharo.fogbugz.com/f/cases/17064 17073 wrong arrow icon in Group Manager https://pharo.fogbugz.com/f/cases/17073 http://files.pharo.org/image/50/50457.zip

Nov. 22, 2015

Re: [Pharo-dev] Digest from slack to the mailing list?

by Dimitris Chloupis

Just to clear something up , because I see people in slack saying goodbye, or "I cant reply right now I have something to do" . Slack is not just a real time chat, it keeps messages inside a history of 10 thousand messages. So that means you can log in Slack at any time and not lose a message. There is no reason for you to be online all time, no reason to say goodbye, goodmorning , goodafternoon. You can come and go as you please the exact same way as the mailing list. The problem arises when we exceed 10k messages, the old ones get lost and I think having a place to store them is a good idea. Also what is important is in the eye of the beholder, for example I dont care about any discussion about web development , its just does not interest me or database coding or many other things. I have learned to filter out the messages I dont care about in the mailing list and just reject them. Slack is same story, I quickly glance through its history and I can search the messages that interest me using the search bar , I can star messages that I want to keep, and I can comment on existing messages / code snippets which create a thread about that message. In the end its impossible to keep the community in one place but to have a central hub that collects all the little gems can be quite useful. On Sun, Nov 22, 2015 at 3:46 PM stepharo <stepharo(a)free.fr> wrote: > Yes this would be good. > People should understand that important discussions should be via the > mailing-list. > Emails are good because you can consume them the way you want. > I simply cannot be connected all the time. So emails are good because I > can process them > when I decide. > Slack is good for more interactive session around debugger and things > like that. > > Stef > > > Le 21/11/15 18:05, Stephan Eggermont a Ã©crit : > > Should we have a digest from slack to a mailing list? > > We are already losing messages > > > > Stephan > > > > > > > > >

Nov. 22, 2015

Re: [Pharo-dev] A plea for responsive coding

by Dimitris Chloupis

because making something work for me comes way before making something work fast. On Sun, Nov 22, 2015 at 3:50 PM stepharo <stepharo(a)free.fr> wrote: > But why don't you manipulate Forms instead of PNGs. Converting from PNGs > to Forms should be done only once. > > Stef > > Le 22/11/15 11:53, Dimitris Chloupis a Ã©crit : > > here is the tricky part , I am willing to bet that the slow down happens > because of the stepping of the seconds indicator. > > The one thing I forgot to mention is that I dont load my images from > external files, the images are already converted to method sources , > strings , with Peter's IconFactory library. Still the PNGReader class tries > to convert those string streams to forms and is where most of the time is > consumed. The reason I chose this approach was in hope of a speed up so > pharo does not waste time opening and closing files. > > In the stepping of the seconds indicator I recreate the form in each step > , depending on the seconds. I could optomise that part by having all images > of the animation loaded into seperate forms during initialisation and just > use the reference of the correct form during stepping that should speed > things up a lot. > > Overall 170ms for opening that GUI is not so bad for a dynamic GC > language. Taking into account that this is mostly pharo code , unlike > python that it would be using a C lib to speed things up. I am a happy > Morphic customer :) > > On Sun, Nov 22, 2015 at 12:39 PM Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Le 22/11/2015 11:27, Dimitris Chloupis a Ã©crit : >> > tried with ChronosManager >> > >> > [ ChronosManager open ] bench >> > >> > 5.6 per second >> > >> > it opened around 30 instances and Morphic was crawling. >> > >> > I profiled it and it reports that it spends a total 170ms which is >> > consistent with bench. Around 50ms is spent only for loading the image >> > of the secondary panel and from what I have seen loading the images and >> > the font accounts around 90% of the time spent and then rest 10% is >> > actually morphic + logic. >> >> If I understand you well, what you have is: >> >> - ChronosManager takes 170ms to open, including external resources >> loading time (which is SSD/HD dependent). >> >> - The whole world performance degrades with many ChronosManager >> instances loaded? (Moving one around probably forces others to refresh >> as well). >> >> What could be nice is to profile rendering time as well (but, if your >> first render time is included in the 10% of 170ms you quote, then it is >> probably fine). >> >> Would you like to try benchmarking rendering one ChronosManager instance >> when you have 30 instances opened / only one instance opened? >> >> > So from the looks of it , it looks like Morphic does not perform well >> > with loaded images and external files. >> >> This is a clear win if you cache those (i.e. have a LRU cache holding >> forms and fonts, filled upon first load, reused over subsequent loads). >> >> Thierry >> >> > >> > >> > On Sun, Nov 22, 2015 at 11:34 AM Thierry Goubier >> > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> > >> > Hi all, >> > >> > I would like to ask you, all of you, something significant when >> doing >> > GUI coding: >> > >> > Pay attention to performance! >> > >> > With the current state of our technology (Morphic, Bloc, whatever >> comes >> > next) your target should be one hundred milliseconds (100 ms), for >> > opening / redisplaying the widget. >> > >> > Why? >> > >> > - Because, in 10ms, Morphic can open and layout dozens of Morphs on >> a >> > low-end machine (1.4GHz Celeron). >> > >> > - Because most of you work on 3GHz+ i7 Macbook Pro (so, at 10x the >> cpu >> > performance of that said Celeron). >> > >> > - Because you are not to reproduce the past: that your current >> tools are >> > slow is no excuse. >> > >> > - Because you now have well designed core widgets (FT) that behaves >> in >> > O(1) and opens fully loaded in 10's of milliseconds >> > >> > So, profile and clean your code! Eliminate unneeded caches! Clean >> your >> > architectures! Avoid or mark slow code and bottlenecks! >> > >> > And bring numbers when you want to criticize the performance of a >> > subsystem... >> > >> > Thierry >> > >> >> >> >

Nov. 22, 2015