<br><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 1:34 PM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 6 February 2013 21:25, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
> Just noticed that TextDomainManager adds properties to methods, and that<br>
> TextDomainManager class>>clearAllDomains was broken (now fixed). Hence<br>
> when recompiling the system these properties will get lost. If trying to<br>
> recompile to test if the compiler is not broken after additions these<br>
> properties will cause naive method comparison to fail. Further, recent<br>
> compiler fixes to areas like the value of inlined to:do: loops means<br>
> different bytecode is generated by the current compiler than exists in<br>
> methods in the image compiled by earlier versions.<br>
><br>
> Can I make a plea that we<br>
> a) add TextDomainManager class>> clearAllDomains to the release process<br>
> (if this information is indeed ephemeral).<br>
> b) we have a more informative class comment for TextDomainManager than<br>
> "I manages mapping from class category to textdomain." (as in w.t.f. does<br>
> /that/ mean?)<br>
> c) we include Compiler recompileAll in the release process<br>
> ?<br>
<br>
</div></div>That should be easy enough to do to ReleaseBuilder4dot5, I suspect.<br>
Otherwise, it could potentially live in the CI <a href="http://release.st" target="_blank">release.st</a> script.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I pulled a whole bunch of functionality together when I made<br>
ReleaseBuilder4do4, and in hindsight I think that was a mistake. It<br>
sounds like a good idea, but then when someone adjusts something in<br>
ReleaseBuilder, ReleaseBuilder4dot4 looks like it did something that<br>
it really didn't do. I think we should nuke old ReleaseBuilders -<br>
4dot3 and 4dot4, in this case. Well, maybe only nuke 4dot4 once its<br>
juice has been extracted into 4dot5. I mean, I see little value into<br>
hanging onto old release processes.<br>
<br>
frank<br>
<br>
> TIA<br>
<span class="HOEnZb"><font color="#888888">> --<br>
> best,<br>
> Eliot<br>
><br>
><br>
><br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>