<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 29, 2013 at 5:28 PM, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi<br>
<br>
[Below, a "fix" to remove those obsoletes…]<br>
<div class="im"><br>
On 29.12.2013, at 14:15, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
<br>
> On 29 December 2013 12:12, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
>> Hi all,<br>
>><br>
>> I just took the todays Trunk image (Squeak4.5-13148#712) (NameVersion-Update#CIJob)<br>
><br>
> Ah, that's nice & specific! Thanks!<br>
</div>(I wrote this mail prior to the other and hoped the order<br>
would stick)<br>
<div class="im"><br>
> (Nit: we might as well not bother<br>
> with update numbers, because our versioning is broken (*). The<br>
> SqueakTrunk builds' TrunkImage artifacts will have an "update number"<br>
> hundreds lower than a "full fat" image.<br>
><br>
> (*) It's broken because an update number doesn't map in any meaningful<br>
> way to what's in the image. "Update number" just means "the sum of all<br>
> MC numbers of all packages in the latest update map that this image<br>
> currently contains." If your Collections package is one ahead of trunk<br>
> (because you have a local hack) while your Kernel package is one<br>
> behind, you have _the same update number_.<br>
<br>
</div>Which is true.<br>
However, for the typically downloaded half-fat TrunkImage from FTP or jenkins,<br>
it is meaningful :)<br>
I think it is comparable to the local revision number in hg: Not meaningful<br>
around the globe but one can work with it in several scenarios.<br>
<div class="im"><br>
<br>
><br>
>> and ran<br>
>> SystemNavigation default obsoleteBehaviors<br>
>> and got<br>
>> {AnObsoleteBlueSmallLandColorTheme . AnObsoleteSmallLandColorTheme . AnObsoleteSmallLandColorTheme class . AnObsoleteBlueSmallLandColorTheme class . AnObsoleteToolBuilderTests class . AnObsoleteToolBuilderTests . AnObsoleteBindingTest class . AnObsoleteBindingTest}<br>
>><br>
>> We should fix that.<br>
>> It breaks at least<br>
>> Smalltalk unloadReloadablePackages<br>
><br>
> It also manifests as failing tests:<br>
> * <a href="http://build.squeak.org/job/SqueakTrunk/712/testReport/junit/Tests.Release/ReleaseTest/testNoObsoleteClasses/" target="_blank">http://build.squeak.org/job/SqueakTrunk/712/testReport/junit/Tests.Release/ReleaseTest/testNoObsoleteClasses/</a><br>
> * <a href="http://build.squeak.org/job/SqueakTrunk/712/testReport/junit/Tests.Release/ReleaseTest/testUndeclared/" target="_blank">http://build.squeak.org/job/SqueakTrunk/712/testReport/junit/Tests.Release/ReleaseTest/testUndeclared/</a><br>
<br>
</div>Well..<br>
<div class="im"><br>
><br>
>> What is the best way?<br>
>> A postscript in a System Package change?<br>
><br>
> I've been hoping someone would tell me! But Chris told us that the<br>
> SqueakTrunk base image's state is a little broken, and that he doesn't<br>
> see these tests failing. That would be well worth verifying. If so,<br>
> the solution is to hand-roll another base image for SqueakTrunk. I<br>
> have a candidate image that I've not quite finished preparing.<br>
><br>
> As an aside, I think the reason the SqueakTrunk base image broke, at<br>
> least in part, was caused by Nicolas and I adding new _necessary_<br>
> packages to trunk. For instance, when I factored out<br>
> ToolBuilder-Tests, the base image was told not to update packages it<br>
> didn't have, so as not to reload unloaded packages (ST80, Universes,<br>
> ...)... but that also meant it didn't get UpdateStream and<br>
> ToolBuilder-Tests.<br>
<br>
<br>
</div>Ok. Sounds reasonable.<br>
Apart from that, I try to get the image in a state I can do<br>
>> unloadReloadablePackages<br>
[1]<br>
<br>
In that process I crashed the current cog vm several times[2]<br>
as well as other vms with out-of-memory issues.<br>
(You can try it:<br>
SystemNavigation default obsoleteBehaviors chasePointers<br>
)<br>
Sadly,<br>
SystemNavigation default obsoleteBehaviors explorePointers<br>
yields no meaningful output :(<br>
<br></blockquote><div>It seems PointersExplorer works on single objects, not a array of objects. So if you look at each item in the list of obsoletes you get valid results:</div><div><br></div><div>SystemNavigation default obsoleteBehaviors first explorePointers</div>
<div><br></div><div>Cheers,</div><div>Karl</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Ok. Different approach. The color theme stuff.<br>
By clicking around I found, ColorTheme's CurrentTheme held unto<br>
AnObsoleteBlueSmallLandColorTheme. Hence:<br>
<br>
SystemNavigation default obsoleteBehaviors size. "8"<br>
ColorTheme current: nil.<br>
ColorTheme current.<br>
Behavior flushObsoleteSubclasses.<br>
Smalltalk garbageCollect; garbageCollect.<br>
SystemNavigation default obsoleteBehaviors size. " 4"<br>
<br>
So, 4 less, but the Menus look different now.<br>
<br>
Here, my approach on finding the remaining culprits.<br>
[| haystack |<br>
"my pointer finder"<br>
haystack := [:needle | SystemNavigation default allObjectsSelect: [:obj | obj pointsTo: needle]].<br>
<br>
"First, onto the binding test."<br>
(haystack value: SystemNavigation default obsoleteBehaviors last " AnObsoleteBindingTest"<br>
) in: [:stuff |<br>
"only 2nd and 3d seem interesting"<br>
(((stuff first: 3) last: 2) collect: [:needle2 | haystack value: needle2]) in: [:stuff2 |<br>
"first of 1st is interesting"<br>
(haystack value: stuff2 first first) in: [:stuff3 |<br>
"first is interesting"<br>
(haystack value: stuff3 first) "there's an export..." in: [:stuff4 |<br>
(haystack value: stuff4 first)<br>
"Smalltalk Enviornment, ie Environment default !!"<br>
]]]].<br>
<br>
"Ok, see if the culprit is there"<br>
[ |assocs |<br>
assocs := (Environment default exports instVarNamed: 'namespace') associationsSelect: [:assoc |<br>
assoc value isBehavior<br>
ifTrue: [assoc value isObsolete]<br>
ifFalse: [false]]. "an IdentityDictionary(#BindingTest->AnObsoleteBindingTest )"<br>
<br>
assocs do: [:a | Environment default exports forgetName: a key]<br>
] value.<br>
<br>
Behavior flushObsoleteSubclasses.<br>
Smalltalk garbageCollect; garbageCollect.<br>
SystemNavigation default obsoleteBehaviors size. " 2"<br>
<br>
"Ok, 2 to go"<br>
"Onto the toolbuildertest"<br>
(haystack value: SystemNavigation default obsoleteBehaviors first "AnObsoleteToolBuilderTests")<br>
in: [:stuff5 |<br>
stuff5 second " SUnitToolBuilderTests class" in: [:suspicious |<br>
suspicious superclass " AnObsoleteToolBuilderTests class"<br>
"Gotcha!"] ].<br>
"I don't know... redo?"<br>
<br>
"Redo.. we add artificial instvar here to assure new class."<br>
ToolBuilderTests subclass: #SUnitToolBuilderTests<br>
instanceVariableNames: 'foo'<br>
classVariableNames: ''<br>
poolDictionaries: ''<br>
category: 'SUnitGUI-ToolBuilder'.<br>
ToolBuilderTests subclass: #SUnitToolBuilderTests<br>
instanceVariableNames: ''<br>
classVariableNames: ''<br>
poolDictionaries: ''<br>
category: 'SUnitGUI-ToolBuilder'.<br>
<br>
Behavior flushObsoleteSubclasses.<br>
Smalltalk garbageCollect; garbageCollect.<br>
SystemNavigation default obsoleteBehaviors size. " 0"<br>
Yay!<br>
<br>
I attached a better Script to handle this and on the way created the<br>
name uncle class :P<br>
<br>
Shall I make a System revision with post script?<br>
<br>
Best<br>
-Tobias<br>
<br>
<br>
<br>
[1] Nit: unloadAllKnownPackages is gone forever, right?<br>
[2] See vm-dev<br>
<br>
<br><br>
<br><br>
<br></blockquote></div><br></div></div>