Gofer versus Installer was: The Trunk: Morphic-laza.489.mcz

> "Lets accept it. For good or bad, monticello packages are the way to
> go,
>
> and gofer desing is around this observation."
>
> Your position is too extreme. I argued against SqueakMap about as hard
> as anybody can six, seven months ago.
> I got serious push back. Gofer is great and there are lots of reasons
> to use it. But I don't see any reason to
> break things, or decide for people who want to do things in an older
> mode.

>
> "Better, add to Installer that which Gofer does that Installer
> doesn't."
>
> This doesn't seem like a great idea. As somebody pointed out, it has
> no active maintainer. Lukas maintains Gofer
> and there are reasons to use it: closer relationship with Pharo,
> contemporary MC integration (Metacello).
>
>
> Chris
>
>

> El mar, 14-12-2010 a las 15:43 -0500, Chris Cunnington escribió:
>> "Lets accept it. For good or bad, monticello packages are the way to
>> go,
>>
>> and gofer desing is around this observation."
>>
>> Your position is too extreme. I argued against SqueakMap about as hard
>> as anybody can six, seven months ago.
>> I got serious push back. Gofer is great and there are lots of reasons
>> to use it. But I don't see any reason to
>> break things, or decide for people who want to do things in an older
>> mode.
>
> Why extreme? Gofer made a decision to focus on Monticello because that
> is the current de facto format widely in use. I didn't say, kill
> SqueakMap or kill universes, I only said that almost nobody uses because
> great majority uses squeaksource and monticello to publish new packages
> and releases. Even if 10 or 50 people can raise the hand and say that
> they use changesets or publish in squeakmap, that, based on observations
> on the the squeak trunk, the squeaksouce.com latest activity landing
> page and the mailing lists from pharo and squeak, this is a hard fact.
> This is akin to the whole blue, yellow, other color click. The fact that
> someday the way to use Squeak and smalltalk was with a 3-colors mouse
> that doesn't validate the 2010 persistence of those terms to instruct
> users to do something. This is plain blindness to the fact that today,
> the mice sold and used in windows and linux have only 2 and with luck, 3
> button, that in laptops is hard to do a 'middle-click' and the most
> evident one that macs have only one button.
> Legacy (code|platforms|customs) must be left behind and sometimes even
> killed for our own good. :)  (that is indeed extreme, but I believe
> it ;)
>
>
>>
>> "Better, add to Installer that which Gofer does that Installer
>> doesn't."
>>
>> This doesn't seem like a great idea. As somebody pointed out, it has
>> no active maintainer. Lukas maintains Gofer
>> and there are reasons to use it: closer relationship with Pharo,
>> contemporary MC integration (Metacello).
>>
>>
>> Chris
>>
>>
>
> --
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
>
>
>
>
>

>"Lets accept it. For good or bad, monticello packages are the way to go,
>
>and gofer desing is around this observation."
>
>Your position is too extreme. I argued against SqueakMap about as hard as anybody can six, seven months ago.
>I got serious push back. Gofer is great and there are lots of reasons to use it. But I don't see any reason to
>break things, or decide for people who want to do things in an older mode.
>
>"Better, add to Installer that which Gofer does that Installer doesn't."
>
>This doesn't seem like a great idea. As somebody pointed out, it has no active maintainer.

>
>  - Chris
>
>
>
> On Tue, Dec 14, 2010 at 3:06 PM, Miguel Cobá <[hidden email]> wrote:
> > El mar, 14-12-2010 a las 15:43 -0500, Chris Cunnington escribió:
> >> "Lets accept it. For good or bad, monticello packages are the way to
> >> go,
> >>
> >> and gofer desing is around this observation."
> >>
> >> Your position is too extreme. I argued against SqueakMap about as hard
> >> as anybody can six, seven months ago.
> >> I got serious push back. Gofer is great and there are lots of reasons
> >> to use it. But I don't see any reason to
> >> break things, or decide for people who want to do things in an older
> >> mode.
> >
> > Why extreme? Gofer made a decision to focus on Monticello because that
> > is the current de facto format widely in use. I didn't say, kill
> > SqueakMap or kill universes, I only said that almost nobody uses because
> > great majority uses squeaksource and monticello to publish new packages
> > and releases. Even if 10 or 50 people can raise the hand and say that
> > they use changesets or publish in squeakmap, that, based on observations
> > on the the squeak trunk, the squeaksouce.com latest activity landing
> > page and the mailing lists from pharo and squeak, this is a hard fact.
> > This is akin to the whole blue, yellow, other color click. The fact that
> > someday the way to use Squeak and smalltalk was with a 3-colors mouse
> > that doesn't validate the 2010 persistence of those terms to instruct
> > users to do something. This is plain blindness to the fact that today,
> > the mice sold and used in windows and linux have only 2 and with luck, 3
> > button, that in laptops is hard to do a 'middle-click' and the most
> > evident one that macs have only one button.
> > Legacy (code|platforms|customs) must be left behind and sometimes even
> > killed for our own good. :)  (that is indeed extreme, but I believe
> > it ;)
> >
> >
> >>
> >> "Better, add to Installer that which Gofer does that Installer
> >> doesn't."
> >>
> >> This doesn't seem like a great idea. As somebody pointed out, it has
> >> no active maintainer. Lukas maintains Gofer
> >> and there are reasons to use it: closer relationship with Pharo,
> >> contemporary MC integration (Metacello).
> >>
> >>
> >> Chris
> >>
> >>
> >
> > --
> > Miguel Cobá
> > http://twitter.com/MiguelCobaMtz
> > http://miguel.leugim.com.mx
> >
> >
> >
> >
> >
>

>>
>> The purpose for continuing to refer to colors is for the added level
>> of indirection required by Squeak's platform-independence...   So we
>> don't have to say, in all dcoumentation:  "If you're running on
>> Windows, press the right button, if a Mac the Command-click, etc."
>
> Maybe, but you're exchanging that for "read XXX wiki page and learn what
> a blue button/menu is, no matter that in the real no new computer comes
> with blue buttons"
>

> El mar, 14-12-2010 a las 15:35 -0600, Chris Muller escribió:
>> > This is akin to the whole blue, yellow, other color click. The fact that
>> > someday the way to use Squeak and smalltalk was with a 3-colors mouse
>> > that doesn't validate the 2010 persistence of those terms to instruct
>> > users to do something.
>>
>> Miguel, for a better understanding about this, see:
>>
>>     http://wiki.squeak.org/squeak/897
>
> Sure, I now, but I didn't know until three years after my first contact
> with Squeak. That is not good and we can expect that every new user read
> a wiki page to learn what the issue with the colored buttons is. This is
> not going to (and have not) work. Aim to the lazy user. To the user that
> "know" that the mouse have 2 buttons (or sometimes 3) or the mac user
> that only have a big square button  and that is not going to learn why
> is good to have more than one button.
>
>
>>
>> The purpose for continuing to refer to colors is for the added level
>> of indirection required by Squeak's platform-independence...   So we
>> don't have to say, in all dcoumentation:  "If you're running on
>> Windows, press the right button, if a Mac the Command-click, etc."
>
> Maybe, but you're exchanging that for "read XXX wiki page and learn what
> a blue button/menu is, no matter that in the real no new computer comes
> with blue buttons"
>
>>
>>  - Chris
>>
>>
>>
>> On Tue, Dec 14, 2010 at 3:06 PM, Miguel Cobá <[hidden email]> wrote:
>> > El mar, 14-12-2010 a las 15:43 -0500, Chris Cunnington escribió:
>> >> "Lets accept it. For good or bad, monticello packages are the way to
>> >> go,
>> >>
>> >> and gofer desing is around this observation."
>> >>
>> >> Your position is too extreme. I argued against SqueakMap about as hard
>> >> as anybody can six, seven months ago.
>> >> I got serious push back. Gofer is great and there are lots of reasons
>> >> to use it. But I don't see any reason to
>> >> break things, or decide for people who want to do things in an older
>> >> mode.
>> >
>> > Why extreme? Gofer made a decision to focus on Monticello because that
>> > is the current de facto format widely in use. I didn't say, kill
>> > SqueakMap or kill universes, I only said that almost nobody uses because
>> > great majority uses squeaksource and monticello to publish new packages
>> > and releases. Even if 10 or 50 people can raise the hand and say that
>> > they use changesets or publish in squeakmap, that, based on observations
>> > on the the squeak trunk, the squeaksouce.com latest activity landing
>> > page and the mailing lists from pharo and squeak, this is a hard fact.
>> > This is akin to the whole blue, yellow, other color click. The fact that
>> > someday the way to use Squeak and smalltalk was with a 3-colors mouse
>> > that doesn't validate the 2010 persistence of those terms to instruct
>> > users to do something. This is plain blindness to the fact that today,
>> > the mice sold and used in windows and linux have only 2 and with luck, 3
>> > button, that in laptops is hard to do a 'middle-click' and the most
>> > evident one that macs have only one button.
>> > Legacy (code|platforms|customs) must be left behind and sometimes even
>> > killed for our own good. :)  (that is indeed extreme, but I believe
>> > it ;)
>> >
>> >
>> >>
>> >> "Better, add to Installer that which Gofer does that Installer
>> >> doesn't."
>> >>
>> >> This doesn't seem like a great idea. As somebody pointed out, it has
>> >> no active maintainer. Lukas maintains Gofer
>> >> and there are reasons to use it: closer relationship with Pharo,
>> >> contemporary MC integration (Metacello).
>> >>
>> >>
>> >> Chris
>> >>
>> >>
>> >
>> > --
>> > Miguel Cobá
>> > http://twitter.com/MiguelCobaMtz
>> > http://miguel.leugim.com.mx
>> >
>> >
>> >
>> >
>> >
>>
>
> --
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
>
>
>
>
>

> Hi guys,
>
> Cross posted to Squeak and Pharo.
>
> On 14. 12. 2010 22:56, Ken G. Brown wrote:
>
>>> Lukas maintains Gofer
>>> and there are reasons to use it: closer relationship with Pharo, contemporary MC integration (Metacello).
>>
>> I can accept using Gofer in trunk, for things that require it like reading it's own scripts.
>> But I don't want to see Installer go away... because of all the things Installer does that Gofer doesn't.
>
> What if someone:
>
>  1. adds to Gofer loading from SqueakMap and other
>  2. then Lukas is kindly asked to rename it to the Installer.
>
> That way we will have a maintained installer with a meaningful name and
> everyone will be happy. Because we really need one and only one
> installer for both Squeak and Pharo.
>
> Best regards
> Janko
>
>
> --
> Janko Mivšek
> AIDA/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
>
>

> On 12/15/2010 6:27 AM, Janko Mivšek wrote:
>>
>> What if someone:
>>
>>  1. adds to Gofer loading from SqueakMap and other
>>  2. then Lukas is kindly asked to rename it to the Installer.
>>
>> That way we will have a maintained installer with a meaningful name and
>> everyone will be happy. Because we really need one and only one
>> installer for both Squeak and Pharo.
>
> Slightly wrong. Gofer isn't an installer. Gofer is the API for Monticello.
> If you wanted to rename it you should rename it simply to "Monticello" and
> merge it with the MC core packages.
>

> Folks -
>
> To illustrate my point about Gofer being an API, here is an
> implementation of the same API. Gofer's little brother -called Goofy-
> provides an implementation of the Gofer API but it's a bit simpler and
> comes in a single class (with a total of 400 LOC or so). It passes most
> of the Gofer tests.
>
> The exercise was actually interesting since it points out several things
> that are just plain broken from the Monticello perspective. I just
> posted a fix for the first issue - a way to get versions and names in a
> consistent way from different repositories. Clearly a thing that should
> be in Monticello.
>
> Another interesting issue is some of the cleanup that is in Gofer and
> pretty much directly replicated in Goofy's #cleanoutWorkingCopy:
> #unloadWorkingCopy: and #unregisterRepositories:. These are all things
> that need to be folded into MCWorkingCopy but I'll leave that for
> another day since I'm a bit tired right now and don't want to
> accidentally break MC in the process :-)
>
> In any case, if you look at Goofy I think you'll see the API much more
> clearly. It's a good API, but it doesn't need to be spread out amongst
> some 20-something classes.
>
> Cheers,
>    - Andreas

> pant, pant.
>
> Eliot
>
> On Wed, Dec 15, 2010 at 11:19 PM, Andreas Raab <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Folks -
>
>     To illustrate my point about Gofer being an API, here is an
>     implementation of the same API. Gofer's little brother -called
>     Goofy- provides an implementation of the Gofer API but it's a bit
>     simpler and comes in a single class (with a total of 400 LOC or so).
>     It passes most of the Gofer tests.
>
>     The exercise was actually interesting since it points out several
>     things that are just plain broken from the Monticello perspective. I
>     just posted a fix for the first issue - a way to get versions and
>     names in a consistent way from different repositories. Clearly a
>     thing that should be in Monticello.
>
>     Another interesting issue is some of the cleanup that is in Gofer
>     and pretty much directly replicated in Goofy's #cleanoutWorkingCopy:
>     #unloadWorkingCopy: and #unregisterRepositories:. These are all
>     things that need to be folded into MCWorkingCopy but I'll leave that
>     for another day since I'm a bit tired right now and don't want to
>     accidentally break MC in the process :-)
>
>     In any case, if you look at Goofy I think you'll see the API much
>     more clearly. It's a good API, but it doesn't need to be spread out
>     amongst some 20-something classes.
>
>     Cheers,
>       - Andreas
>
>     On 12/15/2010 9:54 AM, Andreas Raab wrote:
>
>         On 12/15/2010 9:21 AM, Chris Muller wrote:
>
>             One question that came to my mind last night: What does>
>             1000 lines
>             of Gofer code bring to Monticello-loading that I can't
>             already do with
>             just Monticello? or with a couple of facade methods added to
>             plain
>             MC?
>
>
>         I spent the evening yesterday to look at Gofer in detail and it
>         is what
>         led me to say that Gofer is really an API to Monticello, not an
>         installer. First, there is nothing in there that should not be
>         part of
>         Monticello proper; contrary to Installer and Metacello I would
>         expect
>         all the stuff that is in Gofer to be readily available in Monticello
>         itself. Gofer is simply a good facade to Monticello with a
>         useful API.
>
>         Secondly, much of the code in Gofer comes from the "command
>         pattern gone
>         wild" problem. Gofer simply overuses the command pattern. Every
>         operation is wrapped in a separate class without any need for
>         doing so.
>         As a consequence, things that should be a simple "self foo" become
>         unnecessarily complex in creation, setup, and execution. If you
>         would
>         take this out, it would reduce Gofer to 5 classes or so and the
>         total
>         code size by a significant amount while improving clarity.
>
>         As an API to Monticello, Gofer is very nice and we should
>         standardize on
>         it. But as a "replacement" for Installer it's not even in the same
>         ballpark.
>
>         Cheers,
>         - Andreas
>
>
>
>
>
>
>
>
>
>