Just noticed that TextDomainManager adds properties to methods, and that TextDomainManager class>>clearAllDomains was broken (now fixed). Hence when recompiling the system these properties will get lost. If trying to recompile to test if the compiler is not broken after additions these properties will cause naive method comparison to fail. Further, recent compiler fixes to areas like the value of inlined to:do: loops means different bytecode is generated by the current compiler than exists in methods in the image compiled by earlier versions.
Can I make a plea that we a) add TextDomainManager class>> clearAllDomains to the release process (if this information is indeed ephemeral). b) we have a more informative class comment for TextDomainManager than "I manages mapping from class category to textdomain." (as in w.t.f. does /that/ mean?) c) we include Compiler recompileAll in the release process ?
TIA
On 6 February 2013 21:25, Eliot Miranda eliot.miranda@gmail.com wrote:
Just noticed that TextDomainManager adds properties to methods, and that TextDomainManager class>>clearAllDomains was broken (now fixed). Hence when recompiling the system these properties will get lost. If trying to recompile to test if the compiler is not broken after additions these properties will cause naive method comparison to fail. Further, recent compiler fixes to areas like the value of inlined to:do: loops means different bytecode is generated by the current compiler than exists in methods in the image compiled by earlier versions.
Can I make a plea that we a) add TextDomainManager class>> clearAllDomains to the release process (if this information is indeed ephemeral). b) we have a more informative class comment for TextDomainManager than "I manages mapping from class category to textdomain." (as in w.t.f. does /that/ mean?) c) we include Compiler recompileAll in the release process ?
That should be easy enough to do to ReleaseBuilder4dot5, I suspect. Otherwise, it could potentially live in the CI release.st script.
I pulled a whole bunch of functionality together when I made ReleaseBuilder4do4, and in hindsight I think that was a mistake. It sounds like a good idea, but then when someone adjusts something in ReleaseBuilder, ReleaseBuilder4dot4 looks like it did something that it really didn't do. I think we should nuke old ReleaseBuilders - 4dot3 and 4dot4, in this case. Well, maybe only nuke 4dot4 once its juice has been extracted into 4dot5. I mean, I see little value into hanging onto old release processes.
frank
TIA
best, Eliot
On Wed, Feb 6, 2013 at 1:34 PM, Frank Shearar frank.shearar@gmail.comwrote:
On 6 February 2013 21:25, Eliot Miranda eliot.miranda@gmail.com wrote:
Just noticed that TextDomainManager adds properties to methods, and that TextDomainManager class>>clearAllDomains was broken (now fixed). Hence when recompiling the system these properties will get lost. If trying to recompile to test if the compiler is not broken after additions these properties will cause naive method comparison to fail. Further, recent compiler fixes to areas like the value of inlined to:do: loops means different bytecode is generated by the current compiler than exists in methods in the image compiled by earlier versions.
Can I make a plea that we a) add TextDomainManager class>> clearAllDomains to the release
process
(if this information is indeed ephemeral). b) we have a more informative class comment for TextDomainManager
than
"I manages mapping from class category to textdomain." (as in w.t.f.
does
/that/ mean?) c) we include Compiler recompileAll in the release process ?
That should be easy enough to do to ReleaseBuilder4dot5, I suspect. Otherwise, it could potentially live in the CI release.st script.
Either way I just wanted to add that especially after compilation changes the system should be substantially recompiled. Today I found a bug in the decompiler and was confused in debugging it by the inlining of #timesRepeat. The version of a decompiler method I was stepping through in the debugger was using an uninlined timesRepeat. Obtaining temp names, source ranges etc in the debugger is done by recompiling the method and harvesting results discarded in the final method. So the debugger was using incorrect source ranges and I kept inadvertently stepping past a send because the debugger highlight was incorrect.
I pulled a whole bunch of functionality together when I made ReleaseBuilder4do4, and in hindsight I think that was a mistake. It sounds like a good idea, but then when someone adjusts something in ReleaseBuilder, ReleaseBuilder4dot4 looks like it did something that it really didn't do. I think we should nuke old ReleaseBuilders - 4dot3 and 4dot4, in this case. Well, maybe only nuke 4dot4 once its juice has been extracted into 4dot5. I mean, I see little value into hanging onto old release processes.
frank
TIA
best, Eliot
On 2013-02-06, at 22:25, Eliot Miranda eliot.miranda@gmail.com wrote:
Just noticed that TextDomainManager adds properties to methods, and that TextDomainManager class>>clearAllDomains was broken (now fixed). Hence when recompiling the system these properties will get lost. [...] b) we have a more informative class comment for TextDomainManager than "I manages mapping from class category to textdomain." (as in w.t.f. does /that/ mean?)
Translations are stored per package. The GetTextTranslator needs to know in which package to look up the string to be translated when #translated is sent to it at runtime. Figuring out the package given a compiled method is expensive. So once that expensive lookup is done, it's cached in the compiled method's properties.
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Eliot Miranda -
Frank Shearar