[Pharo-project] 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. 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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. Cheers, Henry
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
I've added a comment to issue 824 with a .cs which re-introduces the removed method as a deprecated one. http://code.google.com/p/pharo/issues/detail?id=824. alain
participants (4)
-
Adrian Lienhard -
Alain Plantec -
Henrik Sperre Johansen -
Stéphane Ducasse