Re: SqueakMap for documentation?

As a demonstration, I threw together some (very) brief slides about
Maui and slapped them up on SqueakMap.  Refresh your Catalog, then
install the 'slides' release of the 'Maui' package in the Catalog.  My
slide-presentation will pop-up on the desktop.

To answer your question at a higher level, there are two parts to SqueakMap:

  1) an elegant object model which is the catalog of Squeak packages.
Each package has an OrderedCollection of Releases.  Each Release knows
what version of Squeak it works in and other things too.  It also
knows its #downloadUrl.

  2) The #downloadUrl can refer to a file that is a file on an
external web-site or a file on the SqueakMap web-site itself.  The
important point is that it refers to a _file_ that SqueakMap gives to
its own "SMInstaller" to install.  SMInstaller is not redundant with
Installer.  SMInstaller installs several types of external files, such
has human language files, for example.  But the most generally
powerful one it can install is ".sar", which means Smalltalk Archive.

A Smalltalk Archive is not only a way to publish MC-packages and
st-scripts, but to also include any necessary resource files as well.
My slide-presentation is just a .morph file, which I made by filing
out the root Morph of the slide-presentation.  The resource files
could just as easily be documents in any other format, graphics,
movies, sound samples, entire databases, or even other Squeak images..

I should mention, Squeak and Pharo include SARInstaller, out-of-the-box.

This rawness is the beauty of SqueakMap:  it assures maximum
compatibility and maximum flexibility without needing to reinvent
anything.  It's a tool that allows us all to be publishers on a rich
medium.  It's full access to the consumer's image (assuming security
permissions are enabled in the VM, of course) where we can really
showcase our ideas and projects using this great medium for doing just
that; Squeak itself.  We should do it!

I know SqueakMap has lost popularity because it has struggled with
usability, but this has mostly been addressed:  I've recently added
the Release editor for publishing load-scripts straight-away from the
image, and for demos and documentation we have MaSarPackage which
provides a nice GUI to generate the SAR's that install automatically..

 - Chris


On Thu, Feb 24, 2011 at 3:32 PM, Ken G. Brown <[hidden email]> wrote:
> What would it take to get SqueakMap to work for documentation?
>
> Wouldn't it be nice if SqueakMap could become the first place to go to find documentation as well as program packages?
>
> Ken G. Brown
>
>

As part of the increasing usability, I was wondering if Squeakmap offers a way of removing any packages that you select.  I feel like having a way to automate the removal of any packages installed would allow for safe experimentation and go a long way to encouraging users to give it a try.  One of the great things about apt on Linux is that I can grab whatever packages I want to experiment with and then remove them with no risk afterwards.  I grabbed the OCompletion package the other night, but then it struck me that if I want to roll back to an image without OCompletion I wouldn't know where to start.  Perhaps I missed this option, but if it is already implemented maybe it could be made a little bit more obvious.

Hi all!

On 02/25/2011 07:23 AM, Jeff G wrote:
> As part of the increasing usability, I was wondering if Squeakmap offers
> a way of removing any packages that you select.  I feel like having a
> way to automate the removal of any packages installed would allow for
> safe experimentation and go a long way to encouraging users to give it a
> try.

The short and brutal answer is that "safe removal" is impossible. This
is because installing code into a Squeak image will run the class side
initialize methods - and God Knows whats they do!

Having said that, we can always offer "removal" (but not promise safety)
and depending on format SM could do the most "reasonable" thing.

And one can always save the image before messing with it you know - as a
fallback!

regards, Göran

PS. When it comes to "undo" of code modifications the Deltastreams
project gives us that - if I/we ever get the time to put in those last
hours to make it usable.

Hi Göran,

I understand your point that as things are now there is no way to automatically roll back the code that is installed by Squeakmap.  You say God knows what the class side initialization methods do when they are run,  but one other person also knows what they do and that is the person who wrote them.  I am speaking from a position of deep ignorance here but does apt know how to automatically remove packages or is there also another side of packaging up software for the repos, which is allowing apt to know what to do to remove the software and config files as well?

I remember that Andreas had worked on a protocol a while back to allow for unloading various blocks of functionality from the image, such as Etoys.  Were the messages called "cleanUp" or something like that?

I guess what I am saying is that I understand that there is no way to automatically remove the software and undo changes that are done to the image, but could people encouraged to provide some sort of protocol that would be responsible for cleaning up  as well as initialization?

As always, please consider this message as ideas and suggestions and not demands or complaints.
Thanks,
Jeff G.

Hi!

On 02/25/2011 11:31 PM, Jeff G wrote:
> Hi Göran,
>
> I understand your point that as things are now there is no way to
> automatically roll back the code that is installed by Squeakmap.

Small correction: There is no way to *100% safely* roll back all *side
effects* from code that is installed by *any tool* into the image.
Again, because of class side initialization.

And of course, if you also *run* the code you have installed (like
playing with it) then in theory it doesn't matter if it doesn't have any
class side initializers - the code itself can then do whatever it
pleases like for example remove objects or even classes in your image.

Note - I don't think the danger here is malicious code, but rather stuff
we hook up and don't have code to undo, like for example registering a
class for startUp behaviour - or adding menu entries etc. Tools
typically do lots of these things in order to get "into the image"
properly. Although this issue may be less these days due to new
mechanisms using Pragmas perhaps? Not sure.

 >  You
> say God knows what the class side initialization methods do when they
> are run,  but one other person also knows what they do and that is the
> person who wrote them.  I am speaking from a position of deep ignorance
> here but does apt know how to automatically remove packages or is there
> also another side of packaging up software for the repos, which is
> allowing apt to know what to do to remove the software and config files
> as well?

I don't know apt that well, but I do know that some distros add hooks in
the filesystem layer during installation (Lunar Linux does) and thus can
track exactly what files were added when a package was installed - and
can then make sure to remove them all. So Lunar does not rely on any
manual "list" of files to remove.

Sidenote - of course a Linux package could also do nasty stuff when
installed, so perhaps there is no real difference after all.

> I remember that Andreas had worked on a protocol a while back to allow
> for unloading various blocks of functionality from the image, such as
> Etoys.  Were the messages called "cleanUp" or something like that?

Just old conventions etc. Not a "protocol" AFAIK.

> I guess what I am saying is that I understand that there is no way to
> automatically remove the software and undo changes that are done to the
> image, but could people encouraged to provide some sort of protocol that
> would be responsible for cleaning up  as well as initialization?
>
> As always, please consider this message as ideas and suggestions and not
> demands or complaints.

Sure!

If we lower our expectations to *usually safe* then one quite nice way
of getting decent uninstall would actually be to push the Deltastreams
project forward a bit. That project is based on the Delta class, which
is like a ChangeSet but much better - and among other things it has full
undo support. And the Delta part is very close to being 100% done.

So if we had Deltas we could just "record" all changes made when making
an install (of whatever format!) into a Delta. And then keep that Delta
around (contrary to ChangeSets Deltas are fully self contained). And
then for uninstall we would just undo the Delta. The Delta has enough
state to tell us if there have been other changes made "on top"
preventing it from getting us back to the original state.

This last problem is exemplified with MC "overrides". In MC a package
can "override" a method in a class outside of itself. Now, if different
MC packages override the same method - then stacking them on top of each
other and then trying to uninstall the previous one will cause this
problem to arise. Luckily the Delta would detect it.

And finally, as you said - classes should ideally have #release (
opposite of initialize) methods I guess if they need to make
modifications to the image before they get deleted. Not sure if that has
ever been used for class side initializers - anyone care to elaborate on
Smalltalk history here?

regards, Göran

PS. MC has unload capability so for MC only it already is there,
although I am not sure how it deals with the override situation.

2011/2/25 Göran Krampe <[hidden email]>:
>
> And finally, as you said - classes should ideally have #release ( opposite
> of initialize) methods I guess if they need to make modifications to the
> image before they get deleted. Not sure if that has ever been used for class
> side initializers - anyone care to elaborate on Smalltalk history here?

To me, at least ,#release would mean something completely different
than what you have mentioned here.  I'd much rather see a method named
something like #prepForUnload.

-Chris

On 02/26/2011 01:21 AM, Chris Cunningham wrote:
Well,  Ijust used the term "release" since it is AFAIK regarded as the
opposite of initialize in Smalltalk. But again, I have almost never used
it - and I don't think I have seen it on the class side, so anyone with
better insight?

regards, Göran

On 25.02.2011, at 23:35, Göran Krampe wrote:

There has always been support for this. The method you are looking for is called "unload". Existing methods do e.g. unregistration. Just browse implementers.

- Bert -

There is a simple approach here: the developer of a package can provide
a second SqueakMap entry for desinstalling if he wants to. No need to
have any specific infrastructure at the SqueakMap level; just release
both MyApp42.42 and UninstallMyApp42.42 at the same time, with all due
warning about what could go wrong of course.

Does that make sense ?

Stef

On 02/26/2011 08:46 AM, Bert Freudenberg wrote:
Ah, right. Getting rusty :)

regards, Göran

> I understand your point that as things are now there is no way to
> automatically roll back the code that is installed by Squeakmap.

Not just code installed by SqueakMap, code installed by anything.
This is really off the topic of this thread, which is using SqueakMap
as a catalog of package documentation..