- Pharo-dev - lists.pharo.org

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

by Tim Mackinnon

If I've understood correctly, this means you can rage master with a version number like v1.1 and then put that in the URL > https://github.com/peteruhnak/IconFactory/tree/master:v1.1/ Tim Sent from my iPhone > On 28 Jul 2017, at 14:59, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > 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] WorkingSession log

by Christophe Demarey

> Le 28 juil. 2017 Ã 10:14, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > >> >> On 28 Jul 2017, at 09:56, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: >> >> Hi Sven, >> >>> Le 27 juil. 2017 Ã 14:49, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : >>> >>> 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. >> >> Yes, it is a nice feature. > > I basically did something similar to what Phil/Clement seem to have done: > > - added a local instance variable #log to WorkingSession holding an OrderedCollection > - instrument #runStartup: and #executeDeferredStartupActions: like this > > runStartup: isImageStarting > self > runList: manager startupList > do: [ :each | | ms | > ms := Time millisecondsToRun: [ each startup: isImageStarting ]. > log add: { ms. #startup:. isImageStarting. each } ]. > self executeDeferredStartupActions: isImageStarting > > but if we do this for real, we better use a real object (like a log event, like SessionActionExecuted) > >> Do you have the same thing for #shutdown: ? > > I considered that, but if the session shuts down, it will disappear, hence the log will be lost, no ? Yes, an option could be to keep an history of sessions (or just the last one?) > Unless we also write it (optionally) to a file. That is difficult because while the shutdown list is processed, you loose functionalities and FileSystem is one of them. > >>> Sven >>> >>> PS: The code of SessionManager/WorkingSession was very readable, well done Christophe ! >> >> Thanks but then you should also thanks Guille and Pablo as it was a joint work ;) > > Thank you Guille and Pablo !!

July 28, 2017

Epicea: Revert the removal of a class

by Cyril Ferlicot D.

Hi, Today I tried to remove a class, go in Epicea and revert the removal of the class. At the end the class was here but with no methods. Is that the normal behaviour? I think it is a bug but since I don't really use Epicea a lot for know I am not sure. Have a nice day. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

July 28, 2017

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