I do most of my experimentation in Cuis these days; the smaller system (especially with regard to, but not limited to, it's Morphic implementation) really reduces the surface area of changes I need to make in order to try out an idea quickly, which leaves me feeling happier and more productive. I also really enjoy some of the usability tweaks like keyboard navigation, context menus that work well with touch screens, etc.

The difference in my productivity is so great, that I'm finding it faster to prototype things in Cuis and then port them to Squeak once my mental model is well baked. 

Cuis uses change sets because the mechanism is simple, which fits with the values behind Cuis. 

I spent an evening trying to see how far I could get making MC work in Cuis, and got about as far as making the UI and network parts work, but many of the tests failed. Making MC compatible with Cuis looks like a lot of work, as there is a *lot* of complexity wrapped up in Monticello. 

I'm using changesets quite a bit, as is Juan, so we have a head count of at least two. 

While I'm in total agreement that MC is the current defacto method for moving code around between images, I would like to make a conjecture: I would bet that the number of people still moving code around with change sets, given the small size of this community, is probably still statistically significant.

WRT Installer vs. Gofer, in spite of the fact that I'm ultimately in favor of a small core Squeak image (something more like Cuis,) I think for now at least, if we don't include both, or make both easily installable, we'll be leaving a small but significant minority of the community out in the cold. 

On Dec 14, 2010, at 12:01 PM, Miguel Cobá <miguel.coba at gmail.com> wrote:

> El mar, 14-12-2010 a las 13:13 -0600, Chris Muller escribió:
>> Does Gofer support all legacy formats?  ChangeSets, SqueakMap,
>> Universes, Monticello, Monticello Configurations?
> 
> Umm, how may people actually uses those legacy format (dead for me).
> Apart from magma, I know of no other project that uses SqueakMap and
> MCM for publishing new versions. Even less for universes and the
> changesets are from the time when Squeak was part of disney.
> As good as they could have been, they are, for all practical purpouses,
> dead. Monticello is the current de facto format for
> storing/publishing/sharing new code and new releases of packages. This
> legacy argument is good in theory but the reality is, they are going the
> way of the dodo.
> Universes, I can't remember the last time it had working packages for
> the current squeak/pharo image.
> 
> Lets accept it. For good or bad, monticello packages are the way to go,
> and gofer desing is around this observation.
> 
> 
>> 
>> I have nothing against aesthetics and compactness, but functionality
>> is a important criteria to me than lines of code.  I want an installer
>> utility to just work for me, not be a work of art to admire.  :-)
>> 
>> If Gofer only supports a subset of the Installer types, maybe
>> Installer could be stripped of its functions that overlap with Gofer
>> and employ Gofer for those parts.  That way, "Installer" can also
>> support Gofer scripts..?
>> 
>> - Chris
>> 
>> 
>> 
>> On Mon, Dec 13, 2010 at 2:23 PM, Bernhard Pieber <bernhard at pieber.com> wrote:
>>> Hi Ken,
>>> 
>>> If you ask... ;-)
>>> 
>>> Am 13.12.2010 um 18:21 schrieb Ken G. Brown:
>>>> I for one do not want to see Installer disappear.
>>>> Can anyone explain to me what advantage GoFer has over Installer?
>>>> Seem to me they are doing more or less the same thing.
>>> I like Gofer better than Installer for the following reasons:
>>> - Gofer has an active maintainer, the original author still maintains it.
>>> - Lukas writes top quality Smalltalk code IMO. I find the code cleaner. (That, of course, may just be my personal preference.)
>>> - Gofer is much smaller than Installer - 640 lines of code versus 1703 - thus the image would be smaller if we replaced Installer with Gofer.
>>> - At the same time Gofer has more functionality which I find quite useful, committing, fetching and pushing. See http://www.lukas-renggli.ch/blog/gofer for a short description.
>>> - Installer has a lot of code which is rarely used.
>>> - Installation code for packages which are compatible between Squeak and Pharo could be the same in many cases, which I find less confusing.
>>> - This brings Squeak and Pharo closer together again, which would be a good thing IMO.
>>> 
>>> Enough reasons in my opinion. Of course, reasonable people might disagree. ;-)
>>> 
>>> Cheers,
>>> Bernhard
>>> 
>> 
> 
> -- 
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
> 
> 
> 
>