SqueakMap soon working in 4.0/4.1!

Hi!

Andreas Raab wrote:
> On 4/8/2010 5:23 AM, Göran Krampe wrote:
>> 1. Include some instructions in the image regarding "how to get stuff"
>> into the image. Seems like a good short term thing to do for 4.1. We can
>> easily explain the difference between SS and SM. PU (as it was called
>> earlier - Package Universes) is ... well, see below.
>
> If you write it, I'll add it to the welcome notes (or perhaps in the
> help menu).

Ok, I will give it a shot.

>> 2. Possibly throw out Universes in 4.1 *iff* it does not work anymore
>> and noone can fix it. I haven't even tried it. Does it work?
>
> It does. So does SM. Barring catastrophic circumstances, the set of
> packages for 4.1 hopefully won't have to change at this point. Remember,
> I want to ship this puppy next week :-)

I am all with you on that one. But... what about the PU for 4.1 as Ralph
mentioned? And also, I need to commit my fixes for SM into the image and
hopefully have time to check that it works. Will try that tonight.

regards, Göran

On 4/8/2010 8:26 AM, Göran Krampe wrote:
Thanks.

>>> 2. Possibly throw out Universes in 4.1 *iff* it does not work anymore
>>> and noone can fix it. I haven't even tried it. Does it work?
>>
>> It does. So does SM. Barring catastrophic circumstances, the set of
>> packages for 4.1 hopefully won't have to change at this point.
>> Remember, I want to ship this puppy next week :-)
>
> I am all with you on that one. But... what about the PU for 4.1 as Ralph
> mentioned?

There has not been a separate PU for 3.10, for 3.11, for Pharo, for 4.0,
nor for 4.1. Yes, the *idea* was that every image would have its own PU
but after several years of use I think we can conclude that the idea
didn't work. That happens. Unless people really want to propose that we
ship an empty PU?

(As an off-topic, the entire direction is very high on my priority list
for things to push for in 4.2 but I'm way to busy with finalizing 4.1
right now to participate in these discussions. Leave some for me, will
'ya :-)

> And also, I need to commit my fixes for SM into the image and
> hopefully have time to check that it works. Will try that tonight.

Great, thanks!

Cheers,
   - Andreas

Chris, yes, you've made me mad.  Since you've completely missed the
point of SqueakMap, won't you please stop pissing all over it and
refrain from "tough-guy" comments about abusing animals (which are
just plain offensive)?

SqueakMap is a piece of *gold* that has been sitting in front of us,
mis-understood and under-appreciated, for years.  The first thing to
understand about SqueakMap is that it is not a tool for merely
"loading code".  If "loading code" is all you want to do, then just go
back to SqueakSource and leave SM alone.

No, SqueakMap is a *presentation tool* that, unlike SqueakSource,
allows an author to deliver a "presentation of software".  A
presentation that is made up of a combination of code AND objects.

If there is anything out there for Squeak that stands ready to "help
newbies", it is SqueakMap.  It should or at least could be used to
load packages that present themselves in a educational or
tutorial-like fashion.  Who needs an on-line "book" about Seaside when
a new user could have an interactive media experience presenting a
*working* Seaside right in front of them, as a live presentation in a
Squeak image.   A "Seaside Tutorial" package loaded from SqueakMap
with one-click.  It wouldn't matter if it wasn't the absolute latest
version of Seaside, because the newbie is just there to learn the core
concepts.  The end of the tutorial, could tell them where to get the
real "latest" Seaside.

It supports SAR installation, so the authors have _unlimited_
flexibility to go out and load other packages from SqueakSource,
SqueakMap, Universes, whatever they want, all with one-click.  It
couldn't get any easier for a newbie, and there's no need for a
dependencies "framework" here because SM does not need to be a SCM
tool.  We already have one, it's called Monticello.

I also find it ridiculous to blame (SM) for packages "not working".
SqueakMap does it's job, which is to store and retrieve the packages
(presentations!) that human users put there.  It's classic GIGO, quit
blaming the tool..

 - Chris


On Thu, Apr 8, 2010 at 6:25 AM, Chris Cunnington
<[hidden email]> wrote:

There is one fundamental problem with both the SqueakMap and Universes model that has not been mentioned yet: It does not encourage participation. For a package author, maintaining a package entry is just an additional burden. And a package user cannot really do much about a broken package entry.

Contrast that with the Trunk Model: One reason it works is that it takes almost zero effort to participate. You publish a fix to the inbox and announce that on squeak-dev. And it's very simple for a core developer to take it and commit to the trunk.

IMHO we need something similarly simple for a package management system for Squeak. Something where it is easy to share. If one user figures out how to get a particular package to load, it must be trivial to share that method. And submitting one such "package loading instruction" must not sign up the user to be perpetual maintainer of the package.

So I think the private "ownership" model is flawed. We need a package management system that allows easy contribution. Maybe SqueakMap can be restructured for this, but currently it seems heavily geared towards single maintainers.

- Bert -

Hi!

Bert Freudenberg wrote:
> There is one fundamental problem with both the SqueakMap and Universes model
 > that has not been mentioned yet: It does not encourage participation.
For a
 > package author, maintaining a package entry is just an additional burden.
 > And a package user cannot really do much about a broken package entry.
>
> Contrast that with the Trunk Model: One reason it works is that it takes
 > almost zero effort to participate. You publish a fix to the inbox and
announce
 > that on squeak-dev. And it's very simple for a core developer to take
it and
 > commit to the trunk.
>
> IMHO we need something similarly simple for a package management system for
 > Squeak. Something where it is easy to share. If one user figures out
how to get
 > a particular package to load, it must be trivial to share that method.
 > And submitting one such "package loading instruction" must not sign
up the user
 > to be perpetual maintainer of the package.
>
> So I think the private "ownership" model is flawed. We need a package management
 > system that allows easy contribution. Maybe SqueakMap can be
restructured for this,
> but currently it seems heavily geared towards single maintainers.

Without going into this in depth there are some things worth mentioning:

- Co-maintainers. Although there is always one owner of a package on SM,
there can be multiple co-maintainers. And today they can do the same
things, except change ownership and co-maintainers IIRC. I agree, not a
medicin here, but worth mentioning.

- Unofficial releases. This was something I toyed with, but never got
done. The idea is of course that anyone can make a release of a given
package - but it will marked as a non-official release.

- The new SM model that I have in my head. :) It builds on the
realization that *almost* everything on SqueakMap is held inside a
personal account - in other words "information about code and packages
etc that I want to share with other people". So that would be a very
nice "partitioning boundary" for a distributed model.

BUT... I agree with you Bert. :)

regards, Göran

> There is one fundamental problem with both the SqueakMap and Universes model that has not been mentioned yet: It does not encourage participation.  For a package author, maintaining a package entry is just an additional burden. And a package user cannot really do much about a broken package entry.
>
> Contrast that with the Trunk Model: One reason it works is that it takes almost zero effort to participate. You publish a fix to the inbox and announce that on squeak-dev. And it's very simple for a core developer to take it and commit to the trunk.

These statements are true, but based on the premise that the goal is
to "participate".  For "participation",
as you said, we already have the trunk process, therefore, I don't
think SM needs to try to duplicate the fulfillment of that role
because the goal of SM isn't to offer the "latest and greatest" of
every package.  Instead, I think SM can fill a gap in the area of
documentation and exploration.

How does the trunk process let me explore MorphicWrappers?  Answer:
it doesn't.  SqueakMap does, because all of the older Squeak images
are available, and since SM documents which image version each package
is for, it provides an avenue for quickly exploring an older package
that *works* in the image it says it works in.

SM is not about "the future", it is about the "past".  It's a reliable
archive of past works, how to load them, what image they last worked
in, etc...

> IMHO we need something similarly simple for a package management system for Squeak. Something where it is easy to share. If one user figures out how to get a particular package to load, it must be trivial to share that method. And submitting one such "package loading instruction" must not sign up the user to be perpetual maintainer of the package.
>
> So I think the private "ownership" model is flawed. We need a package management system that allows easy contribution.  Maybe SqueakMap can be restructured for this, but currently it seems heavily geared towards single maintainers.

I'm not against trying to address this issue; but I just want to keep
our focus on the fact that we don't need SM to be as flexible as our
SCM toolset because it is fulfilling a different role.

 - Chris

On 13.04.2010, at 16:59, Chris Muller wrote:
But how do we make the SM entries for a particular package and a particular Squeak version? *That* is where I see the bottleneck.

Someone who figures out a load procedure because they need a certain package in their image, with all its dependencies, must have a simple way to share that, in a way that does not require contacting anyone else.

- Bert -