<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Dale,<div class=""><br class=""></div><div class="">First off: your script cleaned those obsolete instances as well. So, I think your analysis is correct ;-)</div><div class=""><br class=""></div><div class="">One example of a SimpleBlock instance is one defined in TimeZoneInfo>>readHeader. </div><div class="">The method is an instance of GsNMethod, so that looks good. I have not analysed other methods whose blocks were still referenced. I assume they will be OK as well.</div><div class=""><br class=""></div><div class="">I guess I should replace our ‘recompile script’ with your script as a post upgrade step?</div><div class=""><br class=""></div><div class="">We’re mostly interested in discovering where in our application code we still have some complex blocks that need to be replaced before or after upgrade, so that’s why I’m looking at enumerating and clearing any lingering blocks…</div><div class=""><br class=""></div><div class="">Thanks again for the wonderful help. </div><div class="">Appreciate it a ton!</div><div class=""><br class=""></div><div class="">Onwards ;-)</div><div class=""><br class=""></div><div class="">Johan</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I would be interested in understanding which methods are keeping the obsolete classes alive .... </div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">IIRC, the older methods will be instances of GsMethod and the new methods will all be instances of GsNMethod.</div><div class=""><br class=""></div><div class="">Sooo, if the methods that are hanging onto obsolete classes are instances of GsMethod then something is keeping the GsMethod instances around ... after upgrade there should be no instances of GsMethod in a Class methodDictionary ... </div><div class=""><br class=""></div><div class="">If the methods that are hanging onto obsolete classes are instances of GsNMethod, then that would be interesting ... because It implies that the method was recompiled with a reference to an Obsoloete class ... and that shouldn't happen because all of the methods should have been replaced during the upgrade process ...</div><div class=""><br class=""></div><div class="">It might be possible that the session methods data structure is hanging onto instances of GsMethod. The following code should find and clean up the session method data structure</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">GsPackagePolicy current<br class=""> packages_Do: [ :gsPackage |<br class=""> | badBoys |<br class=""> badBoys := Dictionary new.<br class=""> gsPackage sessionMethods<br class=""> keysAndValuesDo: [ :behavior :ar |<br class=""> (ar at: 1)<br class=""> keysAndValuesDo: [ :selector :method |<br class=""> (method isKindOf: (ObsoleteClasses at: #'GsMethod'))<br class=""> ifTrue: [ (badBoys at: behavior ifAbsentPut: [ Set new ]) add: selector ] ] ].<br class=""> badBoys<br class=""> keysAndValuesDo: [ :beh :sels | sels do: [ :sel | gsPackage removeMethodAt: sel for: beh ] ] ]</blockquote><div class=""><br class=""></div><div class="">Dale</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 19, 2021 at 9:30 AM Johan Brichau via Glass <<a href="mailto:glass@lists.gemtalksystems.com" class="">glass@lists.gemtalksystems.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br class="">
<br class="">
After upgrading a GLASS/Seaside repository from 2.4.4.1 to 3.4.5, I notice there are still a lot of instances of the obsolete classes SimpleBlock, ComplexVCBlock, ExecutableBlock, ComplexBlock<br class="">
We noticed these instances are references held by the methods in which they are defined. <br class="">
<br class="">
Is that ‘expected’ ? Since all methods are recompiled when upgrading, should there still be instances of these obsolete block classes?<br class="">
Running the following code removes the references, but we do get a SecurityError when it tries to recompile GsPackagePolicy class>>initialize. We run it as DataCurator. Should we run it as SystemUser?<br class="">
<br class="">
| obsoleteBlockClasses blockArrays sourceClasses |<br class="">
obsoleteBlockClasses := Array withAll: (ObsoleteClasses select: [ :object | object isClass and: [ object inheritsFrom: BlockClosure ] ]).<br class="">
blockArrays := SystemRepository listInstances: obsoleteBlockClasses.<br class="">
sourceClasses := IdentitySet new.<br class="">
blockArrays do: [ :blocks |<br class="">
blocks do: [ :block |<br class="">
block method inClass ifNotNil: [ :sourceClass |<br class="">
sourceClasses add: sourceClass ] ] ].<br class="">
sourceClasses do: [ :sourceClass |<br class="">
Transcript show: ('Recompiling class {1} ({2})' format: { sourceClass name. sourceClass asOop }).<br class="">
sourceClass recompileAllMethods ].<br class="">
<br class="">
<br class="">
Thanks for insights!<br class="">
Johan<br class="">
_______________________________________________<br class="">
Glass mailing list<br class="">
<a href="mailto:Glass@lists.gemtalksystems.com" target="_blank" class="">Glass@lists.gemtalksystems.com</a><br class="">
<a href="https://lists.gemtalksystems.com/mailman/listinfo/glass" rel="noreferrer" target="_blank" class="">https://lists.gemtalksystems.com/mailman/listinfo/glass</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>