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

Re: [Pharo-project] Metacello configuration conventions

by Camillo Bruni

On 2013-04-18, at 18:47, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > > ----- Original Message ----- > | From: "Camillo Bruni" <camillobruni(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Tuesday, April 16, 2013 3:19:57 PM > | Subject: Re: [Pharo-project] Metacello configuration conventions > | > | I liked ruby-gems approach more than the one in Metacello. You usually > | specify > | a major version (as under linux) for your dependency. That means the > | dependency > | might evolve a bit, typically for bugfixes, without you having to update > | the configuration manually. > | > | http://docs.rubygems.org/read/chapter/16 for me is what I'd like to see. > | > | As you say, #stable and #development are mostly for humans. > > Cami, > > I did look at the way ruby-gems worked pretty early on in Metacello development and I've arranged things such that I should be able to add the ability to specify ranges of versions, but the whole mechanics of the ruby-gem universe is different than the smalltalk universe so I'm not sure that Metacello would give you the behavior you are looking for even I did allow version ranges to be specified ... > > I'd be willing to spend time working through use cases with you to see if there would be benefit for enabling that feature... yes indeed with the global gem server they have a nice central unit which we do not have right now. But Christophe and Erwann are working on a first step towards such a thing for Pharo: - completely automated configuration validation - completely automated tests for loaded configurations But for the version range, I think having that in Metacello would already give very fine-grained control over dependencies. Additionally it would actually give real meaning to the version numbers.

April 18, 2013

Re: [Pharo-project] How to get the AST Node for a Context

by stephane ducasse

On Apr 18, 2013, at 8:19 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 April 2013 19:17, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Sure, typical refactoring process. >> Code is convoluted and hard to follow, so you first document and explicit >> most obscure steps. >> In a second time, you realize how simpler it could be... >> >> Pharo is quite fast and still accelerating these days, so I understand the >> "satisfecit", it's already huge progress. >> My unsatisfied nature just tell to not stop in the middle of the bridge, and >> to not let un-necessarily complex code, even if well commented :) >> > Opal is there we all can start contributing. > I, for instance, have plans for replacing parsing.. to make modular > parser & encoder Yes :) I would like to have a compilationContext instead of this ugly full of parameter methods and â¦. I would like to be able to specify an environment (class binding + literal binding) as input and an environment as output so that we can bootstrap the compiler nicely and do a lot fun stuff. Stef

April 18, 2013

Re: [Pharo-project] How to get the AST Node for a Context

by stephane ducasse

> Sure, typical refactoring process. > Code is convoluted and hard to follow, so you first document and explicit most obscure steps. > In a second time, you realize how simpler it could be... > > Pharo is quite fast and still accelerating these days, so I understand the "satisfecit", it's already huge progress. > My unsatisfied nature just tell to not stop in the middle of the bridge, and to not let un-necessarily complex code, even if well commented :) do not worry for that we have a long list of tasks for the compiler and even more for other components. :) Stef

April 18, 2013

Re: [Pharo-project] Metacello configuration conventions

by stephane ducasse

Dale I was discussing with christophe yesterday and what would be good in metacello is to be able to have in one version of the configurationOf all the information about previous heads stable versions because right now to get this information we need to load previous versions until we see that the stable or development deifnitino changes. I will start to add to my configurations previousVersions ^ #((stable 20 #(1.0 1.2 1.3)) (stable 1.4 #(1.0 )) so that we can perform regression testing and not just test the latest stable version. Stef > > > ----- Original Message ----- > | From: "Camillo Bruni" <camillobruni(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Tuesday, April 16, 2013 3:19:57 PM > | Subject: Re: [Pharo-project] Metacello configuration conventions > | > | I liked ruby-gems approach more than the one in Metacello. You usually > | specify > | a major version (as under linux) for your dependency. That means the > | dependency > | might evolve a bit, typically for bugfixes, without you having to update > | the configuration manually. > | > | http://docs.rubygems.org/read/chapter/16 for me is what I'd like to see. > | > | As you say, #stable and #development are mostly for humans. > > Cami, > > I did look at the way ruby-gems worked pretty early on in Metacello development and I've arranged things such that I should be able to add the ability to specify ranges of versions, but the whole mechanics of the ruby-gem universe is different than the smalltalk universe so I'm not sure that Metacello would give you the behavior you are looking for even I did allow version ranges to be specified ... > > I'd be willing to spend time working through use cases with you to see if there would be benefit for enabling that feature... > > Dale >

April 18, 2013

Re: [Pharo-project] SS lost project description edits done in december 2012

by Marcus Denker

On Apr 18, 2013, at 9:18 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On Apr 18, 2013, at 1:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 18 April 2013 12:37, GÃ¶ran Krampe <goran(a)krampe.se> wrote: >>> Hi! >>> >>> I moved a lot of my projects to StHub back in december, and then I edited >>> the Project descriptions on SS to show that. But these changes have been >>> lost I now realize? >>> >>> Just put it back on Phriak: >>> >>> http://www.squeaksource.com/Phriak.html >>> >>> Any idea on when/how that happened? >>> >> when SS crashing, it "forgets" all metainformation for your project: >> - description >> - members >> etc.. >> >> this is one of the reasons why i migrated my active projects to sthub, >> because i get tired adding members over and over again :) > > and it is cooler, fresher and faster :) Actually a lot fasterâ¦ Marcus

April 18, 2013

Re: [Pharo-project] Versionner in 2.0 again

by stephane ducasse

On Apr 18, 2013, at 2:34 PM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Le 18 avr. 2013 Ã 05:16, Sean P. DeNigris a Ã©crit : > >> Christophe Demarey wrote >>> I was wondering if it is possible to downgrade an already installed >>> package in a configuration. >> >> For now, why don't we just declare a dependency to the correct version of >> the toolbox? I'm uploading a config to Nabble which does this and seems to >> work... ConfigurationOfVersionner-SeanDeNigris.101.mcz >> <http://forum.world.st/file/n4682230/ConfigurationOfVersionner-SeanDeNigris.…> > > I tried with a baseline but it doesn't work (metacello keep the most up to date toolbox). > I didn't think to declare the toolbox as package. Your version works fine. Thanks. I pushed it to the Versionner repo. :) > So, now Versionner is loadable as any other lib. > > @Marcus: Yes, if possible, it should be nice to update the toolbox version in the image. sure open a ticket and explain what we should do. > > Best regards, > Christophe.

April 18, 2013

Re: [Pharo-project] SS lost project description edits done in december 2012

by stephane ducasse

On Apr 18, 2013, at 1:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 April 2013 12:37, GÃ¶ran Krampe <goran(a)krampe.se> wrote: >> Hi! >> >> I moved a lot of my projects to StHub back in december, and then I edited >> the Project descriptions on SS to show that. But these changes have been >> lost I now realize? >> >> Just put it back on Phriak: >> >> http://www.squeaksource.com/Phriak.html >> >> Any idea on when/how that happened? >> > when SS crashing, it "forgets" all metainformation for your project: > - description > - members > etc.. > > this is one of the reasons why i migrated my active projects to sthub, > because i get tired adding members over and over again :) and it is cooler, fresher and faster :) Stef > >> regards, GÃ¶ran >> > > > > -- > Best regards, > Igor Stasenko. >

April 18, 2013

[Pharo-project] Version 1.39 of Versionner

by Alexandre Bergel

Hi All, I have produced a new version of Versionner (how odd is that ? :-) What is Versionner: Versionner is a French word that means handling versions. Versionner is the GUI of metacello. It supports a very simple working style: Pressing commit save all the packages of your application and it will create a new Metacello version. The goal of Versionner, is to not ever write a Metacello baseline or version by hand. A nice GUI, as it should be. What is new: - you can load a project from SmalltalkHub (cf screenshot) - some bugs have been fixed (e.g., browsing a version) - including some other fixes, from Norbert for example To load Versionner: doit in a workspace: Gofer new squeaksource3: 'Versionner'; package: 'ConfigurationOfVersionner'; load. (Smalltalk at: #ConfigurationOfVersionner) project lastVersion load. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 18, 2013

Re: [Pharo-project] How to get the AST Node for a Context

by Igor Stasenko

On 18 April 2013 19:17, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Sure, typical refactoring process. > Code is convoluted and hard to follow, so you first document and explicit > most obscure steps. > In a second time, you realize how simpler it could be... > > Pharo is quite fast and still accelerating these days, so I understand the > "satisfecit", it's already huge progress. > My unsatisfied nature just tell to not stop in the middle of the bridge, and > to not let un-necessarily complex code, even if well commented :) > Opal is there we all can start contributing. I, for instance, have plans for replacing parsing.. to make modular parser & encoder -- Best regards, Igor Stasenko.

April 18, 2013

Re: [Pharo-project] Metacello configuration conventions

by Frank Shearar

On 18 April 2013 17:47, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > > ----- Original Message ----- > | From: "Camillo Bruni" <camillobruni(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Tuesday, April 16, 2013 3:19:57 PM > | Subject: Re: [Pharo-project] Metacello configuration conventions > | > | I liked ruby-gems approach more than the one in Metacello. You usually > | specify > | a major version (as under linux) for your dependency. That means the > | dependency > | might evolve a bit, typically for bugfixes, without you having to update > | the configuration manually. > | > | http://docs.rubygems.org/read/chapter/16 for me is what I'd like to see. > | > | As you say, #stable and #development are mostly for humans. > > Cami, > > I did look at the way ruby-gems worked pretty early on in Metacello development and I've arranged things such that I should be able to add the ability to specify ranges of versions, but the whole mechanics of the ruby-gem universe is different than the smalltalk universe so I'm not sure that Metacello would give you the behavior you are looking for even I did allow version ranges to be specified ... What are the differences in mechanics? frank > I'd be willing to spend time working through use cases with you to see if there would be benefit for enabling that feature... > > Dale >

April 18, 2013