[squeak-dev] Cleaning up after colorPrint removal in Inbox *please read*

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Cleaning up after colorPrint removal in Inbox *please read*

Casey Ransberger
Hello all,

I spent some time today looking into what cruft might be left behind after sloughing colorPrint out of the system browser in favor of Shout. What I found was: somewhat tangled and messy dependencies.

My main goal for the day was cleanly removing the preference #colorWhenPrettyPrinting. Note that I may have removed more than what was actually necessary, e.g., ShoutCore seems to disable the colorWhenPrettyPrinting preference on install, and I removed that line, since the preference would be gone.

Methods changed:

Text>>askIfAddStyle:req: (Collections)
Compiler>>format:in:notifying:contentsSymbol: (Compiler)
SHTextStylerST80>>initializePreferences (ShoutCore ...this is ironic...)

There were a lot of changes in the System category:

Preferences>>
colorWhenPrettyPrinting (removed)
defaultValueTableForCurrentRelease
smallLandPreferences

SystemDictionary>>
testFormatter
testFormatter2

And yet more in tools:

ChangeSorter>>setContents

CodeHolder>>
colorPrintString (removed)
contentsSymbol
showingColorPrint (removed)
sourceStringPrettifiedAndDiffed
toggleColorPrint (removed)

FileContentsBrowser>>selectedMessage

The most disturbing thing that I saw on my Sunday drive was the method #format:in:notifying:contentsSymbol: in Compiler (on both class and instance sides). It looks as though the argument aSymbol is checked for equality to #colorPrint, colorizing text the old way if so, and that's the only thing it's used for. Thus, the method signature could stand to be simplified, if it weren't for the fact that this one has other senders, meaning yet more code churn; I'm hesitant to mess with the signature of a Compiler method at this point, but doing so anyway for at least the sake of experiment, I've changed:

Compiler>>
format:in:notifying:contentsSymbol: (removed)
format:in:notifying:contentsSymbol: (removed)
format:in:notifying: (added)
format:in:notifying: (added)

In addition to applying the above, I had to do:

Preferences removePreference: #colorWhenPrettyPrinting

... to make the actual preference go away.

So far I haven't seen anything explode yet, but this is a pretty ambitious change for me, considering that I've only been Squeaking for a little over a year.

Would the good people of squeak-dev be so kind as to look over the changes I've placed in the Inbox for obvious errors? Here they are:

Collections-rss.118
Compiler-rss.72
Tools-rss.110
System-rss.134

 - Ron


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Cleaning up after colorPrint removal in Inbox *please read*

Andreas.Raab
It's looking very good. Nice job!

Cheers,
   - Andreas

Ronald Spengler wrote:

> Hello all,
>
> I spent some time today looking into what cruft might be left behind
> after sloughing colorPrint out of the system browser in favor of Shout.
> What I found was: somewhat tangled and messy dependencies.
>
> My main goal for the day was cleanly removing the preference
> #colorWhenPrettyPrinting. Note that I may have removed more than what
> was actually necessary, e.g., ShoutCore seems to disable the
> colorWhenPrettyPrinting preference on install, and I removed that line,
> since the preference would be gone.
>
> Methods changed:
>
> Text>>askIfAddStyle:req: (Collections)
> Compiler>>format:in:notifying:contentsSymbol: (Compiler)
> SHTextStylerST80>>initializePreferences (ShoutCore ...this is ironic...)
>
> There were a lot of changes in the System category:
>
> Preferences>>
> colorWhenPrettyPrinting (removed)
> defaultValueTableForCurrentRelease
> smallLandPreferences
>
> SystemDictionary>>
> testFormatter
> testFormatter2
>
> And yet more in tools:
>
> ChangeSorter>>setContents
>
> CodeHolder>>
> colorPrintString (removed)
> contentsSymbol
> showingColorPrint (removed)
> sourceStringPrettifiedAndDiffed
> toggleColorPrint (removed)
>
> FileContentsBrowser>>selectedMessage
>
> The most disturbing thing that I saw on my Sunday drive was the method
> #format:in:notifying:contentsSymbol: in Compiler (on both class and
> instance sides). It looks as though the argument aSymbol is checked for
> equality to #colorPrint, colorizing text the old way if so, and that's
> the only thing it's used for. Thus, the method signature could stand to
> be simplified, if it weren't for the fact that this one has other
> senders, meaning yet more code churn; I'm hesitant to mess with the
> signature of a Compiler method at this point, but doing so anyway for at
> least the sake of experiment, I've changed:
>
> Compiler>>
> format:in:notifying:contentsSymbol: (removed)
> format:in:notifying:contentsSymbol: (removed)
> format:in:notifying: (added)
> format:in:notifying: (added)
>
> In addition to applying the above, I had to do:
>
> Preferences removePreference: #colorWhenPrettyPrinting
>
> ... to make the actual preference go away.
>
> So far I haven't seen anything explode yet, but this is a pretty
> ambitious change for me, considering that I've only been Squeaking for a
> little over a year.
>
> Would the good people of squeak-dev be so kind as to look over the
> changes I've placed in the Inbox for obvious errors? Here they are:
>
> Collections-rss.118
> Compiler-rss.72
> Tools-rss.110
> System-rss.134
>
>  - Ron
>
>
> ------------------------------------------------------------------------
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Cleaning up after colorPrint removal in Inbox *please read*

Casey Ransberger
Is there a way to check a doit into Monticello? I am bothered somewhat by that fact that one must still:

Preferences removePreference: #colorWhenPrettyPrinting

After updating from Trunk, otherwise the preference itself remains.

 - Ron

On Sun, Aug 23, 2009 at 1:49 PM, Andreas Raab <[hidden email]> wrote:
It's looking very good. Nice job!

Cheers,
 - Andreas

Ronald Spengler wrote:
Hello all,

I spent some time today looking into what cruft might be left behind after sloughing colorPrint out of the system browser in favor of Shout. What I found was: somewhat tangled and messy dependencies.

My main goal for the day was cleanly removing the preference #colorWhenPrettyPrinting. Note that I may have removed more than what was actually necessary, e.g., ShoutCore seems to disable the colorWhenPrettyPrinting preference on install, and I removed that line, since the preference would be gone.

Methods changed:

Text>>askIfAddStyle:req: (Collections)
Compiler>>format:in:notifying:contentsSymbol: (Compiler)
SHTextStylerST80>>initializePreferences (ShoutCore ...this is ironic...)

There were a lot of changes in the System category:

Preferences>>
colorWhenPrettyPrinting (removed)
defaultValueTableForCurrentRelease
smallLandPreferences

SystemDictionary>>
testFormatter
testFormatter2

And yet more in tools:

ChangeSorter>>setContents

CodeHolder>>
colorPrintString (removed)
contentsSymbol
showingColorPrint (removed)
sourceStringPrettifiedAndDiffed
toggleColorPrint (removed)

FileContentsBrowser>>selectedMessage

The most disturbing thing that I saw on my Sunday drive was the method #format:in:notifying:contentsSymbol: in Compiler (on both class and instance sides). It looks as though the argument aSymbol is checked for equality to #colorPrint, colorizing text the old way if so, and that's the only thing it's used for. Thus, the method signature could stand to be simplified, if it weren't for the fact that this one has other senders, meaning yet more code churn; I'm hesitant to mess with the signature of a Compiler method at this point, but doing so anyway for at least the sake of experiment, I've changed:

Compiler>>
format:in:notifying:contentsSymbol: (removed)
format:in:notifying:contentsSymbol: (removed)
format:in:notifying: (added)
format:in:notifying: (added)

In addition to applying the above, I had to do:

Preferences removePreference: #colorWhenPrettyPrinting

... to make the actual preference go away.

So far I haven't seen anything explode yet, but this is a pretty ambitious change for me, considering that I've only been Squeaking for a little over a year.

Would the good people of squeak-dev be so kind as to look over the changes I've placed in the Inbox for obvious errors? Here they are:

Collections-rss.118
Compiler-rss.72
Tools-rss.110
System-rss.134

 - Ron


------------------------------------------------------------------------