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

Re: [Pharo-dev] Code Completion in Pharo

by webwarrior

One thing that is broken in current code completion and needs to be addressed is when you try to edit keyword messages. For example you have: dict at: #foo and you want to add ifAbsent: part. Current implementation won't help you, because it works out of context and doesn't recognize the whole selector. Same when you want to edit any part of keyword message. I'd like to see code completion operating on message send level, not on word (token?) level. Is it clear what I'm trying to say? -- View this message in context: http://forum.world.st/Code-Completion-in-Pharo-tp4934313p4937296.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 4, 2017

Re: [Pharo-dev] Spotter idea - bring existing code windows to front

by phil＠highoctane.be

I made a little experiment to get the windows listed in spotter. [image: Inline image 1] I have still an issue with the activation and some weird windows listed but should be able to give you just that in a couple hours. This is a good opportunity for me to jump into spotter extensions, thx for the nudge :-) Phil On Sat, Mar 4, 2017 at 4:19 PM, Ben Coman <btc(a)openinworld.com> wrote: > A quick note on an idea that strikes me, > I often find myself with a large number of windows open and I know I have > a code window open previously but the task bar is a bit opaque to find it, > and its so cheap to open a new code window from Spotter, thats what I do, > and open yet another window, making it harder again to find any particular > window. > You can see the downward spiral here. > > So apart from more discipline is managing the number of windows I have open > a passing idea is that for if an existing code window is open, Spotter > brings that to the front rather than opening another window. Optionally, > if that code window is dirty, as well as bringing it to the front a fresh > code window be opened as well, so that the two are immediately comparable. > > cheers -ben >

March 4, 2017

Re: [Pharo-dev] Seamless integration with GTInspector

by Andrei Chis

Hi Denis, Thanks for the clarification. Then it's good as Seamless will not be impacted by this. Let me if/when you start looking making GTInspector in Seamless use FastTable. I think I'll still add a tiny cache so that the string representation is not recomputed every time. Cheers, Andrei On Sat, Mar 4, 2017 at 6:07 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Andrei > > I already adopted Seamless to changes in GTInspector. So everything works > well. > For now I do not follow your fast table solution. Remote and local > presentations are implemented with old approach. I just copied few methods > from old GT version to make it work. > So it works same way as before and compatible with Pharo 5. > In future I will reuse new fast table approach. > > Thank's for thinking about it :) > > > 2017-03-04 17:48 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > >> Hi Denis, >> >> Can you try Seamless with GTInspector in the latest version of Pharo or >> Moose and let me know if you see any slowness. Not sure how Seamless uses >> GTInspector to inspect proxy objects but now as the inspector uses >> FastTable by default there is no cache whatsoever. What this means is that >> the string representation shown in a FastTable presentation is recomputed >> every time fast table needs to display an element in a row or column. For >> example, this is the case when you scroll or when you resize the window >> (all visible elements are recomputed). >> >> In a local context the inspector is still very fast as it is. Just we >> should double check that it's also the case for Seamless. If not there are >> some caches that could be put into place relatively easy, either at the >> level of the inspector or fast table. Just before doing this I'd like to >> know if this is actually a problem. >> >> Cheers, >> Andrei >> > >

March 4, 2017

Re: [Pharo-dev] Seamless integration with GTInspector

by Denis Kudriashov

Hi Andrei I already adopted Seamless to changes in GTInspector. So everything works well. For now I do not follow your fast table solution. Remote and local presentations are implemented with old approach. I just copied few methods from old GT version to make it work. So it works same way as before and compatible with Pharo 5. In future I will reuse new fast table approach. Thank's for thinking about it :) 2017-03-04 17:48 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > Hi Denis, > > Can you try Seamless with GTInspector in the latest version of Pharo or > Moose and let me know if you see any slowness. Not sure how Seamless uses > GTInspector to inspect proxy objects but now as the inspector uses > FastTable by default there is no cache whatsoever. What this means is that > the string representation shown in a FastTable presentation is recomputed > every time fast table needs to display an element in a row or column. For > example, this is the case when you scroll or when you resize the window > (all visible elements are recomputed). > > In a local context the inspector is still very fast as it is. Just we > should double check that it's also the case for Seamless. If not there are > some caches that could be put into place relatively easy, either at the > level of the inspector or fast table. Just before doing this I'd like to > know if this is actually a problem. > > Cheers, > Andrei >

March 4, 2017

Seamless integration with GTInspector

by Andrei Chis

Hi Denis, Can you try Seamless with GTInspector in the latest version of Pharo or Moose and let me know if you see any slowness. Not sure how Seamless uses GTInspector to inspect proxy objects but now as the inspector uses FastTable by default there is no cache whatsoever. What this means is that the string representation shown in a FastTable presentation is recomputed every time fast table needs to display an element in a row or column. For example, this is the case when you scroll or when you resize the window (all visible elements are recomputed). In a local context the inspector is still very fast as it is. Just we should double check that it's also the case for Seamless. If not there are some caches that could be put into place relatively easy, either at the level of the inspector or fast table. Just before doing this I'd like to know if this is actually a problem. Cheers, Andrei

March 4, 2017

Spotter idea - bring existing code windows to front

by Ben Coman

A quick note on an idea that strikes me, I often find myself with a large number of windows open and I know I have a code window open previously but the task bar is a bit opaque to find it, and its so cheap to open a new code window from Spotter, thats what I do, and open yet another window, making it harder again to find any particular window. You can see the downward spiral here. So apart from more discipline is managing the number of windows I have open a passing idea is that for if an existing code window is open, Spotter brings that to the front rather than opening another window. Optionally, if that code window is dirty, as well as bringing it to the front a fresh code window be opened as well, so that the two are immediately comparable. cheers -ben

March 4, 2017

Re: [Pharo-dev] Growing large images: the case of Moose models

by stepharong

tx clement this is indeed really important On Fri, 03 Mar 2017 11:56:05 +0100, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello everyone, > > This morning I investigated with Vincent Blondeau a problem reported by > the Moose community a while ago: loading Moose model is slower in Spur > (Pharo 5+) than in pre-Spur (Pharo 4 and >older). In general, this > problem was present for anyone growing images to a significant size. > > To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb > image, growing the image to 450Mb. Loading such a model takes 2 minutes > in Spur and 1m30s in pre-Spur VMs. > > Using the stable Pharo VM, the analysis results were the following: > - total time spent to load the Model: 2 minutes > - time spent in full GC: 1 minute (4 fullGCs) > - time spent in scavenges[1]: 15 seconds > On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% > in scavenges, 37.5% executing code. > > We then used the latest VM that features the new compactor (VM from > beginning of March 2017 and over). The full GC execution time went down > from 1 minute to 2 seconds. > > In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time > spent in scavenges decreased from 15 seconds to 5 seconds. > > Overall, loading the model is now taking ~50 seconds instead of 2 > minutes. > > To increase Eden size, one needs to run a script similar to: > > | currentEdenSize desiredEdenSize | > currentEdenSize := Smalltalk vm parameterAt: 44. > desiredEdenSize := currentEdenSize * 4. > Smalltalk vm parameterAt: 45 put: desiredEdenSize. > > And then restart the image. > > I hope this report can be useful for some of you. I will try to make a > blog post out of it, detailing other GC settings one can change from the > image to improve performance. > >> Best, > > Clement > > [1] A scavenge is basically the garbage collection of only young objects > [2] Eden is basically the space where objects are initially allocated. > [3] All numbers in the report are order of magnitudes and not precise > numbers > > > -- Using Opera's mail client: http://www.opera.com/mail/

March 4, 2017

Re: [Pharo-dev] [Pharo6] [Issue Tracker] Current Status

by stepharong

excellent! Tx to all the sprinters Stef On Sat, 04 Mar 2017 09:24:58 +0100, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> On 3 Mar 2017, at 09:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> The current status is: >> >> Issues Tagged Pharo6: 52 >> Overall: 598 >> > > Post Sprint: > > Issues Tagged Pharo6: 26 > Issues Overall: 585 > > Issues closed lat 7 days: 66 > > Good progress! > > Marcus > -- Using Opera's mail client: http://www.opera.com/mail/

March 4, 2017

Re: [Pharo-dev] [Pharo6] [Issue Tracker] Current Status

by Marcus Denker

> On 3 Mar 2017, at 09:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > The current status is: > > Issues Tagged Pharo6: 52 > Overall: 598 > Post Sprint: Issues Tagged Pharo6: 26 Issues Overall: 585 Issues closed lat 7 days: 66 Good progress! Marcus

March 4, 2017

Re: [Pharo-dev] Really amazing bug (or feature) with compiling some ifTrue expressions

by Martin McClure

On 03/03/2017 01:28 PM, ClÃ©ment Bera wrote: > Such bytecode optimisation should be postponed to runtime (Cogit, Sista) > and not be performed by Opal. We did not know that when we wrote Opal. > We may want to fix this. > +1. Actually, plus an indeterminate quantity, but a bunch. -Martin

March 3, 2017