Fwd: preferences to settings refactoring: #colorWhenPrettyPrinting case
Locked
Fwd: preferences to settings refactoring: #colorWhenPrettyPrinting case
 
|
>> Stéphane Ducasse a écrit :
>>> alain >>> >> This slice removes the preference from the core, so it has nothing >> to do with Shout. >> As noticed in the issue comment, because colorWhenPrettyPretting >> has already no effect when set this slice consists more in a clean- >> up. >>> do you always color? >> so, never in core >>> or do you rely on shout? >> and color in pharo (aka pharo-dev) relies on shout as always. > > ok this is what I wanted to know. > > Stef >> >> >> alain >>> >>> Stef >>> >>> On May 29, 2009, at 9:39 AM, Alain Plantec wrote: >>> >>>> Hi, >>>> A slice is upload in pharoInbox. >>>> Cheers >>>> Alain >>>> >>>> Name: SLICE-colorWhenPrettyPrintingRemoval-alain_plantec.2 >>>> Dependencies: Compiler-alain_plantec.104, >>>> Kernel-alain_plantec.renggli.335, KernelTests-alain_plantec.109, >>>> Polymorph-Tools-Diff-alain_plantec.21, >>>> System-FilePackage-alain_plantec.6, System-Support-alain_plantec. >>>> 27, >>>> Tools-alain_plantec.154, Traits-alain_plantec.279 >>>> >>>> Remove the #colorWhenPrettyPrinting preference. >>>> As a consequence, some code formatting methods are refactored >>>> (The major remodelling is the >>>> Compiler>>#format:in:notifying:decorated: >>>> removal, replaced by Compiler>>#format:in:notifying:) >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >> >> > > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: preferences to settings refactoring: #colorWhenPrettyPrinting case
|
|
I could not believe so I checked :)
and indeed this preference was totally not working :) I think that using shout for code colorizing is much better. Now could you deprecated the most important methods instead of simply removing them? I can integrate you changes if you want and after you publish a deprecate method slice. Stef >>>> >>> This slice removes the preference from the core, so it has nothing >>> to do with Shout. >>> As noticed in the issue comment, because colorWhenPrettyPretting >>> has already no effect when set this slice consists more in a clean- >>> up. >>>> do you always color? >>> so, never in core >>>> or do you rely on shout? >>> and color in pharo (aka pharo-dev) relies on shout as always. >> >> ok this is what I wanted to know. >> >> Stef >>> >>> >>> alain >>>> >>>> Stef >>>> >>>> On May 29, 2009, at 9:39 AM, Alain Plantec wrote: >>>> >>>>> Hi, >>>>> A slice is upload in pharoInbox. >>>>> Cheers >>>>> Alain >>>>> >>>>> Name: SLICE-colorWhenPrettyPrintingRemoval-alain_plantec.2 >>>>> Dependencies: Compiler-alain_plantec.104, >>>>> Kernel-alain_plantec.renggli.335, KernelTests-alain_plantec.109, >>>>> Polymorph-Tools-Diff-alain_plantec.21, >>>>> System-FilePackage-alain_plantec.6, System-Support-alain_plantec. >>>>> 27, >>>>> Tools-alain_plantec.154, Traits-alain_plantec.279 >>>>> >>>>> Remove the #colorWhenPrettyPrinting preference. >>>>> As a consequence, some code formatting methods are refactored >>>>> (The major remodelling is the >>>>> Compiler>>#format:in:notifying:decorated: >>>>> removal, replaced by Compiler>>#format:in:notifying:) >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> >>> >>> >> >> >> >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: preferences to settings refactoring: #colorWhenPrettyPrinting case
|
|
Don't know if it's ever been related to the setting though, it broke anyways sometime between 262 and the 281cl image. Not a big loss anyways. I belive the "higherPerformance" preference can also be removed, the only thing it does it is increase the max possible GUI fps from the default 50 to 1000. You're VERY unlikely to ever hit 50 fps with any kind of updating going on, and even if you do, 50 fps is usually more than enough. Preferences serverMode setting is somewhat releated, but instead caps GUI cycles at 20/second (assuming 0ms rendering speed), so should be kept. Cheers, Henry On 30.05.2009 16:14, Stéphane Ducasse wrote: I could not believe so I checked :) and indeed this preference was totally not working :) I think that using shout for code colorizing is much better. Now could you deprecated the most important methods instead of simply removing them? I can integrate you changes if you want and after you publish a deprecate method slice. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: preferences to settings refactoring: #colorWhenPrettyPrinting case
|
|
On May 30, 2009, at 6:12 PM, Henrik Sperre Johansen wrote: > In Pharo-Core, you used to be able to right-click the method > selector pane in System Browser, and in the "What to show..." menu- > option select colorPrint to get syntax highlighting in core. > Don't know if it's ever been related to the setting though, it broke > anyways sometime between 262 and the 281cl image. Not a big loss > anyways. Yes apparently. and we will remove colorPrinting from the core and let Ecompletion do the job. > I belive the "higherPerformance" preference can also be removed, the > only thing it does it is increase the max possible GUI fps from the > default 50 to 1000. This is not that simple. Marcus told me that for server this is important since it can suck all cpu. > > You're VERY unlikely to ever hit 50 fps with any kind of updating > going on, and even if you do, 50 fps is usually more than enough. > > Preferences serverMode setting is somewhat releated, but instead > caps GUI cycles at 20/second (assuming 0ms rendering speed), so > should be kept. thanks this is important that we get feedback. > > > Cheers, > Henry > > On 30.05.2009 16:14, Stéphane Ducasse wrote: >> >> I could not believe so I checked :) >> and indeed this preference was totally not working :) >> >> I think that using shout for code colorizing is much better. >> >> Now could you deprecated the most important methods instead of simply >> removing them? >> I can integrate you changes if you want and after you publish a >> deprecate method slice. >> >> Stef >> >> >>>>> This slice removes the preference from the core, so it has nothing >>>>> to do with Shout. >>>>> As noticed in the issue comment, because colorWhenPrettyPretting >>>>> has already no effect when set this slice consists more in a >>>>> clean- >>>>> up. >>>>> >>>>>> do you always color? >>>>>> >>>>> so, never in core >>>>> >>>>>> or do you rely on shout? >>>>>> >>>>> and color in pharo (aka pharo-dev) relies on shout as always. >>>>> >>>> ok this is what I wanted to know. >>>> >>>> Stef >>>> >>>>> alain >>>>> >>>>>> Stef >>>>>> >>>>>> On May 29, 2009, at 9:39 AM, Alain Plantec wrote: >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> A slice is upload in pharoInbox. >>>>>>> Cheers >>>>>>> Alain >>>>>>> >>>>>>> Name: SLICE-colorWhenPrettyPrintingRemoval-alain_plantec.2 >>>>>>> Dependencies: Compiler-alain_plantec.104, >>>>>>> Kernel-alain_plantec.renggli.335, KernelTests-alain_plantec.109, >>>>>>> Polymorph-Tools-Diff-alain_plantec.21, >>>>>>> System-FilePackage-alain_plantec.6, System-Support- >>>>>>> alain_plantec. >>>>>>> 27, >>>>>>> Tools-alain_plantec.154, Traits-alain_plantec.279 >>>>>>> >>>>>>> Remove the #colorWhenPrettyPrinting preference. >>>>>>> As a consequence, some code formatting methods are refactored >>>>>>> (The major remodelling is the >>>>>>> Compiler>>#format:in:notifying:decorated: >>>>>>> removal, replaced by Compiler>>#format:in:notifying:) >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> [hidden email] >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>>>> project >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: preferences to settings refactoring: #colorWhenPrettyPrinting case
|
|
On 30.05.2009 18:18, Stéphane Ducasse wrote:
I believe we are in agreement, just using different words: - Server mode: Gives 50ms between redraws for non-GUI activity. - Normal mode: Gives (20ms - Time spent in last redraw) for non-GUI activity. - "higher"Performace: Gives (1ms - Time spent in last redraw) for non-GUI activity. If there's no new damage rects, no redrawing happens in updateCycle. For say, a server app with f.ex. a monitoring GUI which sends out dmg rects once one of it's models values that are displayed in the GUI changes, normal can be painful, and downright nasty with higherPerformance enabled when it comes to time left to do actual application stuff... (Especially if GUI contains complex elements, damage rects are somewhat off, + a plethora of other things that are, at the moment, quite likely). So server mode setting is a must-have, higherPerformance not much so. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: preferences to settings refactoring: #colorWhenPrettyPrinting case
|
|
In reply to this post by Stéphane Ducasse
Stéphane Ducasse a écrit :
> I could not believe so I checked :) > and indeed this preference was totally not working :) > > I think that using shout for code colorizing is much better. > > Now could you deprecated the most important methods instead of simply > removing them? > I can integrate you changes if you want and after you publish a > deprecate method slice. > with a .cs which re-introduces the removed method as a deprecated one. http://code.google.com/p/pharo/issues/detail?id=824. alain _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: preferences to settings refactoring: #colorWhenPrettyPrinting case
|
|
In reply to this post by Henrik Sperre Johansen
On May 30, 2009, at 19:00 , Henrik Sperre Johansen wrote: > On 30.05.2009 18:18, Stéphane Ducasse wrote: >> >> >>> I belive the "higherPerformance" preference can also be removed, the >>> only thing it does it is increase the max possible GUI fps from the >>> default 50 to 1000. >>> >> This is not that simple. Marcus told me that for server this is >> important since it can suck all cpu. >> > I believe we are in agreement, just using different words: > - Server mode: Gives 50ms between redraws for non-GUI activity. > - Normal mode: Gives (20ms - Time spent in last redraw) for non- > GUI activity. > - "higher"Performace: Gives (1ms - Time spent in last redraw) for > non-GUI activity. > > If there's no new damage rects, no redrawing happens in updateCycle. > For say, a server app with f.ex. a monitoring GUI which sends out > dmg rects once one of it's models values that are displayed in the > GUI changes, normal can be painful, and downright nasty with > higherPerformance enabled when it comes to time left to do actual > application stuff... (Especially if GUI contains complex elements, > damage rects are somewhat off, + a plethora of other things that > are, at the moment, quite likely). > > So server mode setting is a must-have, higherPerformance not much so. Exactly. "Server Mode" is an important fix I added to solve the image freezing problem two years ago: http://bugs.squeak.org/view.php?id=6581 "Higher performance" can be removed. Cheers, Adrian > > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |