[V3dot10] Request wiki.squeak.org be used instead of pbwiki

[Keith Hodges]

Dear Milan,

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.
> Keith,
>
> 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 
wish.
> As a next step i looked at pbwiki and see an example
>
> Installer mantis fixBug: '3568 asFloat does not always answer nearest fp 
> number'.
>
> 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 
> 3568:
> "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: 
#toDo )

Pragma's would be a natural extension to c) but I have not implemented 
that yet.

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 
still todo).

I hope this helps to answer you questions feel free to ask any more that 
you might have

best regards

Keith



	
	
		
___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html