Smalltalk › Squeak › Squeak - Dev

releasing and recompilation/clean up

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Eliot Miranda-2

releasing and recompilation/clean up

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

--
best,

Eliot

Frank Shearar-3

Re: releasing and recompilation/clean up

On 6 February 2013 21:25, Eliot Miranda <[hidden email]> 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
>
>
>

Eliot Miranda-2

Re: releasing and recompilation/clean up

On Wed, Feb 6, 2013 at 1:34 PM, Frank Shearar <[hidden email]> wrote:

On 6 February 2013 21:25, Eliot Miranda <[hidden email]> 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

Bert Freudenberg

Re: releasing and recompilation/clean up

In reply to this post by Eliot Miranda-2

On 2013-02-06, at 22:25, Eliot Miranda <[hidden email]> 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 -