SqueakMap crashes in 3.10 beta.7158

Hi!

Andreas Raab <[hidden email]> wrote:
> Also, this only seems to emphasize the complementary nature of Universes
> and SM. If, say, Universes would use SM as their "backend-storage" you
> could have your cake and eat it too: Sets of community-tested packages
> that are available for one-click install, and "all code ever written for
> Squeak" available on SM for historical or porting purposes.

I have always viewed a Universe to be "more or less" a sub collection (a
list really) of specific *releases* of packages that is collectively
maintained by a smaller (smaller than the whole Squeak community - and
possibly just being a few people) team.

Given that definition I always felt it could be represented by a new
co-maintained SM artifact that is simply just such a list. If I an
Giovanni (plus hopefully one or two more?) get around doing SM3 then I
suspect we would include such a concept.

regards, Göran

On 11/1/07, Andreas Raab <[hidden email]> wrote:
>
> I figured it was a typo ;-) So the basic difference between SM and
> Universes is that the latter uses a community policy (you "ought" not to
> put bad things there) right?

Yep.

> This sounds reasonable but can we then
> please drop the silly nonsense about "guaranteed to work together"?

Fine with me.  Anything in software "guaranteed" sounds like
propaganda anyway. :)

>If
> you need a catchy marketing phrase, how about "community tested"? (in
> the best of all worlds this is just what it would be)
>
> Also, this only seems to emphasize the complementary nature of Universes
> and SM. If, say, Universes would use SM as their "backend-storage" you
> could have your cake and eat it too: Sets of community-tested packages
> that are available for one-click install, and "all code ever written for
> Squeak" available on SM for historical or porting purposes.

With the newer versions of Universes it can do this in fact.  SM is
one of the sources for a package.

I'm personally looking forward to what Göran has to propose with SM3.

[hidden email] wrote: indeed.
> This means that you can easily write snippets of code interrogating it,
>  
Installer search: 'Author:Bob'.
> you can use it offline (yes you can) etc etc.
>
> AFAIK Installer (while being a nice concept) operates by web scraping,
>  
indeed it does if SM is not loaded.
> which is fine BUT it thus "works around" the SM model and does not work
> offline and does not offer the domain model and does not give you client
> side caching (?) and does also not have code to use the server side
>  
No client side caching indeed, but for building an image for
distribution I am not going to distribute the cache.

I am not saying whether or not SM should be given to end users for all
of these great features. I personally think that SM should be in the
standard distribution.

I am talking specifically about the minimal image that is the stated
deliverable of 3.10. The image from which you can build images for
specific domains. Should this image have SM in it or not? Actually it
shouldn't have universes either, since universes can be loaded from
SqueakMap.

Monticello can go. SUnit-GUI can go too.

Then we might have the actual possibility if loading what we want to load.

For example choosing Monticello 1.5 is actually hindered by the fact
that Monticello is already present in the "3.10 release" image. I have
to jump through hoops in the Universes release of MC1.5 in order to
overwrite MC1.0.

(The update stream should use Installer to load its Monticello packages
in case Monticello is not present)
> cache (I am guessing).
> So even though I like Installer, don't simplify it for people who know
> less - it is NOT a drop in replacement of the SM code.
>  
But it is capable of bootstrapping a minimum image into the form you
want, and many developers will want SM.

For deployment I am happy to build from an Installer script without
Universes or SM.
> But yes, if you WANT to skip all the above parts - then fine, it works.
>
> regards, Göran
>  
If I want those parts it is only one line away...

Installer wsm install: 'SqueakMap'.


all the best

Keith

On Thu, Nov 01, 2007 at 09:43:58AM -0700, Andreas Raab wrote:
I meant it in the sense of how I as a package maintainer would expect
SqueakMap and Universes to work. I don't mean to comment on the
implementations, or whether the two should be integrated.

For example, there are various releases of the OSProcess package listed
on SqueakMap that claim to support images back to Squeak 2.8. If I
release something new, I will expect to register it on SqueakMap. Any
of these versions of the package might end up being registered in a
Universe, possibly with my knowledge and possibly not (this has
actually happened already, so it's not a theoretical example).

It's already enough of a hassle for me to keep SqueakMap entries up
to date, so I don't want to be responsible for figuring out all of
the possible Universes that might need to point to various versions
of my package. In a few cases I might have enough time and interest
to keep track of this and do the necessary testing, but in general
I will not.

On the other hand, if I download a new Squeak image and want to load
OSProcess, I like being able to do this with the Universe loader. As
a Squeak user, it's simply a very convenient way to do this, and as
the package maintainer it's a good way for me to make sure that I
load the same version of the package that other users of this Universe
are seeing.

As a user of SqueakMap and Universes, a loose coupling between the
two of them works perfectly fine for me. Having them be more integrated
sounds like a good thing, but it does not matter to me one way or the
other as long as they both work and serve their intended purposes.

Dave

Hi!

Keith Hodges <[hidden email]> wrote:
[SNIP of all good points]

Yes, I agree with everything you said. :)

regards, Göran

On 11/1/07, Jason Johnson <[hidden email]> wrote:
> On 11/1/07, Chris Muller <[hidden email]> wrote:
> > SqueakMap supports SAR files, which can do *anything*.  Therefore it,
> > too, supports dependencies.
>
> By writing scripts?  In this case I think we can do better.  I mean,
> if someone wanted to modify SM to expose some interface for adding
> dependencies and then implement that interface by creating a script
> inside the SAR then that's good enough.  Just not the ad hoc scripts
> that are done today that fight with each other and so on.

C'mon Jason, I did that a long time ago.  I just added a button to
Monticello Configurations browser called, "Build SAR".  It makes a
one-click self-installing SAR.

It took all of about one hour to implement, and I knew nothing about
Monticello beforehand (still don't).

> As explained in another mail, it doesn't do this.  If you add a
> package to a universe, then add an upgraded version of that package to
> the universe later, of course it picks the most up to date version
> that you have claimed works.

So if it's always picking "the most up to date" branches are
unsupported then?  If so, how is this "better"?

> I suppose you could argue that the act of adding the new version
> should remove the old one from the universe, but I believe it is there
> for the "upgrade" functionality.

Monticello already supports "upgrade".  I see nothing new here.

> > What exactly does "guaranteed to work together" mean?
> > ...
> > how can it be said "guaranteed to work?"
>
> It's the same concept as they have with the Debian apt-get system,

I'm not familiar with that, so that doesn't mean anything to me.

> > By "certiifed" do you mean an assessment of the level of quality?  If
> > so, SqueakMap has this too ("Solid as a rock" ... "Full of bugs for
> > developers only).
>
> Doesn't everyone just pick "Full of bugs" so they don't get blamed if
> it breaks? :)

I don't.  That seems like a pretty chicken-shit thing to do.  That has
little to do with the (SqueakMap) technology anyway?  No software can
stop GIGO.

> > A given version of Squeak?  Yes it does.  They all indicate what
> > versions of Squeak they are for, and when you load it you get a
> > warning if your version of Squeak does not match, but still allowing
> > to proceed at your risk.
>
> But the issue is that no one is updating and saying "yes this does
> work in 3.9/3.10".  I have seen plenty of times where I read about
> some package I should get, it's the latest version, so I go to SM and
> it says the package is for 3.7.

How can it be updated if no one has tried it?  The fact that it is not
updated every time a new Squeak comes out is USEFUL because it means
it hasn't been tested.

Again, I ask you to define the meaning of "works".  This is a non-issue.

> The "advantage" of Universes is that nothing can be loaded until it's
> put in the Universe, so no one can tell me to go load some package
> without setting it up to be in 3.9/etc.

Sounds like the computer controlling the user.  I only believe in the opposite.

It sounds like great legacy stuff like MorphicWrappers will never be

Ok, so for MorphicWrappers and other great stuff available on
SqueakMap, "Universes can't do it".  Fine.  I won't be using it.

El 11/2/07 11:37 AM, "Chris Muller" <[hidden email]> escribió:

> It sounds like great legacy stuff like MorphicWrappers will never be
MorphicWrappers and MathMorphs works on 3.10, Milan Zimmermann and I port to
3.9.
Is on SqueakSource and in FunSqueak 3.10.
When I complete redoing 3.10.1 (the blue pill) I publish new FunSqueak.

I hope next Smalltalks 2007 - Primer Congreso Argentino de Smalltalk  I
could meet Leandro Caniglia and some others original workers,

Edgar

It sounds like your mind is already made up on this, so I wont bother
replying anymore except one comment below.

On 11/2/07, Chris Muller <[hidden email]> wrote:
>
> > Doesn't everyone just pick "Full of bugs" so they don't get blamed if
> > it breaks? :)
>
> I don't.  That seems like a pretty chicken-shit thing to do.  That has
> little to do with the (SqueakMap) technology anyway?  No software can
> stop GIGO.

Notice the smile?  I wasn't pointing this out as a critical flaw.  It
was half a joke, and half just to point out that the field doesn't
really mean that much in my experience.

Andreas Raab writes:
> That is definitely not true. The code in
> UUniverseBrowser>>allPackagesNeededToInstall:orIfImpossible: explicitly
> uses the latest version of a package; the basic loop goes like this:

You are both correct.  This method grabs the latest version within the
current universe.  Many universes are static, for example the stable
releases, and thus that version is fixed for all time.  Other universes,
such as the development universe, change over time.  The precise policy is
up to the maintainers of the universe.



> I don't get it. What you say above is in every way true for Squeakmap.
> First, I don't think you actually meant what you said above because it's
> trivially true in reverse: When putting v2 and v3 on SM and v4...v6 in
> Universes then SM would (obviously) still point at v3.

A motivating example would be the 3.7 stable universe.  If you want to work
with a 3.7-ish set of Squeak code, then you can still download the 3.7u2
image.  That image, released years ago, is a 3.7 image plus a pointer to
the "squeak3.7" stable universe.  That stable universe has 200 packages
that you can still load and work, years after the release was made.


-Lex