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

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

by Stephane Ducasse

Tx denis. I like the scoped refactoring :). Do you have settings for all the automatic protocols? BTW do you kept the inplace edit of protocol? Because it was cool to double click on it to rename it. Stef On Fri, Jul 28, 2017 at 10:58 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > I moved Calypso to github https://github.com/dionisiydk/Calypso. You can > load it with following script: > > Metacello new > baseline: 'Calypso'; > repository: 'github://dionisiydk/Calypso'; > load > > > Now you can fork it and pull requests to dev branch. > > New version includes a lot of new features and fixes. You can read overview > in my blog > http://dionisiydk.blogspot.fr/2017/07/calypso-update-many-improvements-and.… > > Best regards, > Denis

July 28, 2017

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

by Stephane Ducasse

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 Tim Mackinnon

I too am very keen to get a minimal image that can start as quickly as possible as this gets us into the realm of running Pharo efficiently on AWS Lambda where milliseconds count. We're not bad (at least in the running) and comparable to other languages like GO, but milliseconds do add up and cost money, so any efficiencies are useful. This thread has raised very interesting info as with the jump to 6.1 I've not got a minimal image running reliably yet and the full image does show up that there is lots going on, and processes trying to write to a file system that is read only in the Lambda case. Tim Sent from my iPhone > On 28 Jul 2017, at 11:54, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-07-28 10:35 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> About the FreeType issue: the fonts we use are already cached in the image but they still need to be moved to freetype library when starting. > > Looks suprizing that moving two fonts takes so much time. Do you know what happens during move? > I found two cached fonts in image: SourceCode and SourceSans. > There is also LucidaGrandeRegular which always loads font from file. But it is only for Mac (look at #canBeInstalled). > > >> While speeding up will be cool, the only way to avoid this is to not initiate freetype fonts (perfectly doable for headless images) >> >> Esteban >> >> 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. >>> >>> >>> 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

[ANN] Mustache moved to github

by Norbert Hartl

In the spirit of git notificationâ¦I moved mustache to github. https://github.com/noha/mustache <https://github.com/noha/mustache> Enjoy! Norbert

July 28, 2017

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

by Tim Mackinnon

Nice one - my hope is that this can pave the way for much easier collaboration and help particularly for those of us who are recreational helpers (or trying to be). Hopefully many projects can do this and we can save time and effort by reusing existing open source infrastructure. We know there are teething problems - but this feels genuinely worth while. Tim Sent from my iPhone > On 28 Jul 2017, at 10:58, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > I moved Calypso to github https://github.com/dionisiydk/Calypso. You can load it with following script: > > Metacello new > baseline: 'Calypso'; > repository: 'github://dionisiydk/Calypso'; > load > > Now you can fork it and pull requests to dev branch. > > New version includes a lot of new features and fixes. You can read overview in my blog http://dionisiydk.blogspot.fr/2017/07/calypso-update-many-improvements-and.… > > Best regards, > Denis

July 28, 2017

Re: [Pharo-dev] WorkingSession log

by Denis Kudriashov

2017-07-28 10:35 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > About the FreeType issue: the fonts we use are already cached in the image > but they still need to be moved to freetype library when starting. > Looks suprizing that moving two fonts takes so much time. Do you know what happens during move? I found two cached fonts in image: SourceCode and SourceSans. There is also LucidaGrandeRegular which always loads font from file. But it is only for Mac (look at #canBeInstalled). > While speeding up will be cool, the only way to avoid this is to not > initiate freetype fonts (perfectly doable for headless images) > > Esteban > > 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. > > > 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] WorkingSession log

by Denis Kudriashov

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

[Ann] Calypso is moved to github

by Denis Kudriashov

Hi. I moved Calypso to github https://github.com/dionisiydk/Calypso. You can load it with following script: Metacello new baseline: 'Calypso'; repository: 'github://dionisiydk/Calypso'; load Now you can fork it and pull requests to dev branch. New version includes a lot of new features and fixes. You can read overview in my blog http://dionisiydk.blogspot.fr/2017/07/calypso-update-many-improvements-and.… Best regards, Denis

July 28, 2017

Re: [Pharo-dev] WorkingSession log

by Esteban Lorenzano

About the FreeType issue: the fonts we use are already cached in the image but they still need to be moved to freetype library when starting. While speeding up will be cool, the only way to avoid this is to not initiate freetype fonts (perfectly doable for headless images) Esteban 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. > > > 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] WorkingSession log

by Esteban Lorenzano

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. 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