June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] R: [Tutorial] Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator

by Sven Van Caekenberghe

On 27 Jun 2014, at 14:07, Facundo Vozzi <facundov79(a)gmail.com> wrote: > On Fri, Jun 27, 2014 at 3:33 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 27 Jun 2014, at 01:21, Facundo Vozzi <facundov79(a)gmail.com> wrote: > > > Incredible Work! > > You're welcome. > > > Thanks for sharing, > > FV > > > > p.s.: I used one HP-35 at school from my father. I love the RPN method when I understood it :-) > > You are actually the first real person that I heard of that used one ! Cool. > > I got it from the "computation" bussines of my grandfather. It was new on the box, together with a lot of old stuff. The problem were the batteries, I had to adapt another batteries to it. Yeah, I believe most people put it on a power supply now. > I don't where is it now. Too bad, it is worth a lot of money today ;-)

June 27, 2014

GUI question

by Goubier Thierry

Hi all, is there a rationale for the world menu on left mouse button only in Pharo 4? (and world contents on the right mouse button) Mine would be: - if I press a pull down menu (press a menu bar item or a pull down menu), it's the left mouse button. - If I look for a menu on a non-button thing, it's the right mouse button, i.e. contextual menu. Now, should I consider that the Pharo background is a huge pull-down menu button to understand the rationale behind having the world menu on the left-mouse button? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2014

[pharo-project/pharo-core] af0c62: 40049

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: af0c62731c255f8d7b1a5520b77c6f9b9cadb3e7 https://github.com/pharo-project/pharo-core/commit/af0c62731c255f8d7b1a5520… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-27 (Fri, 27 Jun 2014) Changed paths: R MonticelloGUI.package/extension/ChangeList/class/recentLogOn_startingFrom_.st R MonticelloGUI.package/extension/ChangeList/class/recent_on_.st R MonticelloGUI.package/extension/ChangeList/instance/changeTo_.st R NautilusCommon.package/AnnotationRequest.class/instance/requests/priorTimeStamp.st M NautilusCommon.package/AnnotationRequest.class/instance/requests/priorVersionsCount.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script49.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40049.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Tools.package/ChangeList.class/instance/accessing/setLostMethodPointer_.st M Tools.package/CodeHolder.class/instance/annotation/addPriorVersionsCountForSelector_ofClass_to_.st M Tools.package/CodeHolder.class/instance/annotation/annotationForSelector_ofClass_.st M Tools.package/VersionsBrowser.class/class/instance creation/browseVersionsOf_class_meta_category_selector_.st R Tools.package/VersionsBrowser.class/class/instance creation/browseVersionsOf_class_meta_category_selector_lostMethodPointer_.st R Tools.package/VersionsBrowser.class/class/instance creation/timeStampFor_class_reverseOrdinal_.st R Tools.package/VersionsBrowser.class/class/instance creation/versionCountForSelector_class_.st Log Message: ----------- 40049 13424 Clean up #priorTimeStamp https://pharo.fogbugz.com/f/cases/13424 13423 VersionBrowser>>#versionCountForSelector:class: not needed https://pharo.fogbugz.com/f/cases/13423 http://files.pharo.org/image/40/40049.zip

June 27, 2014

[pharo-project/pharo-core]

by GitHub

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

June 27, 2014

Re: [Pharo-dev] Improving Pharo By Example

by kilon alios

finished Chapter 4. Damien your automatic conversion tool worked very well for me, it has been a huge boost to my workflow, there are problems with it that I keep reporting to its github repo . I definitely see if these minor problems are removed that the automatic conversion will do 90% of the work for you. I am sure these problems will be fixed very soon. The things not converted at all like tables etc, which you find hard to parse , its not really a big deal fortunately there are not that many of them. So its not a problem to do them manually. I also love Pillar , its simple, elegant and very easy to use for anyone that wants to produce pdf and html documentation. I would say that your Pillar experiment has been a huge success and I hope one day we will see it also included inside Pharo as on board documentation tool instead of a command line tool only. In 2 months time I have managed to port 30% of the PBE to Pillar and I also added new stuff and replaced images with latest look from Pharo 3. Now with the automatic conversion its should be fairly easy to do the rest 70% till the end of the year. On Thu, Jun 19, 2014 at 10:19 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Yes I have not been doing that because I was lazy and struggling with the > Pier syntax, but now I have learned good enough I will do it the way you > say from now on. > > > On Thu, Jun 19, 2014 at 4:48 PM, Damien Cassou <damien.cassou(a)gmail.com> > wrote: > >> >> On Thu, Jun 19, 2014 at 3:39 PM, kilon alios <kilon.alios(a)gmail.com> >> wrote: >> >>> ok I leave it to your capable hands and I will try to position images at >>> the start of the page , though that is easier said than done :D >>> >> >> >> no! Don't do anything like that. LaTeX is capable of doing it by itself. >> You don't know where the page boundaries will be so it is hopeless for you >> :-). What you must ensure though, is that all figures are properly >> referenced in the text. This is a good example: >> >> ... bla... bla... see Figure *fig:myfig*. >> >> This is a bad example: >> >> ... bla... bla... see figure below: >> >> This is bad because you can't be sure the figure will be below (it can >> also be above, LaTeX decides). >> >> >> >>> In any case chapters need proof reading so what I commit should never >>> consider "the final version". But I always try to produce as much quality >>> as I can. >>> >> >> >> No problem. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without losing >> enthusiasm." >> Winston Churchill >> > >

June 27, 2014

Re: [Pharo-dev] R: [Tutorial] Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator

by Facundo Vozzi

On Fri, Jun 27, 2014 at 3:33 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 27 Jun 2014, at 01:21, Facundo Vozzi <facundov79(a)gmail.com> wrote: > > > Incredible Work! > > You're welcome. > > > Thanks for sharing, > > FV > > > > p.s.: I used one HP-35 at school from my father. I love the RPN method > when I understood it :-) > > You are actually the first real person that I heard of that used one ! > Cool. I got it from the "computation" bussines of my grandfather. It was new on the box, together with a lot of old stuff. The problem were the batteries, I had to adapt another batteries to it. I don't where is it now.

June 27, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Goubier Thierry

Le 27/06/2014 13:02, Goubier Thierry a Ã©crit : > Ok then, a simple profile should do it. Sort of, it doesn't show up that clearly. > I'll have a look. It seems to depend on the Nautilus window state. If you've just opened it, then nothing seems to be amiss. If you start to select things in it, you start to see time spent in updateClassView, but why? > I did profile loading Roassal2 with AltBrowser yesterday evening and > updates on the browser take 15% of the execution time... Will optimize > that. Went from 15% to 2~3% of Roassal2 loading time :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Goubier Thierry

Ok then, a simple profile should do it. I'll have a look. I did profile loading Roassal2 with AltBrowser yesterday evening and updates on the browser take 15% of the execution time... Will optimize that. Thierry Le 27/06/2014 11:58, phil(a)highoctane.be a Ã©crit : > Same story here. > Loading with browsers closed leads to a 10x faster load. > > Phil > > Le 27 juin 2014 10:31, "Johan Brichau" <johan(a)inceptive.be > <mailto:johan@inceptive.be>> a Ã©crit : > > > > I reported it as bug 13422 [1]. > > > > For now, I was only able to do a comparison before/after which > instances are being kept around. > > > > Johan > > > > [1] https://pharo.fogbugz.com/default.asp?13422#104139 > > > > On 26 Jun 2014, at 16:33, Johan Brichau <johan(a)inceptive.be > <mailto:johan@inceptive.be>> wrote: > > > > > Nicolai, > > > > > > It's not a public configuration and it loads quite some packages. > > > I will pick up this issue this evening to get a better reproducible > case. > > > > > > thx > > > Johan > > > > > > On 26 Jun 2014, at 16:03, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > > > > >> 2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>>: > > >> > > >> > > >> Le 26/06/2014 15:25, Sven Van Caekenberghe a Ã©crit : > > >> > > >> > > >> On 26 Jun 2014, at 15:17, Johan Brichau <johan(a)inceptive.be > <mailto:johan@inceptive.be>> wrote: > > >> > > >> I will do that, but the main problem is not the loading speed. > > >> The real problem is that the image blows up (i.e. crashes) when a > browser is open because it runs out of memory. > > >> > > >> But yes, I will make a ticket and get some more profiling with > that so we can fix it. > > >> Right now, I have to tell my co-workers to close all browsers when > they do a full code load interactively... it works but it's a bit > ridiculous ;-) > > >> > > >> I disagree a bit ;-) > > >> > > >> Like Thierry said before: we all expect open browsers to react to > anything that happens, so when you load a very large amount of code, > lots of things change and I can imagine the internal notifications > (announcements) overloading the browsers who are struggling to keep up. > > >> > > >> This means something can be optimized in the browser... Browsers > have a very limited view on the underlying code, more or less a subset > of a class methods and their relation in higher stuff, such as the > package, which means loading a large body of code has little effect on > the Browser (unless it's a live CodeCity instance :)). > > >> > > >> > > >> Now, there is probably something wrong, and things can probably be > tuned, but I think this will always be slower. > > >> > > >> Not by much. > > >> > > >> > > >> Like StÃ©phane said, loading a big batch of code should happen in a > special way, disabling updates and firing a full reset at the end - or > something along those lines. > > >> > > >> I disagree with you there. > > >> > > >> Disabling updates causes problems in many different places > (RPackage, for one) and correct implementation of the Browser updates > should not slow it down significantly. And it allow us, in the future, > to have a responsive GUI while loading code. > > >> > > >> I know because after optimising it, it went from very visible to > being almost invisible on the profile (far below the time spent #pragma > updating). > > >> > > >> Thierry > > >> > > >> -- > > >> Thierry Goubier > > >> CEA list > > >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > > >> 91191 Gif sur Yvette Cedex > > >> France > > >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > >> > > >> > > >> > > >> I can not reproduce this, neither the crash nor the image memory > blow up. > > >> I tested several ConfigurationOfXXX, with one or more open Browsers. > > >> > > >> Can you tell me what Configuration you are trying to load and if > this is a fresh pharo image or > > >> are there any other packages loaded. > > >> And do you have any Nautilus plugins enabled? > > >> > > >> regards > > >> Nicolai > > > > > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by phil＠highoctane.be

Same story here. Loading with browsers closed leads to a 10x faster load. Phil Le 27 juin 2014 10:31, "Johan Brichau" <johan(a)inceptive.be> a Ã©crit : > > I reported it as bug 13422 [1]. > > For now, I was only able to do a comparison before/after which instances are being kept around. > > Johan > > [1] https://pharo.fogbugz.com/default.asp?13422#104139 > > On 26 Jun 2014, at 16:33, Johan Brichau <johan(a)inceptive.be> wrote: > > > Nicolai, > > > > It's not a public configuration and it loads quite some packages. > > I will pick up this issue this evening to get a better reproducible case. > > > > thx > > Johan > > > > On 26 Jun 2014, at 16:03, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > >> 2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goubier(a)cea.fr>: > >> > >> > >> Le 26/06/2014 15:25, Sven Van Caekenberghe a Ã©crit : > >> > >> > >> On 26 Jun 2014, at 15:17, Johan Brichau <johan(a)inceptive.be> wrote: > >> > >> I will do that, but the main problem is not the loading speed. > >> The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory. > >> > >> But yes, I will make a ticket and get some more profiling with that so we can fix it. > >> Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-) > >> > >> I disagree a bit ;-) > >> > >> Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up. > >> > >> This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)). > >> > >> > >> Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower. > >> > >> Not by much. > >> > >> > >> Like StÃ©phane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines. > >> > >> I disagree with you there. > >> > >> Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code. > >> > >> I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating). > >> > >> Thierry > >> > >> -- > >> Thierry Goubier > >> CEA list > >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > >> 91191 Gif sur Yvette Cedex > >> France > >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >> > >> > >> > >> I can not reproduce this, neither the crash nor the image memory blow up. > >> I tested several ConfigurationOfXXX, with one or more open Browsers. > >> > >> Can you tell me what Configuration you are trying to load and if this is a fresh pharo image or > >> are there any other packages loaded. > >> And do you have any Nautilus plugins enabled? > >> > >> regards > >> Nicolai > > > >

June 27, 2014

Spec TreeModel

by Yuriy Tymchuk

Hi, Iâd like to improve the TreeModel of Spec, but I need some help. Fist of all UI breaks when different theme is used: When you deselect checkbox and at that moment item is not highlighted. This happens when checkbox is clicked, the item is not highlighted and so itâs original color is not stored, but when you uncheck item it IS unhighlighted for some reason, and as default color is not stored, black one is used. First of all we can replace black color by theme color, and also I think that we should handle checkbox and list clicks in a separate manner. Now the other thing is related. I can turn on checkbox, but can I turn off the list selection? Are the selected items distinguished is any way, or all items with checked checkboxes and highlights merged into one list? Uko

June 27, 2014