Gofer vs Installer

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Gofer vs Installer

Miguel Cobá
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Lukas Renggli
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Miguel Cobá
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Stéphane Ducasse
>>
>>
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Schwab,Wilhelm K
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Lukas Renggli
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Schwab,Wilhelm K
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Schwab,Wilhelm K
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Lukas Renggli
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Lukas Renggli
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Schwab,Wilhelm K
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

keith1y
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Igor Stasenko
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.
>
Which is partly your own fault.
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

keith1y


>>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Lukas Renggli
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
Reply | Threaded
Open this post in threaded view
|

Re: Gofer vs Installer

Miguel Cobá

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
12