[squeak-dev] Obsoletes...

Frank Shearar frank.shearar at gmail.com
Sun Dec 29 18:33:42 UTC 2013


On 29 December 2013 18:18, Levente Uzonyi <leves at elte.hu> wrote:
>
>
> 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.

Ah, OK. I'd actually thought that Smalltalk globals' exports was
empty: my recent hacking on Environments lead me to believe this
because a new Environment couldn't resolve Object, even after
importing Smalltalk globals, unless I previously executed "Smalltalk
globals exportSelf".

So I'm a bit surprised to see exports involved at all.

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

They're still broken. The only real "version number" we have is a
vector mapping packages to MC version numbers. The update number is
the sum of these version numbers, so it's kind've like the magnitude
of the vector.

But like Tobias says, _assuming_ a full-fat Trunk, and _assuming_ no
fancy trickery like having locally loaded versions higher or lower
than those in trunk, the update number in your image is comparable to
mine.

It occurs to me that we do have a sorta-kinda fuzzy version number in
the update map number.

frank

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


More information about the Squeak-dev mailing list