https://github.com/frankshearar/squeak-ci/blob/master/package-load-tests/XML...
They all get triggered by this guy, who I aim to replace with some Ruby (because I'd really, really, REALLY rather write Ruby than shell): https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh
So the jobs only differ in their command: `./run-test.sh Control`, `./run-test.sh XML-Parser`, and so on.
frank
On 14 February 2013 16:34, H. Hirzel hannes.hirzel@gmail.com wrote:
Great
where can I see what the script is doing for example for XML-Parser?
Which script does the job?
http://www.squeakci.org/job/ExternalPackage-XML-Parser/ws/
--Hannes
On 2/14/13, Frank Shearar frank.shearar@gmail.com wrote:
We also now have builds for XML-Parser, Nebraska and Universes (for what it's worth: the code coverage is abysmal).
frank
On 13 February 2013 15:23, H. Hirzel hannes.hirzel@gmail.com wrote:
Yes, thank you for the clarification, Frank. This makes a lot of sense to me and I hope that others follow this line of reasoning.
--Hannes
On 2/13/13, Frank Shearar frank.shearar@gmail.com wrote:
On 13 February 2013 12:45, H. Hirzel hannes.hirzel@gmail.com wrote:
Frank
If I understand you correctly you want to do the following
- unload some once packages from trunk. The packages are taken from
what is in the list in #unloadAllKnownPackages.
- add a trunk method
#loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload
- add CI build jobs which do
#loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload and run tests on the loaded packages.
- People use the result of 3) for regular work. This is the "full"
4.5 image as we have of now only that we have less in trunk and the unlodable packages reside in their own repositories.
Steps 2..4 are done repeatedly.
Is this what you mean?
Yes. Perhaps with a nicer name than #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload. Maybe #loadBasicPackages or something.
My main aim is to invert the approach we've had up until now, and _enforce_ the clean separation of these packages from the Core. I want it to be difficult to add a dependency from the Core to these packages.
frank
--Hannes
On 2/13/13, Frank Shearar frank.shearar@gmail.com wrote:
On 13 February 2013 11:22, David T. Lewis lewis@mail.msen.com wrote: > On Mon, Feb 11, 2013 at 05:28:26PM +0000, H. Hirzel wrote: >> Yanni, >> >> I think St??phane refers to the original Pharo manifesto which >> clearly >> states "no backward compatibility". http://code.google.com/p/pharo/ >> >> However the current Pharo web page has a mission statement >> http://www.pharo-project.org/about >> sets a much more moderate tone. >> >> In any case in this thread we want to move on towards a Squeak core >> and learn from the Pharo experience as much as possible. Please let >> us >> not digress from this important topic. >> >> Maybe we should follow both at the same time >> >> Let me call it >> - the Pavel Krivanek approach and >> - the >> SmalltalkImage unloadAllKnownPackages >> approach >> >> BTW >> #unloadAllKnownPackages >> >> used to work in Squeak 4.1, see >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152427.ht... >> >> So there is no reason why we should not manage to get it working >> again >> in Squeak 4.5alpha. >> >> And Pavel's approach may be followed in parallel. Because fixing one >> thing will help the other and vice-verse. >> > > +1 > > Exactly so. That is what I intended when I mentioned > #unloadAllKnownPackages. > Thanks for stating it so clearly.
While we're being clear about what's clear :) I'm wanting to _lose_ #unloadAllKnownPackages, and replace it with a #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload, and add a bunch of new jobs running those unloaded packages' test suites.
That way, the thing called Squeak4.5-nnnn.image still contains what Squeak4.5-${whatever_current_is}.image, only the essence of trunk - what SqueakTrunk produces - shrinks.
> Dave