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

[Milan Zimmermann]

Thanks Keith for detail description

let me digest it and maybe ask more questions in the next day or so,

Milan

On 2007 January 17 05:18, Keith Hodges wrote:
> 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
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10