[squeak-dev] Obsoletes...

Frank Shearar frank.shearar at gmail.com
Sun Dec 29 16:46:06 UTC 2013


On 29 December 2013 16:37, Levente Uzonyi <leves at elte.hu> wrote:
> On Sun, 29 Dec 2013, Frank Shearar wrote:
>
>> On 29 December 2013 12:12, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>
>>> Hi all,
>>>
>>> I just took the todays Trunk image (Squeak4.5-13148#712)
>>> (NameVersion-Update#CIJob)
>>
>>
>> Ah, that's nice & specific! Thanks! (Nit: we might as well not bother
>> with update numbers, because our versioning is broken (*). The
>> SqueakTrunk builds' TrunkImage artifacts will have an "update number"
>> hundreds lower than a "full fat" image.
>>
>> (*) It's broken because an update number doesn't map in any meaningful
>> way to what's in the image. "Update number" just means "the sum of all
>> MC numbers of all packages in the latest update map that this image
>> currently contains." If your Collections package is one ahead of trunk
>> (because you have a local hack) while your Kernel package is one
>> behind, you have _the same update number_.
>
>
> The number only applies to Trunk images. There's intended to be only one of
> those (not two or three as it is now).
>
>
>>
>>> and ran
>>>         SystemNavigation default obsoleteBehaviors
>>> and got
>>>         {AnObsoleteBlueSmallLandColorTheme .
>>> AnObsoleteSmallLandColorTheme . AnObsoleteSmallLandColorTheme class .
>>> AnObsoleteBlueSmallLandColorTheme class . AnObsoleteToolBuilderTests class .
>>> AnObsoleteToolBuilderTests . AnObsoleteBindingTest class .
>>> AnObsoleteBindingTest}
>>>
>>> We should fix that.
>>> It breaks at least
>>>         Smalltalk unloadReloadablePackages
>>
>>
>> It also manifests as failing tests:
>> *
>> http://build.squeak.org/job/SqueakTrunk/712/testReport/junit/Tests.Release/ReleaseTest/testNoObsoleteClasses/
>> *
>> http://build.squeak.org/job/SqueakTrunk/712/testReport/junit/Tests.Release/ReleaseTest/testUndeclared/
>
>
> One word: Environments.

No. The obsolete ColorThemes come from unloading the SmallLand themes,
and have nothing to do with Environments. And please take a moment to
review Tests-fbs.280 in the Inbox, which uses Environments for all the
Monticello tests. You'll probably need Monticello-fbs.581, also in the
Inbox.

The two changes need review.

>>> What is the best way?
>>> A postscript in a System Package change?
>
>
> A postscript won't help, because new obsolete classes will be introduced
> because of Environments.

Explain?

>> I've been hoping someone would tell me! But Chris told us that the
>> SqueakTrunk base image's state is a little broken, and that he doesn't
>> see these tests failing. That would be well worth verifying. If so,
>> the solution is to hand-roll another base image for SqueakTrunk. I
>> have a candidate image that I've not quite finished preparing.
>>
>> As an aside, I think the reason the SqueakTrunk base image broke, at
>> least in part, was caused by Nicolas and I adding new _necessary_
>> packages to trunk. For instance, when I factored out
>> ToolBuilder-Tests, the base image was told not to update packages it
>> didn't have, so as not to reload unloaded packages (ST80, Universes,
>> ...)... but that also meant it didn't get UpdateStream and
>> ToolBuilder-Tests.
>
>
> Using a smaller image to build back the full Trunk image doesn't fit the
> Trunk process.

It will.

frank

> Levente
>
>>
>> frank
>>
>>
>


More information about the Squeak-dev mailing list