- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Help currency review

by Martin Dias

I created a fogbugz case for Epicea https://pharo.fogbugz.com/f/cases/19946/Update-Epicea-help On Sun, Apr 16, 2017 at 8:34 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > tx ben > indeed this is nice to update this text > s. > > On Sat, Apr 8, 2017 at 4:25 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> At this late stage of Pharo 6 development, it might be good to do a pass >> at... >> World > Help > Help Browser content >> >> Epicea >Browsers - mentions two separate browser windows >> >> GT Debugger >> Actions - TODO >> >> GT Playground >> Overview - http://gt.moosetechnology.org redirects to >> http://gtoolkit.org/ >> and same for several GT entries >> >> Welcome > Getting Help says... >> - The "Pharo Users" mailing list: http://lists.pharo.org/mailman >> /listinfo/pharo-users_lists.pharo.org >> - The "Pharo Slack Team": http://slack4pharo.trentosur.com/ >> - The "Pharo IRC Channel": irc.freenode.net, #pharo channel >> - http://pharo.org/community >> >> So we should change from Slack to Discord. >> I can take care of this one but a couple questions... >> >> 1. I propose a Discord #Help channel to record here in the help browser. >> >> 2. I bumped into an interesting tip >> https://www.reddit.com/r/discordapp/comments/3yu1bh/server_ >> vs_channel_invites/ >> >> Thus I propose we have a #Welcome channel providing info like what the >> bot has been providing. >> Later it could be good to have a bot just in that channel, but not off >> someone's home server :) >> I would expect that channel to not need anyone lurking in it. Newcomers >> will jump immediately >> from there #Help or #General >> >> 3. How active is the IRC channel? Should we remove it from the help >> browser? >> The mention at http://pharo.org/community could be sufficient. >> >> 4. Should we backport this help info update to Pharo 5? >> >> cheers -ben >> >> >

April 17, 2017

Re: [Pharo-dev] Epicea should ask before recovering

by Martin Dias

You can disable it: World Menu > Settings > Tools > Epicea > Detect lost events on start up I can make it initially disabled by default. However, I have an optimization that can improve a lot the time to read, maybe we can still integrate a new version of Epicea before 6.0 release. I've been testing it for a couple of weeks and works well. On Sun, Apr 16, 2017 at 11:09 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Me three > > Recover dialog is standard on all apps anyway > On Sun, 16 Apr 2017 at 16:22, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2017-04-16 12:09 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: >> >>> Of course if I am the only person that uses images in such a way then I >>> can just work around it myself. (because having endless lists of config >>> options is also nightmare) >> >> >> Me too >> >

April 17, 2017

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