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

Milan Zimmermann milan.zimmermann at sympatico.ca
Thu Jan 18 05:50:58 UTC 2007


Thanks for explaining, a few of my comments inline:

On 2007 January 17 05:18, Keith Hodges wrote:
> 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.

ok makes sense

>  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>', 

Let me pause here and ask a question: Is the idea here that the build server 
would read web pages, and they can have instructions (perhaps in a special 
<tag>) such as 'Installer install a aa.st from a url' - I may be reading it 
wrong, but who would be the pages instructing the build server this way - 
Mantis or some pages trusted by the build server?

> 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.

 ah I see, let me speculate on the "bug item workflow" here:
	- a harvester finds a fix on Mantis that is relevant to his/her package, e.g. 
	- the harvester looks at the code and it looks reasonable, so he adds 
the "fix start/end installer instructions" discussed above, to the bug 3568 
on Mantis
	- during next build, the build server crawls Mantis bugs, discovers 
the "installer instructions", and installs the changeset (or mcz perhaps) for 
the fix, and also installs the tests (automatically)
	- later the tests run and pass, so the fix 3568 is "accepted" - what does 
constitute acceptance though, and how does the "accepted" message propagate, 
because it seems somehow the bug should now be closed on Mantis, and the 
accepted code added to the code base of the relevant package.

The above "bug item workflow" if a complete speculation of mine, sorry if it 
is completely off, let me know if there is a place to read about a high level 
idea behind usage.

> 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.

ok that's interesting, i am not sure about precise meaning of "known version 
of a fix", and also it seems at some point the fix should be accepted and the 
bug closed, but i am not sure about the workflow behind it.

> > 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.

ok thanks for explaining. I loaded Installer 
installUrl: 'squeak310.pbwiki.com/Testing'. in my image - would that have 
installed your changes, i could not find the new way(s) to categorize - I am 
most likely missing some obvious hint.

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

Oh I see, so the automated process can use it to perform commands 
like: "install fix 5023.run all tests in category 'Number'" - or similar - 
all passed from a command line, and it generates a log .. is that correct so 
far?  So that sounds like nice automation,  but does not another process have 
to parse the log for errors - in which case perhaps it would be better for 
the TestRunner to email if there is an error, rather then rely on another 
process to parse logs. (i am speculating again)

Thanks for explaining this and sorry for verbosity, and if there is any place 
to read high level idea about the workflow and intended usage about automated 
builder, installer and testrunner please let me know.

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

I did :)

Thanks Milan

> 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

More information about the V3dot10 mailing list