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