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

Re: [Pharo-dev] Loading scripts vs. configs with #stable and config browser (was: [ann] snapshotcello)

by Tudor Girba

Hi Torsten, Thanks for the rant :) It did not put it as a release yet, because I still wanted people to play with it. Hence the suggested "loadDevelopment". As for Moose not being in the configuration browser, it is precisely because we could not really release it until now in a reliable fashion that you do not find it there :). Snapshotcello is a little tool to help us bootstrap precisely around this problem. Cheers, Doru On Wed, Jul 24, 2013 at 10:04 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Tudor wrote: > >You can get the code at: > >Gofer new > > smalltalkhubUser: 'girba' project: 'Snapshotcello'; > > package: 'ConfigurationOfSnapshotcello'; > > load. > >(Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment > > Sorry about the rant in advance (which is more general and not only > specific to snapshotcello), but: > > Next time someone wants this (or another) nice little Pharo tool: > > - one has to remember this load script or have to find the announcement > mail again > - one has to a lot of typing the expression or copying to a workspace to > load it. > > Just with the posted load script he does dont know if Pharo 1.4, 2.0 or > 3.0 was used to develop it, > so how does he know the Pharo version to use it without failures? A pharo > version where it is not broken. > Maybe the user is still using Pharo 2.0 but maybe the tool requires at > least Pharo 3.0 ... > > What about a new user who starts tomorrow with Pharo and never read this > announcement. > Since he entered the mailinglist very late he missed the mail with the > script. > How can he now about this super cool package? Why cant it be more > accessible? > > I propose: PLEASE define a #stable for the working versions and place an > additional copy in: > > - "ss3.gemtalksystems.com/ss/MetaRepoForPharo20" (Pharo 2.0) > or > - "http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main" (Pharo 3.0) > > when you know it runs in the according pharo version. It will then appear > in the config browser. > > If it is not in the config browser of the current pharo version for easy > loading > then it does not really exist. ;) > It only exists for the people who read about it in the mailinglist. Think > of a first > time user who downloads Pharo 2.0. He may never stumble over the load > script or > the tool in Smalltalkhub. > > I know: it may not yet be the best mechanism to provide packages to users > (we need more infos > on the configs, hence catalog and automatic verification in the future) - > but still it > is better than the "load scripts" and possible confusion. > > So please CARE ABOUT YOUR USERS and make your packages available like this > so it can > be easily accessible and loadable right from the according image! > > Same for Roassal, Moose, ... and all the nice packages that now appear in > the > Pharo universe... > > Thanks > T. > > -- www.tudorgirba.com "Every thing has its own flow"

July 24, 2013

[update 3.0] #30294

by Marcus Denker

30294 ----- 11216 Integrate the new version of the debugger https://pharo.fogbugz.com/f/cases/11216 11212 wrong method used to create a debugger in SyntaxError>>notify:at:in: https://pharo.fogbugz.com/f/cases/11212 11220 Speed up test run: remove #testClassDescriptionAllSubInstances https://pharo.fogbugz.com/f/cases/11220 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1193.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.96… http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-MarcusDenker.536.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.55…

July 24, 2013

Re: [Pharo-dev] Loading scripts vs. configs with #stable and config browser (was: [ann] snapshotcello)

by Goubier Thierry

Hi Torsten, I'd be inclined to agree with you, except that : the configuration browser is too limited by only allowing a stable version which often does not fit with the need and the development process. More often than not, the configuration is in the right repository, but, you still have to find it (how many configurations are in the 20 meta repository) and write a script because in fact you need version 3.4.1, or you need the -dev group, or you need the development version because, yes, this is to try a new thing out. But +1 to have an idea on which pharo version it works :) Thierry Le 24/07/2013 10:04, Torsten Bergmann a Ã©crit : > Tudor wrote: >> You can get the code at: >> Gofer new >> smalltalkhubUser: 'girba' project: 'Snapshotcello'; >> package: 'ConfigurationOfSnapshotcello'; >> load. >> (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment > > Sorry about the rant in advance (which is more general and not only specific to snapshotcello), but: > > Next time someone wants this (or another) nice little Pharo tool: > > - one has to remember this load script or have to find the announcement mail again > - one has to a lot of typing the expression or copying to a workspace to load it. > > Just with the posted load script he does dont know if Pharo 1.4, 2.0 or 3.0 was used to develop it, > so how does he know the Pharo version to use it without failures? A pharo version where it is not broken. > Maybe the user is still using Pharo 2.0 but maybe the tool requires at least Pharo 3.0 ... > > What about a new user who starts tomorrow with Pharo and never read this announcement. > Since he entered the mailinglist very late he missed the mail with the script. > How can he now about this super cool package? Why cant it be more accessible? > > I propose: PLEASE define a #stable for the working versions and place an additional copy in: > > - "ss3.gemtalksystems.com/ss/MetaRepoForPharo20" (Pharo 2.0) or > - "http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main" (Pharo 3.0) > > when you know it runs in the according pharo version. It will then appear in the config browser. > > If it is not in the config browser of the current pharo version for easy loading > then it does not really exist. ;) > It only exists for the people who read about it in the mailinglist. Think of a first > time user who downloads Pharo 2.0. He may never stumble over the load script or > the tool in Smalltalkhub. > > I know: it may not yet be the best mechanism to provide packages to users (we need more infos > on the configs, hence catalog and automatic verification in the future) - but still it > is better than the "load scripts" and possible confusion. > > So please CARE ABOUT YOUR USERS and make your packages available like this so it can > be easily accessible and loadable right from the according image! > > Same for Roassal, Moose, ... and all the nice packages that now appear in the > Pharo universe... > > Thanks > T. > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 24, 2013

Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello

by Johan Brichau

Hi Doru, Stef, May I ask what the difference is with the version generation and updating methods found in MetacelloToolbox ? I want to understand, because I am currently using these of MetacelloToolbox to do the things you describe. Cheers! Johan On 24 Jul 2013, at 09:52, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> On Jul 24, 2013, at 8:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> >>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>>> Stef, >>>> >>>> I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). >>>> >>>> However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. >>> Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the >>> existing configuration trees but this requires some work. >> >> I do not understand this point. What do you mean by "interpreting the configuration trees"? > > I mean going over the configurations with dependencies to recreate the tree structure but with versions. > May be this is not needed because for versions we do not need dependencies so just group them per configurations. > >> >> Doru >> >>>> >>>> With that said it _is_ performing a useful function ... >>>> >>>> I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... >>>> >>>> Dale >>>> >>>> [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html >>>> ----- Original Message ----- >>>> | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >>>> | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> >>>> | Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" >>>> | <pharo-dev(a)lists.pharo.org> >>>> | Sent: Tuesday, July 23, 2013 2:17:50 PM >>>> | Subject: [Moose-dev] Re: [ann] snapshotcello >>>> | >>>> | Nice to see SnapshotCello coming to live. May be it should be >>>> | integrated to Metacello. >>>> | Because everybody may need this cool feature. >>>> | >>>> | Stef >>>> | >>>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> >>>> | wrote: >>>> | >>>> | > Hi, >>>> | > >>>> | > Stef and I developed Snapshotcello, a little utility that enables >>>> | > you to freeze a snapshot of a given configuration based on what is >>>> | > already loaded in your current image. >>>> | > >>>> | > The idea is simple. You develop against the latest versions of all >>>> | > packages, and commit your changes for each package. When you are >>>> | > ready for a release, you assemble your image, and generate a >>>> | > snapshot version that can be reloaded later. >>>> | > >>>> | > Here is an example of how it can work to take a snapshot of a >>>> | > development version: >>>> | > Snapshotcello new >>>> | > configurationClass: ConfigurationOfMoose; >>>> | > configurationVersion: #development; >>>> | > publishVersion: '4.8-snapshot' >>>> | > >>>> | > You can find more details here: >>>> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… >>>> | > >>>> | > You can get the code at: >>>> | > Gofer new >>>> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; >>>> | > package: 'ConfigurationOfSnapshotcello'; >>>> | > load. >>>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) >>>> | > loadDevelopment >>>> | > >>>> | > Cheers, >>>> | > Doru >>>> | > >>>> | > -- >>>> | > www.tudorgirba.com >>>> | > >>>> | > "Every successful trip needs a suitable vehicle." >>>> | > >>>> | > >>>> | > >>>> | > >>>> | > >>>> | > _______________________________________________ >>>> | > Moose-dev mailing list >>>> | > Moose-dev(a)iam.unibe.ch >>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> | >>>> | >>>> | _______________________________________________ >>>> | Moose-dev mailing list >>>> | Moose-dev(a)iam.unibe.ch >>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> | >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "From an abstract enough point of view, any two things are similar." > >

July 24, 2013

Loading scripts vs. configs with #stable and config browser (was: [ann] snapshotcello)

by Torsten Bergmann

Tudor wrote: >You can get the code at: >Gofer new > smalltalkhubUser: 'girba' project: 'Snapshotcello'; > package: 'ConfigurationOfSnapshotcello'; > load. >(Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment Sorry about the rant in advance (which is more general and not only specific to snapshotcello), but: Next time someone wants this (or another) nice little Pharo tool: - one has to remember this load script or have to find the announcement mail again - one has to a lot of typing the expression or copying to a workspace to load it. Just with the posted load script he does dont know if Pharo 1.4, 2.0 or 3.0 was used to develop it, so how does he know the Pharo version to use it without failures? A pharo version where it is not broken. Maybe the user is still using Pharo 2.0 but maybe the tool requires at least Pharo 3.0 ... What about a new user who starts tomorrow with Pharo and never read this announcement. Since he entered the mailinglist very late he missed the mail with the script. How can he now about this super cool package? Why cant it be more accessible? I propose: PLEASE define a #stable for the working versions and place an additional copy in: - "ss3.gemtalksystems.com/ss/MetaRepoForPharo20" (Pharo 2.0) or - "http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main" (Pharo 3.0) when you know it runs in the according pharo version. It will then appear in the config browser. If it is not in the config browser of the current pharo version for easy loading then it does not really exist. ;) It only exists for the people who read about it in the mailinglist. Think of a first time user who downloads Pharo 2.0. He may never stumble over the load script or the tool in Smalltalkhub. I know: it may not yet be the best mechanism to provide packages to users (we need more infos on the configs, hence catalog and automatic verification in the future) - but still it is better than the "load scripts" and possible confusion. So please CARE ABOUT YOUR USERS and make your packages available like this so it can be easily accessible and loadable right from the according image! Same for Roassal, Moose, ... and all the nice packages that now appear in the Pharo universe... Thanks T.

July 24, 2013

Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello

by StÃ©phane Ducasse

On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > On Jul 24, 2013, at 8:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >>> Stef, >>> >>> I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). >>> >>> However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. >> Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the >> existing configuration trees but this requires some work. > > I do not understand this point. What do you mean by "interpreting the configuration trees"? I mean going over the configurations with dependencies to recreate the tree structure but with versions. May be this is not needed because for versions we do not need dependencies so just group them per configurations. > > Doru > >>> >>> With that said it _is_ performing a useful function ... >>> >>> I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... >>> >>> Dale >>> >>> [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html >>> ----- Original Message ----- >>> | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >>> | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> >>> | Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" >>> | <pharo-dev(a)lists.pharo.org> >>> | Sent: Tuesday, July 23, 2013 2:17:50 PM >>> | Subject: [Moose-dev] Re: [ann] snapshotcello >>> | >>> | Nice to see SnapshotCello coming to live. May be it should be >>> | integrated to Metacello. >>> | Because everybody may need this cool feature. >>> | >>> | Stef >>> | >>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> >>> | wrote: >>> | >>> | > Hi, >>> | > >>> | > Stef and I developed Snapshotcello, a little utility that enables >>> | > you to freeze a snapshot of a given configuration based on what is >>> | > already loaded in your current image. >>> | > >>> | > The idea is simple. You develop against the latest versions of all >>> | > packages, and commit your changes for each package. When you are >>> | > ready for a release, you assemble your image, and generate a >>> | > snapshot version that can be reloaded later. >>> | > >>> | > Here is an example of how it can work to take a snapshot of a >>> | > development version: >>> | > Snapshotcello new >>> | > configurationClass: ConfigurationOfMoose; >>> | > configurationVersion: #development; >>> | > publishVersion: '4.8-snapshot' >>> | > >>> | > You can find more details here: >>> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… >>> | > >>> | > You can get the code at: >>> | > Gofer new >>> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; >>> | > package: 'ConfigurationOfSnapshotcello'; >>> | > load. >>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) >>> | > loadDevelopment >>> | > >>> | > Cheers, >>> | > Doru >>> | > >>> | > -- >>> | > www.tudorgirba.com >>> | > >>> | > "Every successful trip needs a suitable vehicle." >>> | > >>> | > >>> | > >>> | > >>> | > >>> | > _______________________________________________ >>> | > Moose-dev mailing list >>> | > Moose-dev(a)iam.unibe.ch >>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> | >>> | >>> | _______________________________________________ >>> | Moose-dev mailing list >>> | Moose-dev(a)iam.unibe.ch >>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> | >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > >

July 24, 2013

Re: [Pharo-dev] [pharo-project/pharo-core]

by Goubier Thierry

Hi Alexandre, I use SmalltalkHub, GitHub and professionally hosted git repositories for my Pharo developments, and I have slowly moved my SmalltalkHub hosted applications to GitHub, so yes, you can use GitHub to store applications. As Dale said, I'm adding a Monticello way to use a git repository to store pharo packages, trying to hide as much as possible the command line (you still have to do 'git clone', 'git pull' and 'git push' on the command line...) while being as close as possible to a mcz-based repository (which means going back and forth between smalltalkhub and github is possible). Overall, I find git to be a bit less of a hassle to connect to than smalltalkhub (authentification by public key is a real plus), and github tools and web interface a lot more powerfull than smalltalkhub at the moment. Some of git operations, however, are not very compatible with pharo code and packages, so its not perfect (yet). I do believe SmalltalkHub could use a git repository to store packages, yes. Synchronize that git to a github repo, why not as well? Thierry Le 23/07/2013 20:01, Alexandre Bergel a Ã©crit : > Hi! > > What this all business with Pharo on github is about? > I checked https://github.com/pharo-project and not much is said. > > Can one store its application in Github? > > About git, can Smalltalkhub be a nice facade of github? I mean, I do not want to use command line to save my code in a repository, but I would be more than happy that non-pharoers are aware of the very cool language Pharo by just glancing projects on github. Can Smalltalkhub instead use github for all the storing? > > Cheers, > Alexandre > > > On Jul 23, 2013, at 7:23 AM, GitHub <noreply(a)github.com> wrote: > >> Branch: refs/tags/30294 >> Home: https://github.com/pharo-project/pharo-core >> > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 24, 2013

14 issues in need of a quick check

by Marcus Denker

Hi, there are 14 issues in the status where they need to be checked. https://pharo.fogbugz.com/f/filters/36/Review

July 24, 2013

Re: [Pharo-dev] [Moose-dev] Re: Re: [ann] snapshotcello

by Tudor Girba

Hi, On Jul 24, 2013, at 8:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > >> Stef, >> >> I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). >> >> However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. > Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the > existing configuration trees but this requires some work. I do not understand this point. What do you mean by "interpreting the configuration trees"? Doru >> >> With that said it _is_ performing a useful function ... >> >> I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... >> >> Dale >> >> [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html >> ----- Original Message ----- >> | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> >> | Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" >> | <pharo-dev(a)lists.pharo.org> >> | Sent: Tuesday, July 23, 2013 2:17:50 PM >> | Subject: [Moose-dev] Re: [ann] snapshotcello >> | >> | Nice to see SnapshotCello coming to live. May be it should be >> | integrated to Metacello. >> | Because everybody may need this cool feature. >> | >> | Stef >> | >> | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> >> | wrote: >> | >> | > Hi, >> | > >> | > Stef and I developed Snapshotcello, a little utility that enables >> | > you to freeze a snapshot of a given configuration based on what is >> | > already loaded in your current image. >> | > >> | > The idea is simple. You develop against the latest versions of all >> | > packages, and commit your changes for each package. When you are >> | > ready for a release, you assemble your image, and generate a >> | > snapshot version that can be reloaded later. >> | > >> | > Here is an example of how it can work to take a snapshot of a >> | > development version: >> | > Snapshotcello new >> | > configurationClass: ConfigurationOfMoose; >> | > configurationVersion: #development; >> | > publishVersion: '4.8-snapshot' >> | > >> | > You can find more details here: >> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… >> | > >> | > You can get the code at: >> | > Gofer new >> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; >> | > package: 'ConfigurationOfSnapshotcello'; >> | > load. >> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) >> | > loadDevelopment >> | > >> | > Cheers, >> | > Doru >> | > >> | > -- >> | > www.tudorgirba.com >> | > >> | > "Every successful trip needs a suitable vehicle." >> | > >> | > >> | > >> | > >> | > >> | > _______________________________________________ >> | > Moose-dev mailing list >> | > Moose-dev(a)iam.unibe.ch >> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> | >> | >> | _______________________________________________ >> | Moose-dev mailing list >> | Moose-dev(a)iam.unibe.ch >> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> | >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

July 24, 2013

Re: [Pharo-dev] [Moose-dev] [ann] snapshotcello

by Tudor Girba

Hi, On Jul 24, 2013, at 8:49 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jul 24, 2013, at 12:09 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> Nice :) >> >> Random Question: Do you have a way to file out a whole configuration as a fuel file? > > Do you mean the packages? or the configuration itself? > What snapshotcello does is that it walks the configurations and gather the packages and their repository > and generate a list. I think he means all packages. I like the idea. >> or would it be considerably easier to so with your Snappy tool? > > probably because you get a linear list of packages. It actually does not depend that much on Snapshotcello, given that Snapshotcello actually uses Metacello for anything meaningful. But, it could be cheaper to simply traverse the snapshotted list of packages and dump them in fuel. Cheers, Doru > Stef > >> >> On 2013-07-23, at 23:17, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Nice to see SnapshotCello coming to live. May be it should be integrated to Metacello. >>> Because everybody may need this cool feature. >>> >>> Stef >>> >>> On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>>> Hi, >>>> >>>> Stef and I developed Snapshotcello, a little utility that enables you to freeze a snapshot of a given configuration based on what is already loaded in your current image. >>>> >>>> The idea is simple. You develop against the latest versions of all packages, and commit your changes for each package. When you are ready for a release, you assemble your image, and generate a snapshot version that can be reloaded later. >>>> >>>> Here is an example of how it can work to take a snapshot of a development version: >>>> Snapshotcello new >>>> configurationClass: ConfigurationOfMoose; >>>> configurationVersion: #development; >>>> publishVersion: '4.8-snapshot' >>>> >>>> You can find more details here: >>>> http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… >>>> >>>> You can get the code at: >>>> Gofer new >>>> smalltalkhubUser: 'girba' project: 'Snapshotcello'; >>>> package: 'ConfigurationOfSnapshotcello'; >>>> load. >>>> (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every successful trip needs a suitable vehicle." >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >> >> > > -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

July 24, 2013