- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Ann] Calypso is moved to github

by Thierry Goubier

2017-07-28 16:11 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > >> But I understand what you are talking about. So it will be >>> pre-refactoring on current scope (full image by default). >>> And change browser will allow choose different scope which will >>> reevaluate refactoring again and update shown changes. >> >> > Understood. Will enlarging the original scope be possible? > > > Yes. > When new method browser is spawned it includes all scopes of original > browser. > If you spawn senders from class references which are restricted by package > then new browser will show senders in scope of this package. But it will > also include all scopes of original browser in scopes list. So you are > always able switch to full image or other scope which you are used in other > "parent windows". > I'll be interested by first impressions (first few times trying it) / expert impressions (once comfortable working with it) with this feature. Who has already switched to Calypso as it's main / only system browser? Regards, Thierry

July 28, 2017

Re: [Pharo-dev] [Ann] Calypso is moved to github

by Denis Kudriashov

> But I understand what you are talking about. So it will be pre-refactoring >> on current scope (full image by default). >> And change browser will allow choose different scope which will >> reevaluate refactoring again and update shown changes. > > Understood. Will enlarging the original scope be possible? Yes. When new method browser is spawned it includes all scopes of original browser. If you spawn senders from class references which are restricted by package then new browser will show senders in scope of this package. But it will also include all scopes of original browser in scopes list. So you are always able switch to full image or other scope which you are used in other "parent windows".

July 28, 2017

Re: [Pharo-dev] [Ann] Calypso is moved to github

by Thierry Goubier

Hi Denis, 2017-07-28 15:29 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi Thierry > > 2017-07-28 15:01 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Hi Denis, >> >> So it's post-refactoring that you scope, not pre-refactoring? >> >> post-refactoring: refactor, then restrict (scope) to what it is applied >> pre-refactoring: restrict (scope) first, then refactor, then apply >> >> > Post/pre distinction looks strange because they both not change anything > in image. > They do change the way you plan your tasks, as a user. > But I understand what you are talking about. So it will be pre-refactoring > on current scope (full image by default). > And change browser will allow choose different scope which will reevaluate > refactoring again and update shown changes. > Understood. Will enlarging the original scope be possible? Regards, Thierry > > >> Or would both be available? >> >> Thierry >> >> 2017-07-28 14:43 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> I like the scoped refactoring :). >>> >>> >>> I hope it was clear that it is in todo. I just shared idea how it will >>> be done. >>> >> >> >

July 28, 2017

Re: [Pharo-dev] [Ann] Calypso is moved to github

by Denis Kudriashov

Hi Thierry 2017-07-28 15:01 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Denis, > > So it's post-refactoring that you scope, not pre-refactoring? > > post-refactoring: refactor, then restrict (scope) to what it is applied > pre-refactoring: restrict (scope) first, then refactor, then apply > > Post/pre distinction looks strange because they both not change anything in image. But I understand what you are talking about. So it will be pre-refactoring on current scope (full image by default). And change browser will allow choose different scope which will reevaluate refactoring again and update shown changes. > Or would both be available? > > Thierry > > 2017-07-28 14:43 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> I like the scoped refactoring :). >> >> >> I hope it was clear that it is in todo. I just shared idea how it will be >> done. >> > >

July 28, 2017

Re: [Pharo-dev] WorkingSession log

by phil＠highoctane.be

If my Seaside app is generating graphics (it is) using FT2 fonts, well, I cannot escape this... Phil On Fri, Jul 28, 2017 at 11:37 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2017-07-28 10:26 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> >> On 28 Jul 2017, at 10:15, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> 6ms startup:true a ClassSessionHandler(ExternalObject) >> >> >> Most time here is taken by ExternalAddress startUp logic: >> >> ExternalAddress>>startUp: resuming >> >> ... >> >> instances := self allInstances. >> >> wordSize ~= Smalltalk wordSize >> ifTrue: "Implement nulling by becomming all existing instances to new >> (and hence null) pointers of the right size." >> [wordSize := Smalltalk wordSize. >> instances elementsForwardIdentityTo: (instances collect: [:ea| self >> basicNew: wordSize])] >> ifFalse: >> [instances do: [:addr| addr beNull]]] >> >> >> It scans all instances which is very expensive. And I thing it can lead >> to much more time in bigger images. >> Maybe we can perform this cleanup at "prepare for production" script and >> add special flag in image that all externals are already clean. >> >> >> Sorry but no :) >> > This will lead to all kind of pain since a lot of functionality depends on >> that. I played with moving the clean up to shutdown instead (which would be >> a better approach) but there were also problems. >> If you want to play in that sense, is cool. But ExternalAddress needs to >> be cleaned and each new session needs to be started and find instances of >> EA nulled. >> > > Imaging that I deploy Seaside application. Why my image should spend time > for this useless check while fast server startup is very important? > I understand that current logic simplifies a lot of things when we do > development with many image saves. But production image can be safe enough > for such kind optimization. > > >> >> Esteban >> >> >> >> 2017-07-27 14:49 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> Hi, >>> >>> I instrumented WorkingSession with a log collection that holds timing >>> info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. >>> Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. >>> they were faster than 1ms). Here is the list of the non zero ones: >>> >>> 1ms startup:true a ClassSessionHandler(ProcessorScheduler) >>> 1ms startup:true a ClassSessionHandler(OSPlatform) >>> 6ms startup:true a ClassSessionHandler(ExternalObject) >>> 1ms startup:true a ClassSessionHandler(DiskStore) >>> 5ms startup:true a ClassSessionHandler(SmalltalkImage) >>> 9ms startup:true a ClassSessionHandler(DisplayScreen) >>> 1ms startup:true a ClassSessionHandler(Cursor) >>> 41ms startup:true a ClassSessionHandler(FT2Handle) >>> 238ms startup:true a ClassSessionHandler(FreeTypeSettings) >>> 1ms startup:true a ClassSessionHandler(WorldMorph) >>> 14ms startup:true a ClassSessionHandler(OmSessionStore) >>> >>> For a total of 318ms >>> >>> I think being able to inspect the WorkingSession and see this list >>> (ordered, with timing info) would be generally useful (and low cost). Even >>> headless, we could access the list using eval. >>> >>> Sven >>> >>> PS: The code of SessionManager/WorkingSession was very readable, well >>> done Christophe ! >>> >>> >>> >>> >>> >> >

July 28, 2017

Re: [Pharo-dev] [Ann] Calypso is moved to github

by Thierry Goubier

Hi Denis, So it's post-refactoring that you scope, not pre-refactoring? post-refactoring: refactor, then restrict (scope) to what it is applied pre-refactoring: restrict (scope) first, then refactor, then apply Or would both be available? Thierry 2017-07-28 14:43 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I like the scoped refactoring :). > > > I hope it was clear that it is in todo. I just shared idea how it will be > done. >

July 28, 2017

Re: [Pharo-dev] [ANN] Mustache moved to github

by Peter Uhnak

ConfigurationOf still remains (for the time-being), however now you don't have to specify what packages and their commits to load for each version. Instead you point to a Baseline with a specific version. E.g. https://github.com/peteruhnak/IconFactory/tree/master/repository/Configurat… the syntax for the repo is 'github://<user>/<project>:<branch name or commit id or tag id>/<optional subfolder where the packages are>' (the branch is optional, and if ommitted the latest commit of the master branch will be used) Peter On Fri, Jul 28, 2017 at 02:48:08PM +0200, Denis Kudriashov wrote: > In my projects I defined configuration with single stable which points to > baseline master: > > stable: spec > <symbolicVersion: #stable>. > spec for: #'pharo' version: 'master' > > master: spec > <version: 'master'> > spec for: #pharo do: [ > spec > baseline: 'Mustache' > with: [ spec repository: 'github://noha/mustache' ]; > import: 'Mustache' ] > > And I am supposed that master will be always stable. > > 2017-07-28 14:13 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > > I don't know how. I must say that it is not clear to me what to do. Do I > > need a configuration? Do I still need to put it in Metarepo? > > > > Norbert > > > > > > > Am 28.07.2017 um 14:06 schrieb Stephane Ducasse <stepharo.self(a)gmail.com > > >: > > > > > > Hi norbert > > > > > > did you update the catalog entry? > > > > > > Stef > > > > > > On Fri, Jul 28, 2017 at 12:40 PM, Norbert Hartl <norbert(a)hartl.name> > > wrote: > > >> In the spirit of git notificationâ¦I moved mustache to github. > > >> > > >> https://github.com/noha/mustache > > >> > > >> Enjoy! > > >> > > >> Norbert > > >> > > >> > > > >

July 28, 2017

Re: [Pharo-dev] [ANN] Mustache moved to github

by Denis Kudriashov

In my projects I defined configuration with single stable which points to baseline master: stable: spec <symbolicVersion: #stable>. spec for: #'pharo' version: 'master' master: spec <version: 'master'> spec for: #pharo do: [ spec baseline: 'Mustache' with: [ spec repository: 'github://noha/mustache' ]; import: 'Mustache' ] And I am supposed that master will be always stable. 2017-07-28 14:13 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > I don't know how. I must say that it is not clear to me what to do. Do I > need a configuration? Do I still need to put it in Metarepo? > > Norbert > > > > Am 28.07.2017 um 14:06 schrieb Stephane Ducasse <stepharo.self(a)gmail.com > >: > > > > Hi norbert > > > > did you update the catalog entry? > > > > Stef > > > > On Fri, Jul 28, 2017 at 12:40 PM, Norbert Hartl <norbert(a)hartl.name> > wrote: > >> In the spirit of git notificationâ¦I moved mustache to github. > >> > >> https://github.com/noha/mustache > >> > >> Enjoy! > >> > >> Norbert > >> > >> > >

July 28, 2017

Re: [Pharo-dev] [Ann] Calypso is moved to github

by Denis Kudriashov

> > I like the scoped refactoring :). I hope it was clear that it is in todo. I just shared idea how it will be done.

July 28, 2017

Re: [Pharo-dev] [Ann] Calypso is moved to github

by Denis Kudriashov

> > BTW do you kept the inplace edit of protocol? Because it was cool to > double click on it to rename it. > It will be implemented with DoubleClickCommandActivator which means that we can apply this way to any other commands.

July 28, 2017