- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Code colors with dark theme (out of box)

by Cyril Ferlicot D.

On 27/04/2017 10:07, Torsten Bergmann wrote: > The damn deal might be done to switch Pharo 6 now to the dark theme - but my impression > is that the way we provide it now lets say is "not very comfortable". > > When > - opening Pharo 6.0 Latest update: #60471 (as of today) > - opening a new Nautilus browser > > the code color settings are unreadable (see screenshot). > > I suggest to use black text on black background in the future to improve the situation > even further ;) > > Are there already any bugs to have a better color code scheme for the dark theme? > > Have fun > T. > Hum... I do not have this problem: https://puu.sh/vxH5r/e1d08b0639.png I just opened a fresh image and Nautilus. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

April 27, 2017

Re: [Pharo-dev] Commenting the Session Manager

by Guillermo Polito

I meant to change the comment and leave the code as is... On Wed, Apr 26, 2017 at 6:25 PM, Ben Coman <btc(a)openinworld.com> wrote: > eh! sorry, thats way too confusing to leave alone. > I meant... I'm not sure I properly understand. > > > On Thu, Apr 27, 2017 at 12:17 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> I'm sure I properly understand, you mean to change the behaviour rather >> than the comment? >> My naive understanding and intuition is the current behaviour is fine. >> What do you see wrong with it? >> >> cheers -ben >> >> On Wed, Apr 26, 2017 at 11:46 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Hi Ben, true. >>> >>> This happens because of this line: >>> >>> "create a new session object if we're booting" >>> isImageStarting ifTrue: [ self installNewSession ]. >>> >>> in SessionManager>>snapshot:andQuit: >>> >>> I'd say we should not change this now, but we should fix it for pharo 7. >>> >>> On Tue, Apr 18, 2017 at 6:15 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> hi Guille, >>>> >>>> Thanks very much for that detailed write up. I have one concern about >>>> the [bracketed] text... >>>> A new session starts when the image starts [or when the image is >>>> saved]. >>>> A session ends when the image quits [or it is saved]. >>>> >>>> Doing the following in a playground... >>>> s1 := SessionManager default currentSession. >>>> "Save image without quitting" >>>> s2 := SessionManager default currentSession. >>>> "Save and quit image, then after reloading..." >>>> s3 := SessionManager default currentSession. >>>> s1 == s2. "==> true" >>>> s2 == s3. "==> false" >>>> >>>> So it seems a new session does not start when the image is saved. >>>> With that in minds, can you review my proposed modifications... >>>> https://www.diffchecker.com/FUWg5J8t >>>> >>>> cheers -ben >>>> >>>> On Thu, Apr 13, 2017 at 5:41 PM, Guillermo Polito < >>>> guillermopolito(a)gmail.com> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I took some minutes to write down a class comment for the >>>>> SessionManager class. There was an issue asking for it: >>>>> >>>>> https://pharo.fogbugz.com/f/cases/19463/Improve-SessionManag >>>>> er-class-comment >>>>> >>>>> Since it is an important topic, and sometimes too low level for some >>>>> people, I'd like to have some feedback. Is it well explained? Is there >>>>> something that is key for you and is missing? >>>>> >>>>> I know that the comment is not exhaustive, it can be iterated and >>>>> enhanced, but we can have a nice first version of it for the release. >>>>> >>>>> Thanks, >>>>> Guille >>>>> >>>>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>>> >>>>> >>>>> I am the object responsible of managing how sessions work in Pharo. >>>>> A session defines the boundaries of work in the image. >>>>> >>>>> A new session starts when the image starts or when the image is saved. >>>>> A session ends when the image quits or it is saved. >>>>> There is only one active session at a single point of time. >>>>> Saving the image causes the active to stop, and starts a new session. >>>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> The current active session is hold by myself, the singleton session >>>>> manager. It can be accessed by doing: >>>>> >>>>> SessionManager default currentSession. >>>>> >>>>> The most important responsibility of the session manager is to manage >>>>> how resources and services in the image are started up and shut down at the >>>>> beginning and end of a session respectively. For example, when the image >>>>> starts, several initialization routines should be executed to make sure >>>>> that the image has access to the graphic drivers, the standard input/output >>>>> file descriptors and so on. >>>>> >>>>> Such initialization happens in the #snapshot:andQuit: method. >>>>> #snapshot:andQuit: will: >>>>> - stop current session >>>>> - save current image if requested >>>>> - quit if requested >>>>> - start a new session >>>>> >>>>> When a session is started, all elements registered in the startup list >>>>> are started up. >>>>> When a session is stopped, all elements registered in the shutdown >>>>> list are shut down. >>>>> >>>>> # Managing Startup and Shutdown lists >>>>> >>>>> The startup and shutdown lists can be accessed through the messages: >>>>> >>>>> SessionManager default startupList. >>>>> SessionManager default shutdownList. >>>>> >>>>> In general terms, the shutdown list is the startup list reversed. >>>>> >>>>> Upon a startup [shutdown], all elements in the startup list are sent >>>>> the message #startup: [#shutdown:] with a boolean as argument that >>>>> indicates wether the image is being saved [closed]. >>>>> >>>>> Internally, startup and shutdown lists are prioritised. Priorities are >>>>> managed by startup categories. By default the session manager includes the >>>>> following categories in decreasing priority order: >>>>> >>>>> - System >>>>> - Network >>>>> - Graphical User Interface >>>>> - Tools >>>>> - User >>>>> >>>>> Categories can be accessed as follows: >>>>> >>>>> SessionManager default categoryNamed: aName. >>>>> >>>>> New categories can be registered in the system using the messages: >>>>> >>>>> SessionManager default createCategory: aCategoryName. >>>>> SessionManager default createCategory: aCategoryName after: >>>>> anotherCategoryName. >>>>> >>>>> Finally, to subscribe some resource handler to the startup shutdown >>>>> lists, we need to subscribe a handler, subclass of AbstractSessionHandler. >>>>> The most common handler implementation so far is the >>>>> ClassSessionHandler, that allows to subscribe a class for startup and >>>>> shutdown, keeping backwards compatibility to the old startup mechanism. >>>>> >>>>> ClassSessionHandler forClassNamed: aClassName >>>>> >>>>> We can register a session handler as follows >>>>> >>>>> SessionManager default >>>>> register: (ClassSessionHandler forClassNamed: self name) >>>>> inCategory: SessionManager default systemCategory. >>>>> Or alternatively, by talking to the corresponding category: >>>>> >>>>> SessionManager default systemCategory register: (ClassSessionHandler >>>>> forClassNamed: self name) >>>>> >>>>> # System Category Priorities >>>>> >>>>> A system category internally prioritizes its elements to provide a >>>>> fine grained control on the startup and shutdown order. >>>>> All methods above have variants that allow developers to specify the >>>>> priority inside the category: >>>>> >>>>> SessionManager default >>>>> register: (ClassSessionHandler forClassNamed: self name) >>>>> inCategory: SessionManager default systemCategory >>>>> atPriority: 100. >>>>> >>>>> SessionManager default systemCategory >>>>> register: (ClassSessionHandler forClassNamed: self name) >>>>> atPriority: 100 >>>>> By default, if no priority is specified, a default priority is used. >>>>> Every category answers to the message #defaultPriority. >>>>> >>>>> # How does an image restart from the point it was before >>>>> >>>>> An important point in the image startup is how does it manage to >>>>> restart from the point where it was executing when it was saved. >>>>> >>>>> When the image is saved, using the snapshot primitive, the entire >>>>> image is freezed at the point of the snapshot. >>>>> More particularly, the process that invoked the snapshot primitive is >>>>> freezed at the point of the primitive call. >>>>> This works as a process fork: the running image will return from the >>>>> snapshot primitive and the saved file will also start from the freezed >>>>> point. >>>>> To differentiate whether we are executing in the running image or in >>>>> the freshly-saved image, the snapshot primitive returns a boolean >>>>> indicating it. >>>>> >>>>> Read the comment of #snapshotPrimitive for more details. >>>>> >>>> >>>> >>> >> >

April 27, 2017

Code colors with dark theme (out of box)

by Torsten Bergmann

The damn deal might be done to switch Pharo 6 now to the dark theme - but my impression is that the way we provide it now lets say is "not very comfortable". When - opening Pharo 6.0 Latest update: #60471 (as of today) - opening a new Nautilus browser the code color settings are unreadable (see screenshot). I suggest to use black text on black background in the future to improve the situation even further ;) Are there already any bugs to have a better color code scheme for the dark theme? Have fun T.

April 27, 2017

Re: [Pharo-dev] spec ui as morph

by Christophe Demarey

Hi Peter, Very useful information. Thanks for it. Christophe. > Le 26 avr. 2017 Ã 12:38, Peter Uhnak <i.uhnak(a)gmail.com> a Ã©crit : > > #buildWithSpec returns the SpecModel's Morph, which is what you want. > > `model spec instance`, which is the same as calling `model widget` returns the model's Adapter; but don't use the former, I will remove it in Pharo 7. > > If you want retrieve the morph from Spec after it was built, then > > yourModel widget "-> Adapter" > yourModel widget widget "-> Morph" > > Peter > > On Wed, Apr 26, 2017 at 12:23:03PM +0200, Nicolai Hess wrote: >> 2017-04-26 12:00 GMT+02:00 Christophe Demarey <christophe.demarey(a)inria.fr>: >> >>> thanks but the result is not a morph. >>> >> >> Are you sure ? >> >> (TextModel new text: Morph comment; buildWithSpec) openInHand -> a Morph >> >> >>> Should I use yourModel buildWithSpec spec instance? >>> >>>> Le 26 avr. 2017 Ã 11:55, Esteban Lorenzano <estebanlm(a)gmail.com> a >>> Ã©crit : >>>> >>>> yourModel buildWithSpec. >>>> >>>> Esteban >>>> >>>>> On 26 Apr 2017, at 11:51, Christophe Demarey < >>> christophe.demarey(a)inria.fr> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Does anyone know how to embed a UI component made with Spec into a UI >>> expecting a morph? >>>>> It looks like the only way to build a spec UI is to open it with >>> #openWithSpec that will always embed the component in a window. >>>>> >>>>> Thanks, >>>>> Christophe >>>> >>> >>> >>> >

April 27, 2017

Re: [Pharo-dev] spec ui as morph

by Christophe Demarey

Hi Nicolai, Thanks Nicolas, I tested quickly before leaving and I made a stupid mistake. Indeed, I get a morph. Maybe it would be a nice idea to put this information (how to integrate a spec ui into a morph) in the 0.1 section of the spec book? Thanks > Le 26 avr. 2017 Ã 12:23, Nicolai Hess <nicolaihess(a)gmail.com> a Ã©crit : > > > > 2017-04-26 12:00 GMT+02:00 Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>>: > thanks but the result is not a morph. > > Are you sure ? > > (TextModel new text: Morph comment; buildWithSpec) openInHand -> a Morph > > Should I use yourModel buildWithSpec spec instance? > > > Le 26 avr. 2017 Ã 11:55, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : > > > > yourModel buildWithSpec. > > > > Esteban > > > >> On 26 Apr 2017, at 11:51, Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>> wrote: > >> > >> Hi, > >> > >> Does anyone know how to embed a UI component made with Spec into a UI expecting a morph? > >> It looks like the only way to build a spec UI is to open it with #openWithSpec that will always embed the component in a window. > >> > >> Thanks, > >> Christophe > > > > >

April 27, 2017

Re: [Pharo-dev] saving an image on windows and opening it on mac problems

by Martin Dias

Hi Andrei, Could you tell me what's your "EpMonitor current sessionStore baseLocator" ? By default it's a FileLocator, but maybe you personalized it and setted a FileReference. FileLocators don't have a WindowsStore but FileReference do. The OmSessionStore is part of Epicea, and has a startUp: that executes the #ensureCreateDirectory. Well, maybe it shouldn't be done on start up but when a change happens... I should try this. MartÃn On Wed, Apr 26, 2017 at 3:40 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > What about loading some TTF fonts into the image? > > --Hannes > > On 4/26/17, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > I'd say that one should clear all fonts being loaded, refresh the list of > > available fonts because they are on another location (and this should > > happen even moving from windows to windows), and switch back to a default > > font that is sure to be available. > > > > I got an issue with the "hack" font because the new version changed the > > file names of the fonts and the system died. > > > > That should already solve some problems. > > > > Phil > > > > On Wed, Apr 26, 2017 at 5:10 PM, Andrei Chis <chisvasileandrei(a)gmail.com > > > > wrote: > > > >> Any hints about how to handle Freetype fonts? > >> Right now I'm getting also some segmentation faults when opening on mac > >> an > >> image saved on windows, that seem related to Freetype fonts. > >> > >> On Wed, Apr 26, 2017 at 5:04 PM, phil(a)highoctane.be <phil(a)highoctane.be > > > >> wrote: > >> > >>> You will also face serious fun with Freetype fonts. > >>> > >>> Phil > >>> > >>> On Wed, Apr 26, 2017 at 3:06 PM, Andrei Chis > >>> <chisvasileandrei(a)gmail.com> > >>> wrote: > >>> > >>>> Hi all, > >>>> > >>>> I saw that there are a few issues about images saved on an operating > >>>> system not working when opened on other operating systems: > >>>> - https://pharo.fogbugz.com/f/cases/19852/Unable-to-open-ima > >>>> ge-in-OSX-after-it-has-been-updated-in-Windows > >>>> - https://pharo.fogbugz.com/f/cases/19869/Infinite-loop-on-m > >>>> ac-when-opening-an-image-saved-on-windows > >>>> - https://pharo.fogbugz.com/f/cases/19272/Image-freezes-on-L > >>>> inux-if-it-was-previously-saved-on-Windows > >>>> - http://forum.world.st/Image-freezes-on-Linux-if-it-was-pre > >>>> viously-saved-on-Windows-td4903258.html > >>>> > >>>> I gave the fix in case 19869 a try and with it I can save an image on > >>>> windows and open it on mac, however, there are some side effects. > >>>> First several folders having the following name are created in the > >>>> image > >>>> folder: > >>>> > >>>> '\Users\andrei\test-image' > >>>> '\Users\andrei\test-image\pharo-local\' > >>>> '\Users\andrei\test-image\pharo-local\ombu-sessions' > >>>> > >>>> Second, I can only open the image on man once. The second time I get > >>>> the > >>>> following stack: > >>>> > >>>> [31mPrimitiveFailed: primitive #createDirectory: in WindowsStore > failed > >>>> [0mWindowsStore(Object)>>primitiveFailed: > >>>> WindowsStore(Object)>>primitiveFailed > >>>> WindowsStore(DiskStore)>>createDirectory: > >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: > >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: > >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: > >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: > >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: > >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: > >>>> FileSystem>>ensureCreateDirectory: > >>>> FileReference>>ensureCreateDirectory > >>>> OmSessionStore>>resetWithStoreNamed: > >>>> OmSessionStore>>resetWithNextStoreName > >>>> OmSessionStore>>store > >>>> WeakMessageSend>>value > >>>> WeakMessageSend>>cull: > >>>> WeakMessageSend>>cull:cull: > >>>> [ action cull: arg1 cull: announcer ] in > LegacyWeakSubscription(WeakAnn > >>>> ouncementSubscription)>>deliver: in Block: [ action cull: arg1 cull: > >>>> announcer ] > >>>> BlockClosure>>on:do: > >>>> BlockClosure>>on:fork: > >>>> LegacyWeakSubscription(WeakAnnouncementSubscription)>>deliver: > >>>> [ tmp4 deliver: arg1 ] in SubscriptionRegistry>>deliver: > to:startingAt: > >>>> in Block: [ tmp4 deliver: arg1 ] > >>>> BlockClosure>>ifCurtailed: > >>>> SubscriptionRegistry>>deliver:to:startingAt: > >>>> SubscriptionRegistry>>deliver:to: > >>>> SubscriptionRegistry>>deliver: > >>>> SystemAnnouncer(Announcer)>>announce: > >>>> SystemAnnouncer>>announce: > >>>> SystemAnnouncer>>snapshotDone: > >>>> SessionManager>>snapshot:andQuit: > >>>> [0m > >>>> > >>>> So it seems that OmSessionStore is not reset and holds a reference to > a > >>>> the windows path which it tries to create. > >>>> > >>>> Cheers, > >>>> Andrei > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > > > >

April 27, 2017

Re: [Pharo-dev] saving an image on windows and opening it on mac problems

by H. Hirzel

What about loading some TTF fonts into the image? --Hannes On 4/26/17, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I'd say that one should clear all fonts being loaded, refresh the list of > available fonts because they are on another location (and this should > happen even moving from windows to windows), and switch back to a default > font that is sure to be available. > > I got an issue with the "hack" font because the new version changed the > file names of the fonts and the system died. > > That should already solve some problems. > > Phil > > On Wed, Apr 26, 2017 at 5:10 PM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> Any hints about how to handle Freetype fonts? >> Right now I'm getting also some segmentation faults when opening on mac >> an >> image saved on windows, that seem related to Freetype fonts. >> >> On Wed, Apr 26, 2017 at 5:04 PM, phil(a)highoctane.be <phil(a)highoctane.be> >> wrote: >> >>> You will also face serious fun with Freetype fonts. >>> >>> Phil >>> >>> On Wed, Apr 26, 2017 at 3:06 PM, Andrei Chis >>> <chisvasileandrei(a)gmail.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> I saw that there are a few issues about images saved on an operating >>>> system not working when opened on other operating systems: >>>> - https://pharo.fogbugz.com/f/cases/19852/Unable-to-open-ima >>>> ge-in-OSX-after-it-has-been-updated-in-Windows >>>> - https://pharo.fogbugz.com/f/cases/19869/Infinite-loop-on-m >>>> ac-when-opening-an-image-saved-on-windows >>>> - https://pharo.fogbugz.com/f/cases/19272/Image-freezes-on-L >>>> inux-if-it-was-previously-saved-on-Windows >>>> - http://forum.world.st/Image-freezes-on-Linux-if-it-was-pre >>>> viously-saved-on-Windows-td4903258.html >>>> >>>> I gave the fix in case 19869 a try and with it I can save an image on >>>> windows and open it on mac, however, there are some side effects. >>>> First several folders having the following name are created in the >>>> image >>>> folder: >>>> >>>> '\Users\andrei\test-image' >>>> '\Users\andrei\test-image\pharo-local\' >>>> '\Users\andrei\test-image\pharo-local\ombu-sessions' >>>> >>>> Second, I can only open the image on man once. The second time I get >>>> the >>>> following stack: >>>> >>>> [31mPrimitiveFailed: primitive #createDirectory: in WindowsStore failed >>>> [0mWindowsStore(Object)>>primitiveFailed: >>>> WindowsStore(Object)>>primitiveFailed >>>> WindowsStore(DiskStore)>>createDirectory: >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >>>> FileSystem>>ensureCreateDirectory: >>>> FileReference>>ensureCreateDirectory >>>> OmSessionStore>>resetWithStoreNamed: >>>> OmSessionStore>>resetWithNextStoreName >>>> OmSessionStore>>store >>>> WeakMessageSend>>value >>>> WeakMessageSend>>cull: >>>> WeakMessageSend>>cull:cull: >>>> [ action cull: arg1 cull: announcer ] in LegacyWeakSubscription(WeakAnn >>>> ouncementSubscription)>>deliver: in Block: [ action cull: arg1 cull: >>>> announcer ] >>>> BlockClosure>>on:do: >>>> BlockClosure>>on:fork: >>>> LegacyWeakSubscription(WeakAnnouncementSubscription)>>deliver: >>>> [ tmp4 deliver: arg1 ] in SubscriptionRegistry>>deliver:to:startingAt: >>>> in Block: [ tmp4 deliver: arg1 ] >>>> BlockClosure>>ifCurtailed: >>>> SubscriptionRegistry>>deliver:to:startingAt: >>>> SubscriptionRegistry>>deliver:to: >>>> SubscriptionRegistry>>deliver: >>>> SystemAnnouncer(Announcer)>>announce: >>>> SystemAnnouncer>>announce: >>>> SystemAnnouncer>>snapshotDone: >>>> SessionManager>>snapshot:andQuit: >>>> [0m >>>> >>>> So it seems that OmSessionStore is not reset and holds a reference to a >>>> the windows path which it tries to create. >>>> >>>> Cheers, >>>> Andrei >>>> >>>> >>>> >>>> >>>> >>> >> >

April 26, 2017

Re: [Pharo-dev] Traits methods flattened

by Nicolai Hess

2017-04-25 19:08 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > Can you produce tests exposing these fails? > |set| set := Set new. Smalltalk allClassesAndTraits select:[:tc | tc traitComposition notEmpty] thenDo:[:b | |tc nonLocal| tc:= b traits. nonLocal := b localMethods select:[:m | tc anySatisfy:[:t | t methods contains:[:tm| ((tm selector = m selector and:[tm bytecode = m bytecode]) and:[tm literals allButLast = m literals allButLast])]]]. nonLocal notEmpty ifTrue:[set addAll:( nonLocal)]]. MessageBrowser browse:set > > Hilaire > > > Le 25/04/2017 Ã 10:47, Nicolai Hess a Ã©crit : > > Keep in mind. > > 1. the way new trait methods are handled is still wrong > > if non-local methods (methods from a trait) aren't added to the > > rpackage when creating the user of this trait, why are new trait > > methods "flattened" into this package > > 2. we already have some "corrupted" (flattened) packages in the image. > > (some methods of users of Traits are copied from the trait). > > For example, > > traits using the trait GLMBrickExtensionTrait or > > test case traits using other traits (TRemoveForMultiplenessTest / > > TRemoveTest, TDictionaryCopyingTest/TCloneTest) > > > > -- > Dr. Geo > http://drgeo.eu > > > >

April 26, 2017

Re: [Pharo-dev] Commenting the Session Manager

by Ben Coman

eh! sorry, thats way too confusing to leave alone. I meant... I'm not sure I properly understand. On Thu, Apr 27, 2017 at 12:17 AM, Ben Coman <btc(a)openinworld.com> wrote: > I'm sure I properly understand, you mean to change the behaviour rather > than the comment? > My naive understanding and intuition is the current behaviour is fine. > What do you see wrong with it? > > cheers -ben > > On Wed, Apr 26, 2017 at 11:46 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi Ben, true. >> >> This happens because of this line: >> >> "create a new session object if we're booting" >> isImageStarting ifTrue: [ self installNewSession ]. >> >> in SessionManager>>snapshot:andQuit: >> >> I'd say we should not change this now, but we should fix it for pharo 7. >> >> On Tue, Apr 18, 2017 at 6:15 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> hi Guille, >>> >>> Thanks very much for that detailed write up. I have one concern about >>> the [bracketed] text... >>> A new session starts when the image starts [or when the image is >>> saved]. >>> A session ends when the image quits [or it is saved]. >>> >>> Doing the following in a playground... >>> s1 := SessionManager default currentSession. >>> "Save image without quitting" >>> s2 := SessionManager default currentSession. >>> "Save and quit image, then after reloading..." >>> s3 := SessionManager default currentSession. >>> s1 == s2. "==> true" >>> s2 == s3. "==> false" >>> >>> So it seems a new session does not start when the image is saved. >>> With that in minds, can you review my proposed modifications... >>> https://www.diffchecker.com/FUWg5J8t >>> >>> cheers -ben >>> >>> On Thu, Apr 13, 2017 at 5:41 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Hi all, >>>> >>>> I took some minutes to write down a class comment for the >>>> SessionManager class. There was an issue asking for it: >>>> >>>> https://pharo.fogbugz.com/f/cases/19463/Improve-SessionManag >>>> er-class-comment >>>> >>>> Since it is an important topic, and sometimes too low level for some >>>> people, I'd like to have some feedback. Is it well explained? Is there >>>> something that is key for you and is missing? >>>> >>>> I know that the comment is not exhaustive, it can be iterated and >>>> enhanced, but we can have a nice first version of it for the release. >>>> >>>> Thanks, >>>> Guille >>>> >>>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> >>>> I am the object responsible of managing how sessions work in Pharo. >>>> A session defines the boundaries of work in the image. >>>> >>>> A new session starts when the image starts or when the image is saved. >>>> A session ends when the image quits or it is saved. >>>> There is only one active session at a single point of time. >>>> Saving the image causes the active to stop, and starts a new session. >>>> >>> >>> >>> >>> >>> >>>> >>>> The current active session is hold by myself, the singleton session >>>> manager. It can be accessed by doing: >>>> >>>> SessionManager default currentSession. >>>> >>>> The most important responsibility of the session manager is to manage >>>> how resources and services in the image are started up and shut down at the >>>> beginning and end of a session respectively. For example, when the image >>>> starts, several initialization routines should be executed to make sure >>>> that the image has access to the graphic drivers, the standard input/output >>>> file descriptors and so on. >>>> >>>> Such initialization happens in the #snapshot:andQuit: method. >>>> #snapshot:andQuit: will: >>>> - stop current session >>>> - save current image if requested >>>> - quit if requested >>>> - start a new session >>>> >>>> When a session is started, all elements registered in the startup list >>>> are started up. >>>> When a session is stopped, all elements registered in the shutdown list >>>> are shut down. >>>> >>>> # Managing Startup and Shutdown lists >>>> >>>> The startup and shutdown lists can be accessed through the messages: >>>> >>>> SessionManager default startupList. >>>> SessionManager default shutdownList. >>>> >>>> In general terms, the shutdown list is the startup list reversed. >>>> >>>> Upon a startup [shutdown], all elements in the startup list are sent >>>> the message #startup: [#shutdown:] with a boolean as argument that >>>> indicates wether the image is being saved [closed]. >>>> >>>> Internally, startup and shutdown lists are prioritised. Priorities are >>>> managed by startup categories. By default the session manager includes the >>>> following categories in decreasing priority order: >>>> >>>> - System >>>> - Network >>>> - Graphical User Interface >>>> - Tools >>>> - User >>>> >>>> Categories can be accessed as follows: >>>> >>>> SessionManager default categoryNamed: aName. >>>> >>>> New categories can be registered in the system using the messages: >>>> >>>> SessionManager default createCategory: aCategoryName. >>>> SessionManager default createCategory: aCategoryName after: >>>> anotherCategoryName. >>>> >>>> Finally, to subscribe some resource handler to the startup shutdown >>>> lists, we need to subscribe a handler, subclass of AbstractSessionHandler. >>>> The most common handler implementation so far is the >>>> ClassSessionHandler, that allows to subscribe a class for startup and >>>> shutdown, keeping backwards compatibility to the old startup mechanism. >>>> >>>> ClassSessionHandler forClassNamed: aClassName >>>> >>>> We can register a session handler as follows >>>> >>>> SessionManager default >>>> register: (ClassSessionHandler forClassNamed: self name) >>>> inCategory: SessionManager default systemCategory. >>>> Or alternatively, by talking to the corresponding category: >>>> >>>> SessionManager default systemCategory register: (ClassSessionHandler >>>> forClassNamed: self name) >>>> >>>> # System Category Priorities >>>> >>>> A system category internally prioritizes its elements to provide a fine >>>> grained control on the startup and shutdown order. >>>> All methods above have variants that allow developers to specify the >>>> priority inside the category: >>>> >>>> SessionManager default >>>> register: (ClassSessionHandler forClassNamed: self name) >>>> inCategory: SessionManager default systemCategory >>>> atPriority: 100. >>>> >>>> SessionManager default systemCategory >>>> register: (ClassSessionHandler forClassNamed: self name) >>>> atPriority: 100 >>>> By default, if no priority is specified, a default priority is used. >>>> Every category answers to the message #defaultPriority. >>>> >>>> # How does an image restart from the point it was before >>>> >>>> An important point in the image startup is how does it manage to >>>> restart from the point where it was executing when it was saved. >>>> >>>> When the image is saved, using the snapshot primitive, the entire image >>>> is freezed at the point of the snapshot. >>>> More particularly, the process that invoked the snapshot primitive is >>>> freezed at the point of the primitive call. >>>> This works as a process fork: the running image will return from the >>>> snapshot primitive and the saved file will also start from the freezed >>>> point. >>>> To differentiate whether we are executing in the running image or in >>>> the freshly-saved image, the snapshot primitive returns a boolean >>>> indicating it. >>>> >>>> Read the comment of #snapshotPrimitive for more details. >>>> >>> >>> >> >

April 26, 2017

Re: [Pharo-dev] Commenting the Session Manager

by Ben Coman

I'm sure I properly understand, you mean to change the behaviour rather than the comment? My naive understanding and intuition is the current behaviour is fine. What do you see wrong with it? cheers -ben On Wed, Apr 26, 2017 at 11:46 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hi Ben, true. > > This happens because of this line: > > "create a new session object if we're booting" > isImageStarting ifTrue: [ self installNewSession ]. > > in SessionManager>>snapshot:andQuit: > > I'd say we should not change this now, but we should fix it for pharo 7. > > On Tue, Apr 18, 2017 at 6:15 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> hi Guille, >> >> Thanks very much for that detailed write up. I have one concern about >> the [bracketed] text... >> A new session starts when the image starts [or when the image is >> saved]. >> A session ends when the image quits [or it is saved]. >> >> Doing the following in a playground... >> s1 := SessionManager default currentSession. >> "Save image without quitting" >> s2 := SessionManager default currentSession. >> "Save and quit image, then after reloading..." >> s3 := SessionManager default currentSession. >> s1 == s2. "==> true" >> s2 == s3. "==> false" >> >> So it seems a new session does not start when the image is saved. >> With that in minds, can you review my proposed modifications... >> https://www.diffchecker.com/FUWg5J8t >> >> cheers -ben >> >> On Thu, Apr 13, 2017 at 5:41 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Hi all, >>> >>> I took some minutes to write down a class comment for the SessionManager >>> class. There was an issue asking for it: >>> >>> https://pharo.fogbugz.com/f/cases/19463/Improve-SessionManag >>> er-class-comment >>> >>> Since it is an important topic, and sometimes too low level for some >>> people, I'd like to have some feedback. Is it well explained? Is there >>> something that is key for you and is missing? >>> >>> I know that the comment is not exhaustive, it can be iterated and >>> enhanced, but we can have a nice first version of it for the release. >>> >>> Thanks, >>> Guille >>> >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> >>> >>> I am the object responsible of managing how sessions work in Pharo. >>> A session defines the boundaries of work in the image. >>> >>> A new session starts when the image starts or when the image is saved. >>> A session ends when the image quits or it is saved. >>> There is only one active session at a single point of time. >>> Saving the image causes the active to stop, and starts a new session. >>> >> >> >> >> >> >>> >>> The current active session is hold by myself, the singleton session >>> manager. It can be accessed by doing: >>> >>> SessionManager default currentSession. >>> >>> The most important responsibility of the session manager is to manage >>> how resources and services in the image are started up and shut down at the >>> beginning and end of a session respectively. For example, when the image >>> starts, several initialization routines should be executed to make sure >>> that the image has access to the graphic drivers, the standard input/output >>> file descriptors and so on. >>> >>> Such initialization happens in the #snapshot:andQuit: method. >>> #snapshot:andQuit: will: >>> - stop current session >>> - save current image if requested >>> - quit if requested >>> - start a new session >>> >>> When a session is started, all elements registered in the startup list >>> are started up. >>> When a session is stopped, all elements registered in the shutdown list >>> are shut down. >>> >>> # Managing Startup and Shutdown lists >>> >>> The startup and shutdown lists can be accessed through the messages: >>> >>> SessionManager default startupList. >>> SessionManager default shutdownList. >>> >>> In general terms, the shutdown list is the startup list reversed. >>> >>> Upon a startup [shutdown], all elements in the startup list are sent the >>> message #startup: [#shutdown:] with a boolean as argument that indicates >>> wether the image is being saved [closed]. >>> >>> Internally, startup and shutdown lists are prioritised. Priorities are >>> managed by startup categories. By default the session manager includes the >>> following categories in decreasing priority order: >>> >>> - System >>> - Network >>> - Graphical User Interface >>> - Tools >>> - User >>> >>> Categories can be accessed as follows: >>> >>> SessionManager default categoryNamed: aName. >>> >>> New categories can be registered in the system using the messages: >>> >>> SessionManager default createCategory: aCategoryName. >>> SessionManager default createCategory: aCategoryName after: >>> anotherCategoryName. >>> >>> Finally, to subscribe some resource handler to the startup shutdown >>> lists, we need to subscribe a handler, subclass of AbstractSessionHandler. >>> The most common handler implementation so far is the >>> ClassSessionHandler, that allows to subscribe a class for startup and >>> shutdown, keeping backwards compatibility to the old startup mechanism. >>> >>> ClassSessionHandler forClassNamed: aClassName >>> >>> We can register a session handler as follows >>> >>> SessionManager default >>> register: (ClassSessionHandler forClassNamed: self name) >>> inCategory: SessionManager default systemCategory. >>> Or alternatively, by talking to the corresponding category: >>> >>> SessionManager default systemCategory register: (ClassSessionHandler >>> forClassNamed: self name) >>> >>> # System Category Priorities >>> >>> A system category internally prioritizes its elements to provide a fine >>> grained control on the startup and shutdown order. >>> All methods above have variants that allow developers to specify the >>> priority inside the category: >>> >>> SessionManager default >>> register: (ClassSessionHandler forClassNamed: self name) >>> inCategory: SessionManager default systemCategory >>> atPriority: 100. >>> >>> SessionManager default systemCategory >>> register: (ClassSessionHandler forClassNamed: self name) >>> atPriority: 100 >>> By default, if no priority is specified, a default priority is used. >>> Every category answers to the message #defaultPriority. >>> >>> # How does an image restart from the point it was before >>> >>> An important point in the image startup is how does it manage to restart >>> from the point where it was executing when it was saved. >>> >>> When the image is saved, using the snapshot primitive, the entire image >>> is freezed at the point of the snapshot. >>> More particularly, the process that invoked the snapshot primitive is >>> freezed at the point of the primitive call. >>> This works as a process fork: the running image will return from the >>> snapshot primitive and the saved file will also start from the freezed >>> point. >>> To differentiate whether we are executing in the running image or in the >>> freshly-saved image, the snapshot primitive returns a boolean indicating it. >>> >>> Read the comment of #snapshotPrimitive for more details. >>> >> >> >

April 26, 2017