<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [squeak-dev] "welcome" projects for
4.2</title></head><body>
<div>At 10:45 AM -0800 12/13/10, Jecel Assumpcao Jr. apparently
wrote:</div>
<blockquote type="cite" cite>Thanks David, Casey, Edgar, Chris and Ken
for the feedback so far. It<br>
seems this is a good quick-and-dirty thing to do for 4.2 to make
the<br>
possibilities of Squeak more explicit to new users without
annoying<br>
people who just want a clean image to based their work on.<br>
<br>
Ken Brown raised a very importan point:<br>
> I would like to see an easy way of unloading the stuff I have
temporarily loaded to<br>
> take a look at. I would NOT like to have loaded a project, then
deleted it only to<br>
> find out that all the code that was necessary for the project,
was still hanging<br>
> around. I do not like having to rely on closing the image without
saving to revert<br>
> back to the previous state. I often find I do some messing around
in a Workspace<br>
> that I probably want to keep, but that gets blown away too when
quitting without<br>
> saving the image.<br>
<br>
It is even a little worse than you think - if you close without
saving,<br>
the extra code will be gone from your image but will still be present
in<br>
the .changes file. If you play with it some more the next day and
again<br>
quit without saving, then it will be there twice. Or am I wrong
about<br>
the interaction between loading packages and .changes?<br>
<br>
Unfortunately, I don't have a good suggestion. Unloading in
general<br>
would require some infrastructure that we don't have and certainly
won't<br>
have time to build for Squeak 4.2.</blockquote>
<div><br></div>
<div>Sake has unload infrastructure:</div>
<div><br></div>
<div><http://wiki.squeak.org/squeak/5953></div>
<div><br></div>
<div>From Sake class documentation:</div>
<div><font color="#000000">Sake-Packages/Packages<br>
<br>
Sake/Packages usage:<br>
<br>
Definitions Search Path<br>
============================<br>
Packages named: 'PackageName'.<br>
<br>
Will obtain a package definition. Subclasses of Packages are searched
using the order defined by #findPath which is specified by
#priority.<br>
<br>
e.g. Packages findPath => {PackagesSqueak310 . PackagesDev .
PackagesAll . PackagesSeaside29}<br>
<br>
Packages-#priority is used to sort classes like so:<br>
<br>
The class with defns for a relevant version (listed in
#relevantVersions) => 100<br>
The class with defns for dev version (PackagesDev) => 400<br>
The class with defns for all versions (PackagesAll) => 500<br>
<br>
Additional package "universes" can define their own priority
in order to specify where to appear in the #findPath.<br>
PackagesSeaside29<br>
PackagesGjaller<br>
PackagesBeach<br>
<br>
Usage:<br>
========<br>
verbose usage specifying run style.<br>
<br>
(Packages named: 'Seaside') run. " or runQuietly,
runStepping, runLogging"<br>
<br>
#runStepping , - presents a confirm/debug dialog before each
action.<br>
#run
- default.<br>
#runQuietly - auto-confirms any SakeConfirm
dialogs.<br>
#runLogging - Writes any SakeStop warnings to self
log.<br>
<br>
default usage:<br>
<br>
Packages load: 'Seaside'.<br>
Packages latest: 'Seaside'. "as above, but use latest versions of
everything"<br>
Packages unload: 'Seaside'.<br>
<br>
multiples:<br>
<br>
Packages load: #('Seaside' 'Magma' 'Logging') <br>
<br>
Unloading<br>
========<br>
Unloading comes in two variants.<br>
<br>
Each package task loaded by Sake/Packages is remembered in the
'provided' list<br>
If you perform:<br>
<br>
Packages unload: 'Seaside' .<br>
<br>
Packages unloadStepping: 'Seaside' .<br>
<br>
Then the 'historical' unload scripts are used, as defined when the
original load tasks were run.<br>
<br>
If instead you perform:<br>
<br>
(Packages current named: 'Seaside') beUnloading
runStepping.<br>
<br>
Then the most recently defined unload script will be run.<br>
<br>
Note: If packages such as "Magma server" and "Magma
client" provides "Magma", then<br>
<br>
Packages unload: 'Magma'.<br>
<br>
Will unload whichever of the two are loaded.<br>
===<br>
Misc notes...<br>
<br>
Universes are using 'instance side' task definition, so the task
extensions mechanism does not work in this context.<br>
<br>
If a package appears in Packages under an obscure name, it can<br>
tell the PackageInfo instance what name was used to load it via
#mcName:<br>
<br>
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.</font></div>
<div><font color="#000000"><br>
To generate all of the methods based upon universes definitions:<br>
<br>
Packages
taskGenerateAllUniverses run.<br>
or<br>
Packages taskGenerateAll
run.<br>
---------------------------------------------------------------------</font
></div>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">Also see the post from</font><font
color="#F58537"> Saturday, November 07, 2009<br>
</font><font color="#000000">More Installer and Sake/Packages
documentation</font></div>
<div><font color="#000000">at
<http://squeaktipsandtrickswatch.blogspot.com/> for more
documentation copied from the class comments.</font><br>
<font color="#000000"></font></div>
<div>Ken G. Brown</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite> An option would be to limit
ourself<br>
to showing off packages that do have unload scripts available. I have
no<br>
idea of how much "fun" this restriction would eliminate. By
the way - I<br>
think of it all as fun, even stuff like Seaside and Aida and drivers
for<br>
object databases; not just music and games.<br>
<br>
In this case I imagine a typical project having a column of buttons
on<br>
the left side like "load all", "unload all",
"load seaside", "load<br>
pier", "load scriptaculous", "load seachart".
Then you would have some<br>
text windows and/or bookMorphs explaining stuff and possibly some<br>
drawings.<br>
<br>
Another issue is how much to depend on online operation. In the past
I<br>
have put in a lot of effort making Squeak distributions that would
be<br>
useable to people with a CD drive but not an Internet connection.
The<br>
fraction of our community in that situation has been significantly<br>
reduced (perhaps to zero?) in the past few years. So one option would
be<br>
to have a single "Worlds of Squeak" project inside the image
itself,<br>
with a bunch of subprojects actually living in<br>
http://ftp.squeak.org/4.2/worlds or something like that. Since the<br>
project needs to download code to show off whatever it is trying
to<br>
demo, then having the project itself unavailable when offline won't
be<br>
too much worse.<br>
<br>
That said, it might be a good idea to mirror those particular
versions<br>
of the packages used inside the ftp.squeak.org/4.2 directory and
always<br>
fetch from there so things don't break when squeaksource.org gets<br>
reorganized a few years down the road or some other site goes
entirely<br>
off the air. Once that is done, having an offline "CD-ROM"
mode wouldn't<br>
be too much extra work. But as I wrote above, it might be that this
is<br>
no longer worth any extra work.<br>
<br>
-- Jecel</blockquote>
<div><br></div>
</body>
</html>