[squeak-dev] releasing and recompilation/clean up

Eliot Miranda eliot.miranda at gmail.com
Fri Feb 8 23:58:18 UTC 2013


On Wed, Feb 6, 2013 at 1:34 PM, Frank Shearar <frank.shearar at gmail.com>wrote:

> On 6 February 2013 21:25, Eliot Miranda <eliot.miranda at 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
> >
> >
> >
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130208/dd733360/attachment.htm


More information about the Squeak-dev mailing list