[squeak-dev] Re: Towards SqueakCore

David T. Lewis lewis at mail.msen.com
Mon Feb 25 15:35:46 UTC 2013


On Mon, Feb 25, 2013 at 03:01:18PM +0000, Frank Shearar wrote:
> On 25 February 2013 14:49, Bert Freudenberg <bert at freudenbergs.de> wrote:
> >
> > On 2013-02-25, at 15:33, Frank Shearar <frank.shearar at gmail.com> wrote:
> >
> >> On 14 February 2013 16:50, Frank Shearar <frank.shearar at gmail.com> wrote:
> >>> No, this takes the Trunk image as is and runs the job. No stripping
> >>> has occurred. Noone's actually said "oh, that's a sane idea someone
> >>> should do that" yet (except possibly for you, by virtue of not saying
> >>> "are you crazy?" :) ), so I haven't done it yet.
> >>>
> >>> So the installation is essentially a no-op.
> >>>
> >>> With green lights on these builds, we can now verify that removing
> >>> these packages won't break anything. At least, to the limit of the
> >>> tests, which isn't much at all. So if we _do_ actually strip these
> >>> guys out of Trunk, the builds should stay green. If they don't, we'll
> >>> need to roll back the change and investigate.
> >>>
> >>> But I don't actually know how to strip them out of Trunk. I _suspect_
> >>> it'll be via a Monticello config map of some description.
> >>
> >> Anyone? Bert? How do we strip packages out of Trunk?
> >
> > Manually once, when you prepare the Core image. Otherwise, if we put it in the trunk update stream, the packages would be unloaded from everyone's working images when updating.
> 
> Given that we're early in 4.5's release cycle, if we do this kind of
> thing - stripping unnecessary things out of trunk - we ought to do it
> now rather than later. And announce loudly what we're doing, why, and
> how people can load in their favourite not-Core packages.

NO.

If Squeak developers work with images that contain just "their favourite
non-Core packages" then none of the non-Core packages get maintained.

It is important to work on making packages loadable and unloadable, but
you do not need to break the trunk image in order to accomplish this. 

Also, please recognize that not everybody wants to do all their work in
a clean image built by a robot. I for example do most of my work in a
Squeak3.11alpha image that has been continuously updated from the update
stream for quite a while. I also periodically check things against a
fresh 4.4 image, but my usual pattern is to use one image over a long
period of time with the trunk update stream, and most of my updates to
trunk come from that old image.

Dave


> 
> We have CI tests for the packages (well, the packages I chose as the
> first victims) showing that they can be loaded into a Trunk image, and
> while the test coverage is dismal, that just means we don't know
> whether they work while in Trunk.
> 
> I'm _not_ about to go and start unloading packages without significant
> buy-in, but I really do think we ought to actually start working
> towards a lean, minimal, modular core. That will, of necessity, cause
> disruption to people updating from trunk. The ReleaseBuilder script or
> CI job can re-add these packages so that people downloading an image
> see no change.
> 
> frank
> 
> > - Bert -
> >>> frank
> >>>
> >>> On 14 February 2013 16:44, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> >>>> OK
> >>>>
> >>>>    https://github.com/frankshearar/squeak-ci/blob/master/run-test.sh
> >>>>
> >>>> executes
> >>>>   XML-Parser.st
> >>>>
> >>>> which contains
> >>>>
> >>>> Installer installUrl: 'http://source.squeak.org/trunk/XML-Parser-ael.35.mcz'.
> >>>>
> >>>> HDTestReport runPackage: 'XML-Parser'.
> >>>>
> >>>> "Throw away the dirty image."
> >>>> WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot:
> >>>> false andQuit: true ].
> >>>>
> >>>>
> >>>> I assume this operates on a trunk image which has the XML-Parser removed?
> >>>>
> >>>> In which script does that happen?
> >>>>
> >>>> --Hannes
> >>>>
> >>>> On 2/14/13, Frank Shearar <frank.shearar at gmail.com> wrote:
> >>>>> https://github.com/frankshearar/squeak-ci/blob/master/package-load-tests/XML-Parser.st
> >>>>>
> >>>>> 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 at 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 at 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 at 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 at gmail.com> wrote:
> >>>>>>>>> On 13 February 2013 12:45, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> >>>>>>>>>> Frank
> >>>>>>>>>>
> >>>>>>>>>> If I understand you correctly you want to do the following
> >>>>>>>>>>
> >>>>>>>>>> 1) unload some once packages from trunk. The packages are taken from
> >>>>>>>>>> what is in the list in #unloadAllKnownPackages.
> >>>>>>>>>>
> >>>>>>>>>> 2) add a trunk method
> >>>>>>>>>> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload
> >>>>>>>>>>
> >>>>>>>>>> 3) add CI build jobs which do
> >>>>>>>>>> #loadAllPackagesThatUnloadAllKnownPackagesUsedToUnload and run tests
> >>>>>>>>>> on the loaded packages.
> >>>>>>>>>>
> >>>>>>>>>> 4) 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 at gmail.com> wrote:
> >>>>>>>>>>> On 13 February 2013 11:22, David T. Lewis <lewis at 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.html
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >
> >


More information about the Squeak-dev mailing list