Lex, thank you very much for taking the time for such a complete answer,
I appreciate it.

"Lex Spoon" <lex at cc.gatech.edu> writes:

> You raise a lot of issues, Chris.  A lot of these are actually better,
> if you the docs would just point you better.  Some are getting better, I
> think, but certainly still need work.
>

IME, this is not all unusual in Free software, especially when it
'moves' as fast as Squeak seems to.  Documentation always lags, and I've
notied serval times that when people ask Richard Stallman the best thing
to contribute, documentation and testing are alway at or very near the
top of the list.

But it is unfortunate, especially since Squeak's major intended audience
is the opposite of 'geekly'. :-)

Also, since I posted the original, I've learned a *lot* more - someone
on #squeak mentioned your Universes work, and I read a little about it.
That looks like a *big* step in the right direction, and believe me, I
am familiar with a lot of the issues and realize what a challenge coming
up with a reasonable solution is.

So I feel much better already, thanks.

> A few resources you should have in mind:
>
> 1. There is a Debian package of Squeak, but it is not in Debian proper
> because of licensing disputes.  (If you have any idea how to resolve
> that, it would be great to know -- writing to debian-legal has just
> gotten me into a never-progressing debate.)  Anyway, on the swiki, go to
> "Downloading Squeak", then "Download for Unix", and then "Squeak for
> Debian Users":
>
> 	http://minnow.cc.gatech.edu/squeak/3616
>
>
> 2. There is a "stable 3.7 universe" release which has loadable Comanche.
>  Grab the 3.7univ image from the Debian repository, or go to .  I know
> that that version basically works, because an older version of Universes
> was using that version.  (I've since dumped it in favor of a
> StringSocket-based protocol, augmented by a static webserver to help
> people behind firewalls -- which is the main reason to use HTTP outside
> of real web browsers.)
>

Thanks, if only I had known about that before!  In the meantime, I got
3.7 running from the linux tarball at the 'inria' site, though Goran and
C. Degroot (sp?) had to help debug Pakage Loader, which refused to load
*anything*.

UUIDGenerator's makeUnixSeed was getting nulls when it tried to read
/dev/urandom, and Goran suggested that I comment out rhe first two
lines.  After that - woot!  Everything I wanted - KomHttp, Seaside,
Swazoo, Postgres, MySql - all dropped right into place and fired up just
fine.

For the record, it looks like the Swiki distribution comes as an image
already bundled with (an older) Comanche?  I haven't tried that yet,
but plan to very soon, on my old, 200mhz server (with SCSI drives).

>
> That sucks about the man page.  I don't honestly have time to work on
> it, though....  You might want to poke around on the web and see if you
> can find a good description of the arguments.  Honestly, though, you
> don't need most of those options by far.
>

If I wasn't such a n00b w/Squeak, I probably would have split my
original post into two - one for here and the other for squeak-dev, but
I had no idea whether I would even be able to post to squeak-dev.

>
> To pick a nit, individual maintainers aren't that awesome.  However,

Yup, nobody's perfect, and there are all sorts of maintainers.

> Anyway, one thing we should adopt, IMHO, is the notion of generating
> stable *sets* of packages.  Additionally, we should adopt their approach
> of not breaking compatibility so much.  It's easy to say "let's move to
> the next great thing in Squeak", but all too often that battle cry seems
> to amount to loading half-working code that breaks compatibility with
> existing code.  All other things aside, we simply have to be careful
> about breaking code that *uses* Squeak.
>

To me, this seems to be the heart of the matter, and man, is it a tough
one.  It has been a while since I did serious OO work (I've been much
more focused on Lisp/Scheme for a couple of years, and database stuff
for a couple of years before that), but one I thing I *do* remember is
the necessity of being very, very careful how you design the message
protocol (I think that is the SmallTalk term?  Interface contract, more
generally).

Code needs to change over time, that is a given.  And keeping old
methods around so that old code doesn't break, or refactoring them to
use the newer ones isn't very pretty, either, or even always possible.

Another important factor here is the *type* of thing being written -
monolithic apps are one thing, reusable building blocks that other
people can rely on to incorporate into their programs entirely another,
and at least another order of magnitude more difficult to do well.

>
> They do indeed take 1-2 years to produce new stable releases.  I don't
> know whether we will end up in the same boat.  They, like us, seem to
> have trouble finding volunteers to help with those last several release
> critical bugs.  I agree that it's worth it, though, so long as it
> doesn't take any longer than this.  Having an occasional stable release
> is a very valuable thing.  It lets people work in Squeak without dealing
> with the day to day errors that developers are adding.
>

Producing a stable release of hundreds (as in Squeak's case) or
thousands (as in Debian's case) of software packages is simply a
mind-boggling feat, in my view.  Its like the saying about the dancing
dog - it isn't so much the fact it dances well that amazes, but the fact
that it dances at all. :-)

I noticed that in Squeak Map, some packages offer both a current release
and earlier versions - Comanche for example offers 3 versions, I think.
If we extend this idea a bit, a repository of all earlier published
versions might be useful for the more technically capable Squeak users -
does something like this exist?

One of the things that I really like about Squeak/ST is some of the
ideas inspired by Lisp and the old Lisp machines - access to the entire
system's code base, change-on-the-fly, browsers and built in version
control.  Concerning the latter, in the Lisp world one decides on a
number of versions to be kept for an object (this can be 'all'), and the
system takes care of it, so the recent change history is available
locally, but not when published, unless one chooses to include the
version history.  From the very little I know of Squeak, the
'changesets' facility is similar?  (At the moment, the Swiki on 'minnow'
seems to be refusing connections.)

I don't know if you are familiar w/Tom Lord's version control system,
GNU/Arch, but it uses *nix programs diff and patch to manage changes,
and when you grab a package from an Arch site, you get the entire change
history.  So it makes it easy to recreate any version of the software.
(In fact, they use the concept of a 'patchset'.)  IINM, CVS makes this
possible as well, though I think it takes a bit more work than with Arch.

More to the point, that is how Arch-maintained software is distributed -
with the version history.  The process of fetching the archive includes
applying all the patches to the original version, so when the fetch
process is complete, you have the current version, freshly
reconstructed, in your directories ready for building, if necessary.

So unless it is only binaries being shipped, one has the entire history.

With both Arch and CVS, it is possible to define 'synch points' across
multiple components of a project.  For example, just before shipping
something deemed 'stable', one flags the current state of the repository
with a 'label', and anytime thereafter it is simple to get that version
of the product out of the repository, even if extensive changes have
been made since.  One can even rollback the repository to that point.

If one were to combine the concept of Debian's pseudo-packages (I forget
at the moment the correct name), with either a remote repository
containing the complete version history, or local packages with version
history, it seems to me this would go a long way to ameliorating the
situation.

Simpler yet, a repository of all versions *released*, and
psuedo-packages, though this assumes that earlier releases have no image
version dependencies.

Let's use Swiki and Comanche as an example.  I notice that Swiki
currently ships in an image bundled with the version of Comanche it
requires.  Assuming there are no Squeak image version dependencies, it
would be a simple matter to define a pseudo package for Swiki-Comanche
that would, either from a remote repository or from the local packages,
extract the correct versions and proceed with the install.

I mention all this because I am far more familiar with Arch and CVS than
with Squeak changesets, but it seems with changesets already available
in Squeak that it is 'do-able'.

Of course, I am a total n00b here - doubtless this has all been
considered and rejected for some good reason that will become obviuos to
me as I learn a bit more!

>
>> I have noticed that some Squeak packages do run SUnits test as the last
>> step of install, a practice I like a lot and wish were more widespread.
>
> I don't really like this kind of thing, personally.  I wish packages
> would quietly load and unload and not try to get in my face with helpful
> offers.  Automatic test-running applies to every single package, and
> thus it should be supported in the test loader, not as a part of each
> package.
>

Ummm, surely the tests should ship with the source code?  And the only
reason I noticed the Sunit tests running was because I had a Transcript
open.  Curious monkey that I am, I decided to see what, if anything,
showed up during package loading - quite a bit, as it turns out.  If I
hadn't had the Transcript open, I don't think I would have seen anything
related to the tests, unless perhaps they failed?  And if the tests
failed, I would certainly hope I was notified!

> Same with documentation, configuration options, extra load options, and
> dependencies.  Don't say "Would you like to load *mumble*"; put it as a
> "Recommends" dependency.  Don't pop up a workspace -- install a document
> into the system documentation repository.
>

Or perhaps offer an option for a 'verbose' package load that if enabled,
does all the things you dislike ;-) otherwise behaves as you'd prefer?

Where might I find such a beast, this 'system documentation repository'?
I'd *love* to poke around in it for a while.  I think?

>


>
> -Lex
>
>

-- 
Simplicity of implementation is generally not a value, because the
elegance of use is what matters to users.
-- Erik Naggum, comp.lang.lisp 2002-08-02 21:11:54 PST