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

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

by Dale Henrichs

On 04/17/2017 12:47 PM, Thierry Goubier wrote: > Hi Dale, > > Le 17/04/2017 Ã 21:05, Dale Henrichs a Ã©crit : >> I would think that a `project list` view that made the Metacello project >> registration visible would help developers keep things straight. >> >> It seems that the issue here is that developers can't tell what projects >> are already loaded in the current image and also cannot tell what >> version of the project is loaded ... if you are using the `Metacello >> new` to load projects, then Metacello knows what projects and what >> versions are loaded in the image .... and that informatation really >> needs to be exposed to the developers ... >> >> If you have a `project list` then you can do things like automatically >> do a get on a configuration/baseline when a project is loaded via the >> `project list tool` ... there are additional details that need to be >> tracked and managed, but without the a basic `project list` the >> developer is responsible for "knowing what to do" and the first step is >> to let the developer know exactly which versions of which projects are >> loaded in the base image ... > > I wrote some code to that effect in the AltBrowser (gives access to > the project, and all packages loaded via that project, via a Metacello > registry tag). > > It didn't work as well as I expected, in part due to the interaction > between the Metacello registry and package loading into the image. > Nothing undoable, but due to the total lack of Metacello state in the > default Pharo image (nothing is loaded via Metacello in there) and the > Catalog browser not using Metacello as well, it was a bit too early to > invest into that. > > In short, the Metacello registry provides a nice entry point for a > system browser view of loaded projects and versions, but the Pharo > image building process is not yet there. > > If someone is interested, one need to look into the GT extensions for > Metacello objects ... those extensions are a nice source of knowledge > about extracting information from the loaded projects. This is unfortunate ... I'm willing to help anyone who wants to tackle this problem as well --- I know a thing or two about Metacello myself and I've had a working `project list` in tODE for 3-4 years now ... oh well ... Dale

April 17, 2017

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

by Thierry Goubier

Hi Dale, Le 17/04/2017 Ã 21:05, Dale Henrichs a Ã©crit : > I would think that a `project list` view that made the Metacello project > registration visible would help developers keep things straight. > > It seems that the issue here is that developers can't tell what projects > are already loaded in the current image and also cannot tell what > version of the project is loaded ... if you are using the `Metacello > new` to load projects, then Metacello knows what projects and what > versions are loaded in the image .... and that informatation really > needs to be exposed to the developers ... > > If you have a `project list` then you can do things like automatically > do a get on a configuration/baseline when a project is loaded via the > `project list tool` ... there are additional details that need to be > tracked and managed, but without the a basic `project list` the > developer is responsible for "knowing what to do" and the first step is > to let the developer know exactly which versions of which projects are > loaded in the base image ... I wrote some code to that effect in the AltBrowser (gives access to the project, and all packages loaded via that project, via a Metacello registry tag). It didn't work as well as I expected, in part due to the interaction between the Metacello registry and package loading into the image. Nothing undoable, but due to the total lack of Metacello state in the default Pharo image (nothing is loaded via Metacello in there) and the Catalog browser not using Metacello as well, it was a bit too early to invest into that. In short, the Metacello registry provides a nice entry point for a system browser view of loaded projects and versions, but the Pharo image building process is not yet there. If someone is interested, one need to look into the GT extensions for Metacello objects ... those extensions are a nice source of knowledge about extracting information from the loaded projects. Regards, Thierry > Dale > > > On 04/16/2017 11:46 AM, Cyril Ferlicot D. wrote: >> On 16/04/2017 08:54, Tudor Girba wrote: >>> However, Configurations are useful in offering people a way to >>> understand how the code is organized. For example, in Moose we have >>> the inspector extension that shows the dependencies and it is very >>> valuable. >>> >>> The only thing we need is to Metacello to be able to load new >>> versions of the configuration/baseline. >>> >> Hi, >> >> This is already possible via the method #get. >> >> But, IMO, the user should not have to do that with a fresh Pharo image. >> >> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> âThe smaller and more pervasive the hardware becomes, the more >>> physical the software gets." >>> >>> >> > > >

April 17, 2017

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

by Dale Henrichs

I would think that a `project list` view that made the Metacello project registration visible would help developers keep things straight. It seems that the issue here is that developers can't tell what projects are already loaded in the current image and also cannot tell what version of the project is loaded ... if you are using the `Metacello new` to load projects, then Metacello knows what projects and what versions are loaded in the image .... and that informatation really needs to be exposed to the developers ... If you have a `project list` then you can do things like automatically do a get on a configuration/baseline when a project is loaded via the `project list tool` ... there are additional details that need to be tracked and managed, but without the a basic `project list` the developer is responsible for "knowing what to do" and the first step is to let the developer know exactly which versions of which projects are loaded in the base image ... Dale On 04/16/2017 11:46 AM, Cyril Ferlicot D. wrote: > On 16/04/2017 08:54, Tudor Girba wrote: >> However, Configurations are useful in offering people a way to understand how the code is organized. For example, in Moose we have the inspector extension that shows the dependencies and it is very valuable. >> >> The only thing we need is to Metacello to be able to load new versions of the configuration/baseline. >> > Hi, > > This is already possible via the method #get. > > But, IMO, the user should not have to do that with a fresh Pharo image. > > >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> âThe smaller and more pervasive the hardware becomes, the more physical the software gets." >> >> >

April 17, 2017

Re: [Pharo-dev] Missing VMMaker repo in Pharo 6

by Cyril Ferlicot D.

Le 17/04/2017 Ã 11:22, K K Subbu a Ã©crit : > Hi, > > I couldn't find the http://source.squeak.org/VMMaker repo in Monticello > Browser list of repos. I have to add it to the downloaded image every > time to work with VM :-(. > > Is there any specific reason for not including it by default in Pharo 6 > (60465). > > Regards .. Subbu > Hi! You can add it via a setting. To do it just execute this in Pharo: StartupPreferencesLoader default addAtStartupInGeneralPreferenceFolder: {(StartupAction name: 'Add my repository' code: [ MCRepositoryGroup default addRepository: (MCSqueaksourceRepository location: 'http://source.squeak.org/VMMaker') ] runOnce: true)} Note that you can also add your credentials with: StartupPreferencesLoader default addAtStartupInGeneralPreferenceFolder: {(StartupAction name: 'Add my repository' code: [ MCRepositoryGroup default addRepository: (MCSqueaksourceRepository location: 'http://source.squeak.org/VMMaker' user: 'user' password: 'password') ] runOnce: true)} What will this do? It will create a new .st file in the preferences folder (Find his location at StartupPreferencesLoader preferencesGeneralFolder). This .st file will be executed each time you launch an image for the first time. If you don't want the settings to be loaded you can add the argument --no-default-preferences to the command line. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

April 17, 2017

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

by Eliot Miranda

On Sat, Apr 15, 2017 at 5:45 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > this belongs to pharo-dev, please continue there :) > It should also have been cc'ed to vm-dev. It is mostly about VM related issues. On 15 Apr 2017, at 14:25, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On Sat, Apr 15, 2017 at 02:14:26PM +0200, Luke Gorrie wrote: > > On 15 April 2017 at 11:53, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > (actually, I'm not sure why you're bothering since 6 should > be out before the end of the month, but that's your choice :-)). > > > I just want something stable and reasonably modern for running existing > applications and building new ones. > > If that means waiting for Pharo 6.0 release then that is okay with me. > > > The (V6) linux install relies on a number of bash scripts to launch > pharo > (bin/pharo, bin/pharo-ui and bin/pharo-vm/pharo). How are you producing > these, or are you doing something else? > > > Here is where those scripts are generated in the existing pharo-vm > packaging: > https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/pharo/vm/ > build-vm.nix#L50-L70 > > > Ahh, so Nix is doing its own thing, not using the ZeroConf scripts. > > > (I didn't write the nix packaging code but I have volunteered to maintain > it so > if it's out of date then I should fix that.) > > > It will be for V6. Esteban has changed the scripts to ensure that Pharo > versions of libraries are loaded (from memory)(this is also partly why I > would like to use the full build process). > > > git clone https://github.com/pharo-project/pharo-vm.git > git checkout <the stable code...> > cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build > ./mvm > -- > > BTW: HEAD is currently eaf13db484ac87720d8454e66b5ce92f51c01036, and my > experience is that it is significantly less stable than the latest > binary, which is from 1c38b03fb043a2962f30f080db5b1292b5b7badb > > > This is really the bleeding edge :-) both of those commits were pushed > within > the past three days! > > > Yep, V6 is still in testing. :-) > > Cheers, > Alistair > > > -- _,,,^..^,,,_ best, Eliot

April 17, 2017

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

by David T. Lewis

On Mon, Apr 17, 2017 at 09:34:53AM +0200, Luke Gorrie wrote: > On 17 April 2017 at 07:50, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > Yes, 32 bit VM will only work with 32 bit images, and 64 bit VM with 64 > > bit images. > > > > 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. > > Has anybody made such a "DWIM" script that automatically selects the right > VM? Would love a link to use for reference. > http://lists.squeakfoundation.org/pipermail/vm-dev/2017-April/024751.html Dave

April 17, 2017

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

by Ben Coman

Hi Luke, On Mon, Apr 17, 2017 at 9:50 PM, Luke Gorrie <luke(a)snabb.co> wrote: > Success! > > I'm now running the Pharo 5.0, Pharo 6.0, and Moose 6.1 images without a > hitch. > > Some hero has even fixed the libcairo name lookup issue in the Moose > image. Now it's searching LD_LIBRARY_PATH and so I have added every shared > library there in the wrapper script. > > I decided to manually write the SCCS version information directly in the > package definition and update that with sed. This is the part that I need > to maintain manually now: > > pharo-spur = pharo-vm-build rec { > name = "pharo-vm-${version}"; > version = "git.${revision}"; > binary-basename = "pharo-vm"; > src = fetchFromGitHub { > owner = "pharo-project"; > repo = "pharo-vm"; > rev = revision; > sha256 = "114ydx015i8sg4xwy1hkb7vwkcxl93h5vqz4bry46x2gnvsay7yh"; > }; > # metadata compiled into the image: > revision = "1c38b03fb043a2962f30f080db5b1292b5b7badb"; > sourceDate = "Wed Apr 12 19:25:16 2017 +0200"; > sourceURL = "https://github.com/pharo-project/pharo-vm"; > }; > > > I will close my PR on the pharo-vm repo too because I ended up packaging > the upstream source as-is without depending on any of those changes. > > Have to think about what's left... tidy up, test with the pharo-launcher > image, test on OSX, push to nix upstream... something like that. > > Thanks for all the help !! > > Cheers, > -Luke > > > Great to hear of your success. I was just in the middle of composing the following when your post popped up for me. Some of the points you raise actually would have been best discussed on the vm-dev [1] mail list. I'm going to post some follow up questions there and you may want to listen in. Also, since much of the vm level stuff is shared with Squeak, it would be good for them to benefit from knowing of your solution. Could you post a summary at vm-dev? [1] http://lists.squeakfoundation.org/mailman/listinfo/vm-dev cheers -ben

April 17, 2017

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

by Luke Gorrie

Success! I'm now running the Pharo 5.0, Pharo 6.0, and Moose 6.1 images without a hitch. Some hero has even fixed the libcairo name lookup issue in the Moose image. Now it's searching LD_LIBRARY_PATH and so I have added every shared library there in the wrapper script. I decided to manually write the SCCS version information directly in the package definition and update that with sed. This is the part that I need to maintain manually now: pharo-spur = pharo-vm-build rec { name = "pharo-vm-${version}"; version = "git.${revision}"; binary-basename = "pharo-vm"; src = fetchFromGitHub { owner = "pharo-project"; repo = "pharo-vm"; rev = revision; sha256 = "114ydx015i8sg4xwy1hkb7vwkcxl93h5vqz4bry46x2gnvsay7yh"; }; # metadata compiled into the image: revision = "1c38b03fb043a2962f30f080db5b1292b5b7badb"; sourceDate = "Wed Apr 12 19:25:16 2017 +0200"; sourceURL = "https://github.com/pharo-project/pharo-vm"; }; I will close my PR on the pharo-vm repo too because I ended up packaging the upstream source as-is without depending on any of those changes. Have to think about what's left... tidy up, test with the pharo-launcher image, test on OSX, push to nix upstream... something like that. Thanks for all the help !! Cheers, -Luke

April 17, 2017

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