On Sun, 29 Dec 2013, Frank Shearar wrote:

> 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?

If you run the tests using the Test Runner, then close it, there will be 
new obsolete classes. If you explore the pointers to them, you'll find 
that some of them are referenced from the global environment's exports.

This might be because the exports of the global environment are broken. 
Instead of the public IdentityDictionary, another one is held by the only 
export of the global environment. It has all kind of weird stuff, like 
#'_windows_which_were_not_collapsed'.

The import chain is also "broken", there's an empty Import at the end. It 
doesn't cause any harm, but it's unnecessary.

>
>>> 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.

I mean, it was designed to be done the other way: The Trunk image always 
contains all packages managed by the Trunk process, and some packages can 
be unloaded to create a smaller image, but that's not a Trunk image 
anymore.
This is why the version numbers are "broken".


Levente

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