[squeak-dev] [CI] Unloading a package programmatically?

Frank Shearar frank.shearar at gmail.com
Fri Sep 9 11:39:01 UTC 2011


On 9 September 2011 12:36, Casey Ransberger <casey.obrien.r at gmail.com> wrote:
> If we wanted to be purists, and I say this with my grumpy tester hat on, we
> would leave the build bits in the image, because *ideally* you want to test
> exactly what you ship, if it's possible, but nothing depends on this stuff,
> and I doubt it will affect the tests, so I'm afraid I'm on the fence about
> it. I might start another thread about this.

So the answer is to fall on the side of "make it work" because
crossing over to the "make it right" side? :)

Or: I'd rather we had SOME confidence in the build, than NO confidence.

frank

> On Fri, Sep 9, 2011 at 4:33 AM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
>>
>> On 9 September 2011 12:23, Casey Ransberger <casey.obrien.r at gmail.com>
>> wrote:
>> > Okay, so, here's what we're gonna do. Sort out how to unload it when
>> > there's
>> > more people awake:)
>> > It's seriously like six or seven classes in one category. There *must*
>> > be a
>> > way to do this using... Smalltalk.
>> > Frank: No, the idea is that you archive the image, and it becomes the
>> > next
>> > trunk image, so that I don't have to make them by hand anymore:) and
>> > then
>> > you also have a release image ready to rock when all the features are in
>> > and
>> > the tests are clean.
>>
>> I guess we're talking about subtly different things: I'm looking at
>> the problem of "can I assemble an image that passes its tests?" and
>> you're looking at the problem of "the latest trunk image passes its
>> tests". But then isn't the right thing to do this?:
>> * get the latest trunk image
>> * run its tests (like from a starter script passed into the image on
>> the command line)
>> * report the results (which would require a TestRunner capable of
>> dumping Hudson-friendly XML, which is probably what the Hudson tooling
>> provides...)
>>
>> Hm. But you COULD write a script that loads whatever build
>> infrastructure you need, couldn't you?:
>>
>> Installer whereever
>>    install: 'The build tools'.
>>
>> "Insert stuff causing the test runner to run and send its output to
>> stdout"
>>
>> It's not _quite_ what we want, since Hudson reports that the image
>> _plus_the_extra_bits_ passes its tests (or not, of course). Pretty
>> close, though.
>>
>> frank
>>
>> > I'm not installing Gofer over this, I don't need it for anything in the
>> > base
>> > system. Unloading seven classes or whatnot should not be a major
>> > problem,
>> > I'm just going to have to figure out how to do it. If I have to I'll
>> > just
>> > install it with a change set so that MC doesn't see it. Then I can just
>> > tell
>> > the system organizer to drop it or whatnot. I'm sure this will be
>> > doable.
>> >
>> > On Fri, Sep 9, 2011 at 4:10 AM, Levente Uzonyi <leves at elte.hu> wrote:
>> >>
>> >> On Fri, 9 Sep 2011, Edgar J. De Cleene wrote:
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On 9/9/11 12:58 AM, "Casey Ransberger" <casey.obrien.r at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> This is to rid the build tools from the produced artifact, a nice
>> >>>> touch.
>> >>>> Since
>> >>>> we don't have Gofer in Squeak, is there an easy way to do this?
>> >>>>
>> >>>> --
>> >>>
>> >>> Port Gofer to Squeak, get rid of all another loaders (Universes,
>> >>> Installer,
>> >>> SqueakMap),etc.
>> >>
>> >> Gofer is an API for Monticello. Installer is a general purpose
>> >> (un)installer tool, SqueakMap is a package catalog. So no, we won't get
>> >> rid
>> >> of them. Universes is abandoned and SqueakMap has similar capabilities,
>> >> so
>> >> we'll probably remove it from the system.
>> >>
>> >>
>> >> Levente
>> >>
>> >>> So you was closer to Pharopatas way of work and avoid many troubles
>> >>>
>> >>> Cheers.
>> >>>
>> >>> Edgar
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Casey Ransberger
>> >
>> >
>> >
>> >
>>
>
>
>
> --
> Casey Ransberger
>
>
>
>



More information about the Squeak-dev mailing list