Gofer vs Installer
Locked
12
12
 
|
What is the difference in:
goals? implementation? speed? license? other aspects? I can see that they both can install packages in a pharo image. Thanks -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
For Gofer:
> goals? Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages. > implementation? Focus on keeping the system clean, e.g. no empty categories/protocols, properly ordered categories/protocols, no duplicated repositories, etc. > speed? Not optimized yet. > license? MIT Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
El sáb, 19-09-2009 a las 18:34 +0200, Lukas Renggli escribió:
> For Gofer: > > > goals? > > Perform MC actions (load, update, merge, revert, commit, diff, > recompile) on a set of packages. So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader? Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo. Or nothing has been decided yet? It is considered? > > > implementation? > > Focus on keeping the system clean, e.g. no empty categories/protocols, > properly ordered categories/protocols, no duplicated repositories, > etc. Installer can't do that? Is a question, I don't know much about the internals of Installer. > > > speed? > > Not optimized yet. > > > license? > > MIT Can you please give us a big picture of the role Gofer will have? > > Lukas Thanks -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>>
>> >>> goals? >> >> Perform MC actions (load, update, merge, revert, commit, diff, >> recompile) on a set of packages. > > So, not like Installer that can load packages from everywhere, Gofer > will concentrate on MC? What about ScriptLoader? ScriptLoader will certainly use gofer to install packages instead of installer > Stephane has mentioned Gofer before. Is in the plans to support only > MC > packages for Pharo and to use Gofer as the tool for load them on > pharo. Yes. Because in pharo we do not use anything else besides on changeset to kick in the load. > Or nothing has been decided yet? It is considered? >> >>> implementation? >> >> Focus on keeping the system clean, e.g. no empty categories/ >> protocols, >> properly ordered categories/protocols, no duplicated repositories, >> etc. > > Installer can't do that? Is a question, I don't know much about the > internals of Installer. Compared to sometimes ago they were cleaned but > >> >>> speed? >> >> Not optimized yet. >> >>> license? >> >> MIT > > Can you please give us a big picture of the role Gofer will have? After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages. Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period). > >> >> Lukas > > Thanks > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I'd like to put on my user hat for a moment. A big concern of mine is doing a good job of saving packages from one image and moving them to another. I have (hopefully) been keeping my install script current as I add new packages, but it currently relies on my being careful.
Clearly having very good coverage with tests would help to check the health of any new image; I'm slowly working on that. It would be nice to have ways to check for packaging mistakes. A "smell" that comes to mind is any methods that I wrote but are not in packages in my load script. Is there anything that does such checks? Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism. This seems like such a common task that there must be some good tools to handle it?? Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Saturday, September 19, 2009 4:07 PM To: [hidden email] Subject: Re: [Pharo-project] Gofer vs Installer >> >> >>> goals? >> >> Perform MC actions (load, update, merge, revert, commit, diff, >> recompile) on a set of packages. > > So, not like Installer that can load packages from everywhere, Gofer > will concentrate on MC? What about ScriptLoader? ScriptLoader will certainly use gofer to install packages instead of installer > Stephane has mentioned Gofer before. Is in the plans to support only > MC packages for Pharo and to use Gofer as the tool for load them on > pharo. Yes. Because in pharo we do not use anything else besides on changeset to kick in the load. > Or nothing has been decided yet? It is considered? >> >>> implementation? >> >> Focus on keeping the system clean, e.g. no empty categories/ >> protocols, properly ordered categories/protocols, no duplicated >> repositories, etc. > > Installer can't do that? Is a question, I don't know much about the > internals of Installer. Compared to sometimes ago they were cleaned but > >> >>> speed? >> >> Not optimized yet. >> >>> license? >> >> MIT > > Can you please give us a big picture of the role Gofer will have? After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages. Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period). > >> >> Lukas > > Thanks > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
The first thing you can try is to check using the browse button of MC
that you extensions methods are well in your package. Stef On Sep 20, 2009, at 12:43 AM, Schwab,Wilhelm K wrote: > I'd like to put on my user hat for a moment. A big concern of mine > is doing a good job of saving packages from one image and moving > them to another. I have (hopefully) been keeping my install script > current as I add new packages, but it currently relies on my being > careful. > > Clearly having very good coverage with tests would help to check the > health of any new image; I'm slowly working on that. It would be > nice to have ways to check for packaging mistakes. A "smell" that > comes to mind is any methods that I wrote but are not in packages in > my load script. Is there anything that does such checks? Seaside > 2.9 includes a tool that helps to manage packages, and _somewhere_ I > have an image with that loaded and ready for shameless plagairism. > This seems like such a common task that there must be some good > tools to handle it?? > > Bill > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email] > ] On Behalf Of Stéphane Ducasse > Sent: Saturday, September 19, 2009 4:07 PM > To: [hidden email] > Subject: Re: [Pharo-project] Gofer vs Installer > >>> >>> >>>> goals? >>> >>> Perform MC actions (load, update, merge, revert, commit, diff, >>> recompile) on a set of packages. >> >> So, not like Installer that can load packages from everywhere, Gofer >> will concentrate on MC? What about ScriptLoader? > > ScriptLoader will certainly use gofer to install packages instead of > installer > >> Stephane has mentioned Gofer before. Is in the plans to support only >> MC packages for Pharo and to use Gofer as the tool for load them on >> pharo. > > Yes. > Because in pharo we do not use anything else besides on changeset to > kick in the load. > >> Or nothing has been decided yet? It is considered? >>> >>>> implementation? >>> >>> Focus on keeping the system clean, e.g. no empty categories/ >>> protocols, properly ordered categories/protocols, no duplicated >>> repositories, etc. >> >> Installer can't do that? Is a question, I don't know much about the >> internals of Installer. > > Compared to sometimes ago they were cleaned but >> >>> >>>> speed? >>> >>> Not optimized yet. >>> >>>> license? >>> >>> MIT >> >> Can you please give us a big picture of the role Gofer will have? > > After discussion at Esug between dale, lukas and me listening :) it > seems that Metacello will use Gofer to load packages. > > Now I think that you should give a try to Gofer and report what is > missing or not. > I have some behvaior I would really like to have (that are specific > to ScriptLoader like tell me which packages have changed since a > given marked period). > > > >> >>> >>> Lukas >> >> Thanks >> -- >> Miguel Cobá >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
> Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism. This seems like such a common task that there must be some good tools to handle it??
That's exactly Gofer. Seaside 3 is one of the reasons why I wrote it. Lukas > > Bill > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse > Sent: Saturday, September 19, 2009 4:07 PM > To: [hidden email] > Subject: Re: [Pharo-project] Gofer vs Installer > >>> >>> >>>> goals? >>> >>> Perform MC actions (load, update, merge, revert, commit, diff, >>> recompile) on a set of packages. >> >> So, not like Installer that can load packages from everywhere, Gofer >> will concentrate on MC? What about ScriptLoader? > > ScriptLoader will certainly use gofer to install packages instead of installer > >> Stephane has mentioned Gofer before. Is in the plans to support only >> MC packages for Pharo and to use Gofer as the tool for load them on >> pharo. > > Yes. > Because in pharo we do not use anything else besides on changeset to kick in the load. > >> Or nothing has been decided yet? It is considered? >>> >>>> implementation? >>> >>> Focus on keeping the system clean, e.g. no empty categories/ >>> protocols, properly ordered categories/protocols, no duplicated >>> repositories, etc. >> >> Installer can't do that? Is a question, I don't know much about the >> internals of Installer. > > Compared to sometimes ago they were cleaned but >> >>> >>>> speed? >>> >>> Not optimized yet. >>> >>>> license? >>> >>> MIT >> >> Can you please give us a big picture of the role Gofer will have? > > After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages. > > Now I think that you should give a try to Gofer and report what is missing or not. > I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period). > > > >> >>> >>> Lukas >> >> Thanks >> -- >> Miguel Cobá >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Stef,
I've done that, but my understanding is that "all" it does is show the methods that are packaged. I am hoping for something that would sniff out the methods that I have altered and are not in packages that I (somehow) claim to own. It seems like it would be really easy to miss important work and that it should be relatively easy to create something that scans for at-risk code. One thing I can enivision would compare a list of packages with user-owned methods in the system; anything that is not in one of the packages goes in a method browser with commands to package them in likely places. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Sunday, September 20, 2009 1:03 AM To: [hidden email] Subject: Re: [Pharo-project] Gofer vs Installer The first thing you can try is to check using the browse button of MC that you extensions methods are well in your package. Stef On Sep 20, 2009, at 12:43 AM, Schwab,Wilhelm K wrote: > I'd like to put on my user hat for a moment. A big concern of mine is > doing a good job of saving packages from one image and moving them to > another. I have (hopefully) been keeping my install script current as > I add new packages, but it currently relies on my being careful. > > Clearly having very good coverage with tests would help to check the > health of any new image; I'm slowly working on that. It would be nice > to have ways to check for packaging mistakes. A "smell" that comes to > mind is any methods that I wrote but are not in packages in my load > script. Is there anything that does such checks? Seaside > 2.9 includes a tool that helps to manage packages, and _somewhere_ I > have an image with that loaded and ready for shameless plagairism. > This seems like such a common task that there must be some good tools > to handle it?? > > Bill > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email] > ] On Behalf Of Stéphane Ducasse > Sent: Saturday, September 19, 2009 4:07 PM > To: [hidden email] > Subject: Re: [Pharo-project] Gofer vs Installer > >>> >>> >>>> goals? >>> >>> Perform MC actions (load, update, merge, revert, commit, diff, >>> recompile) on a set of packages. >> >> So, not like Installer that can load packages from everywhere, Gofer >> will concentrate on MC? What about ScriptLoader? > > ScriptLoader will certainly use gofer to install packages instead of > installer > >> Stephane has mentioned Gofer before. Is in the plans to support only >> MC packages for Pharo and to use Gofer as the tool for load them on >> pharo. > > Yes. > Because in pharo we do not use anything else besides on changeset to > kick in the load. > >> Or nothing has been decided yet? It is considered? >>> >>>> implementation? >>> >>> Focus on keeping the system clean, e.g. no empty categories/ >>> protocols, properly ordered categories/protocols, no duplicated >>> repositories, etc. >> >> Installer can't do that? Is a question, I don't know much about the >> internals of Installer. > > Compared to sometimes ago they were cleaned but >> >>> >>>> speed? >>> >>> Not optimized yet. >>> >>>> license? >>> >>> MIT >> >> Can you please give us a big picture of the role Gofer will have? > > After discussion at Esug between dale, lukas and me listening :) it > seems that Metacello will use Gofer to load packages. > > Now I think that you should give a try to Gofer and report what is > missing or not. > I have some behvaior I would really like to have (that are specific > to ScriptLoader like tell me which packages have changed since a > given marked period). > > > >> >>> >>> Lukas >> >> Thanks >> -- >> Miguel Cobá >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
Sounds great! Is it downloadable?
-----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Lukas Renggli Sent: Sunday, September 20, 2009 1:18 AM To: [hidden email] Subject: Re: [Pharo-project] Gofer vs Installer > Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism. This seems like such a common task that there must be some good tools to handle it?? That's exactly Gofer. Seaside 3 is one of the reasons why I wrote it. Lukas > > Bill > > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of > Stéphane Ducasse > Sent: Saturday, September 19, 2009 4:07 PM > To: [hidden email] > Subject: Re: [Pharo-project] Gofer vs Installer > >>> >>> >>>> goals? >>> >>> Perform MC actions (load, update, merge, revert, commit, diff, >>> recompile) on a set of packages. >> >> So, not like Installer that can load packages from everywhere, Gofer >> will concentrate on MC? What about ScriptLoader? > > ScriptLoader will certainly use gofer to install packages instead of > installer > >> Stephane has mentioned Gofer before. Is in the plans to support only >> MC packages for Pharo and to use Gofer as the tool for load them on >> pharo. > > Yes. > Because in pharo we do not use anything else besides on changeset to kick in the load. > >> Or nothing has been decided yet? It is considered? >>> >>>> implementation? >>> >>> Focus on keeping the system clean, e.g. no empty categories/ >>> protocols, properly ordered categories/protocols, no duplicated >>> repositories, etc. >> >> Installer can't do that? Is a question, I don't know much about the >> internals of Installer. > > Compared to sometimes ago they were cleaned but >> >>> >>>> speed? >>> >>> Not optimized yet. >>> >>>> license? >>> >>> MIT >> >> Can you please give us a big picture of the role Gofer will have? > > After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages. > > Now I think that you should give a try to Gofer and report what is missing or not. > I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period). > > > >> >>> >>> Lukas >> >> Thanks >> -- >> Miguel Cobá >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
Ok I will
I do not have the snipped at hand that can check all the dirty methods. Could you add that to bug traker with a request for feature because indeed this is a nice one. Stef On Sep 20, 2009, at 8:24 AM, Schwab,Wilhelm K wrote: > Stef, > > I've done that, but my understanding is that "all" it does is show > the methods that are packaged. I am hoping for something that would > sniff out the methods that I have altered and are not in packages > that I (somehow) claim to own. It seems like it would be really > easy to miss important work and that it should be relatively easy to > create something that scans for at-risk code. One thing I can > enivision would compare a list of packages with user-owned methods > in the system; anything that is not in one of the packages goes in a > method browser with commands to package them in likely places. > > Bill > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email] > ] On Behalf Of Stéphane Ducasse > Sent: Sunday, September 20, 2009 1:03 AM > To: [hidden email] > Subject: Re: [Pharo-project] Gofer vs Installer > > The first thing you can try is to check using the browse button of > MC that you extensions methods are well in your package. > > Stef > > On Sep 20, 2009, at 12:43 AM, Schwab,Wilhelm K wrote: > >> I'd like to put on my user hat for a moment. A big concern of mine >> is >> doing a good job of saving packages from one image and moving them to >> another. I have (hopefully) been keeping my install script current >> as >> I add new packages, but it currently relies on my being careful. >> >> Clearly having very good coverage with tests would help to check the >> health of any new image; I'm slowly working on that. It would be >> nice >> to have ways to check for packaging mistakes. A "smell" that comes >> to >> mind is any methods that I wrote but are not in packages in my load >> script. Is there anything that does such checks? Seaside >> 2.9 includes a tool that helps to manage packages, and _somewhere_ I >> have an image with that loaded and ready for shameless plagairism. >> This seems like such a common task that there must be some good tools >> to handle it?? >> >> Bill >> >> >> -----Original Message----- >> From: [hidden email] [mailto:[hidden email] >> ] On Behalf Of Stéphane Ducasse >> Sent: Saturday, September 19, 2009 4:07 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] Gofer vs Installer >> >>>> >>>> >>>>> goals? >>>> >>>> Perform MC actions (load, update, merge, revert, commit, diff, >>>> recompile) on a set of packages. >>> >>> So, not like Installer that can load packages from everywhere, Gofer >>> will concentrate on MC? What about ScriptLoader? >> >> ScriptLoader will certainly use gofer to install packages instead of >> installer >> >>> Stephane has mentioned Gofer before. Is in the plans to support only >>> MC packages for Pharo and to use Gofer as the tool for load them on >>> pharo. >> >> Yes. >> Because in pharo we do not use anything else besides on changeset to >> kick in the load. >> >>> Or nothing has been decided yet? It is considered? >>>> >>>>> implementation? >>>> >>>> Focus on keeping the system clean, e.g. no empty categories/ >>>> protocols, properly ordered categories/protocols, no duplicated >>>> repositories, etc. >>> >>> Installer can't do that? Is a question, I don't know much about the >>> internals of Installer. >> >> Compared to sometimes ago they were cleaned but >>> >>>> >>>>> speed? >>>> >>>> Not optimized yet. >>>> >>>>> license? >>>> >>>> MIT >>> >>> Can you please give us a big picture of the role Gofer will have? >> >> After discussion at Esug between dale, lukas and me listening :) it >> seems that Metacello will use Gofer to load packages. >> >> Now I think that you should give a try to Gofer and report what is >> missing or not. >> I have some behvaior I would really like to have (that are specific >> to ScriptLoader like tell me which packages have changed since a >> given marked period). >> >> >> >>> >>>> >>>> Lukas >>> >>> Thanks >>> -- >>> Miguel Cobá >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
from
source.lukasrenggli.com/flair I'm about to write a chapter on it for PharoByexample2 Stef On Sep 20, 2009, at 8:30 AM, Schwab,Wilhelm K wrote: > Sounds great! Is it downloadable? > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email] > ] On Behalf Of Lukas Renggli > Sent: Sunday, September 20, 2009 1:18 AM > To: [hidden email] > Subject: Re: [Pharo-project] Gofer vs Installer > >> Seaside 2.9 includes a tool that helps to manage packages, and >> _somewhere_ I have an image with that loaded and ready for >> shameless plagairism. This seems like such a common task that >> there must be some good tools to handle it?? > > That's exactly Gofer. Seaside 3 is one of the reasons why I wrote it. > > Lukas > >> >> Bill >> >> >> -----Original Message----- >> From: [hidden email] >> [mailto:[hidden email]] On Behalf Of >> Stéphane Ducasse >> Sent: Saturday, September 19, 2009 4:07 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] Gofer vs Installer >> >>>> >>>> >>>>> goals? >>>> >>>> Perform MC actions (load, update, merge, revert, commit, diff, >>>> recompile) on a set of packages. >>> >>> So, not like Installer that can load packages from everywhere, Gofer >>> will concentrate on MC? What about ScriptLoader? >> >> ScriptLoader will certainly use gofer to install packages instead of >> installer >> >>> Stephane has mentioned Gofer before. Is in the plans to support only >>> MC packages for Pharo and to use Gofer as the tool for load them on >>> pharo. >> >> Yes. >> Because in pharo we do not use anything else besides on changeset >> to kick in the load. >> >>> Or nothing has been decided yet? It is considered? >>>> >>>>> implementation? >>>> >>>> Focus on keeping the system clean, e.g. no empty categories/ >>>> protocols, properly ordered categories/protocols, no duplicated >>>> repositories, etc. >>> >>> Installer can't do that? Is a question, I don't know much about the >>> internals of Installer. >> >> Compared to sometimes ago they were cleaned but >>> >>>> >>>>> speed? >>>> >>>> Not optimized yet. >>>> >>>>> license? >>>> >>>> MIT >>> >>> Can you please give us a big picture of the role Gofer will have? >> >> After discussion at Esug between dale, lukas and me listening :) >> it seems that Metacello will use Gofer to load packages. >> >> Now I think that you should give a try to Gofer and report what is >> missing or not. >> I have some behvaior I would really like to have (that are specific >> to ScriptLoader like tell me which packages have changed since a >> given marked period). >> >> >> >>> >>>> >>>> Lukas >>> >>> Thanks >>> -- >>> Miguel Cobá >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
> I've done that, but my understanding is that "all" it does is show the methods that are packaged. I am hoping for something that would sniff out the methods that I have altered and are not in packages that I (somehow) claim to own. It seems like it would be really easy to miss important work and that it should be relatively easy to create something that scans for at-risk code. One thing I can enivision would compare a list of packages with user-owned methods in the system; anything that is not in one of the packages goes in a method browser with commands to package them in likely places.
The refactoring Code Checker reliably detects unpackaged code, see Possible Bugs > Unpackaged Code. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
ScriptLoader
loadLatestPackage: 'Gofer' from: 'http://source.lukas-renggli.ch/flair'. 2009/9/20 Schwab,Wilhelm K <[hidden email]>: > Sounds great! Is it downloadable? > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Lukas Renggli > Sent: Sunday, September 20, 2009 1:18 AM > To: [hidden email] > Subject: Re: [Pharo-project] Gofer vs Installer > >> Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism. This seems like such a common task that there must be some good tools to handle it?? > > That's exactly Gofer. Seaside 3 is one of the reasons why I wrote it. > > Lukas > >> >> Bill >> >> >> -----Original Message----- >> From: [hidden email] >> [mailto:[hidden email]] On Behalf Of >> Stéphane Ducasse >> Sent: Saturday, September 19, 2009 4:07 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] Gofer vs Installer >> >>>> >>>> >>>>> goals? >>>> >>>> Perform MC actions (load, update, merge, revert, commit, diff, >>>> recompile) on a set of packages. >>> >>> So, not like Installer that can load packages from everywhere, Gofer >>> will concentrate on MC? What about ScriptLoader? >> >> ScriptLoader will certainly use gofer to install packages instead of >> installer >> >>> Stephane has mentioned Gofer before. Is in the plans to support only >>> MC packages for Pharo and to use Gofer as the tool for load them on >>> pharo. >> >> Yes. >> Because in pharo we do not use anything else besides on changeset to kick in the load. >> >>> Or nothing has been decided yet? It is considered? >>>> >>>>> implementation? >>>> >>>> Focus on keeping the system clean, e.g. no empty categories/ >>>> protocols, properly ordered categories/protocols, no duplicated >>>> repositories, etc. >>> >>> Installer can't do that? Is a question, I don't know much about the >>> internals of Installer. >> >> Compared to sometimes ago they were cleaned but >>> >>>> >>>>> speed? >>>> >>>> Not optimized yet. >>>> >>>>> license? >>>> >>>> MIT >>> >>> Can you please give us a big picture of the role Gofer will have? >> >> After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages. >> >> Now I think that you should give a try to Gofer and report what is missing or not. >> I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period). >> >> >> >>> >>>> >>>> Lukas >>> >>> Thanks >>> -- >>> Miguel Cobá >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Definitively not well woken up yet :)
> from > source.lukasrenggli.com/flair > > I'm about to write a chapter on it for PharoByexample2 > > Stef > > > On Sep 20, 2009, at 8:30 AM, Schwab,Wilhelm K wrote: > >> Sounds great! Is it downloadable? >> >> >> -----Original Message----- >> From: [hidden email] [mailto:[hidden email] >> ] On Behalf Of Lukas Renggli >> Sent: Sunday, September 20, 2009 1:18 AM >> To: [hidden email] >> Subject: Re: [Pharo-project] Gofer vs Installer >> >>> Seaside 2.9 includes a tool that helps to manage packages, and >>> _somewhere_ I have an image with that loaded and ready for >>> shameless plagairism. This seems like such a common task that >>> there must be some good tools to handle it?? >> >> That's exactly Gofer. Seaside 3 is one of the reasons why I wrote it. >> >> Lukas >> >>> >>> Bill >>> >>> >>> -----Original Message----- >>> From: [hidden email] >>> [mailto:[hidden email]] On Behalf Of >>> Stéphane Ducasse >>> Sent: Saturday, September 19, 2009 4:07 PM >>> To: [hidden email] >>> Subject: Re: [Pharo-project] Gofer vs Installer >>> >>>>> >>>>> >>>>>> goals? >>>>> >>>>> Perform MC actions (load, update, merge, revert, commit, diff, >>>>> recompile) on a set of packages. >>>> >>>> So, not like Installer that can load packages from everywhere, >>>> Gofer >>>> will concentrate on MC? What about ScriptLoader? >>> >>> ScriptLoader will certainly use gofer to install packages instead of >>> installer >>> >>>> Stephane has mentioned Gofer before. Is in the plans to support >>>> only >>>> MC packages for Pharo and to use Gofer as the tool for load them on >>>> pharo. >>> >>> Yes. >>> Because in pharo we do not use anything else besides on changeset >>> to kick in the load. >>> >>>> Or nothing has been decided yet? It is considered? >>>>> >>>>>> implementation? >>>>> >>>>> Focus on keeping the system clean, e.g. no empty categories/ >>>>> protocols, properly ordered categories/protocols, no duplicated >>>>> repositories, etc. >>>> >>>> Installer can't do that? Is a question, I don't know much about the >>>> internals of Installer. >>> >>> Compared to sometimes ago they were cleaned but >>>> >>>>> >>>>>> speed? >>>>> >>>>> Not optimized yet. >>>>> >>>>>> license? >>>>> >>>>> MIT >>>> >>>> Can you please give us a big picture of the role Gofer will have? >>> >>> After discussion at Esug between dale, lukas and me listening :) >>> it seems that Metacello will use Gofer to load packages. >>> >>> Now I think that you should give a try to Gofer and report what is >>> missing or not. >>> I have some behvaior I would really like to have (that are specific >>> to ScriptLoader like tell me which packages have changed since a >>> given marked period). >>> >>> >>> >>>> >>>>> >>>>> Lukas >>>> >>>> Thanks >>>> -- >>>> Miguel Cobá >>>> http://miguel.leugim.com.mx >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Stef,
It is listed as 1229. I added a brief mention of using a list of packages to generate a load script. If I understand our current level of dependency control, it would probably be best to have an explicit list that would be litle more than a build script expressed in objects (perhaps living in a class method named for the author or something like that) that would be used to write a load script and aid the search for dirty methods. I'm not sure how helpful any of that is :) Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Sunday, September 20, 2009 1:50 AM To: [hidden email] Subject: Re: [Pharo-project] Gofer vs Installer Ok I will I do not have the snipped at hand that can check all the dirty methods. Could you add that to bug traker with a request for feature because indeed this is a nice one. Stef On Sep 20, 2009, at 8:24 AM, Schwab,Wilhelm K wrote: > Stef, > > I've done that, but my understanding is that "all" it does is show the > methods that are packaged. I am hoping for something that would sniff > out the methods that I have altered and are not in packages that I > (somehow) claim to own. It seems like it would be really easy to miss > important work and that it should be relatively easy to create > something that scans for at-risk code. One thing I can enivision > would compare a list of packages with user-owned methods in the > system; anything that is not in one of the packages goes in a method > browser with commands to package them in likely places. > > Bill > > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email] > ] On Behalf Of Stéphane Ducasse > Sent: Sunday, September 20, 2009 1:03 AM > To: [hidden email] > Subject: Re: [Pharo-project] Gofer vs Installer > > The first thing you can try is to check using the browse button of MC > that you extensions methods are well in your package. > > Stef > > On Sep 20, 2009, at 12:43 AM, Schwab,Wilhelm K wrote: > >> I'd like to put on my user hat for a moment. A big concern of mine >> is doing a good job of saving packages from one image and moving them >> to another. I have (hopefully) been keeping my install script >> current as I add new packages, but it currently relies on my being >> careful. >> >> Clearly having very good coverage with tests would help to check the >> health of any new image; I'm slowly working on that. It would be >> nice to have ways to check for packaging mistakes. A "smell" that >> comes to mind is any methods that I wrote but are not in packages in >> my load script. Is there anything that does such checks? Seaside >> 2.9 includes a tool that helps to manage packages, and _somewhere_ I >> have an image with that loaded and ready for shameless plagairism. >> This seems like such a common task that there must be some good tools >> to handle it?? >> >> Bill >> >> >> -----Original Message----- >> From: [hidden email] >> [mailto:[hidden email] >> ] On Behalf Of Stéphane Ducasse >> Sent: Saturday, September 19, 2009 4:07 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] Gofer vs Installer >> >>>> >>>> >>>>> goals? >>>> >>>> Perform MC actions (load, update, merge, revert, commit, diff, >>>> recompile) on a set of packages. >>> >>> So, not like Installer that can load packages from everywhere, Gofer >>> will concentrate on MC? What about ScriptLoader? >> >> ScriptLoader will certainly use gofer to install packages instead of >> installer >> >>> Stephane has mentioned Gofer before. Is in the plans to support only >>> MC packages for Pharo and to use Gofer as the tool for load them on >>> pharo. >> >> Yes. >> Because in pharo we do not use anything else besides on changeset to >> kick in the load. >> >>> Or nothing has been decided yet? It is considered? >>>> >>>>> implementation? >>>> >>>> Focus on keeping the system clean, e.g. no empty categories/ >>>> protocols, properly ordered categories/protocols, no duplicated >>>> repositories, etc. >>> >>> Installer can't do that? Is a question, I don't know much about the >>> internals of Installer. >> >> Compared to sometimes ago they were cleaned but >>> >>>> >>>>> speed? >>>> >>>> Not optimized yet. >>>> >>>>> license? >>>> >>>> MIT >>> >>> Can you please give us a big picture of the role Gofer will have? >> >> After discussion at Esug between dale, lukas and me listening :) it >> seems that Metacello will use Gofer to load packages. >> >> Now I think that you should give a try to Gofer and report what is >> missing or not. >> I have some behvaior I would really like to have (that are specific >> to ScriptLoader like tell me which packages have changed since a >> given marked period). >> >> >> >>> >>>> >>>> Lukas >>> >>> Thanks >>> -- >>> Miguel Cobá >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On 19 Sep 2009, at 22:06, Stéphane Ducasse wrote: >>> >>> >>>> goals? >>> >>> Perform MC actions (load, update, merge, revert, commit, diff, >>> recompile) on a set of packages. >> >> So, not like Installer that can load packages from everywhere, Gofer >> will concentrate on MC? What about ScriptLoader? > > ScriptLoader will certainly use gofer to install packages instead of > installer > I always thought that you guys didnt actually understand installer. Installer is intended to fulfill a strategic role, it has a role "Installing things", and it is extensible, so that anyone else who wants to "Install things" can contribute to it and extend it. So when a user wants to Install things, there is a logical place to go, that is called "Installer" for installing things. If you want to create an additional tool for "installing things" then why not consider how this tool may provide facilities for installer. Otherwise this indicates that the whole design concept and envisioned role of Installer has been overlooked. There is nothing wrong with ScriptLoader per se, but to be consistent with the vision for Installer it would be provided as an extension to Installer, thus... Installer scriptloader doWhateverYouWantHere. Installer was created to be the first and only dependency for kernel images of any kind, that you can use to load additional things. You guys come along and use ScriptLoader for roughly this purpose, thus explicitly ignoring, and implicitly undermining this goal from the outset. Furthermore none of your scripts in script loader appear to take advantage of the second installer feature. which is... Installer is supposed to enable scripts to be written and executed piecemeal, i.e. bit by bit, in a workspace, or for debugging. i.e. Installer scripts do not , and should not use temporaries. i.e. this style of code is NOT suitable for this purpose. | repo | repo := Installer squeaksource project: 'This'. repo install: 'That'. A better code example which has no method temporaries is shown below Installer squeaksource project: 'This'; install: 'That'. Installer monticello http: 'www.myrepo.com'; rememberAs: #mine. Installer mine project: 'This'; install: 'That'. Installer is supposed to provide a uniform API as a front end for all code loading tools so if this new gofer thing comes along, its API (implemented on InstallerGofer perhaps) could be published as Installer gofer project: 'This'; addPackage: 'That'; addPackage: 'TheOther'; install. or Installer gofer project: 'This'; addPackage: 'That'; addPackage: 'TheOther'; merge. I think that it would be a shame if the gofer tool whatever it is, doesn't come with an Installer api, then it would not be contributing to the Installer story, it would be competing with it, in the same strategic space. Given the fragmentation that is continuing to occur in the speak community, I think that this is tragic, that we end up with so many re- inventions of the wheel, yet none of them actually fulfills the role that, if you sit down and think about it for a few minutes, we actually need I.e. the original invention of Installer was expressly so that EVERY base image published would at least have Installer loaded (or loadable) and users could build from there, using whatever tools, and a consistent API. Installer helps this along in some situations since it knows how to load the source from an MC package in the event that MC is not actually loaded, and this helps with bootstapping Monticello etc. If everyone uses, or has the option of using the same tools for building images, in every release, then this facilitates exchange of packages among forks, and helps those of us who are not at liberty to jump ship on a whim, and it helps those who do want to jump ship on a whim. I was asking you for months to think along these lines and make such strategic choices based upon contributing to things that the squeak communities have in common or might want to use in common... The vision for Installer was to be a base for building derived images in all release images in all forks. The vision for MC1.5 was to be a set of tools that actually worked to load code in all images in all forks. The vision for LevelPlayingField is to provide bootstrapping for difficult code to load in all images in all forks. The vision for Sake/Packages was to be a universal set of package definitions and dependencies that show what works where in ALL images, in ALL Forks. The vision for SUnit-improved was to be a universal means for defining SUnit and SSpec tests for ALL images so that it is possible to indicate what works where, in ALL forks, so that packages of tests can be maintained in common for ALL forks. So, may I appeal to you, please contribute to and use installer, rather than compete with it, and perhaps reconsider your approach to the other ideas listed above. Keith p.s. I am considering, recruiting members for an independant "guild" of package developers, whose role would be to promote interoperability between squeak forks, so that packages can be developed once and deployed anywhere. I think this is needed because now we have no core image developers in either squeak or pharo, that look at interoperability. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/9/21 keith <[hidden email]>:
> > On 19 Sep 2009, at 22:06, Stéphane Ducasse wrote: > >>>> >>>> >>>>> goals? >>>> >>>> Perform MC actions (load, update, merge, revert, commit, diff, >>>> recompile) on a set of packages. >>> >>> So, not like Installer that can load packages from everywhere, Gofer >>> will concentrate on MC? What about ScriptLoader? >> >> ScriptLoader will certainly use gofer to install packages instead of >> installer >> > > I always thought that you guys didnt actually understand installer. > As for the rest of post i agreeing with you. Except, maybe that Gofer may be targeted not only as cross-fork but for cross-dialect tool. But i don't have any info on that, and indeed, i think Installer , with some refactorings could also work as a cross-dialect tool, at least on platforms which already supporting MC. > Installer is intended to fulfill a strategic role, it has a role > "Installing things", and it is extensible, so that anyone else who > wants to "Install things" can contribute to it and extend it. So when > a user wants to Install things, there is a logical place to go, that > is called "Installer" for installing things. > > If you want to create an additional tool for "installing things" then > why not consider how this tool may provide facilities for installer. > Otherwise this indicates that the whole design concept and envisioned > role of Installer has been overlooked. > > There is nothing wrong with ScriptLoader per se, but to be consistent > with the vision for Installer it would be provided as an extension to > Installer, thus... > > Installer scriptloader doWhateverYouWantHere. > > Installer was created to be the first and only dependency for kernel > images of any kind, that you can use to load additional things. > > You guys come along and use ScriptLoader for roughly this purpose, > thus explicitly ignoring, and implicitly undermining this goal from > the outset. Furthermore none of your scripts in script loader appear > to take advantage of the second installer feature. > > which is... > > Installer is supposed to enable scripts to be written and executed > piecemeal, i.e. bit by bit, in a workspace, or for debugging. i.e. > Installer scripts do not , and should not use temporaries. > > i.e. this style of code is NOT suitable for this purpose. > > | repo | > > repo := Installer squeaksource project: 'This'. > > repo install: 'That'. > > A better code example which has no method temporaries is shown below > > Installer squeaksource project: 'This'; install: 'That'. > Installer monticello http: 'www.myrepo.com'; rememberAs: #mine. > Installer mine project: 'This'; install: 'That'. > > Installer is supposed to provide a uniform API as a front end for all > code loading tools > > so if this new gofer thing comes along, its API (implemented on > InstallerGofer perhaps) could be published as > > Installer gofer project: 'This'; addPackage: 'That'; addPackage: > 'TheOther'; install. > > or > > Installer gofer project: 'This'; addPackage: 'That'; addPackage: > 'TheOther'; merge. > > I think that it would be a shame if the gofer tool whatever it is, > doesn't come with an Installer api, then it would not be contributing > to the Installer story, it would be competing with it, in the same > strategic space. > > Given the fragmentation that is continuing to occur in the speak > community, I think that this is tragic, that we end up with so many re- > inventions of the wheel, yet none of them actually fulfills the role > that, if you sit down and think about it for a few minutes, we > actually need > > I.e. the original invention of Installer was expressly so that EVERY > base image published would at least have Installer loaded (or > loadable) and users could build from there, using whatever tools, and > a consistent API. > Installer helps this along in some situations since it knows how to > load the source from an MC package in the event that MC is not > actually loaded, and this helps with bootstapping Monticello etc. > > If everyone uses, or has the option of using the same tools for > building images, in every release, then this facilitates exchange of > packages among forks, and helps those of us who are not at liberty to > jump ship on a whim, and it helps those who do want to jump ship on a > whim. > > I was asking you for months to think along these lines and make such > strategic choices based upon contributing to things that the squeak > communities have in common or might want to use in common... > > The vision for Installer was to be a base for building derived images > in all release images in all forks. > The vision for MC1.5 was to be a set of tools that actually worked to > load code in all images in all forks. > The vision for LevelPlayingField is to provide bootstrapping for > difficult code to load in all images in all forks. > The vision for Sake/Packages was to be a universal set of package > definitions and dependencies that show what works where in ALL images, > in ALL Forks. > The vision for SUnit-improved was to be a universal means for defining > SUnit and SSpec tests for ALL images so that it is possible to > indicate what works where, in ALL forks, so that packages of tests can > be maintained in common for ALL forks. > > So, may I appeal to you, please contribute to and use installer, > rather than compete with it, and perhaps reconsider your approach to > the other ideas listed above. > > Keith > > p.s. I am considering, recruiting members for an independant "guild" > of package developers, whose role would be to promote interoperability > between squeak forks, so that packages can be developed once and > deployed anywhere. I think this is needed because now we have no core > image developers in either squeak or pharo, that look at > interoperability. > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>> >> I always thought that you guys didnt actually understand installer. >> > Which is partly your own fault. How so? I may have been lax at many things, but on leaving Installer unexplained, I cant see that charge sticking. 1 - Installer was documented from the beginning, on the swiki, and in the class comment 2 - the first line of the documentation states that it is a DSL for installing things 3 - the second line of the documentation talks about executing scripts in the workspace. 4 - Installer has been available and used by many people for 3 years - Pharo are the only people routinely misusing it as far as I know. I have talked about having a strategic pan-fork approach until I am blue in the face, to the point of exhaustion. What I am left with is some mysterious unanswered questions. Like why hasn't my arm been bitten off for this stuff, and how does anyone actually get anything done with Universes? Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Miguel Cobá
I've posted a blog entry (based on the class-comment of the Gofer
class) to get people started. http://www.lukas-renggli.ch/blog/gofer Lukas 2009/9/19 Miguel Enrique Cobá Martinez <[hidden email]>: > What is the difference in: > > goals? > implementation? > speed? > license? > other aspects? > > I can see that they both can install packages in a pharo image. > > Thanks > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
El lun, 21-09-2009 a las 13:46 +0200, Lukas Renggli escribió: > I've posted a blog entry (based on the class-comment of the Gofer > class) to get people started. > > http://www.lukas-renggli.ch/blog/gofer > > Lukas >From the post: Now the following expressions can be used at any time: gofer load Load all packages. gofer update Update all packages. gofer merge Merge all packages into their working copies. gofer diff Display the difference between the working copy and the base version of all packages. gofer commit Commit all modified packages. gofer revert Revert all packages to their base version. gofer recompile Recompile all packages. gofer unload Unload all packages. This is something that I can't understand. Is this supposed to be a package management system per se, a la Metacello, aptitude, yum?? Isn't just a installer of MC packages but tries to manage the MC database of packages in a way that is clean and *atomic*? So, there will be a registry of gofer installed operations so that can be utilized after the install operation (maybe months later)? Or will just be for trying to install some group of packages and if some error happens immediatly revert? Can you relate the scenarios showing how gofer is intended to use, because until now (maybe my narrow perspective) the examples shown can be done also with ScriptLoader and Installer. Other thing, I tried to convert my image install script but I can't finish because I install packages from monticello configurations (magma 1.0r42) and from my local directory repository. Neither of those options can be handled by gofer (as far as I can see). Of course this can be corrected, it is just to integrate the correct MC installer classes. That reminds me other thing, Installer can handle monticello configurations, is the corresponding way of loading the packages using gofer to list each package in the mcm file in a gofer script? So mcm will not used or it is just that there have no been time to add those capability to gofer? Thanks -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |