Discussion:
[squeak-dev] Perl is to CPAN as Squeak is to (what)?
Randal L. Schwartz
2012-01-28 12:18:54 UTC
Permalink
Since I promised the folks in #squeak I would start this thread...

It's been my observation for quite a while that Squeak is missing
the equivalent of what Perl has in the CPAN.

First, let me describe the CPAN:

Anyone can get a CPAN ID for free. Once they have a CPAN ID, they upload
packages to a central server, which are then indexed and replicated to 500+
places worldwide, usually within an hour.

A package has a name and a version number. Version numbers are floating point
numbers, with "larger = better". If the version number contains an
underscore, it's considered "better, but only beta" and not automatically
offered as an upgrade (see below).

In general, package names are *not* registered, meaning that if I upload
Foo-3.4, and you upload Foo-3.5, users around the world will be asked if they
want to upgrade my package with yours. By default, this allows cooperating
team members to upgrade new releases of a cooperative project, as long as they
work together on the version numbers. This also allows the
long-gone-developer's code to be updated in-absentia. Although this has the
possibility for abuse, in the 15 years of the CPAN it has only been abused a
few times, and the CPAN gods can quickly remedy the situation.

For more managed care, a package name or prefix can be *registered*, which
means only a small group of individuals can upload things in that prefix.
Again, this is rare, but solves the wildcard issue. If a package is
abandoned, the CPAN gods can transfer the registration or deregister it.

Any CPAN package can declare that it is dependent on another CPAN package, or
even particular versions of core-installed packages. The CPAN installer can
be told to automatically or manually install all dependencies (or even ignore
them, but that's rarely wise).

Speaking of which, the core Perl distro has had a CPAN installer for many
years (CPAN.pm), and even a newer one (CPANPLUS.pm) has been included in
recent releases. As long as the CPAN index can be read, and the packages
downloaded, anyone can write additional CPAN installers too, but they probably
won't go into the core.

As a result of the above rules:

* CPAN installation is easy
* CPAN publishing is easy
* The CPAN is vital and thriving - see search.cpan.org/recent

Notice about 50 uploads a *day*. And everything *works* in an
automated way, except for the "CPAN gods" exceptions listed above.

Now. Squeak has been around only half as long as Perl. But that's about
how long Perl was around before we came up with the CPAN, so it's about
time Squeak had the same thing, I think.

Here's what I know (and I could be wrong):

Squeakmap - *everything* is "registered", so cooperation is hard
Squeaksource - no index is made, so you have to find things yourself
Universes - like Squeakmap
Sake/Packages - single point of update, making publishing hard

And except for Squeakmap, there's none of these that have been in all of the
recent Squeak releases for installation, so we have a bootstrapping problem.
Even installing Universes is hard from Squeakmap. :)

And all of these systems are missing dependency and automatic upgrade
management.

Can we discuss something like the CPAN for Squeak?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Merik Voswinkel
2012-01-28 12:18:54 UTC
Permalink
+1
Post by Randal L. Schwartz
Since I promised the folks in #squeak I would start this thread...
It's been my observation for quite a while that Squeak is missing
the equivalent of what Perl has in the CPAN.
Yes, that is indeed something that is missing, and I think we need it
badly.
Post by Randal L. Schwartz
In general, package names are *not* registered, meaning that if I upload
Foo-3.4, and you upload Foo-3.5, users around the world will be asked if they
want to upgrade my package with yours. By default, this allows cooperating
team members to upgrade new releases of a cooperative project, as long as they
work together on the version numbers. This also allows the
long-gone-developer's code to be updated in-absentia.
I agree that not registering is better.
Post by Randal L. Schwartz
* CPAN installation is easy
* CPAN publishing is easy
Lowering this barrier in Squeak is important

Merik
Andreas Raab
2012-01-28 12:18:54 UTC
Permalink
Post by Randal L. Schwartz
Can we discuss something like the CPAN for Squeak?
I like the idea. From a practical point of view it seems that relaxing
the rules at SqueakMap such that "registered" access becomes an option
seems the most realistic approach. In addition, one might consider
creating a breed of SM and Squeaksource by having SM automatically index
SqueakSource projects.

Cheers,
- Andreas
Post by Randal L. Schwartz
Since I promised the folks in #squeak I would start this thread...
It's been my observation for quite a while that Squeak is missing
the equivalent of what Perl has in the CPAN.
Anyone can get a CPAN ID for free. Once they have a CPAN ID, they upload
packages to a central server, which are then indexed and replicated to 500+
places worldwide, usually within an hour.
A package has a name and a version number. Version numbers are floating point
numbers, with "larger = better". If the version number contains an
underscore, it's considered "better, but only beta" and not automatically
offered as an upgrade (see below).
In general, package names are *not* registered, meaning that if I upload
Foo-3.4, and you upload Foo-3.5, users around the world will be asked if they
want to upgrade my package with yours. By default, this allows cooperating
team members to upgrade new releases of a cooperative project, as long as they
work together on the version numbers. This also allows the
long-gone-developer's code to be updated in-absentia. Although this has the
possibility for abuse, in the 15 years of the CPAN it has only been abused a
few times, and the CPAN gods can quickly remedy the situation.
For more managed care, a package name or prefix can be *registered*, which
means only a small group of individuals can upload things in that prefix.
Again, this is rare, but solves the wildcard issue. If a package is
abandoned, the CPAN gods can transfer the registration or deregister it.
Any CPAN package can declare that it is dependent on another CPAN package, or
even particular versions of core-installed packages. The CPAN installer can
be told to automatically or manually install all dependencies (or even ignore
them, but that's rarely wise).
Speaking of which, the core Perl distro has had a CPAN installer for many
years (CPAN.pm), and even a newer one (CPANPLUS.pm) has been included in
recent releases. As long as the CPAN index can be read, and the packages
downloaded, anyone can write additional CPAN installers too, but they probably
won't go into the core.
* CPAN installation is easy
* CPAN publishing is easy
* The CPAN is vital and thriving - see search.cpan.org/recent
Notice about 50 uploads a *day*. And everything *works* in an
automated way, except for the "CPAN gods" exceptions listed above.
Now. Squeak has been around only half as long as Perl. But that's about
how long Perl was around before we came up with the CPAN, so it's about
time Squeak had the same thing, I think.
Squeakmap - *everything* is "registered", so cooperation is hard
Squeaksource - no index is made, so you have to find things yourself
Universes - like Squeakmap
Sake/Packages - single point of update, making publishing hard
And except for Squeakmap, there's none of these that have been in all of the
recent Squeak releases for installation, so we have a bootstrapping problem.
Even installing Universes is hard from Squeakmap. :)
And all of these systems are missing dependency and automatic upgrade
management.
Can we discuss something like the CPAN for Squeak?
Ralph Johnson
2012-01-28 12:18:54 UTC
Permalink
I would like to speak up for Package Universe.

I have always disliked SqueakMap and I like Package Universe. The
problem with SqueakMap is that there is no dependency information. I
can't just select a package in SqueakMap and file it in and expect it
to work. I can do that with Package Universe. With SqueakMap, I have
to read comments and try to figure out what else needs to be filed in.
I have found PU to be much easier to use than SM. I haven't
published anything with either system, so by "to use" I mean "to get
packages so I can run them" not "to publish packages".

Of course, SM could be fixed. I can't see what would be hard, so I
wonder why it hasn't been done.

A "feature" of Squeak that might differentiate it from perl is that
there are many versions of Squeak. Packages that work with one image
might not work with another. So, if you are using 3.8 then you do not
necessarily want the latest version of some package if that package
only works in 3.9 or 3.10. PU addresses this problem by having a
different Universe for each version of the image, though I think there
is currently a Universe only for 3.9 and 3.10. Even if the code for
PU could run in earlier images, it isn't useful until someone builds a
Universe for it.

This could be handled in SqueakMap by saying that you only load the
versions of packages that have been registered to work with your
image.

In theory, PU is much different from CPAN because it limits who is
allowed to maintain a package. In practice, lots of people are able
to do it. Existing Universes have had a large set of people who can
change them, and pretty much anybody who wanted to do it, could. So,
in practice that aspect of CPAN isn't much different from Universes.

CPAN seems to be distributed, whereas each Universe is on a single
server. Plus, Universes (as with SqueakMap) do not actually store the
source code, but just have pointers to it. Most users can't tell the
difference, though.

-Ralph
Randal L. Schwartz
2012-01-28 12:18:54 UTC
Permalink
Ralph> A "feature" of Squeak that might differentiate it from perl is that
Ralph> there are many versions of Squeak. Packages that work with one image
Ralph> might not work with another. So, if you are using 3.8 then you do not
Ralph> necessarily want the latest version of some package if that package
Ralph> only works in 3.9 or 3.10. PU addresses this problem by having a
Ralph> different Universe for each version of the image, though I think there
Ralph> is currently a Universe only for 3.9 and 3.10. Even if the code for
Ralph> PU could run in earlier images, it isn't useful until someone builds a
Ralph> Universe for it.

It would be nice if it would work like SM where SM at least says "this
might break", and lets you try anyway.

I think the UI for PU is also pretty "early", to put it nicely. At least
I can *search* in SM!

Maybe PU is the closest to CPAN we have. So the question is, do we keep
mutating PU into what I'm looking for? Or do we first need to agree that the
CPAN might be a pretty darn good model?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Ralph Johnson
2012-01-28 12:18:54 UTC
Permalink
On Thu, Jun 26, 2008 at 4:26 PM, Randal L. Schwartz
Post by Randal L. Schwartz
Maybe PU is the closest to CPAN we have. So the question is, do we keep
mutating PU into what I'm looking for? Or do we first need to agree that the
CPAN might be a pretty darn good model?
It might be easier to add dependency information to SqueakMap. I
don't have an opinion about that. I just wanted to point out the
features of PU that made me prefer it. I'd be happy if every Squeak
packaging system had those features. And if there was a single system
that had the best of all possible features.

CPAN is probably a good model. However, a model that works well for
one language does not always work well for another. How would you
think a CPAN-like system would handle the fact that people are using
3.6, 3.7, 3.8, 3.9 and 3.10 and that some packages work for all of
these, but some packages are specialized for a particular image?

-Ralph
Randal L. Schwartz
2012-01-28 12:18:54 UTC
Permalink
Ralph> CPAN is probably a good model. However, a model that works well for
Ralph> one language does not always work well for another. How would you
Ralph> think a CPAN-like system would handle the fact that people are using
Ralph> 3.6, 3.7, 3.8, 3.9 and 3.10 and that some packages work for all of
Ralph> these, but some packages are specialized for a particular image?

Well, that's why I'm liking Universes now. :)

We do need something that says package X works with squeak Y and package X
depends on package Z. so it's two dimensions, not just one.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Matthew Fulmer
2012-01-28 12:18:54 UTC
Permalink
Post by Randal L. Schwartz
Ralph> CPAN is probably a good model. However, a model that works well for
Ralph> one language does not always work well for another. How would you
Ralph> think a CPAN-like system would handle the fact that people are using
Ralph> 3.6, 3.7, 3.8, 3.9 and 3.10 and that some packages work for all of
Ralph> these, but some packages are specialized for a particular image?
Well, that's why I'm liking Universes now. :)
We do need something that says package X works with squeak Y and package X
depends on package Z. so it's two dimensions, not just one.
SqueakMap already does this: packages are marked as being stable
in certain image versions. Universes has no such mechanism
--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Merik Voswinkel
2012-01-28 12:18:54 UTC
Permalink
Post by Randal L. Schwartz
We do need something that says package X works with squeak Y and package X
depends on package Z. so it's two dimensions, not just one.
And what about patches?

When an Seaside website needs a patch of an Integer method, for example.

I once thought Monticello would solve distributing these dependent
packages,
but I was to stupid to figure out how.

How could SqueakSource and Monticello be integrated with this Squeak
Cpan?

Merik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080627/70714228/attachment.htm
stephane ducasse
2012-01-28 12:18:55 UTC
Permalink
But you can search also in PackageUniverse.
I agree with Ralph. I gave up trying somethig on SM because it broke
on me.

Stef
Post by Randal L. Schwartz
Ralph> A "feature" of Squeak that might differentiate it from perl is that
Ralph> there are many versions of Squeak. Packages that work with one image
Ralph> might not work with another. So, if you are using 3.8 then you do not
Ralph> necessarily want the latest version of some package if that package
Ralph> only works in 3.9 or 3.10. PU addresses this problem by having a
Ralph> different Universe for each version of the image, though I think there
Ralph> is currently a Universe only for 3.9 and 3.10. Even if the code for
Ralph> PU could run in earlier images, it isn't useful until someone builds a
Ralph> Universe for it.
It would be nice if it would work like SM where SM at least says "this
might break", and lets you try anyway.
I think the UI for PU is also pretty "early", to put it nicely. At least
I can *search* in SM!
Maybe PU is the closest to CPAN we have. So the question is, do we keep
mutating PU into what I'm looking for? Or do we first need to agree that the
CPAN might be a pretty darn good model?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Bert Freudenberg
2012-01-28 12:18:54 UTC
Permalink
Post by Ralph Johnson
Universes (as with SqueakMap) do not actually store the
source code, but just have pointers to it. Most users can't tell the
difference, though.
Actually, SqueakMap nowadays caches packages, because URLs got stale
too often.

I agree opening up is a relatively cheap and promising way to make
contributing easier.

- Bert -
stephane ducasse
2012-01-28 12:18:55 UTC
Permalink
I have a naive question
why Squeaksource/MC + config map does not work.

You can build map of components and sveral people can work on the same
project?

Stef
Post by Bert Freudenberg
Post by Ralph Johnson
Universes (as with SqueakMap) do not actually store the
source code, but just have pointers to it. Most users can't tell the
difference, though.
Actually, SqueakMap nowadays caches packages, because URLs got stale
too often.
I agree opening up is a relatively cheap and promising way to make
contributing easier.
- Bert -
Bert Freudenberg
2012-01-28 12:18:55 UTC
Permalink
I do not understand your question. An MC configuration is simply a
list of several MC package versions, to be loaded together, plus a
list of repositories to find the versions. It's an alternative to the
MC dependency mechanism, which for our needs was too inflexible. It's
also TSTTCPW so it might lack a great deal of sophistication.

- Bert -
Post by stephane ducasse
I have a naive question
why Squeaksource/MC + config map does not work.
You can build map of components and sveral people can work on the
same project?
Stef
Post by Bert Freudenberg
Post by Ralph Johnson
Universes (as with SqueakMap) do not actually store the
source code, but just have pointers to it. Most users can't tell the
difference, though.
Actually, SqueakMap nowadays caches packages, because URLs got
stale too often.
I agree opening up is a relatively cheap and promising way to make
contributing easier.
- Bert -
Sean Allen
2012-01-28 12:18:54 UTC
Permalink
CPAN is a killer feature for perl.

I've done projects in perl simply because of CPAN.
I found libraries etc I needed there quickly and easily,
no hunting around and said, good enough and banged out
the work.

I would love to see a CPAN for Squeak....
Göran Krampe
2012-01-28 12:18:55 UTC
Permalink
Hi all!

Being the principal developer of SM I thought I should "chip in", note
though that I have NOT read this thread and I am going to Mallorca
tomorrow. :)
Post by Randal L. Schwartz
Since I promised the folks in #squeak I would start this thread...
It's been my observation for quite a while that Squeak is missing
the equivalent of what Perl has in the CPAN.
Anyone can get a CPAN ID for free. Once they have a CPAN ID, they upload
packages to a central server, which are then indexed and replicated to 500+
places worldwide, usually within an hour.
Mmm, anyone can register on SM. One of the primary ideas with SM was to
not only keep track of packages but also of developers.

SM does have a very simplistic upload facility but it was mostly added for
hosting simple scripts.

And of course, SM lacks signatures etc. And there is no replication of
packages themselves - except for the server keeping a server side cache
(not very well known), but it was on the other hand designed more like a
"freshmeat" than a "cpan" - the map is downloaded and cached locally
inside your image.

This was btw also a primary idea - the fact that the whole map is a true
object model that you can easily use with normal Smalltalk. I still find
that aspect quite nice, even though the monolithic nature is something I
have wanted to move away from for several years.
Post by Randal L. Schwartz
A package has a name and a version number. Version numbers are floating point
numbers, with "larger = better". If the version number contains an
underscore, it's considered "better, but only beta" and not automatically
offered as an upgrade (see below).
SM keeps track of releases and each release has both an automatic version
number and a manual one. The automatic one is not that good (doesn't
support branching that good actually).
Post by Randal L. Schwartz
In general, package names are *not* registered, meaning that if I upload
Foo-3.4, and you upload Foo-3.5, users around the world will be asked if they
want to upgrade my package with yours. By default, this allows cooperating
team members to upgrade new releases of a cooperative project, as long as they
work together on the version numbers.
SM instead has a concept of co-maintainership - a maintainer can add other
developers as co-maintainers and they can more or less do the same stuff
as the maintainer can.

SM also has the ability to transfer packages. Hmmm, can't recall right now
if that is offered in the UI.
Post by Randal L. Schwartz
This also allows the
long-gone-developer's code to be updated in-absentia. Although this has the
possibility for abuse, in the 15 years of the CPAN it has only been abused a
few times, and the CPAN gods can quickly remedy the situation.
If someone wants to co-maintain it is IMHO quite easy to contact the
maintainer and get added as a co-maintainer. If the maintainer does not
answer - you can always talk to the SM "gods" = being me more or less.

But I very seldom get such calls so I am not sure this is a BIG problem
(yet).
Post by Randal L. Schwartz
For more managed care, a package name or prefix can be *registered*, which
means only a small group of individuals can upload things in that prefix.
Again, this is rare, but solves the wildcard issue. If a package is
abandoned, the CPAN gods can transfer the registration or deregister it.
Again, transfers are easily done in SM too. This is also why it has a
separate Authors-field, in order to give credit to the original authors
despite the current maintainers.
Post by Randal L. Schwartz
Any CPAN package can declare that it is dependent on another CPAN package, or
even particular versions of core-installed packages. The CPAN installer can
be told to automatically or manually install all dependencies (or even ignore
them, but that's rarely wise).
There is no dependency management in SM today. I started one model,
another guy did one too (can't recall his name) - and I asked him if he
could just add it and then take responsibility for maintaining it -
because I didn't quite grok the code - but there was no such interest at
the time.

I have repeatedly asked for help in adapting SM and adding dependencies,
but so far only a very few individuals have expressed interest in helping
out. Please, please, please raise your hand! :)

It would be great to:

- Clean the model, make it distributed and also make it "bidirectional" so
that client images can also "upload" model changes and thus open up for
Morphic UIs for maintaining packages (and not just the web UI).
- Smack a new Seaside good lookin UI on top of the model.
- Add dependencies to the model.
- Make it aware of Installer, Universes and Squeaksource
- Add free text indexing. In Gjallar we already have nice code for using
Swish-e.

...and of course there are tons of other things we could do.

[SNIP]
Post by Randal L. Schwartz
Squeakmap - *everything* is "registered", so cooperation is hard
Mmmm, not sure what the above means.
Post by Randal L. Schwartz
Squeaksource - no index is made, so you have to find things yourself
Universes - like Squeakmap
Sake/Packages - single point of update, making publishing hard
And except for Squeakmap, there's none of these that have been in all of the
recent Squeak releases for installation, so we have a bootstrapping problem.
Even installing Universes is hard from Squeakmap. :)
And all of these systems are missing dependency and automatic upgrade
management.
Can we discuss something like the CPAN for Squeak?
Hehe, of course. Ever since I created SM we *have* been discussing it AND
making things happen. When SS came around I expressed fears that it would
"compete" with SM. People didn't really agree - but I think we can clearly
see it today. Universes came about in order to attack lack of dependencies
in SM and I have repeatedly argued for merging Universes/SM but without
really getting any traction for that idea.

These days I don't have THAT much time to share - but IF there were a few
individuals standing up - I would definitely help out making something
happen. It just takes 2 raised arms. Or perhaps even just one. :)

regards, G?ran
Göran Krampe
2012-01-28 12:18:55 UTC
Permalink
Hi again!

Ok, read the thread and wanted to add a few things:

Dependencies
============
Adding dependency management to SM would not be hard. There have been one
successful attempt (though, don't ask me about the code) and there have
been several proposed models. My model may have been too "complex", but
eventually I came to the point where I said "Let's take ANY model".

Why it has not been done? Well, because only one person did it, and that
person didn't have time/energy/whatever to pull it all the way (not me).

I perhaps ended up trying to fix "too many things" in one go - so I got
stuck in "analysis/design paralysis". :)

Patches
=======
I personally would like to keep the "map" separate from the "format" and
the actual SCM/package tools. So SM handles many different formats, not
just MC. For patches I would like Deltas (as in DeltaStreams) to replace
ChangeSets.


There is one aspect of SM that I think people may miss:

Since SM can install .st-files .cs-files, mcz-files etc etc - there is
nothing really stopping us from adding new "kinds" of packages. For
example, I have toyed with the idea of adding a "Universe" package. The
package content itself would be a complete Universe map. Thus we could
have a group of co-maintainers of that Universe and they could make new
releases of it. The Universe itself would be simply a maintained "subset"
of SM packagereleases that work in a given environment - say a specific
image or whatever.

Distribution
============
The new model I have sketched on for SM is to go "distributed" like
apt-get etc. The concept of storing partial map information typically
using "dumb servers" and having the SM client code in the image "merge
them together". This would enable private SM catalogs, company wide SM
catalogs etc etc.

It would also enable "pushing" changes up to the map instead of going
through a centralized web UI. Thus much easier to make a Morphic UI (or
whatever) to *maintain* entries in SM.


Anyway, tons of ideas, tons of good things we can do. Just one thing
missing, and it is *always* the same thing:

** Noone actually steps up and offers to help in doing the work on SM to
make it happen!**

Except for Brian who did a really nice workover on the package loader UI,
and a few more things. :)

regards, G?ran
Benoit St-Jean
2012-01-28 12:18:55 UTC
Permalink
If I might add to the discussion, we should ask ourselves what is missing to the Cincom repository to become as useful/friendly/whatever as CPAN?? What are the pros and cons of the Cincom repository and Squeakmap as compared to CPAN ?? I don't think we're that far from a "Smalltalkish" CPAN.? I also think we definitely need such a mechanism.

?-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
Blog: lamneth.wordpress.com
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080627/b597fb5c/attachment.htm
Edgar J. De Cleene
2012-01-28 12:18:55 UTC
Permalink
Post by Göran Krampe
I have repeatedly argued for merging Universes/SM but without
really getting any traction for that idea.
+1

I always like Universes/SM merge , but as usual time is to short.
Web interface is HttpView2 ?
If so, I think a single way to way is to have some like

http://map1.squeakfoundation.org/sm/packages3dot8
http://map1.squeakfoundation.org/sm/packages3dot9
http://map1.squeakfoundation.org/sm/packages3dot10
http://map1.squeakfoundation.org/sm/packages3dot11
http://map1.squeakfoundation.org/sm/packagesSpoon
http://map1.squeakfoundation.org/sm/packagesCroquet
http://map1.squeakfoundation.org/sm/packagesOLPC
etc

I wish polish and have SqueakLightII out so too busy, but could help
testing.

Edgar
Claus Kick
2012-01-28 12:18:55 UTC
Permalink
Post by Randal L. Schwartz
Since I promised the folks in #squeak I would start this thread...
It's been my observation for quite a while that Squeak is missing
the equivalent of what Perl has in the CPAN.
Yes.

*snip CPAN description*
Post by Randal L. Schwartz
Any CPAN package can declare that it is dependent on another CPAN package, or
even particular versions of core-installed packages. The CPAN installer can
be told to automatically or manually install all dependencies (or even ignore
them, but that's rarely wise).
Updating the CPAN installer itself can be a bit of a PITA, though. I
have one server at work where updating CPAN is simply not working.

*snip*
Post by Randal L. Schwartz
Squeakmap - *everything* is "registered", so cooperation is hard
Squeaksource - no index is made, so you have to find things yourself
Universes - like Squeakmap
Sake/Packages - single point of update, making publishing hard
And except for Squeakmap, there's none of these that have been in all of the
recent Squeak releases for installation, so we have a bootstrapping problem.
Even installing Universes is hard from Squeakmap. :)
And all of these systems are missing dependency and automatic upgrade
management.
Can we discuss something like the CPAN for Squeak?
I think It would be a start to agree on one of the four above mentioned
systems, like CST has it with the public store (whatever problems STORE
itself might have aside).

The absence of something like STORE/CPAN that is what is driving me
towards CST.

The existence of CPAN is keeping me with Perl ;)
Keith Hodges
2012-01-28 12:18:56 UTC
Permalink
Post by Claus Kick
The absence of something like STORE/CPAN that is what is driving me
towards CST.
The existence of CPAN is keeping me with Perl ;)
The existence of sake/packages to enable me to consistently build and
debug the building of the production image that I want is helping to
keep me sane! (after attempting to achieve what I needed with Universes
drove me mad for a couple of weeks)

The last thing we need is yet another package management system, when we
have hardly started using the features of the existing ones.

Oh yes it is all very well to go and drum up political support for
various ideas and complain that it will not handle the needs of millions
of coders, but the reality is that it is a lot of hot air! (see next
paragraph)

The ***@lists.squeakfoundation.org list was recently re-rejuvenated
to address this very issue, and as far as I am aware we had 1 more
member subscribe to it as a result (and one member left). Hardly a sign
of a community desparate to actually contribute to make things better
for all, do you think?

Furthermore, the goals chosen by the current informal release team is to
work in ways which will support the disparate communities that are
emerging based upon squeak. (olpc etoys, sophie, croquet etc) Part of
this involves championing tools that have been designed to actually work
in all squeak derivatives.

Unfortunatelty none of these "other" communities have shown much
interest as yet. The invitation for volunteers to be a package-czar for
any version of squeak is still very much open.

==

Since the full list of actual dependencies relies upon use-ontext rather
than publication-context, having a central repository as the sole place
to manage dependencies is going to be useful but only to a limited extent.

I would personally prefer SqueakMap without dependencies, or at least if
it had them sake/packages would enable the defaults to be overridden.

I think we could re-write SqueakMap to be a front end manager of
Sake/Packages. If we did this then the dependencies could be managed to
resolve to the correct data entries. But having said that, who has the
time to actually do the work.

For those highlighting of lack of documentation for Sake/Packages , it
is true I have had very very little time since writing it... however it
DOES have class comments, and I have posted numerous examples and emails
in the past 5 months or so, so you could do worse than search the mail
archives for my posts.

best regards

Keith
Randal L. Schwartz
2012-01-28 12:18:56 UTC
Permalink
Keith> The last thing we need is yet another package management system, when we have
Keith> hardly started using the features of the existing ones.

I think this says more about the existing ones (including Sake/Packages) than
about the desire for something that works.

Keith> Oh yes it is all very well to go and drum up political support for
Keith> various ideas and complain that it will not handle the needs of
Keith> millions of coders, but the reality is that it is a lot of hot air!
Keith> (see next paragraph)

If you build it, they will come.

Nobody was *clamoring* for the CPAN before it existed. But once it did,
people started finding it easier to share their modules, and use other
people's modules.

I'm looking for that kind of ease. Where I can say:

"Here is a new parser generator I just created. it requires an XML
package. I think it runs on 3.9 but I've only tested it on 3.10."

and then publish it somewhere.

And then you, coming along, can say:

"I need a parser generator. Oh, here's one Randal wrote. I'll
install it... oh it looks like it needs an XML parser, so that's
getting installed too."

And then later, I can say:

"Oh, I have an update, and it requires a newer version of the XML parser."

And then you can notice that update in some tool, and press a button, and you
get both the newer version of the XML parser and my parser generator.

When it's *that* simple, I think 90% of the people will be happy.

This isn't the goal of Sake/Packages. So Keith, stop derailing this
conversation with what *you* want to do with Sake. I'm not talking about
configuration management.

I'm talking about simple "publish" and "subscribe" options.

Make it as easy as listed above, including scaling so that 20 people can all
"publish" in the same 5-minute window without knowing a darn thing about each
other, and you'll have what I'm setting as the goal. Your Packages isn't
meant for that. Squeakmap is a lot closer, but is missing a few things,
perhaps borrowed from Universes. We just all need to come together to make
this happen.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Stéphane Rollandin
2012-01-28 12:18:56 UTC
Permalink
Post by Randal L. Schwartz
Make it as easy as listed above, including scaling so that 20 people can all
"publish" in the same 5-minute window without knowing a darn thing about each
other, and you'll have what I'm setting as the goal. Your Packages isn't
meant for that. Squeakmap is a lot closer, but is missing a few things,
perhaps borrowed from Universes. We just all need to come together to make
this happen.
maybe what SqueakMap is missing is first-class actual objects for
package description. I mean that saying "this package Y loads into 3.9"
should be done by instanciating some kind of VersionCompatibility object
(the structure of which I have no real ideas about) and "this package Y
requires package X" would instanciate a PackageFetcher for X, which
along with the VersionCompatibility of both X and Y and the
PackageFetcher of X would figure out how to intall the whole thingy.

to say it differently, packages and their interactions should be made
first-class citizens of Squeak, so that the packages themselves can
reason about how and where they can be installed.

of course I have no clue about the actual implementation :) this is just
a sketch..


Stef
Sean Allen
2012-01-28 12:18:57 UTC
Permalink
Post by Randal L. Schwartz
"Here is a new parser generator I just created. it requires an XML
package. I think it runs on 3.9 but I've only tested it on 3.10."
and then publish it somewhere.
"I need a parser generator. Oh, here's one Randal wrote. I'll
install it... oh it looks like it needs an XML parser, so that's
getting installed too."
this aspect of cpan ( and ruby's gem system and some other systems. )
is just so nice. i don't have to care that package A depends on 15 other
packages, it tells me that when i want to install and gives me the
choice
install them or not. i hit yes to a few dependencies and bam! i have
something
that works 99% of the time.

do the same thing by hand, ugh... so much time.
The simplicity of this basic operation is the killer feature. You miss
it so much when you go to systems that don't handle all of it for you.

If you haven't used something like it, you don't know what you are
missing.
I speak as a convert who for years after CPAN was introduced continued
to build by hand because I was obstinate. I've seen the light,
all hail cpan, ruby gems, apt-get and all their brethren that 99%
of the time, work and save me tons of time.
Victor Rodriguez
2012-01-28 12:18:56 UTC
Permalink
On Fri, Jun 27, 2008 at 2:12 PM, Keith Hodges <***@yahoo.co.uk> wrote:
[snip]
Post by Keith Hodges
The last thing we need is yet another package management system, when we
have hardly started using the features of the existing ones.
What we need is a package management system that works, *period*. We
do not need a set of competing package systems that do not quite work.
Post by Keith Hodges
Oh yes it is all very well to go and drum up political support for various
ideas and complain that it will not handle the needs of millions of coders,
but the reality is that it is a lot of hot air! (see next paragraph)
address this very issue, and as far as I am aware we had 1 more member
subscribe to it as a result (and one member left). Hardly a sign of a
community desparate to actually contribute to make things better for all, do
you think?
I don't think so. I think that it is a sign of a community that has
given up on the current packaging systems.
Post by Keith Hodges
Furthermore, the goals chosen by the current informal release team is to
work in ways which will support the disparate communities that are emerging
based upon squeak. (olpc etoys, sophie, croquet etc) Part of this involves
championing tools that have been designed to actually work in all squeak
derivatives.
Squeak errs trying to please all, but that is another discussion.
[snip]
Post by Keith Hodges
I think we could re-write SqueakMap to be a front end manager of
Sake/Packages. If we did this then the dependencies could be managed to
resolve to the correct data entries. But having said that, who has the time
to actually do the work.
This, I think, is the crucial problem: who has the time to do the
work? And having multiple competing systems with no clear best option
just makes matter worse. Who, say, will work on SqueakMap if it is
going to be replaced by Universes? Who will work in Universes if it is
going to be replaces by Sake packages? And so on...

Hopefully, this thread will result in a project with a leader to see
it through, and not disipate like so many other things in squeak-dev.

For my part, I will try to contribute. Although my Smalltalk skills
are still pretty limited (and my time much more), I could, for
example, contribute to reimplementing SquekMap's interface in
Seaside.

Best Regards,

Victor Rodriguez.
Post by Keith Hodges
For those highlighting of lack of documentation for Sake/Packages , it is
true I have had very very little time since writing it... however it DOES
have class comments, and I have posted numerous examples and emails in the
past 5 months or so, so you could do worse than search the mail archives for
my posts.
best regards
Keith
nicolas cellier
2012-01-28 12:18:56 UTC
Permalink
Non profit organization is looking after a motivated fighting spirit
able to understand/resolve problems of/merge
- Monticello 1.0 1.5 2.0 ...
- Universe
- ChangeSet
- DeltaStream
- UpdateStream
- SqueakMap
- Sake
- Installer
- SAR
preferrably with good UI skills, both Morphic and Seaside,
experience of rock solid distributed services,
and an overall understanding of source code databases.

Knowledge in ImageSegment and/or Spoon-Naiad is a plus.

Unlimited gratitude rewards. Please send your expectations.

---------------

Given the skill level/salary ratio offered for the job, really
surprising if we cannot get a candidate...

Common cowards, anyone interested by the gauntlet?

---------------

Facing complexity, tentation of rewriting from scratch is high.
But didn't proliferation of good ideas already went out of control?
Please let us not invent a new one!

Have we other choice than progressing in SMALL STEPS?
Goran's ones seems reasonnnable / constructive...
Under the GSOC auspices maybe?
If only the pre-requisite list was not that frightening...

Any other dream should be reserved to solid financially supported teams.

Nicolas
Edgar J. De Cleene
2012-01-28 12:18:56 UTC
Permalink
Post by nicolas cellier
Non profit organization is looking after a motivated fighting spirit
able to understand/resolve problems of/merge
- Monticello 1.0 1.5 2.0 ...
- Universe
- ChangeSet
- DeltaStream
- UpdateStream
- SqueakMap
- Sake
- Installer
- SAR
preferrably with good UI skills, both Morphic and Seaside,
experience of rock solid distributed services,
and an overall understanding of source code databases.
Knowledge in ImageSegment and/or Spoon-Naiad is a plus.
Unlimited gratitude rewards. Please send your expectations.
---------------
Given the skill level/salary ratio offered for the job, really
surprising if we cannot get a candidate...
Common cowards, anyone interested by the gauntlet?
---------------
I plan to have this in SqueakLightII (aka. Unofficial 3.11)
Post by nicolas cellier
Have we other choice than progressing in SMALL STEPS?
I afraid no, so or we do a small step or we be always is same place
Post by nicolas cellier
solid financially supported teams.
Well, you could have more people working in Argentina.
At same Euro fare you could have 4.5 and a same U$S fare 3.1.
I have so many talented students going to do COBOL (they need eat you know
?)

Edgar
Claus Kick
2012-01-28 12:18:56 UTC
Permalink
Post by Keith Hodges
Post by Claus Kick
The absence of something like STORE/CPAN that is what is driving me
towards CST.
The existence of CPAN is keeping me with Perl ;)
The existence of sake/packages to enable me to consistently build and
debug the building of the production image that I want is helping to
keep me sane! (after attempting to achieve what I needed with Universes
drove me mad for a couple of weeks)
The last thing we need is yet another package management system, when we
have hardly started using the features of the existing ones.
I do not think there is need for another package management system, I just think that there should be an agreement on using and expanding _one_, incorporating what is best about all the others. I realize that means stepping on many, many toes and legs and probably even heads, but I think things need to be streamlined a bit.

If push comes to shove, I would even say, lets ditch them all and just use SVN like the rest of the planet (if that is possible). It is hard enough to sell a image-based language with a real IDE to the C-style crowd, the package management systems should not add their grain of salt to the soup.
--
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der N?he des Wahnsinns auf.
Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy.
More clearly, on the narrow path between lunacy and panic.
Right around the corner of fear of death,
not far away from idiotism and insanity."
Colin Putney
2012-01-28 12:18:57 UTC
Permalink
Post by Claus Kick
If push comes to shove, I would even say, lets ditch them all and
just use SVN like the rest of the planet (if that is possible). It
is hard enough to sell a image-based language with a real IDE to the
C-style crowd, the package management systems should not add their
grain of salt to the soup.
Been there, done that... <shudder/>

Monticello was created because this turned out not to be feasible in
practice. The simple fact is that Smalltalk *is* image based, and
that's a feature, not a bug. For those who can't accept that, there's
Ruby.

Colin
Andreas Raab
2012-01-28 12:18:57 UTC
Permalink
Post by Colin Putney
Post by Claus Kick
If push comes to shove, I would even say, lets ditch them all and just
use SVN like the rest of the planet (if that is possible). It is hard
enough to sell a image-based language with a real IDE to the C-style
crowd, the package management systems should not add their grain of
salt to the soup.
Been there, done that... <shudder/>
Monticello was created because this turned out not to be feasible in
practice.
Can you say something more about that? A couple of weeks ago I saw a
demo at HPI in Potsdam where students used SVN down to the method level,
and it seemed to me that this approach might very well work because the
SVN granularity is the same as the in-image granularity. It may also be
interesting that this wasn't even trying to deal with source files of
any sort - it retained the nature of the image and simply hooked it up
directly with SVN. From my perspective this looked like an
extraordinarily interesting approach that I am certain to try out as
soon as it is available.

Cheers,
- Andreas
Bert Freudenberg
2012-01-28 12:18:57 UTC
Permalink
Post by Andreas Raab
Post by Colin Putney
Post by Claus Kick
If push comes to shove, I would even say, lets ditch them all and
just use SVN like the rest of the planet (if that is possible). It
is hard enough to sell a image-based language with a real IDE to
the C-style crowd, the package management systems should not add
their grain of salt to the soup.
Been there, done that... <shudder/>
Monticello was created because this turned out not to be feasible
in practice.
Can you say something more about that? A couple of weeks ago I saw a
demo at HPI in Potsdam where students used SVN down to the method
level, and it seemed to me that this approach might very well work
because the SVN granularity is the same as the in-image granularity.
It may also be interesting that this wasn't even trying to deal with
source files of any sort - it retained the nature of the image and
simply hooked it up directly with SVN. From my perspective this
looked like an extraordinarily interesting approach that I am
certain to try out as soon as it is available.
Do you think it would be feasible to exclusively manage an image from
SVN sources?

The reason I'm asking is related to the "image" problem I reported
earlier, the Linux folks demand the image to be to bootstrapped from
sources + media files. Which IMHO would be a major re-engineering
effort. E.g.,

http://lists.laptop.org/pipermail/devel/2008-June/015868.html

which is even one of the nicer emails in the thread, there were openly
hostile posts, too.

- Bert -
David T. Lewis
2012-01-28 12:18:57 UTC
Permalink
Post by Bert Freudenberg
Do you think it would be feasible to exclusively manage an image from
SVN sources?
The reason I'm asking is related to the "image" problem I reported
earlier, the Linux folks demand the image to be to bootstrapped from
sources + media files. Which IMHO would be a major re-engineering
effort. E.g.,
Well, it's not a great fit with Squeak, but Smalltalk/X has always worked
this way (and probably Gnu Smalltalk too), so clearly it's possible.

But frankly I suspect that a good old fashioned update stream with
human-readable change sets applied to some known base system would
address most of the perceived problem. If the base system consists
of sources plus "media" (a well-recognized image of known heritage),
then everything applied subsequently is easily traced, and can be
reapplied by anyone interested in doing so.

I would also note that those annoying Linux folks might just have a
point here. If we had followed these guidelines consistently over the
last few years, we would not have ended up with the mess of lost
author initials, untraceable changes, and unidentified licensing that
we are faced with today.

I think that Edgar has talked about trying to rebuild Squeak 3.9/10
from changes on top of a solid 3.8 image. I think he has the right
idea: fully traceable sources, all in plain text, and easily rebuilt
from a known base system. The 3.8 image itself was built from update
streams all the way back to an image of known heritage and license
status. Really, this is not a bad state of affairs.

Dave
Yoshiki Ohshima
2012-01-28 12:18:57 UTC
Permalink
Post by David T. Lewis
I would also note that those annoying Linux folks might just have a
point here. If we had followed these guidelines consistently over the
last few years, we would not have ended up with the mess of lost
author initials, untraceable changes, and unidentified licensing that
we are faced with today.
At least this time around, the licencing part isn't question. We
are making progress^^;

BTW, there was a discussion about a month ago (I basically read them
just recently), and Bert was asking that how hard it is to do
bootstrap from source. I know many of you have thought about the
actual bootstrapping. That would go something like:

- Write a compiler in another language. That can generates the bits
that are same as CompiledMethods. For a class definition, it
creates (yes) the network of pointers.

- The compiler sticks the class definitions, method dictionaries,
subclass structure, and compiled methods into a big "int*" array.
The goal is to make that something just run, so for example, the
stuff managed by ClassDescription (instanceVariable names and
organization) don't have to be compiled. Stuff like the source
pointer is not needed at this stage.

- There should be a support for IdentityDictionary, Array, Symbol
and String. and for the latter two, a way to create instances
would be needed. SystemDictionary and Undeclared would be the
instances of IdentityDictionary that should be created and gets
into the int* array. The symbol table that manages the instances
of Symbol is needed during the compilation, but it probably
doesn't have to go into the int* array, as we can recreate it in
the next initialization stage.

- During the compilation, we may have some garbage, but of course we
just leave them in the int* array. A class may get many
subclasses. The subclasses array of the class may be assigned
many times, but we just cr

- In this senario, nil, true, false aren't needed, I believe (as
CompiledMethods don't hold onto them). However, it would be nice
to "create" them early and store in the int* array.

- A few more necessary instances that go to special objects array is
created. Perhaps only Processor and active context would be
needed.

- The int* array is saved into a file with the header.

- Now launch the image with a regular VM. The active context goes
over a list of classes and initialize them.

- Compile all sources again so that they get proper source pointer.
(Or, scan the sources and set the source pointers properly).

- Create a project, enter and save the image normally.

- Load more code. and keep it going.

How feasible is it to do? Or, do somebody have some idea that how
many contexts would we need to create "manually"? What other
instances are needed? How much code rewriting would be necessary?

Yes, there are other ways of doing it. For example, if we make the
kernel part is fairly small (like 500k), we can have a program that
holds onto the bytes as constant and write out to disk. This would be
enough to persuade these people. We can load all the rest onto it
later. (But if this is the case, I'd ask myself that if 300k is ok
why not 20MB? That was the artificial distinction Andreas mentioned,
I believe.)

-- Yoshiki
Ralph Johnson
2012-01-28 12:18:57 UTC
Permalink
Pavel Krivanek
http://www.comtalk.eu/Squeak/98
Post by Yoshiki Ohshima
- Write a compiler in another language. That can generates the bits
that are same as CompiledMethods. For a class definition, it
creates (yes) the network of pointers.
- The compiler sticks the class definitions, method dictionaries,
subclass structure, and compiled methods into a big "int*" array.
The goal is to make that something just run, so for example, the
stuff managed by ClassDescription (instanceVariable names and
organization) don't have to be compiled. Stuff like the source
pointer is not needed at this stage.
The compiler doesn't have to be in another language. What is
important is that the compiler builds a Squeak image from a text file.
The compiler can be written in Smalltalk as long as it uses only the
class definitions in the test file, not in the compiler's image.

In face, it would be possible to reuse the existing compiler to build
up a standard structure of classes in the image, but to put them all
in their own namespace. Thus, an Object class defined in the test
file would not be the same as the Object class used in the compiler.
Thus, a system that bootstraps images from text files could first read
the text file and produce a set of classes in the image, and then
write out an image that contains only those classes.

Pavel Krivanek's KernelImage does the second part, but not the first.
It creates a parallel class hierarchy by copying part of the existing
classes, then it writes out an image that contains only those classes.

So, I think you could make a bootstrapping compiler by hacking the
existing compiler to read in a regular .st file into a separate
namespace. Then you'd use KernelImage to write out the image. The
system would have to make sure that instances of String,
CompilerMethod, etc., pointed to the new classes and not the old, but
KernelImage has to do something like this already.

Given KernelImage, I don't think that the compiler is all that hard to
write. The hard part would be making the text file of all the
classes. If I were doing this, I'd hack KernelImage to create the
text file for me, so I could at least create something similar to
KernelImage.

-Ralph Johnson
tim Rowledge
2012-01-28 12:18:58 UTC
Permalink
Post by Ralph Johnson
In face, it would be possible to reuse the existing compiler to build
up a standard structure of classes in the image, but to put them all
in their own namespace. Thus, an Object class defined in the test
file would not be the same as the Object class used in the compiler.
Thus, a system that bootstraps images from text files could first read
the text file and produce a set of classes in the image, and then
write out an image that contains only those classes.
Pavel Krivanek's KernelImage does the second part, but not the first.
It creates a parallel class hierarchy by copying part of the existing
classes, then it writes out an image that contains only those classes.
Alejandro Reimondo's Fenix stuff read (through some extraordinarily
'creative' and Windows dependant code) source snippets from files and
built a parallel object hierarchy and then wrote an image out via a
modified tracer. It's a very simple idea but rather less simple to
implement correctly. It is however certainly doable.

In principle one could certainly keep a tree of SVN like form, read in
the code whilst traversing the tree, create objects to suit and then
trace only those objects to create an 'image created from source'.

And you know what? If we put together a system to do that, there would
still be objectors; there will always be objectors.

tim
--
tim Rowledge; ***@rowledge.org; http://www.rowledge.org/tim
Base 8 is just like base 10, if you are missing two fingers.
Michael Rueger
2012-01-28 12:18:58 UTC
Permalink
Post by tim Rowledge
And you know what? If we put together a system to do that, there would
still be objectors; there will always be objectors.
If you can't edit it in emacs, it's not OpenSource.
At least that seems to be the acid test for some people...

So unless we support the four step magic dance ritual
- edit in emacs
- make config
- make
- make install
we're out by default.
After that probably because it's not Python...

Michael
Michael Haupt
2012-01-28 12:18:58 UTC
Permalink
Hi Michael,
Post by Michael Rueger
After that probably because it's not Python...
ha! http://pypysqueak.blogspot.com/

scnr,

Michael
nicolas cellier
2012-01-28 12:18:58 UTC
Permalink
Post by tim Rowledge
Alejandro Reimondo's Fenix stuff read (through some extraordinarily
'creative' and Windows dependant code) source snippets from files and
built a parallel object hierarchy and then wrote an image out via a
modified tracer. It's a very simple idea but rather less simple to
implement correctly. It is however certainly doable.
In principle one could certainly keep a tree of SVN like form, read in
the code whilst traversing the tree, create objects to suit and then
trace only those objects to create an 'image created from source'.
And you know what? If we put together a system to do that, there would
still be objectors; there will always be objectors.
tim
--
This is the idea of replacing a "binary blob" (the image) with an
automatically generated "textual blob" (a textual description of the
object graph, or a script to reconstruct object graph).

Is it usable? A maintainer will use diff tools to check difference
between two versions.
Unfortunately, a small difference in an Object graph (think graph, not
tree) might result in a big difference in textual representation. Such
generator should take care to generate minimal textual diffs... That
means diffing two general graph, analyzing previous textual
representation and producing a textual representation closest to
previous one.

What a maintainer would need, is rather a new diff tool able to perform
above operation, find the diffs between two images...

A tool that analyzes a foreign image and generates a script able to
convert this image to the foreign one...

Not simple, a naive implementation would not work, for example because
of sourcePointers, an image is not independant form it's change files...

Nicolas
Rob Rothwell
2012-01-28 12:18:58 UTC
Permalink
Post by nicolas cellier
This is the idea of replacing a "binary blob" (the image) with an
automatically generated "textual blob" (a textual description of the object
graph, or a script to reconstruct object graph).
Is it usable? A maintainer will use diff tools to check difference between
two versions.
Unfortunately, a small difference in an Object graph (think graph, not
tree) might result in a big difference in textual representation. Such
generator should take care to generate minimal textual diffs... That means
diffing two general graph, analyzing previous textual representation and
producing a textual representation closest to previous one.
What a maintainer would need, is rather a new diff tool able to perform
above operation, find the diffs between two images...
A tool that analyzes a foreign image and generates a script able to convert
this image to the foreign one...
Not simple, a naive implementation would not work, for example because of
sourcePointers, an image is not independant form it's change files...
Not simple at all! I know this isn't exactly the same as what you are
talking about, but I saw some presentations at Smalltalk Solutions dealing
with file-based code storage and/or analysis:

http://www.stic.st/stic?content=sts08Detail#june18Detail

Using VisualWorks Store for GemStone Code Management

Porting experience report

Smalltalk Development Tools: Bringing Smalltalk to Eclipse

I think the consensus was "it's hard!"

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080629/c9c07796/attachment.htm
Yoshiki Ohshima
2012-01-28 12:19:01 UTC
Permalink
At Sun, 29 Jun 2008 07:31:26 -0500,
Post by Ralph Johnson
Pavel Krivanek
http://www.comtalk.eu/Squeak/98
Post by Yoshiki Ohshima
- Write a compiler in another language. That can generates the bits
that are same as CompiledMethods. For a class definition, it
creates (yes) the network of pointers.
- The compiler sticks the class definitions, method dictionaries,
subclass structure, and compiled methods into a big "int*" array.
The goal is to make that something just run, so for example, the
stuff managed by ClassDescription (instanceVariable names and
organization) don't have to be compiled. Stuff like the source
pointer is not needed at this stage.
The compiler doesn't have to be in another language. What is
important is that the compiler builds a Squeak image from a text file.
The compiler can be written in Smalltalk as long as it uses only the
class definitions in the test file, not in the compiler's image.
This is more or less settled but...

If the compiler is written in Smalltalk, we would have a binary
image to store the compiler; and some people wouldn't like it.
Nonetheless, it can be in Slang and we can just show the translated C
code as if it is the "egg".

-- Yoshiki
K. K. Subramaniam
2012-01-28 12:18:59 UTC
Permalink
? BTW, there was a discussion about a month ago (I basically read them
just recently), and Bert was asking that how hard it is to do
bootstrap from source. ?I know many of you have thought about the
actual bootstrapping.
The OOPSLA Squeak paper refers to "Design a new ObjectMemory and image file
format". Were these design notes ever published anywhere? They could be
included in Squeak package along with the description of chunk file format
used for sources and changes.

Subbu
Igor Stasenko
2012-01-28 12:18:59 UTC
Permalink
What Linux people proposing looks controversial to me.

Why, bits which was written in early '80 and then forgotten because
they don't needed anymore now become important? :)
A proposal sounds like: lets forget what we're done in last decades
and start it over again. Just because of what?
Smalltalk image is a living system. Try load and save new version of
image. We could say, its the same image. But we all know, that many
objects and states within newly saved image will be different to
original image. So how you suppose to convince linux-people that given
image is a product of creating from text sources? After few iterations
(loading/saving and loading new code) it can be nearly impossible to
clearly state that.
--
Best regards,
Igor Stasenko AKA sig.
Damien Pollet
2012-01-28 12:19:00 UTC
Permalink
Post by Igor Stasenko
What Linux people proposing looks controversial to me.
Well, being able to redo the bootstrap from scratch or just to edit an
image from a separate tool would also make it simpler to throw stuff
away and get *really* minimal image for special purposes. You could
generate an image with just kernel plus application code, no UI, no
compiler, no reflective stuff...
--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet
Yoshiki Ohshima
2012-01-28 12:19:01 UTC
Permalink
Post by Igor Stasenko
What Linux people proposing looks controversial to me.
The attitude toward Etoys/Squeak vary widely among *them*, also.
Fortunately, the guys who are viciously bashing Etoys on the OLPC
devel list aren't the guys who make decisions there. Hopefully a bit
by bit, we can make some progress. That thread is great for these
decision makers because it is yet another example of how not to
discuss stuff^^;

-- Yoshiki
Bert Freudenberg
2012-01-28 12:18:57 UTC
Permalink
Post by David T. Lewis
Post by Bert Freudenberg
Do you think it would be feasible to exclusively manage an image from
SVN sources?
The reason I'm asking is related to the "image" problem I reported
earlier, the Linux folks demand the image to be to bootstrapped from
sources + media files. Which IMHO would be a major re-engineering
effort. E.g.,
Well, it's not a great fit with Squeak, but Smalltalk/X has always worked
this way (and probably Gnu Smalltalk too), so clearly it's possible.
But frankly I suspect that a good old fashioned update stream with
human-readable change sets applied to some known base system would
address most of the perceived problem.
No it would not. The main issue for them is that you have to start
from what they perceive as "binary blob" which is monkey-patched into
newer versions.

- Bert -
Post by David T. Lewis
If the base system consists
of sources plus "media" (a well-recognized image of known heritage),
then everything applied subsequently is easily traced, and can be
reapplied by anyone interested in doing so.
I would also note that those annoying Linux folks might just have a
point here. If we had followed these guidelines consistently over the
last few years, we would not have ended up with the mess of lost
author initials, untraceable changes, and unidentified licensing that
we are faced with today.
I think that Edgar has talked about trying to rebuild Squeak 3.9/10
from changes on top of a solid 3.8 image. I think he has the right
idea: fully traceable sources, all in plain text, and easily rebuilt
from a known base system. The 3.8 image itself was built from update
streams all the way back to an image of known heritage and license
status. Really, this is not a bad state of affairs.
Dave
Randal L. Schwartz
2012-01-28 12:18:58 UTC
Permalink
Bert> No it would not. The main issue for them is that you have to start from what
Bert> they perceive as "binary blob" which is monkey-patched into newer versions.

The C compiler would fit the same definition, by that reasoning.

At some point, you have toggle switches. Everything after that
is binary blobs building other binary blobs. Do they really need
us to trace it back to toggle switches?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Bert Freudenberg
2012-01-28 12:18:58 UTC
Permalink
Post by Randal L. Schwartz
Bert> No it would not. The main issue for them is that you have to start from what
Bert> they perceive as "binary blob" which is monkey-patched into
newer versions.
The C compiler would fit the same definition, by that reasoning.
No. You need a C compiler, true, but it builds the next C compiler
from text sources only, it does not clone itself.

This is also the difference between using SystemTracer to clone an
image into a new format vs. what Ralph suggested, using an image to
assemble a new image from scratch, containing only an explicitly
defined set of objects.

- Bert -
Randal L. Schwartz
2012-01-28 12:18:58 UTC
Permalink
Bert> No. You need a C compiler, true, but it builds the next C compiler from text
Bert> sources only, it does not clone itself.

Bert> This is also the difference between using SystemTracer to clone an image
Bert> into a new format vs. what Ralph suggested, using an image to assemble a
Bert> new image from scratch, containing only an explicitly defined set of
Bert> objects.

Sorry, I was inadvertently confusing what Ralph suggested (which seems
like the C compiler technique) with the objection to the SystemTracer.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Yoshiki Ohshima
2012-01-28 12:18:58 UTC
Permalink
At Sun, 29 Jun 2008 18:48:01 +0200,
Post by Bert Freudenberg
Post by Randal L. Schwartz
Bert> No it would not. The main issue for them is that you have to start from what
Bert> they perceive as "binary blob" which is monkey-patched into
newer versions.
The C compiler would fit the same definition, by that reasoning.
No. You need a C compiler, true, but it builds the next C compiler
from text sources only, it does not clone itself.
Come to think of it, we don't have to write the bootstrapper in
another language. They already accept Squeak VM, so we can write the
Smalltalk-to-CompiledMethod compiler in Slang (even better; write it
in OMeta and generate Slang), and generate a modified VM that has
different main(). That main() reads the "source" files, compile them
(by using the memory management in ObjectMemory), and write the result
to file. (Yes, you need a C compiler^^;)

Isn't it sound a bit more doable?

-- Yoshiki
Bert Freudenberg
2012-01-28 12:18:59 UTC
Permalink
Post by Yoshiki Ohshima
At Sun, 29 Jun 2008 18:48:01 +0200,
Post by Bert Freudenberg
Post by Randal L. Schwartz
Bert> No it would not. The main issue for them is that you have to start from what
Bert> they perceive as "binary blob" which is monkey-patched into
newer versions.
The C compiler would fit the same definition, by that reasoning.
No. You need a C compiler, true, but it builds the next C compiler
from text sources only, it does not clone itself.
Come to think of it, we don't have to write the bootstrapper in
another language. They already accept Squeak VM, so we can write the
Smalltalk-to-CompiledMethod compiler in Slang (even better; write it
in OMeta and generate Slang), and generate a modified VM that has
different main(). That main() reads the "source" files, compile them
(by using the memory management in ObjectMemory), and write the result
to file. (Yes, you need a C compiler^^;)
Isn't it sound a bit more doable?
A bit. But I suspect getting classes and methods assembled into an
image is not even half the work. We'll have to create objects, too,
that were manually assembled (I'm thinking of the PaintBox prototype
for example). Recreating a full Etoys image would still be a major
effort, since many parts would have to be rewritten to actually be
bootstrappable.

- Bert -
Yoshiki Ohshima
2012-01-28 12:19:01 UTC
Permalink
At Sun, 29 Jun 2008 20:27:33 +0200,
Post by Bert Freudenberg
Post by Yoshiki Ohshima
At Sun, 29 Jun 2008 18:48:01 +0200,
Post by Bert Freudenberg
Post by Randal L. Schwartz
Bert> No it would not. The main issue for them is that you have to start from what
Bert> they perceive as "binary blob" which is monkey-patched into
newer versions.
The C compiler would fit the same definition, by that reasoning.
No. You need a C compiler, true, but it builds the next C compiler
from text sources only, it does not clone itself.
Come to think of it, we don't have to write the bootstrapper in
another language. They already accept Squeak VM, so we can write the
Smalltalk-to-CompiledMethod compiler in Slang (even better; write it
in OMeta and generate Slang), and generate a modified VM that has
different main(). That main() reads the "source" files, compile them
(by using the memory management in ObjectMemory), and write the result
to file. (Yes, you need a C compiler^^;)
Isn't it sound a bit more doable?
A bit. But I suspect getting classes and methods assembled into an
image is not even half the work. We'll have to create objects, too,
that were manually assembled (I'm thinking of the PaintBox prototype
for example). Recreating a full Etoys image would still be a major
effort, since many parts would have to be rewritten to actually be
bootstrappable.
Certainly, the PaintBox is one of the worst examples! The basic
part may be able to "take off", but yes, there are stuff build around.

It sounds like I'm not going to do it (of course)...

-- Yoshiki
Jecel Assumpcao Jr
2012-01-28 12:18:59 UTC
Permalink
Post by Bert Freudenberg
Post by Randal L. Schwartz
The C compiler would fit the same definition, by that reasoning.
No. You need a C compiler, true, but it builds the next C compiler
from text sources only, it does not clone itself.
Jim Gettys pointed out Ken Thompson's "Trusting trust" paper when this
thread was started in the olpc/education lists:

http://cm.bell-labs.com/who/ken/trust.html

Even though you carefully examine the sources for the next version of
the C compiler, you can't know for sure what the current binary of the C
compiler will do with them. It can insert code not seen in the sources.

The solution is to use more than one C compiler. User your current gcc
binary to compile the sources for lcc. Then use the resulting binary to
compile the sources for gcc. A Thompson-style Trojan that can handle
this situation is still possible, but exponentially more complex than
one designed for a single set of sources.

One equivalent in Squeak would be to have image manipulation tools
written in some other language, but a simpler alternative would be to
port the Smalltalk based tools we are already using to VisualWorks or
(better yet) GNU Smalltalk. But since I don't see anyone bothering to do
the gcc->lcc->gcc dance I don't see why Squeak should be held to such a
high standard.

The binary blob thing is a normal problem for Linux distributions. If I
give you the complete sources for some C application but also include
some PNG files for button images and a splash screen, it would take
about as much effort for me to hide nasty stuff in these as it would to
do the same in a Squeak image. If you were aware that I had done this
you would easily find the place in the C code where I was using the
images as I shouldn't, but otherwise I bet any number of people could
look right at the spot and not notice the evil intent.

In the end it is a matter of trusting some people, as Ken pointed out in
his paper. There is not way for me to know what the Intel or AMD people
put in the processors I am using. I might get the full sources for some
Linux system but don't have enough seconds left in my life to read it
all myself (I did it in 1994 when it was orders of magnitude smaller).
So I have to trust my processor company and I have to trust my software
suppliers. Then only alternative is to build my own processor from TTLs
and do all the software:

http://www.homebrewcpu.com/

-- Jecel
tim Rowledge
2012-01-28 12:18:59 UTC
Permalink
Post by Bert Freudenberg
No. You need a C compiler, true, but it builds the next C compiler
from text sources only, it does not clone itself.
This is also the difference between using SystemTracer to clone an
image into a new format vs. what Ralph suggested, using an image to
assemble a new image from scratch, containing only an explicitly
defined set of objects.
This turns to not be the case. I did not suggest using the tracer to
clone an image into a new format; I suggested building a clump of new
objects in an existing image's memory and then tracing out that clump
only. How would one separate this from the operation of a typical C
compiler; read source, generate stuff into memory, write it out.

But it really doesn't matter. Nothing we can do will stop some people
from making pointless objections and raising a ruckus. They just don't
like Smalltalk.

tim
--
tim Rowledge; ***@rowledge.org; http://www.rowledge.org/tim
A computer scientist is someone who fixes things that aren't broken.
Keith Hodges
2012-01-28 12:18:59 UTC
Permalink
Post by tim Rowledge
But it really doesn't matter. Nothing we can do will stop some people
from making pointless objections and raising a ruckus. They just don't
like Smalltalk.
tim
-
Their loss, as far as I am concerned.

Keith
Claus Kick
2012-01-28 12:19:00 UTC
Permalink
tim Rowledge wrote:

*snip*
Post by tim Rowledge
But it really doesn't matter. Nothing we can do will stop some people
from making pointless objections and raising a ruckus. They just don't
like Smalltalk.
How did my former boss (Smalltalk software development shop) say it:
Their loss - why should I help them see the light?

From the list, I gather that they like GNU/Smalltalk, probably because
of the prefix. Other than that: Is it that important to get the Debian
crowd to accept Etoys?

Claus
Jecel Assumpcao Jr
2012-01-28 12:19:00 UTC
Permalink
Post by Claus Kick
*snip*
Post by tim Rowledge
But it really doesn't matter. Nothing we can do will stop some people
from making pointless objections and raising a ruckus. They just don't
like Smalltalk.
I call this the "Mac slots" syndrome. Back when the Mac was first
introduced I was amazed that the most popular excuse by far for
rejecting it was "it doesn't have slots and I can't buy a computer that
I can't expand as time goes on". I would have expected to hear that it
didn't have needed applications or that it was too expensive, but these
became common later (and are used to this day). When the Mac II and Mac
SE came out in 1987, guess how many of these complainers bought one?

Changing yourself to please people who currently don't like you doesn't
always get results.
Post by Claus Kick
Their loss - why should I help them see the light?
This is a very important point - they think it is our loss, that their
suggestions will add good things to Squeak and won't hurt anything we
already have. But as you mention below, other Smalltalks like
GNU/Smalltalk already have these features. So an alternative would be to
add EToys to one of them.

How about Self? Its VM is hand written C++ code. It includes the
compiler so it can build a new image entirely from a set of source files
(which happen to be already organized nicely into one-module-per-file
chunks divided in several subdirectories). It includes a version of
Morphic, which I personally find nicer than Squeak's (but far less
complete since it is older). The VM has advanced adaptive compilation
technology and performs very well.

So I nominate Self for Debian! Oh... right... the Linux port is very
outdated and was never complete in the first place. Why is that? Because
of all the "advantages" I listed above. Because of doing everything
right from the Linux viewpoint.

There are many things that are just fine in theory but never happen in
real life: a good Linux port of Self, an implementation of EToys in
Python, Squeak running on the Strongtalk VM and so on. Some of the
"flaws" that have pointed out in Squeak are exactly what have made
possible in practice for it to have great ports to many OSes and to
serve as the platform for EToys.
Post by Claus Kick
From the list, I gather that they like GNU/Smalltalk, probably because
of the prefix. Other than that: Is it that important to get the Debian
crowd to accept Etoys?
Do they want to reject it entirely or just want to lump it in the "non
free" repositories? Having Squeak live next to Adobe Acrobat Reader
rather than beside GIMP isn't something that worries me very much.

-- Jecel
Jason Johnson
2012-01-28 12:18:59 UTC
Permalink
Post by Colin Putney
Post by Claus Kick
If push comes to shove, I would even say, lets ditch them all and just
use SVN like the rest of the planet (if that is possible). It is hard enough
to sell a image-based language with a real IDE to the C-style crowd, the
package management systems should not add their grain of salt to the soup.
Been there, done that... <shudder/>
Monticello was created because this turned out not to be feasible in
practice.
Can you say something more about that? A couple of weeks ago I saw a demo at
HPI in Potsdam where students used SVN down to the method level, and it
seemed to me that this approach might very well work because the SVN
granularity is the same as the in-image granularity. It may also be
interesting that this wasn't even trying to deal with source files of any
sort - it retained the nature of the image and simply hooked it up directly
with SVN. From my perspective this looked like an extraordinarily
interesting approach that I am certain to try out as soon as it is
available.
Cheers,
- Andreas
Are you sure that was SVN and not something more modern like git,
mercuial, darcs or the like? I can't imagine SVN being seen as
anything but legacy by anyone but the most die-hard of fans. I
suspect integrating with a more modern system would be easier and it
would certainly make repositories better since SVN can't even do one
of the more common actions on a repository: merging [1].

[1] Well, they do a hack using comments to simulate merging with some
of the SVN bolt-on tools, but these days there is just no reason to
use a hack when you can just use one of many properly designed
systems.
Michael Haupt
2012-01-28 12:19:00 UTC
Permalink
Hi Jason,

On Mon, Jun 30, 2008 at 2:10 PM, Jason Johnson
Post by Jason Johnson
Are you sure that was SVN
sure it was.

Best,

Michael
Randal L. Schwartz
2012-01-28 12:19:00 UTC
Permalink
Jason> Are you sure that was SVN and not something more modern like git,
Jason> mercuial, darcs or the like? I can't imagine SVN being seen as
Jason> anything but legacy by anyone but the most die-hard of fans.

As a big proponent of git, I can tell you that the number of people and
companies who are just *now* considering the move from CVS(!) to "something
modern" like *SVN* is still staggering.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Jason Johnson
2012-01-28 12:19:05 UTC
Permalink
On Mon, Jun 30, 2008 at 4:57 PM, Randal L. Schwartz
Post by Randal L. Schwartz
As a big proponent of git, I can tell you that the number of people and
companies who are just *now* considering the move from CVS(!) to "something
modern" like *SVN* is still staggering.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
You're completely right, but having spent most of my career working
for big companies, I can say they are *not* the place to see where the
industry is moving. Only where it was years ago. :)
Colin Putney
2012-01-28 12:19:00 UTC
Permalink
Post by Andreas Raab
Post by Colin Putney
Post by Claus Kick
If push comes to shove, I would even say, lets ditch them all and
just use SVN like the rest of the planet (if that is possible). It
is hard enough to sell a image-based language with a real IDE to
the C-style crowd, the package management systems should not add
their grain of salt to the soup.
Been there, done that... <shudder/>
Monticello was created because this turned out not to be feasible
in practice.
Can you say something more about that? A couple of weeks ago I saw a
demo at HPI in Potsdam where students used SVN down to the method
level, and it seemed to me that this approach might very well work
because the SVN granularity is the same as the in-image granularity.
It may also be interesting that this wasn't even trying to deal with
source files of any sort - it retained the nature of the image and
simply hooked it up directly with SVN. From my perspective this
looked like an extraordinarily interesting approach that I am
certain to try out as soon as it is available.
DVS, the precursor to Monticello, stored all the source code to each
package in a single text file. Those files were then versioned using
CVS. The file format was a modified chunk format, with the chunks
sorted to prevent unnecessary textual churn. The usage pattern was to
file out, commit, update and file in.

A large part of the problem came from this two step process for
dealing with CVS. It was a hassle to keep track of the state of the
image relative to the state of the CVS working copy. It was easy to
make mistakes - commit when the wc wasn't up to date, develop when the
image wasn't up to date, etc. That would lead to weirdness in the code
that had to be manually sorted out.

Merge conflicts were another problem. The textual merging done by CVS
wasn't smart enough to deal with a lot of the changes that would
happen in development. For example, if two developers each added a
method that sorted similarly, they'd get a textual conflict even
though there was no conflict at the Smalltalk level.

As DVS developed we added functionality to minimize or work around
these issues, until it became clear that it would be less effort to
just keep our own version history and do our own merges. At that point
we ditched CVS and renamed DVS to Monticello.

Now, this idea of using one file per method has come up before, and I
believe it would eliminate many of the difficulties we had with DVS.
Merging methods would get better, for sure. Merging class definitions
would still be hassle, unless each instance variable, class variable,
and pool import were defined in separate files. If the sources and
changes files were eliminated, that would fix many of the
synchronization problems that we had with DVS, since there would be no
need to manually decide when to synchronize.

Still, I see two big problems with this approach. One is that the
synchronization problems don't entirely go away. What if some other
process modifies the files on disk? How does the image find out about
the change, and what should it do in response? What if the
modification happens while the image isn't running? There are probably
answers to these questions, but I doubt they'll be *good* answers.

The other big problem is that tens of thousands of tiny files is a
horribly inefficient way to store source code. Yes, disk is cheap. But
disk IO is not. I discovered this early in the development of MC2,
when I implemented a type of repository that stored each method in a
separate file. Loading OmniBrowser from that repository involved
opening, reading, and closing over 600 files, and was very slow. I
don't remember the exact timing, but I think it was like 5 to 10
minutes, and in any case it was far too slow. Avi wrote a repository
that stored every thing in a single indexed file, and now load time is
dominated by compilation.

A quick doIt in my working image shows 44682 methods. Now imagine that
on start up, the image scans all those files to make sure that all its
compiled methods are up to date. That will take a very, very long time.

Colin
Avi Bryant
2012-01-28 12:19:00 UTC
Permalink
The other big problem is that tens of thousands of tiny files is a horribly
inefficient way to store source code. Yes, disk is cheap. But disk IO is
not. I discovered this early in the development of MC2, when I implemented a
type of repository that stored each method in a separate file. Loading
OmniBrowser from that repository involved opening, reading, and closing over
600 files, and was very slow. I don't remember the exact timing, but I think
a repository that stored every thing in a single indexed file, and now load
time is dominated by compilation.
It's worth pointing out that file-based version control has advanced
significantly since we did this work - CVS and SVN are now far from
the state of the art. I haven't used git much, for example, but it
seems to be a well layered system, and it may be that we can build an
alternative front end to its database which is image-based rather than
working directory based. For example, imagine comparing an image
directly to this index file rather than to a directory full of files
on disk:

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-index

And look at this description of the workflow:

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-workflow

I personally believe that we're better off with Smalltalk-specific
version control, but if someone *is* looking at integration with more
mainstream tools, I would strongly suggest they start with git rather
than SVN.

Avi
Igor Stasenko
2012-01-28 12:19:00 UTC
Permalink
Post by Avi Bryant
The other big problem is that tens of thousands of tiny files is a horribly
inefficient way to store source code. Yes, disk is cheap. But disk IO is
not. I discovered this early in the development of MC2, when I implemented a
type of repository that stored each method in a separate file. Loading
OmniBrowser from that repository involved opening, reading, and closing over
600 files, and was very slow. I don't remember the exact timing, but I think
a repository that stored every thing in a single indexed file, and now load
time is dominated by compilation.
It's worth pointing out that file-based version control has advanced
significantly since we did this work - CVS and SVN are now far from
the state of the art. I haven't used git much, for example, but it
seems to be a well layered system, and it may be that we can build an
alternative front end to its database which is image-based rather than
working directory based. For example, imagine comparing an image
directly to this index file rather than to a directory full of files
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-index
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-workflow
I personally believe that we're better off with Smalltalk-specific
version control, but if someone *is* looking at integration with more
mainstream tools, I would strongly suggest they start with git rather
than SVN.
This is quite interesting.
Really, if we could just avoid using file-based working directory and
make image to be a kind of 'working directory' this would simplify
things a lot - no need to make file outs and synchronization is
always made between current methods in image and git repository.
Interesting, how much coding needed to connect image with git
repository in that way.
Post by Avi Bryant
Avi
--
Best regards,
Igor Stasenko AKA sig.
Avi Bryant
2012-01-28 12:19:00 UTC
Permalink
Post by Igor Stasenko
This is quite interesting.
Really, if we could just avoid using file-based working directory and
make image to be a kind of 'working directory' this would simplify
things a lot - no need to make file outs and synchronization is
always made between current methods in image and git repository.
Interesting, how much coding needed to connect image with git
repository in that way.
Well, I don't know how much coding it would be, but from a *very*
cursory look I would say what you need to do is model the index file
format in Smalltalk, and reproduce the update-index and checkout-index
commands. Once you had that, you could reuse all the normal
merge/commit/etc commands from git, because those all operate on the
index and on the repository database.

Avi
Avi Bryant
2012-01-28 12:19:01 UTC
Permalink
Post by Avi Bryant
Well, I don't know how much coding it would be, but from a *very*
cursory look I would say what you need to do is model the index file
format in Smalltalk, and reproduce the update-index and checkout-index
commands. Once you had that, you could reuse all the normal
merge/commit/etc commands from git, because those all operate on the
index and on the repository database.
Here's (I think) the equivalent Java code to what you'd need...

http://repo.or.cz/w/egit.git?a=blob;f=org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java;h=5be404e63041471d64a45e268d0ee04a7378d3c6;hb=HEAD
Colin Putney
2012-01-28 12:19:02 UTC
Permalink
Post by Igor Stasenko
This is quite interesting.
Really, if we could just avoid using file-based working directory and
make image to be a kind of 'working directory' this would simplify
things a lot - no need to make file outs and synchronization is
always made between current methods in image and git repository.
Interesting, how much coding needed to connect image with git
repository in that way.
One option would be to use FUSE (or something similar) to make the
image appear to be a filesystem. That wouldn't be git-specific, and
would even appease all the folks that want to edit their code with
emacs.

Colin
Keith Hodges
2012-01-28 12:19:02 UTC
Permalink
Post by Colin Putney
Post by Igor Stasenko
This is quite interesting.
Really, if we could just avoid using file-based working directory and
make image to be a kind of 'working directory' this would simplify
things a lot - no need to make file outs and synchronization is
always made between current methods in image and git repository.
Interesting, how much coding needed to connect image with git
repository in that way.
One option would be to use FUSE (or something similar) to make the
image appear to be a filesystem. That wouldn't be git-specific, and
would even appease all the folks that want to edit their code with emacs.
Colin
It has been done

Keith
Igor Stasenko
2012-01-28 12:19:02 UTC
Permalink
Post by Keith Hodges
Post by Igor Stasenko
This is quite interesting.
Really, if we could just avoid using file-based working directory and
make image to be a kind of 'working directory' this would simplify
things a lot - no need to make file outs and synchronization is
always made between current methods in image and git repository.
Interesting, how much coding needed to connect image with git
repository in that way.
One option would be to use FUSE (or something similar) to make the image
appear to be a filesystem. That wouldn't be git-specific, and would even
appease all the folks that want to edit their code with emacs.
Colin
It has been done
Haha, really, run a file system adaptor in image. And then run git, or
any other file based version control tool on it.
The complication is , that most of such tools using subdirectories to
maintain own specific info (like CVS in CVS, and .svn with SVN).
So, you will need to make it able to store these files somewhere in
image , not only methods which are subject of version control.
Post by Keith Hodges
Keith
--
Best regards,
Igor Stasenko AKA sig.
Michael Haupt
2012-01-28 12:19:02 UTC
Permalink
Hi Igor,
Post by Igor Stasenko
Haha, really, run a file system adaptor in image. And then run git, or
any other file based version control tool on it.
that sounds like heresy to die-hard Smalltalk image paracletes,
agreed. ;-) The approach taken for SqueakSVN, where the image talks,
via a plugin, to the version management libraries directly, is clearly
more appreciable.
Post by Igor Stasenko
The complication is , that most of such tools using subdirectories to
maintain own specific info (like CVS in CVS, and .svn with SVN).
So, you will need to make it able to store these files somewhere in
image , not only methods which are subject of version control.
Right, that would be an interesting task for the file system to manage.

Best,

Michael
Post by Igor Stasenko
Keith
--
Best regards,
Igor Stasenko AKA sig.
Michael Haupt
2012-01-28 12:19:02 UTC
Permalink
Hi Colin,
One option would be to use FUSE (or something similar) to make the image
appear to be a filesystem. That wouldn't be git-specific, and would even
appease all the folks that want to edit their code with emacs.
SqueakFS exists, and is able to make an image available to the outside
(file system) world. We're in the process of setting up a development
repository (based on SVN, mind you). In the meantime, it's available
from www.squeaksource.com/SqueakFS.html in the current version.

Best,

Michael
Brent Pinkney
2012-01-28 12:19:02 UTC
Permalink
Hi,
Post by Michael Haupt
SqueakFS exists, and is able to make an image available to the outside
(file system) world. We're in the process of setting up a development
repository (based on SVN, mind you). In the meantime, it's available
from www.squeaksource.com/SqueakFS.html in the current version.
Do be so kind as to update the Project Description field on SqueakSource to describe this project.
It is a tad terse as it stands.

Brent
Michael Haupt
2012-01-28 12:19:02 UTC
Permalink
Hi Brent,
Post by Brent Pinkney
Do be so kind as to update the Project Description field on SqueakSource to describe this project.
It is a tad terse as it stands.
heh, indeed. :-) The Wiki page has loads of information instead.

I've put it on my to-do list; the description will be updated. Thanks
for pointing this out.

Best,

Michael
Colin Putney
2012-01-28 12:19:02 UTC
Permalink
Post by Michael Haupt
Hi Colin,
One option would be to use FUSE (or something similar) to make the image
appear to be a filesystem. That wouldn't be git-specific, and would even
appease all the folks that want to edit their code with emacs.
SqueakFS exists, and is able to make an image available to the outside
(file system) world. We're in the process of setting up a development
repository (based on SVN, mind you). In the meantime, it's available
from www.squeaksource.com/SqueakFS.html in the current version.
Ah good. I must have run across it at some point and forgotten about it.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080630/36d3e69a/attachment.htm
Lukas Renggli
2012-01-28 12:19:02 UTC
Permalink
Post by Michael Haupt
SqueakFS exists, and is able to make an image available to the outside
(file system) world. We're in the process of setting up a development
repository (based on SVN, mind you). In the meantime, it's available
from www.squeaksource.com/SqueakFS.html in the current
version.
Ah good. I must have run across it at some point and forgotten about it.
There is also the FTP server that I wrote together with Ian at ESUG 2005.

http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&printTitle=FTPlets&entry=3303394043

I used it for a while to develop from within an external editor, but
in the end the clumsy Squeak environment is still less annoying than
an external editor.

Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Colin Putney
2012-01-28 12:19:02 UTC
Permalink
Post by Lukas Renggli
Post by Michael Haupt
SqueakFS exists, and is able to make an image available to the outside
(file system) world. We're in the process of setting up a development
repository (based on SVN, mind you). In the meantime, it's available
from www.squeaksource.com/SqueakFS.html in the current
version.
Ah good. I must have run across it at some point and forgotten about it.
There is also the FTP server that I wrote together with Ian at ESUG 2005.
Yes, it's excellent. I use it for editing Javascript and CSS that live
inside the image as part of OB-Web.

Colin
Joshua ben Jore
2012-01-28 12:19:15 UTC
Permalink
Post by Michael Haupt
Hi Colin,
One option would be to use FUSE (or something similar) to make the image
appear to be a filesystem. That wouldn't be git-specific, and would even
appease all the folks that want to edit their code with emacs.
SqueakFS exists, and is able to make an image available to the outside
(file system) world. We're in the process of setting up a development
repository (based on SVN, mind you). In the meantime, it's available
from www.squeaksource.com/SqueakFS.html in the current version.
There's also Stave which is like SqueakFS but uses WebDAV instead of
FUSE. http://www.squeaksource.com/Stave.html I've since stopped using
Squeak til I can figure out a reasonable thunk between Squeak and perl
so I can use CPAN directly.

Josh

Stephen Pair
2012-01-28 12:19:01 UTC
Permalink
Post by Colin Putney
Post by Colin Putney
The other big problem is that tens of thousands of tiny files is a
horribly
Post by Colin Putney
inefficient way to store source code. Yes, disk is cheap. But disk IO is
not. I discovered this early in the development of MC2, when I
implemented a
Post by Colin Putney
type of repository that stored each method in a separate file. Loading
OmniBrowser from that repository involved opening, reading, and closing
over
Post by Colin Putney
600 files, and was very slow. I don't remember the exact timing, but I
think
Post by Colin Putney
it was like 5 to 10 minutes, and in any case it was far too slow. Avi
a repository that stored every thing in a single indexed file, and now
load
Post by Colin Putney
time is dominated by compilation.
It's worth pointing out that file-based version control has advanced
significantly since we did this work - CVS and SVN are now far from
the state of the art. I haven't used git much, for example, but it
seems to be a well layered system, and it may be that we can build an
alternative front end to its database which is image-based rather than
working directory based. For example, imagine comparing an image
directly to this index file rather than to a directory full of files
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-index
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-workflow
I personally believe that we're better off with Smalltalk-specific
version control, but if someone *is* looking at integration with more
mainstream tools, I would strongly suggest they start with git rather
than SVN.
Avi
I've been using git quite a bit lately and really like its approach (though
I've heard good things about Hg too). I liked it so much that I did a
Smalltalk version of it a while back. The idea was to do basically what git
does, but make it general purpose such that it could be used for managing
versions of any object for which you could define the serialization. I
started out making it do version control for contacts and later hooked it up
to store Monticello packages (and built a new merge tool in the process).
I've had it mostly done for several months but have resisted mentioning it,
because once you mention something, you're on the hook to get it out. I'll
see if I can clean it up enough in the next few days and publish it. I had
hoped to record a screencast to show both how to use it and how the code is
currently organized...probably won't do that, but I'll try to get the code
out soon.

- Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080630/96c4fc4c/attachment.htm
Keith Hodges
2012-01-28 12:19:01 UTC
Permalink
Having tried Hg and looked at git, I have decided that I much prefer
bzr, since it offers mor flexibility and a lightweight checkout.

Keith
Jason Johnson
2012-01-28 12:19:09 UTC
Permalink
Post by Avi Bryant
I personally believe that we're better off with Smalltalk-specific
version control, but if someone *is* looking at integration with more
mainstream tools, I would strongly suggest they start with git rather
than SVN.
Avi
+1. If we must chase inferior methodologies, hopefully we can at
least not use obsolete variations of them.
Bert Freudenberg
2012-01-28 12:19:09 UTC
Permalink
Post by Jason Johnson
Post by Avi Bryant
I personally believe that we're better off with Smalltalk-specific
version control, but if someone *is* looking at integration with more
mainstream tools, I would strongly suggest they start with git rather
than SVN.
Avi
+1. If we must chase inferior methodologies, hopefully we can at
least not use obsolete variations of them.
Agreed, although git is rather Linux-centric, so Hg might be a better
choice for a cross-platform system like Squeak.

- Bert -
Randal L. Schwartz
2012-01-28 12:19:09 UTC
Permalink
Bert> Agreed, although git is rather Linux-centric, so Hg might be a better choice
Bert> for a cross-platform system like Squeak.

What makes you think git is Linux-centric? I've worked hard for the last two
years to be "the canary in the coal mine" whenever Git failed to work on OSX
and OpenBSD, and the git developers have been *very* responsive. In fact,
some of the core developers are now exclusively on Macs. :)

The only place git still doesn't feel "at home" is Windows, where it
has to run under some unix-layer on windows (not familiar with this,
so I'm not explaining it well).

However, for flexibility and raw speed, git is hard to beat, especially at
branching and merging, which is the point of having a distributed SCM.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Bert Freudenberg
2012-01-28 12:19:09 UTC
Permalink
Post by Randal L. Schwartz
Bert> Agreed, although git is rather Linux-centric, so Hg might be a better choice
Bert> for a cross-platform system like Squeak.
What makes you think git is Linux-centric? [...]
The only place git still doesn't feel "at home" is Windows
That is exactly my point.

Don't get me wrong, I develop on Linux and OS X only (using svn and
git), but I hear git is faster on Linux and Windows users do complain.
And no matter how we skin this cat, Windows users are in the majority.

- Bert -
Ramon Leon
2012-01-28 12:19:10 UTC
Permalink
Post by Bert Freudenberg
And no matter how we skin this cat, Windows users are in the majority.
- Bert -
The *vast* majority, by far; however, cygwin makes Windows a perfectly
acceptable unix as far as the command line goes and git is available as a
loadable package so there's no reason say git is Linux centric, rather that
it's command line centric. Any developer worth his salt uses the command
line regularly, even in Windows.

Ramon Leon
http://onsmalltalk.com
Keith Hodges
2012-01-28 12:19:09 UTC
Permalink
Post by Bert Freudenberg
Post by Jason Johnson
Post by Avi Bryant
I personally believe that we're better off with Smalltalk-specific
version control, but if someone *is* looking at integration with more
mainstream tools, I would strongly suggest they start with git rather
than SVN.
Avi
+1. If we must chase inferior methodologies, hopefully we can at
least not use obsolete variations of them.
Agreed, although git is rather Linux-centric, so Hg might be a better
choice for a cross-platform system like Squeak.
- Bert -
Having tried Hg, I have found Bzr to be preferable.

Hg doesnt have a lightweight checkout, Bzr does. i.e. you can deploy the
latest, without the whole history.

I have setup a public (ish) bzr server at bzr.warwick.st with 160Gb of
space. We will be using this for managing and distributing the results
of automated image builds in the near future.

best regards

Keith
Claus Kick
2012-01-28 12:19:10 UTC
Permalink
Post by Keith Hodges
Having tried Hg, I have found Bzr to be preferable.
Hg doesnt have a lightweight checkout, Bzr does. i.e. you can deploy the
latest, without the whole history.
I have setup a public (ish) bzr server at bzr.warwick.st with 160Gb of
space. We will be using this for managing and distributing the results
of automated image builds in the near future.
Just trying to bring everything back to the core question:
What about having something like CPAN (with a CPAN installer) for Squeak?

I am trying to follow the discussions, but to me it seems as if this
central question is not really discussed.

Instead, there are interesting topics, like Squeak-To-SVN,
advantages/disadvantages of other Versioning Tools (whose names I have
not even heard, was in ENVY/Manager, SVN and ClearCase land too long it
seems), nameing and so on...

What about the central question?
What about having something like CPAN (with a CPAN installer) for Squeak?
Norbert Hartl
2012-01-28 12:19:13 UTC
Permalink
Post by Claus Kick
Post by Keith Hodges
Having tried Hg, I have found Bzr to be preferable.
Hg doesnt have a lightweight checkout, Bzr does. i.e. you can deploy the
latest, without the whole history.
I have setup a public (ish) bzr server at bzr.warwick.st with 160Gb of
space. We will be using this for managing and distributing the results
of automated image builds in the near future.
What about having something like CPAN (with a CPAN installer) for Squeak?
I am trying to follow the discussions, but to me it seems as if this
central question is not really discussed.
Instead, there are interesting topics, like Squeak-To-SVN,
advantages/disadvantages of other Versioning Tools (whose names I have
not even heard, was in ENVY/Manager, SVN and ClearCase land too long it
seems), nameing and so on...
What about the central question?
What about having something like CPAN (with a CPAN installer) for Squeak?
What makes you think CPAN is a good solution or appropriate for squeak?
For me CPAN means a lot of things. Maybe you should go into detail about
it to show the good things that would be valuable for squeak.

I personally read a lot of good points in the discussion what could be
appropriate for squeak. Especially the tension not to build another tool
but to enhance/migrate the existing ones.

Norbert
Robert Krahn
2012-01-28 12:19:02 UTC
Permalink
Hi,

it was mentioned already: We developed SqueakSVN, a project-centric
code management tool, as a student project at HPI. It completely
integrates SVN, so the workflow is different than the one from DVS.
Everything can be controlled from within Squeak.

We are currently cleaning up the code and after we are done, SqueakSVN
will be released.

Robert
Post by Andreas Raab
Can you say something more about that? A couple of weeks ago I saw a
demo at HPI in Potsdam where students used SVN down to the method
level, and it seemed to me that this approach might very well work
because the SVN granularity is the same as the in-image granularity.
It may also be interesting that this wasn't even trying to deal with
source files of any sort - it retained the nature of the image and
simply hooked it up directly with SVN. From my perspective this
looked like an extraordinarily interesting approach that I am
certain to try out as soon as it is available.
Cheers,
- Andreas
Avi Bryant
2012-01-28 12:19:02 UTC
Permalink
On Tue, Jul 1, 2008 at 11:10 AM, Robert Krahn
Hi,
it was mentioned already: We developed SqueakSVN, a project-centric code
management tool, as a student project at HPI. It completely integrates SVN,
so the workflow is different than the one from DVS. Everything can be
controlled from within Squeak.
Just curious - how is the integration done? Via a network protocol,
or using OSProcess, or some other way?

Avi
Robert Krahn
2012-01-28 12:19:04 UTC
Permalink
Hi Avi,

we communicate with Subversion by using the C-API of SVN and a VMPlugin.

Robert
Post by Avi Bryant
On Tue, Jul 1, 2008 at 11:10 AM, Robert Krahn
Hi,
it was mentioned already: We developed SqueakSVN, a project-centric code
management tool, as a student project at HPI. It completely
integrates SVN,
so the workflow is different than the one from DVS. Everything can be
controlled from within Squeak.
Just curious - how is the integration done? Via a network protocol,
or using OSProcess, or some other way?
Avi
Claus Kick
2012-01-28 12:18:57 UTC
Permalink
Post by Colin Putney
Post by Claus Kick
If push comes to shove, I would even say, lets ditch them all and
just use SVN like the rest of the planet (if that is possible). It
is hard enough to sell a image-based language with a real IDE to the
C-style crowd, the package management systems should not add their
grain of salt to the soup.
Been there, done that... <shudder/>
Trying to get SVN to work or trying to sell Smalltalk to the C people, or both? :)
Post by Colin Putney
Monticello was created because this turned out not to be feasible in
practice.
Could you please elucidate the main obstacles to this approach?
Post by Colin Putney
The simple fact is that Smalltalk *is* image based, and
that's a feature, not a bug. For those who can't accept that, there's
Ruby.
I agree, in principle - though I would have liked slls to stay outside the image, that makes changing them externally much easier.
Instead that meant, unloading, reloading and sometimes crossing your thumbs and hoping all would go well and not fry your image.
--
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der N?he des Wahnsinns auf.
Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy.
More clearly, on the narrow path between lunacy and panic.
Right around the corner of fear of death,
not far away from idiotism and insanity."
David Zmick
2012-01-28 12:18:58 UTC
Permalink
i havent read all of this yet, but the first thing that comes to my
mind is, why do we have so many different tools? It seems like there
should be one way, Meaning squeakMap, or something else, to download
files. I think keeping all of the methods to get local code in is
important though.
Post by Claus Kick
Post by Colin Putney
Post by Claus Kick
If push comes to shove, I would even say, lets ditch them all and
just use SVN like the rest of the planet (if that is possible). It
is hard enough to sell a image-based language with a real IDE to the
C-style crowd, the package management systems should not add their
grain of salt to the soup.
Been there, done that... <shudder/>
Trying to get SVN to work or trying to sell Smalltalk to the C people, or both? :)
Post by Colin Putney
Monticello was created because this turned out not to be feasible in
practice.
Could you please elucidate the main obstacles to this approach?
Post by Colin Putney
The simple fact is that Smalltalk *is* image based, and
that's a feature, not a bug. For those who can't accept that, there's
Ruby.
I agree, in principle - though I would have liked slls to stay outside the
image, that makes changing them externally much easier.
Instead that meant, unloading, reloading and sometimes crossing your thumbs
and hoping all would go well and not fry your image.
--
Claus Kick
"Wenn Sie mich suchen: Ich halte mich in der N?he des Wahnsinns auf.
Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."
"If you are looking for me: I am somewhere near to lunacy.
More clearly, on the narrow path between lunacy and panic.
Right around the corner of fear of death,
not far away from idiotism and insanity."
--
David Zmick
/dz0004455\
http://dz0004455.googlepages.com
http://dz0004455.blogspot.com
Edgar J. De Cleene
2012-01-28 12:18:57 UTC
Permalink
Post by David T. Lewis
I think that Edgar has talked about trying to rebuild Squeak 3.9/10
from changes on top of a solid 3.8 image. I think he has the right
idea: fully traceable sources, all in plain text, and easily rebuilt
from a known base system. The 3.8 image itself was built from update
streams all the way back to an image of known heritage and license
status. Really, this is not a bad state of affairs.
Dave
Thanks Dave.

Also I wish have a "Class repository" for ages.
See what I got from 3.8 in 2005

ftp://squeakros.atspace.com/squeakros.atspace.com/CompressedClasses/

password is squeak


I just build SqueakLightII aka Unofficial 3.11.
I plan to have the same thing here.

Its 3.9 with more packages going to live outside the image.
About 1400 clases, 2/3 size normal 3.10
All the way until 3.10 is with the same we do in Ralph era, but in easy to
follow .cs form.

The image could be updated hitting the load updates of Squeak flap or doing
Utilites slUpdates from Workspace.

At the moment you should reach 7183 with one error when image try to load
the Matthew version of Monticello 1.6 beta.
Close the error and repeat the loading and then save as 7183

I add a page on swiki, all could put any you wish

http://wiki.squeak.org/squeak/6056

And a couple of ready to run

In a Workspace,

|sourceFile |
sourceFile := HTTPLoader default retrieveContentsFor:
'http://wiki.squeak.org/squeak/uploads/6056/LightWeb.sar'.
sourceFile := RWBinaryOrTextStream with: (sourceFile content).
SARInstaller new fileInFrom: sourceFile

|sourceFile |
sourceFile := HTTPLoader default retrieveContentsFor:
'http://wiki.squeak.org/squeak/uploads/6056/ SqueakRosDev3dot10.sar'.
sourceFile := RWBinaryOrTextStream with: (sourceFile content).
SARInstaller new fileInFrom: sourceFile

Not to bad having a server and web page builder and a development set for a
pre-alpha ...

Help and we could have a polished system ready for ESUG or Smalltalks 2008


Also at the moment I development crude tools for analyze all in 3.10
Universes, the first output I send to "Discussion about development of
Squeak 3.10" <***@lists.squeakfoundation.org>

As seems Colin finished Monticello2, I wish try it if someone say the files
I should load from http://source.wiresong.ca/mc/

Edgar
Loading...