February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Nautilus groups

by Thierry Goubier

Hi Christophe, I do use groups a lot but not in Nautilus ;) Groups I use: package, class, hierarchy. More rarely: recent packages. Would I use groups in Nautilus the way the GUI is done? Probably not as much. Scoped browsing is harder to reach, scoped browser happens in the same browser and doesn't open a new one. Would I use groups if they require me to flag something per class? No, not worth the hassle. Do I know what is the benefit of groups in Nautilus? No, it's unclear. Groups do not seem to bring any benefit. Example : - Switched to group Last Modified Classes - searched implementors of #type: - expected list of implementors of #type in last modified classes - got implementors of #type in the whole world - Fail :( Thierry 2015-02-10 14:26 GMT+01:00 Christophe Demarey <christophe.demarey(a)inria.fr>: > Hello, > > We would like to know if some of you use Nautilus groups functionality: > > - dynamic groups: 'Last modified packages', 'Most viewed classes', > 'Work' > - user defined groups : from the menu, you can flatten the content of > many packages and get all classes into the newly created group. > > We have the feeling that it is not used (or not a lot) and we think to > replace it with another mechanism (for example, let the user define his/her > 'favorites' classes / packages). > > Thanks for the feedback. >

Feb. 10, 2015

Create a user for jenkins

by Sebastian Tleye

Hi All, I'd like to see some of the jenkins jobs of Pharo to have an idea how they were created, I don't have a user in jenkins and when I want to see the jobs as an anonymous user (read-only) jenkins throws an java.lang.NullPointerException error. How can I create a user? I only need a user to see how the jobs were created, I don't need to create or modify jobs. Thanks! SebastiÃ¡n Tleye

Feb. 10, 2015

[pharo-project/pharo-core]

by GitHub

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

Feb. 10, 2015

[pharo-project/pharo-core] 5c7ba4: 40486

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 5c7ba42c1767d58e962d996de1178faeb92d468f https://github.com/pharo-project/pharo-core/commit/5c7ba42c1767d58e962d996d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-10 (Tue, 10 Feb 2015) Changed paths: M Kernel.package/Delay.class/instance/delaying/waitOtherwise_.st M Kernel.package/Delay.class/instance/private/schedule.st M Kernel.package/DelayScheduler.class/instance/low priority processes/schedule_.st A Kernel.package/ManifestKernel.class/instance/code-critics/ruleConsistencyCheckRuleV1FalsePositive.st M KernelTests.package/ClassTest.class/instance/testing/testClassRespectsPolymorphismWithTrait.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/private-class var/privateAddClassVarFrom_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script486.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40486.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/SlotClassBuilder.class/instance/initialize-release/buildNewClass.st Log Message: ----------- 40486 14904 Slot: hand the correct class to slot in #buildNewClass https://pharo.fogbugz.com/f/cases/14904 14899 add addSlot in testClassRespectsPolymorphismWithTrait https://pharo.fogbugz.com/f/cases/14899 14874 WorldState>>#interCyclePause: failed https://pharo.fogbugz.com/f/cases/14874 14895 Class Variable Refactoring -> Add produce error when pressing escape on dialog https://pharo.fogbugz.com/f/cases/14895 http://files.pharo.org/image/40/40486.zip

Feb. 10, 2015

Nautilus groups

by Christophe Demarey

Hello, We would like to know if some of you use Nautilus groups functionality: dynamic groups: 'Last modified packages', 'Most viewed classes', 'Work' user defined groups : from the menu, you can flatten the content of many packages and get all classes into the newly created group. We have the feeling that it is not used (or not a lot) and we think to replace it with another mechanism (for example, let the user define his/her 'favorites' classes / packages). Thanks for the feedback.

Feb. 10, 2015

Running some code at fogbugz CI

by Pablo Herrero

Hello, I had this patch (for issue 11992) for a while now at the bug system. The problem I'm having is that in order to to run the test suite properly I need to run some code before merging the slice and then just before running the test suite. And as a consequence, I'm not notified whenever some other patch that gets integrated breaks my code. I have read that you can use metacello to configure post and preLoad hooks for a project. I'm not sure if this could work for the fogbugz CI, also since you need to add a class in order to use metacello it would probably get integrated into the image which is not what I intend. Is there then some easy way so run some code before the CI merges the patch and just before the test suite runs?. PS1: Sorry is the answer for this turns out being pretty obvious, I'm not that familiar with metacello. PS2: The issue haven't receive a lot of attention probably because it's been at 'Work Needed' state since forever, maybe it would help if the test suite passes. PS3: Here's a link to the issue https://pharo.fogbugz.com/f/cases/11992/Remove-tokens-from-the-AST-Core-Nod… . Thanks, Pablo

Feb. 10, 2015

Re: [Pharo-dev] TROSMTileProvider

by Sven Van Caekenberghe

> On 10 Feb 2015, at 12:49, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi Sven!! > > I will check this in two days. I am still on holidays :) You should include the 14th in your holiday as well unless you refuse to give in to commercial pressure ;-) > Alexandre > > > >> Le 5 fÃ©vr. 2015 Ã 11:47, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : >> >> Thierry, Onil, >> >> I rounded up my experiments with a 2nd commit on my experimental branch: >> >> === >> Name: Roassal2-SvenVanCaekenberghe.720 >> Author: SvenVanCaekenberghe >> Time: 5 February 2015, 3:40:43.211681 pm >> UUID: 121ffc22-4a30-4153-bef1-e019a92862bc >> Ancestors: Roassal2-SvenVanCaekenberghe.719 >> >> Experimental branch. Second version. >> >> Some more changes after discussing with Thierry @ Pharo Days and hours of experimenting >> >> Added TROSMTileProvider>>#cachedTileNamed: and #memoryCachedTileNamed: >> >> Rewrote/simplified TROSMShape>>#getTile: to no longer fork a 'get tile' process when the tile is cached in memory or on the file system >> >> Removed all hacks trying to optimize the number of times #signalUpdate was called - made no difference. >> >> Tried several logging approaches but that did not reveal anything special. >> >> The observed slowdown for tiles in the file cache but not the memory cache is still there, even though loading about 10 tiles takes less than 40 ms (see #testEmptyMemoryCacheParisLevel7) >> === >> >> >> Summary, it should be faster, but it is not. Forking and network downloading are gone, each of about 10 tiles takes less than 4 ms, the total observed slowdown is still about 1 to 2 seconds - with no extra #signalUpdate. >> >> I don't know why and I don't understand. >> >> I hope somebody can have a look, I feel that we can/should make this better still. >> >> Sven >> >>> On 28 Jan 2015, at 16:58, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>> Hi Sven, >>> >>> Thanks for the work. I'll have a try (if I manage to get the time) and we'll meet tomorrow for sure :) >>> >>> Thierry >>> >>> 2015-01-28 14:43 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> Hi Thierry, Onil, >>> >>> First let me iterate what I wrote last week, the OSM stuff in Roassal is very cool, very well written. Great work. >>> >>> Since I have some experience with OSM maps, tiles and serving them, I had a look to see if I could optimise the tile drawing/loading, which is visibly a bit slow, one would assume because of the loading of the tiles over the network. >>> >>> I just committed (based on code that I wrote some time ago): >>> >>> === >>> Name: Roassal2-SvenVanCaekenberghe.719 >>> Author: SvenVanCaekenberghe >>> Time: 28 January 2015, 2:31:50.462461 pm >>> UUID: 0978fb6a-d6d0-4d86-a9ae-1f2f83a0b6a2 >>> Ancestors: Roassal2-AlexandreBergel.718 >>> >>> Experimental branch. >>> >>> Introduction of TROSMTileProvider to optimize getting OSM tiles, adds one shared memory cache and a local file system cache, predefines and reuses 6 http clients spread over different hosts. >>> >>> Modifies TROSMShape>>#getTile: and adds TROSMShape>>#tileNamed: >>> === >>> >>> The strange thing is though, that I can optimise the loading (as benchmarked separately), but in most cases (not when they are in the memory cache, but when they are in the file cache) the drawing still has the same pauses as before - which I don't understand, at all. But it is a bit hard to explain. >>> >>> Anyway, Thierry, I will see you tomorrow and the day thereafter and I hope I can show you what I mean. >>> >>> Regards, >>> >>> Sven >>> >>> >>> >> >> >

Feb. 10, 2015

Re: [Pharo-dev] TROSMTileProvider

by Alexandre Bergel

Hi Sven!! I will check this in two days. I am still on holidays :) Alexandre > Le 5 fÃ©vr. 2015 Ã 11:47, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > > Thierry, Onil, > > I rounded up my experiments with a 2nd commit on my experimental branch: > > === > Name: Roassal2-SvenVanCaekenberghe.720 > Author: SvenVanCaekenberghe > Time: 5 February 2015, 3:40:43.211681 pm > UUID: 121ffc22-4a30-4153-bef1-e019a92862bc > Ancestors: Roassal2-SvenVanCaekenberghe.719 > > Experimental branch. Second version. > > Some more changes after discussing with Thierry @ Pharo Days and hours of experimenting > > Added TROSMTileProvider>>#cachedTileNamed: and #memoryCachedTileNamed: > > Rewrote/simplified TROSMShape>>#getTile: to no longer fork a 'get tile' process when the tile is cached in memory or on the file system > > Removed all hacks trying to optimize the number of times #signalUpdate was called - made no difference. > > Tried several logging approaches but that did not reveal anything special. > > The observed slowdown for tiles in the file cache but not the memory cache is still there, even though loading about 10 tiles takes less than 40 ms (see #testEmptyMemoryCacheParisLevel7) > === > > > Summary, it should be faster, but it is not. Forking and network downloading are gone, each of about 10 tiles takes less than 4 ms, the total observed slowdown is still about 1 to 2 seconds - with no extra #signalUpdate. > > I don't know why and I don't understand. > > I hope somebody can have a look, I feel that we can/should make this better still. > > Sven > >> On 28 Jan 2015, at 16:58, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Hi Sven, >> >> Thanks for the work. I'll have a try (if I manage to get the time) and we'll meet tomorrow for sure :) >> >> Thierry >> >> 2015-01-28 14:43 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> Hi Thierry, Onil, >> >> First let me iterate what I wrote last week, the OSM stuff in Roassal is very cool, very well written. Great work. >> >> Since I have some experience with OSM maps, tiles and serving them, I had a look to see if I could optimise the tile drawing/loading, which is visibly a bit slow, one would assume because of the loading of the tiles over the network. >> >> I just committed (based on code that I wrote some time ago): >> >> === >> Name: Roassal2-SvenVanCaekenberghe.719 >> Author: SvenVanCaekenberghe >> Time: 28 January 2015, 2:31:50.462461 pm >> UUID: 0978fb6a-d6d0-4d86-a9ae-1f2f83a0b6a2 >> Ancestors: Roassal2-AlexandreBergel.718 >> >> Experimental branch. >> >> Introduction of TROSMTileProvider to optimize getting OSM tiles, adds one shared memory cache and a local file system cache, predefines and reuses 6 http clients spread over different hosts. >> >> Modifies TROSMShape>>#getTile: and adds TROSMShape>>#tileNamed: >> === >> >> The strange thing is though, that I can optimise the loading (as benchmarked separately), but in most cases (not when they are in the memory cache, but when they are in the file cache) the drawing still has the same pauses as before - which I don't understand, at all. But it is a bit hard to explain. >> >> Anyway, Thierry, I will see you tomorrow and the day thereafter and I hope I can show you what I mean. >> >> Regards, >> >> Sven >> >> >> > >

Feb. 10, 2015

Re: [Pharo-dev] Reducing the activity of the image

by Norbert Hartl

> Am 10.02.2015 um 11:23 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> On 10 Feb 2015, at 11:19, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Sven, >> >>> Am 10.02.2015 um 10:36 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>>> >>>> On 10 Feb 2015, at 09:51, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> >>>>> Am 10.02.2015 um 09:23 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>>> >>>>> Hello, >>>>> >>>>> About the Morphic rendering loop, the delay between rendering is handled in WorldState>>#interCyclePause:. The best solution to reduce the cost of the Morphic rendering loop is to put it in server mode by executing in Pharo: WorldState serverMode: true. In squeak you have to set that in the Preferences. >>>>> >>>> I'll play with it and see what can be gained. >>> >>> I tried the following on an otherwise idle DigitalOcean VM running Ubuntu 13.10 >>> >>> $ mkdir pharo4 >>> $ curl get.pharo.org/40+vm | bash >>> $ ./pharo Pharo.image save Server >>> >>> First patch (slower event handling, extra delay of 50ms): >>> >>> $ ./pharo Server.image eval --save 'WorldState serverMode: true' >>> >>> Second patch (give time back to OS while idle for 10ms instead of for 1ms): >>> >>> $ cat ProcessorScheduler-class-idleProcess.st >>> 'From Pharo4.0 of 18 March 2013 [Latest update: #40484] on 10 February 2015 at 9:49:15.412839 am!ProcessorScheduler class methodsFor: 'background process' stamp: 'SvenVanCaekenberghe 2/10/2015idleProc[true] w[self relinquishProcessorForMicroseconds: 10000]! ! >>> >>> $ ./pharo Server.image eval "'ProcessorScheduler-class-idleProcess.st' asFileReference fileIn" >>> $ ./pharo Server.image eval '(ProcessorScheduler class>>#idleProcess) sourceCode' >>> 'idleProcess >>> "A default background process which is invisible." >>> >>> [true] whileTrue: >>> [self relinquishProcessorForMicroseconds: 10000]' >>> >>> Run an image with a basic Zn HTTP server in background: >>> >>> $ ./pharo Server.image eval --no-quit 'ZnServer startDefaultOn: 1701' & >>> $ curl http://localhost:1701 >>> >>> Overall load is 0.01% but this is virtual/shared hardware, so who knows. >>> >>> CPU load of the pharo process hovers around a couple of %, I am not seeing much difference, maybe it is a bit lower, but that might be wishful thinking. >>> >> my findings are similar. I have a CPU usage of 6%. WorldState serverMode adds a Delay for 50ms. Setting a higher number in the idle process does not seem to have any effect until the number is too high, then the image does not start anymore. >> I tuned all of these things and it is not faster sometimes it appears to take more CPU which probably is not true. > > I am afraid that we as a community do not fully understand what is happening or how we can control it. > > On the other hand, on a machine with many images running, things are still totally fine, so we should not worry too much. It is only in specific case like yours where it becomes a concern. > I can say that pharo-vm-nox --noevents --nohandlers --notimer --headless -vm-sound-null /opt/nted/image/NTed.image --no-quit eval "RFBServer stop; reset. ZnServer managedServers do: #stop. UIManager default uiProcess suspend. WorldState serverMode: true. ProcessorScheduler class compile: 'idleProcess',String cr,'[true] whileTrue: [self relinquishProcessorForMicroseconds: 10000]'. ProcessorScheduler startUp" does not make a difference at all. My assumption here is to switch everything off, don't use sockets, try to sleep as much as possible. Butâ¦.nothing. Norbert >> >>>>> But as it was discussed, the cpu consumption most probably does not come from Morphic but comes from the idle loop, which can be solved by doing an event-driven VM. >>>>> >>>>> I am particularly willing to have an event-driven VM because it then means that the VM performance would then be directly proportional to the cpu consumption. For example, theoretically, with an event-driven VM, having the VM twice faster with Spur would also mean that the VM consumes twice less energy. Go Green IT :-) >>>>> >>>> That is exactly my point. While consumed energy is turned into heat the act of saving energy is the same as having a cool device (pun intended). >>>> >>>> So I would like to take my consortium hat to state my upvote on this. >>>> >>>> Norbert >>>> >>>>> 2015-02-10 8:00 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>> >>>>> >>>>> >>>>> On Feb 9, 2015, at 10:41 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>>> >>>>>>> On 10 Feb 2015, at 01:55, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi Sven, >>>>>>> >>>>>>> On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>> There is some timer thread between the image and the vm that ticks every millisecond, that is the cause. I don't know what it does but it is apparently needed. >>>>>>> >>>>>>> Anyway, that is how I understood it from Igor and Eliot, long ago. >>>>>>> >>>>>>> So basically, the VM is always slightly busy. >>>>>>> >>>>>>> Yet the VM is always slightly busy with the heartbeat thread, but this is very cheap. The actual idle cost comes form the idle loop in the background process that sends relinquishProcessorForMicroseconds:, which is a primitive that eventually calls the select system call. This is the source of the cost. >>>>>> >>>>>> Can we change something about that ? >>>>>> Maybe just as an experiment to prove your point ? >>>>> >>>>> What do you think halving or doubling the argument to relinquishProcessorForMicroseconds: should do if this is the major source of overhead? Processor usage at idle should be closely inversely proportional right? >>>>> >>>>>> >>>>>>>> On 09 Feb 2015, at 21:11, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>>>>> >>>>>>>> I have an installation where a pharo powered hardware is used in a closed case. Over time that collects quite some heat. One reason for this is that the pharo vm is taking approx. 6% CPU all the time. The only thing that happens is network/sockets. I suspended the ui thread in the image but on this platform it doesn't help. >>>>>>>> Are there any tweaks to lower the polling and the activity of the image/vm even more? >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Norbert >>>>>>> -- >>>>>>> best, >>>>>>> Eliot

Feb. 10, 2015

Re: [Pharo-dev] get.pharo.org/travis+vm failing: Package 'pharo-vm-core:i386' has no installation candidate

by Markus Fritsche

On 09.02.2015 19:07, Dale Henrichs wrote: > Thanks Norbert, > > Is there a way that you can update the zero-conf script > (http://get.pharo.org/travis) with the proper incantation? > > I really would rather not have to reinvent the zero conf system for > pharo, unless the whole zero conf system is being deprecated ... I > haven't googled that yet ... > > Something changed in the last 5 days and I don't imagine that it is a > missing `sudo dpkg --add-architecture i386` that changed ... unless > someone removed that line from the zero conf script ... Hmm, I uploaded my first updated VM to stable instead of unstable. Everything seemed to work fine on my end, but I guess not. DOH! I'll look into that tonight after work, sorry for the inconvenience :/

Feb. 10, 2015