[V3dot10] Request wiki.squeak.org be used instead of pbwiki
keith_hodges at yahoo.co.uk
Wed Jan 17 10:18:31 UTC 2007
Thanks for asking lots of interesting questions. I think that the class
comment may help to answer some of them in more or less detail than I
can manage here.
> I downloaded Installer from SQMapPackageLoader(SMPL). Let me verify my
> understanding of where it fits: Basically, it allows to install Packages from
> command line as opposed to using SMPL correct so far? Now, the packages can
Yes, and Installer is intended for situations where an Image does not
actually have SMPL loaded. The websqueakmap interface provides access to
squeakmap packages with the 'Network' being the only prerequisite
package in the KernelImage.
Installer websqueakmap install: '<packageName>(<packageVersion)'
> be located not only on SqueakMap, but also use other protocols, http, ftp,
> perhaps others. So for example I can do as above:
> Installer installUrl: 'squeak310.pbwiki.com/Testing'.
> I have a question at this point - isnt' there another way I can install
> packages from Workspace using a SMPL related class? (apart from using the
> SMPL UI).
There is, it is just that each of the different, sources and package
types have a different way of doing things. I often found that it was
difficult to know which of the hundreds of classes to start with, where
to look for a public package loading api.
Purists have objected to the one-class implementation of Installer as
bad design, and it would be trivial to separate it out into separate
classes for each function, i.e. InstallerWebSqueakMap, and
InstallerSqueakMap, however I have put it all in one place simply to
have everything in one place if that makes sense.
Installer is just a front end to attempt to unify the interface a bit
and make the resultant code readable. It is intended as a "Domain
Specific Language" for installing.
It is also designed so that an installer script can be read in a
workspace and parts can be doit-ed, this gives a reader of the script
full control, which is often missing from 'one-click' installs where you
end up having to understand and retrace the steps of the one-click
installer yourself. You can load parts you like of someone-else's script
and fine tune the rest.
In the case of a script on a web site, Installer path: <searchpath>;
view: '<url>', is intended to grab someone else's script and put it in
a workspace for you to so the whole thing and do-it in whatever way you
> As a next step i looked at pbwiki and see an example
> Installer mantis fixBug: '3568 asFloat does not always answer nearest fp
> So it sound like it has some buildin smarts to go to mantis, look at an item
> and install from there. Does the above simply load all attached files from
> the BugID=3568 on Mantis? Does it have some added smarts to look whether the
> fix is already loaded (i guess that' irrelevant), whether the version number
> on Mantis = Version of Image, etc? Also I see these comments on Mantis on
> "fix begin"
> Installer mantis bug: 3568 fix: 'Kernel-Number-Fraction-asFloat-Patch.3.cs'.
> "fix test"
> Installer mantis bug: 3568 fix: 'Kernel-Number-Fraction-asFloat-Test.2.cs'.
> "fix end"
> How did these comments appear, were they added by the Installer when it ran
> agains some (any?) image?
These comments are manually added by the 'harvester' of that bug fix, to
inform Installer which of the available files are relevant to a) the
fix, and b) testing of the fix.
If another harvester needs to change this, then they will have to append
an updated version, Installer will use the last of such notes. Installer
can also perform a date check to ensure that only a known version of a
fix is loaded, and to inform you if someone has commented on the bug fix
page since you last looked.
> Sorry for all these questions, I just want to understand the motivation and
> position of the Installer.
> Also, regarding the TestRunner: I thought there were some changes to
> TestRunner by you, related to the Installer, but maybe I am misuderstanding.
The changes that I made to TestCase etc, and TestRunner are to do with
categorisation of test cases, it provides more methods for categorising
tests, and building suites.
Tests can be categorised based upon a) method selector pattern, b)
method category pattern c) flags embedded in the test case ( self flag:
Pragma's would be a natural extension to c) but I have not implemented
The improved TestRunner has a UI for selecting suites and filtering out
tests, Tests are timed and if the Network is used or not, is recorded.
There is a UI for categorising tests based upon these measurements.
In addition I have arranged it so that TestRunner can be started from
the command line, together with Installer taking parameters as to what
to run, and when it generates a log, where to save the log (this is
I hope this helps to answer you questions feel free to ask any more that
you might have
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
More information about the V3dot10