At 10:45 AM -0800 12/13/10, Jecel Assumpcao Jr. apparently wrote:
>Thanks David, Casey, Edgar, Chris and Ken for the feedback so far. It
>seems this is a good quick-and-dirty thing to do for 4.2 to make the
>possibilities of Squeak more explicit to new users without annoying
>people who just want a clean image to based their work on.
>
>Ken Brown raised a very importan point:
>>  I would like to see an easy way of unloading the stuff I have 
>>temporarily loaded to
>>  take a look at. I would NOT like to have loaded a project, then 
>>deleted it only to
>>  find out that all the code that was necessary for the project, was 
>>still hanging
>>  around. I do not like having to rely on closing the image without 
>>saving to revert
>>  back to the previous state. I often find I do some messing around 
>>in a Workspace
>>  that I probably want to keep, but that gets blown away too when 
>>quitting without
>>  saving the image.
>
>It is even a little worse than you think - if you close without saving,
>the extra code will be gone from your image but will still be present in
>the .changes file. If you play with it some more the next day and again
>quit without saving, then it will be there twice. Or am I wrong about
>the interaction between loading packages and .changes?
>
>Unfortunately, I don't have a good suggestion. Unloading in general
>would require some infrastructure that we don't have and certainly won't
>have time to build for Squeak 4.2.

Sake has unload infrastructure:

<http://wiki.squeak.org/squeak/5953>

 From Sake class documentation:
Sake-Packages/Packages

Sake/Packages usage:

Definitions Search Path
============================
Packages named: 'PackageName'.

Will obtain a package definition. Subclasses of Packages are searched 
using the order defined by #findPath which is specified by #priority.

e.g. Packages findPath => {PackagesSqueak310 . PackagesDev . 
PackagesAll . PackagesSeaside29}

Packages-#priority is used to sort classes like so:

The class with defns for a relevant version (listed in 
#relevantVersions) => 100
The class with defns for dev version (PackagesDev) => 400
The class with defns for all versions (PackagesAll) => 500

Additional package "universes" can define their own priority in order 
to specify where to appear in the #findPath.
PackagesSeaside29
PackagesGjaller
PackagesBeach

Usage:
========
verbose usage specifying run style.

(Packages named: 'Seaside') run.  " or runQuietly, runStepping, runLogging"

#runStepping , - presents a confirm/debug dialog before each action.
#run            - default.
#runQuietly    - auto-confirms any SakeConfirm dialogs.
#runLogging   - Writes any SakeStop warnings to self log.

default usage:

Packages load: 'Seaside'.
Packages latest: 'Seaside'. "as above, but use latest versions of everything"
Packages unload: 'Seaside'.

multiples:

Packages load: #('Seaside' 'Magma' 'Logging') 

Unloading
========
Unloading comes in two variants.

Each package task loaded by Sake/Packages is remembered in the 'provided' list
If you perform:

     Packages unload: 'Seaside' .

     Packages unloadStepping: 'Seaside' .

Then the 'historical' unload scripts are used, as defined when the 
original load tasks were run.

If instead you perform:

     (Packages current named: 'Seaside') beUnloading runStepping.

Then the most recently defined unload script will be run.

Note: If packages such as "Magma server" and "Magma client" provides 
"Magma", then

     Packages unload: 'Magma'.

Will unload whichever of the two are loaded.
===
Misc notes...

Universes are using 'instance side' task definition, so the task 
extensions mechanism does not work in this context.

If a package appears in Packages under an obscure name, it can
tell the PackageInfo instance what name was used to load it via #mcName:

If a package has a version number with a '+' after it, then 'Packages 
upgrade' will always attempt to load the latest code, leaving 
Monticello to determine if there are any code changed that need to be 
applied.

To generate all of the methods based upon universes definitions:
        
         Packages taskGenerateAllUniverses run.
   or
         Packages taskGenerateAll  run.
---------------------------------------------------------------------

Also see the post from Saturday, November 07, 2009
More Installer and Sake/Packages documentation
at <http://squeaktipsandtrickswatch.blogspot.com/> for more 
documentation copied from the class comments.

Ken G. Brown


>  An option would be to limit ourself
>to showing off packages that do have unload scripts available. I have no
>idea of how much "fun" this restriction would eliminate. By the way - I
>think of it all as fun, even stuff like Seaside and Aida and drivers for
>object databases; not just music and games.
>
>In this case I imagine a typical project having a column of buttons on
>the left side like "load all", "unload all", "load seaside", "load
>pier", "load scriptaculous", "load seachart". Then you would have some
>text windows and/or bookMorphs explaining stuff and possibly some
>drawings.
>
>Another issue is how much to depend on online operation. In the past I
>have put in a lot of effort making Squeak distributions that would be
>useable to people with a CD drive but not an Internet connection. The
>fraction of our community in that situation has been significantly
>reduced (perhaps to zero?) in the past few years. So one option would be
>to have a single "Worlds of Squeak" project inside the image itself,
>with a bunch of subprojects actually living in
>http://ftp.squeak.org/4.2/worlds or something like that. Since the
>project needs to download code to show off whatever it is trying to
>demo, then having the project itself unavailable when offline won't be
>too much worse.
>
>That said, it might be a good idea to mirror those particular versions
>of the packages used inside the ftp.squeak.org/4.2 directory and always
>fetch from there so things don't break when squeaksource.org gets
>reorganized a few years down the road or some other site goes entirely
>off the air. Once that is done, having an offline "CD-ROM" mode wouldn't
>be too much extra work. But as I wrote above, it might be that this is
>no longer worth any extra work.
>
>-- Jecel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101213/37b381c4/attachment.htm