- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Commenting the Session Manager

by Juraj Kubelka

I like it! :-) Maybe it could also goes to the Help Browser, because it is quite extensive. Juraj > On Apr 13, 2017, at 06:41, 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-SessionManager-class-comment <https://pharo.fogbugz.com/f/cases/19463/Improve-SessionManager-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 17, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by news{＠bestley.co.uk

Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > --001a113a8620c74f7a054d5aba55 > Content-Type: text/plain; charset=UTF-8 > > Not before IMMEDIATELY realizing that all screenshots containing the white > theme are outdated and will IMMEDIATELY prefer the dark ones that will have > an updated view of the Pharo GUI compared to a screenshot that has the > white theme and it's outdated by two or more years. > No they will think it is for a different environment and waste time looking for a match. A beginner won't see that just that they cannot get the same answer as the mooc or documentation. They will look for a language where the documentation matches what they get as they don't know if the documentation or their code is wrong. (and probably cast aspersions on the quality of what they are using) > Updating the screenshots for PBE5 was a big pain and I am sure there are > ones that are left that are still outdated showing 1.4 , which is at least > 6 years old. > -- Mark

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Luke Gorrie

On 17 April 2017 at 10:37, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > You can use the attached magic file with file(1) command: > > file -m magic <image files> ... > > to detect the image type. or register the patterns with binfmt_misc to > match the vm to the image type automatically. > Thanks for this!

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Alistair Grant

On Sun, Apr 16, 2017 at 11:21:48PM +0800, Ben Coman wrote: > On Sun, Apr 16, 2017 at 10:50 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Do you know how the linux zero conf scripts are / will be built? > > > > My assumption has been that they are part of the image build. > > I'm not familiar with the zero-conf implementation. > You might learn something here... > https://github.com/pharo-project/pharo-zeroconf Thanks. This looks like it provides the download scripts and CONFIG for the threaded vm, but not the pharo and pharo-ui scripts that actually launch Pharo. I'll have to keep searching... :-) Thanks again, Alistair

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Alistair Grant

On Mon, Apr 17, 2017 at 12:47:38PM +0200, Luke Gorrie wrote: > On 17 April 2017 at 11:33, Luke Gorrie <luke(a)snabb.co> wrote: > > Fighting the VM build in another window. Just now I am able to build the > 32-bit VM from master and run both the Pharo 5 and Pharo 6 images. The next > problem is the issue of accessing $HOME. The actual error is > ExternalLibraryFunction>>invokeWithArguments: failing to call getenv() from > libc. Simplest way that I can reproduce it here is Smalltalk os environment > at: 'HOME'. > > > I have resolved this now. > > The problem was the VM primitive ioLoadModule() not being able to find libc. It > has some heuristics for where to look but they don't work on NixOS. I added the > relevant folder into $LD_LIBRARY_PATH in my wrapper script and now it is happy. > > There will be a lot of this in my future... finding hard-coded paths for things > like shared libraries and un-hard-coding them. I am not sure what to do in > cases where the paths are in Smalltalk code inside an image, that's harder to > patch than the VM sources or ELF headers etc. I've hit this as well building the snap package, e.g. CairoLibrary>>unixModuleName. I modified the method directly, but probably it would be better to create a UnixPlatform>>findLibrary: method to look after it centrally. Cheers, Alistair

April 17, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by Dimitris Chloupis

Not before IMMEDIATELY realizing that all screenshots containing the white theme are outdated and will IMMEDIATELY prefer the dark ones that will have an updated view of the Pharo GUI compared to a screenshot that has the white theme and it's outdated by two or more years. Updating the screenshots for PBE5 was a big pain and I am sure there are ones that are left that are still outdated showing 1.4 , which is at least 6 years old. At some point we will have to automate the whole process with the documentation. Which is why I am implementing a new in image interactive documentation system QA tooltip based I call Prometheas using a online PostgreSQL database that will make it unnecessary to have to download the latest Pharo to get latest documentation. As long as you are online you will have direct access to latest documentation. It won't replace the online HTML/PDF docs but it will provide a quick and dirty way to fetch and create documentation in image. On Mon, 17 Apr 2017 at 12:46, Mark Bestley <news{(a)bestley.co.uk> wrote: > Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > --94eb2c190338e56e92054d34764f > > Content-Type: text/plain; charset=UTF-8 > > > > Wow guys seriously it's a setting , not the end of the world . Completely > > agree with Cyril , I find white theme terrible and I never imagined > making > > such a big fuss for a setting. > > > > The mooc anmd other documentation show the white theme. > > So when new users start they see the documentation is wrong - so > IMMEDIATELY have a problem > > > > > You guys need to chill out. > > > > -- > Mark > > >

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Luke Gorrie

On 17 April 2017 at 11:33, Luke Gorrie <luke(a)snabb.co> wrote: > Fighting the VM build in another window. Just now I am able to build the > 32-bit VM from master and run both the Pharo 5 and Pharo 6 images. The next > problem is the issue of accessing $HOME. The actual error is > ExternalLibraryFunction>>invokeWithArguments: failing to call getenv() > from libc. Simplest way that I can reproduce it here is Smalltalk os > environment at: 'HOME'. > I have resolved this now. The problem was the VM primitive ioLoadModule() not being able to find libc. It has some heuristics for where to look but they don't work on NixOS. I added the relevant folder into $LD_LIBRARY_PATH in my wrapper script and now it is happy. There will be a lot of this in my future... finding hard-coded paths for things like shared libraries and un-hard-coding them. I am not sure what to do in cases where the paths are in Smalltalk code inside an image, that's harder to patch than the VM sources or ELF headers etc.

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Luke Gorrie

On 17 April 2017 at 11:59, Alistair Grant <akgrant0710(a)gmail.com> wrote: > What about the genVersion.sh script I provided earlier in this thread? > The genVersion.sh script has a dependency under the hood that I can't satisfy: it expects to be able to run git commands but I can't do that in the nix environment. The root problem is that nix requires a perfectly reproducible build environment, with the sha256 hash of every dependency declared, and that is hard to do for the .git folder. The .git is really a database that contains many source code versions and not just the one that I have checked out. Which perl script (I'm still learning about the build process), and why > would you need access to git blobs directly? > Check out opensmalltalk-vm/.git_filters/RevDateURL.smudge. This is a perl script that is accessing environmental state that's off-limits in the nix universe e.g. whoami, hostname, date, git, etc. Could be that I should write the version info by hand and apply it as a patch. I have to make my build produce the same result every time it runs. That way it will always work the same, and somebody in 5 years who wants to run an _ancient_ Pharo 6 image will be able to do that with my build script because it's a fixed point. > What does "Smalltalk vm interpreterSourceDate" actually return? > actually it gets an exception because I don't have well-formed values from the strings it is trying to parse.

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Alistair Grant

On Mon, Apr 17, 2017 at 02:07:40PM +0530, K K Subbu wrote: > On Monday 17 April 2017 01:04 PM, Luke Gorrie wrote: > > > >I wonder if some DWIM would make sense here. For example, my bash > >wrapper that starts the VM could inspect the image file and decide which > >VM is appropriate (spur, non-spur, 32-it, 64-bit, etc.) Otherwise the > >user needs to guess and decipher cryptic error messages. > > You can use the attached magic file with file(1) command: > > file -m magic <image files> ... > > to detect the image type. or register the patterns with binfmt_misc to match > the vm to the image type automatically. Thanks! This should make it straightforward to update the startup scripts. Cheers, Alistair

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Alistair Grant

Hi Luke, On Mon, Apr 17, 2017 at 11:33:38AM +0200, Luke Gorrie wrote: > On 17 April 2017 at 11:01, Luke Gorrie <luke(a)snabb.co> wrote: > Otherwise I need to supply the "smudged" version information in some reasonable > way. What about the genVersion.sh script I provided earlier in this thread? > I don't have access to the .git folder during build so I can't use the > perl script directly. Which perl script (I'm still learning about the build process), and why would you need access to git blobs directly? > I see that I can't just skip these values either because > on startup I am also seeing a warning that my "VM is too old" coming from > DiskStore class>>checkVMVersion that wants to see that my VM source is from at > least July 2012 :). What does "Smalltalk vm interpreterSourceDate" actually return? Cheers, Alistair

April 17, 2017