search

GemTalk / Rowan

a new project/package manager for Smalltalk that supports FileTree and Tonel repositories, and is independent of Monticello and Metacello
MIT License
13 stars 7 forks source link

(v3.0) during RowanUpgradeV2 processing ... greedy adopt of Rowan extension methods against base #895

Open dalehenrich opened 1 year ago

dalehenrich commented 1 year ago

In a v2.4.1 RowanUpgrade of 3.7.0, the method GsNMethod >> _rwRecompileFromSourceIfUnpackagedDo: is adopted by gemstoneBaseImage ... but it should ultimately be owned by Rowan (it comes in as part of Filein1A-BootstrapOnly... .gs file ... which is a package that is not actually loaded) so it gets swooped up by the Filein4Rowan package ... massively incorrect, made worse by the fact that the loaded gemstoneBaseImage becomes dirty, plus the gemstoneBaseImage an Rowan projects think they are managing the same method ... (keep in mind that Rowan upgrades have to do some "illegal" operations to repair the damage caused by gs filein) ...

I added a hack to UpgradeRowanV2>>gemstoneBaseRepairMissingLoadedMethod: to not adopt the method into gemstoneBaseImage project ... I think it shouldn't e this hard, but the work if any should be done in v3 ...

[see https://www.notion.so/c_-50317-GsNMethod-recompileFromSource-does-not-work-for-Rowanized-methods-2c356077d9414e4888a6d18c09ba37f0 private Notion notes for detailed logs of the issues]

dalehenrich commented 1 year ago

Note that GsNMethod >> _rwRecompileFromSourceIfUnpackagedDo: is actually loaded bu upgradeImage, so it isn't necessarily greediness that gets us into trouble, but the inability (at the moment) of Rowan to properly load over the top of a method belonging to the base ... something that I will fix in v3 ...