[Pharo-dev] Flat button look in Pharo3
I grew really fed up of the blue - gray gradients in the Pharo3Theme. Watching it all day long was too much, so I embarked on looking inside. Check https://pharo.fogbugz.com/default.asp?13132 and the SLICE-Issue-13132-Ugly-gradients-in-Pharo3Theme-Not-in-line-with-the-times-P hilippeBack.1 Phil --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
Re: [Pharo-dev] Crazy Smalltalk code snippets
Hi frank It would really great if you send an article on this to the ESUG workshop. I can help reviewing the draft if you want. Stef Yes: http://ss3.gemstone.com/ss/Control.html Last time I checked I did need to add a shim (see the ControlPharo package), but it did load cleanly and pass all its own tests. Control not only provides a convenient way of making partial continuations (of the shift/reset sort, if you're familiar with the literature), but also _delimited_ dynamic variables. As soon as you start stack-slicing with partial continuations, you quickly find that standard implementations of dynamic variables fail in all sorts of nasty ways. Fundamentally, normal dynamic variables _cannot_ work cleanly with partial continuations because they either close over too much of the dynamic environment, or too little. Here's some reading on the topic: [1] http://okmij.org/ftp/Computation/dynamic-binding.html [2] http://www.cs.rutgers.edu/~ccshan/dynscope/DDBinding.pdf [3] http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-express-delimited-dynamic-variables frank Cheers, -- Pavel -- best, Eliot
Re: [Pharo-dev] Use Spotlight to quickly evaluate and inspect short expressions
I like the idea now it is importznt that spotlight found class , method, package well :) Stef On 25 Mar 2014, at 14:30, Sven Van Caekenberghe s...@stfx.eu wrote: I had this idea: https://pharo.fogbugz.com/f/cases/13128/Use-Spotlight-to-quickly-evaluate-and-inspect-short-expressions now you can do shift-Enter:42Enter to inspect the magic number 42 shift-Enter:1500*1.25Enter to quickly compute your 25% raise shift-Enter:Float piEnter to see how many decimals you still remember shift-Enter:ZnClient new get: 'http://zn.stfx.eu/zn/small.html'Enter and so on. The interaction with the completion menu is not 100% perfect, but pressing Space at the end before Enter solves that. Feedback ? Sven PS: I know that many Smalltalk greybeards type everywhere to the same effect, and that is cool to, but it leaves around dirty windows. Opening a workspace for a single expression often is overkill. This feature is totally keyboard driven and very clean. PS2: Yes it resembles Emacs' M-: (evaluate-expression), but Pharo is much cooler, right ;-)
[Pharo-dev] When change on class with trait freeze
https://pharo.fogbugz.com/f/cases/13133/When-change-on-class-with-trait-freeze -- Dr. Geo http://drgeo.eu
[Pharo-dev] Fixing inconsistent buttons look in PharoUI
I've made a pass at fixing the buttons look (border in some places, no border in others). Spec-generated buttons are using the ButtonModel and MorphicButtonAdapter but the defaultSpec fo the the ButtonModel is asking the borderWidth and borderColor from the model, which is all nice but should be looking like the standard PluggableButtonMorphs, which do have a border. So, aligned now. https://pharo.fogbugz.com/default.asp?13135 Slice in inbox: SLICE-Issue-13135-Inconsistent-look-of-buttons-across-tools-Border-no-border -PhilippeBack.1 Phil --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
Re: [Pharo-dev] Crazy Smalltalk code snippets
+1 Doru On Wed, Mar 26, 2014 at 8:26 AM, Pharo4Stef pharo4s...@free.fr wrote: Hi frank It would really great if you send an article on this to the ESUG workshop. I can help reviewing the draft if you want. Stef Yes: http://ss3.gemstone.com/ss/Control.html Last time I checked I did need to add a shim (see the ControlPharo package), but it did load cleanly and pass all its own tests. Control not only provides a convenient way of making partial continuations (of the shift/reset sort, if you're familiar with the literature), but also _delimited_ dynamic variables. As soon as you start stack-slicing with partial continuations, you quickly find that standard implementations of dynamic variables fail in all sorts of nasty ways. Fundamentally, normal dynamic variables _cannot_ work cleanly with partial continuations because they either close over too much of the dynamic environment, or too little. Here's some reading on the topic: [1] http://okmij.org/ftp/Computation/dynamic-binding.html [2] http://www.cs.rutgers.edu/~ccshan/dynscope/DDBinding.pdf [3] http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-express-delimited-dynamic-variables frank Cheers, -- Pavel -- best, Eliot -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] Nicer scrollbars [was RE: Fixing inconsistent buttons look in PharoUI]
And while I was at it, I made the scrollbars nicer. https://pharo.fogbugz.com/default.asp?13136 All of this made me notice that there are quite a number of little glitches all over. Especially when using larger fonts. Phil From: Philippe Back [mailto:p...@highoctane.be] Sent: mercredi 26 mars 2014 10:51 To: 'pharo-dev@lists.pharo.org' Subject: Fixing inconsistent buttons look in PharoUI I've made a pass at fixing the buttons look (border in some places, no border in others). Spec-generated buttons are using the ButtonModel and MorphicButtonAdapter but the defaultSpec fo the the ButtonModel is asking the borderWidth and borderColor from the model, which is all nice but should be looking like the standard PluggableButtonMorphs, which do have a border. So, aligned now. https://pharo.fogbugz.com/default.asp?13135 Slice in inbox: SLICE-Issue-13135-Inconsistent-look-of-buttons-across-tools-Border-no-border -PhilippeBack.1 Phil --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
Re: [Pharo-dev] Flat button look in Pharo3
Flat design. It is funny. After the colors overdoses of the '90 and '00, we are back to the '70, with just a few more colors. It looks much better with flat blue, thanks. Hilaire Le 26/03/2014 09:55, Philippe Back a écrit : I grew really fed up of the blue - gray gradients in the Pharo3Theme. Watching it all day long was too much, so I embarked on looking inside.
Re: [Pharo-dev] Nicer scrollbars [was RE: Fixing inconsistent buttons look in PharoUI]
Phil, Nice. You should be attention to the refactoring in the UITheme hierarchy as Pharo3Theme is now a direct child of UITheme The SLICE is 13118 https://pharo.fogbugz.com/f/cases/13118/Clean-up-the-mess-in-UITheme-hierarchy Thanks Hilaire Le 26/03/2014 11:58, Philippe Back a écrit : And while I was at it, I made the scrollbars nicer. https://pharo.fogbugz.com/default.asp?13136 All of this made me notice that there are quite a number of little glitches all over. Especially when using larger fonts. Phil *From:*Philippe Back [mailto:p...@highoctane.be] *Sent:* mercredi 26 mars 2014 10:51 *To:* 'pharo-dev@lists.pharo.org' *Subject:* Fixing inconsistent buttons look in PharoUI I’ve made a pass at fixing the buttons look (border in some places, no border in others). Spec-generated buttons are using the ButtonModel and MorphicButtonAdapter but the defaultSpec fo the the ButtonModel is asking the borderWidth and borderColor from the model, which is all nice but should be looking like the standard PluggableButtonMorphs, which do have a border. So, aligned now. https://pharo.fogbugz.com/default.asp?13135 Slice in inbox: SLICE-Issue-13135-Inconsistent-look-of-buttons-across-tools-Border-no-border-PhilippeBack.1 Phil http://www.avast.com/ Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! http://www.avast.com/ est active. -- Dr. Geo http://drgeo.eu
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30801 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 557274: 30801
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 557274427ddcc51da0bbf382fa8b981a803b425b https://github.com/pharo-project/pharo-core/commit/557274427ddcc51da0bbf382fa8b981a803b425b Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-03-26 (Wed, 26 Mar 2014) Changed paths: A Kernel.package/Integer.class/instance/mathematical functions/nthRootRounded_.st M Kernel.package/Integer.class/instance/mathematical functions/nthRoot_.st R Kernel.package/LargeInteger.class/instance/mathematical functions/sqrtFloor.st M Kernel.package/NumberParser.class/instance/parsing-private/makeIntegerOrScaledInteger.st M Kernel.package/NumberParser.class/instance/parsing-private/readNumberWithFractionPartNumberOfTrailingZeroInIntegerPart_.st R Kernel.package/NumberParser.class/instance/parsing-private/readScale.st A Kernel.package/NumberParser.class/instance/parsing-private/readScaleWithDefaultNumberOfDigits_.st M Kernel.package/NumberParser.class/instance/parsing-public/nextScaledDecimal.st A KernelTests.package/FloatTest.class/instance/tests - characterization/testMaxExactInteger.st A KernelTests.package/IntegerTest.class/instance/tests - mathematical functions/testNthRootExactness.st A KernelTests.package/LargePositiveIntegerTest.class/instance/tests/testLargeSqrtFloor.st A KernelTests.package/NumberParserTest.class/instance/tests - ScaledDecimal/testScaledDecimalWithoutScaleSpecification.st A KernelTests.package/NumberParsingTest.class/instance/tests - ScaledDecimal/testScaledDecimalWithoutScaleSpecification.st M Metacello-ToolBox.package/MetacelloToolBox.class/class/scripts/createDevelopment_for_importFromBaseline_description_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script454.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30801.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 30801 13096 Do not update projects when releasing from the toolbox https://pharo.fogbugz.com/f/cases/13096 13081 Integer nthRoot: is not allways exact though it claims to https://pharo.fogbugz.com/f/cases/13081 13109 Incorrect sqrtFloor for large Integers https://pharo.fogbugz.com/f/cases/13109 13082 ScaledDecimal 0.050s should be interpreted with scale 3, not 0. https://pharo.fogbugz.com/f/cases/13082 http://files.pharo.org/image/30/30801.zip
Re: [Pharo-dev] Nicer scrollbars [was RE: Fixing inconsistent buttons look in PharoUI]
Cool, you're giving me hope that one day I'll switch to the Pharo3 theme :) Thierry Le 26/03/2014 11:58, Philippe Back a écrit : And while I was at it, I made the scrollbars nicer. https://pharo.fogbugz.com/default.asp?13136 All of this made me notice that there are quite a number of little glitches all over. Especially when using larger fonts. Phil *From:*Philippe Back [mailto:p...@highoctane.be] *Sent:* mercredi 26 mars 2014 10:51 *To:* 'pharo-dev@lists.pharo.org' *Subject:* Fixing inconsistent buttons look in PharoUI I’ve made a pass at fixing the buttons look (border in some places, no border in others). Spec-generated buttons are using the ButtonModel and MorphicButtonAdapter but the defaultSpec fo the the ButtonModel is asking the borderWidth and borderColor from the model, which is all nice but should be looking like the standard PluggableButtonMorphs, which do have a border. So, aligned now. https://pharo.fogbugz.com/default.asp?13135 Slice in inbox: SLICE-Issue-13135-Inconsistent-look-of-buttons-across-tools-Border-no-border-PhilippeBack.1 Phil http://www.avast.com/ Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! http://www.avast.com/ est active. -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
[Pharo-dev] [pharo-project/pharo-core] 8415a3: 30802
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 8415a33051a1b45ef02a5df2dc37ee30650a57a2 https://github.com/pharo-project/pharo-core/commit/8415a33051a1b45ef02a5df2dc37ee30650a57a2 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-03-26 (Wed, 26 Mar 2014) Changed paths: M Kernel.package/Number.class/instance/mathematical functions/floorLog_.st A KernelTests.package/FractionTest.class/instance/tests - mathematical functions/testFloorLog.st A KernelTests.package/IntegerTest.class/instance/tests - mathematical functions/testFloorLog.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script455.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30802.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHParserST80.class/instance/scan/scanBinary.st M Shout.package/SHParserST80.class/instance/scan/scanNumber.st M ShoutTests.package/SHParserST80Test.class/instance/tests/testNumbers.st Log Message: --- 30802 13080 Shout does not recognize doubled vertical bar || as a binary selector https://pharo.fogbugz.com/f/cases/13080 13083 Shout does not recognize Scaled decimal terminated by s https://pharo.fogbugz.com/f/cases/13083 13085 Large Integer and Fraction should avoid Float overflow when asked for their floogLog: https://pharo.fogbugz.com/f/cases/13085 http://files.pharo.org/image/30/30802.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30802 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] Nicer scrollbars [was RE: Fixing inconsistent buttons look in PharoUI]
If you are at it, would you be interested in trying to provide a scrollbar without the arrow buttons, and with half the width? :) Doru On Wed, Mar 26, 2014 at 12:39 PM, Goubier Thierry thierry.goub...@cea.frwrote: Cool, you're giving me hope that one day I'll switch to the Pharo3 theme :) Thierry Le 26/03/2014 11:58, Philippe Back a écrit : And while I was at it, I made the scrollbars nicer. https://pharo.fogbugz.com/default.asp?13136 All of this made me notice that there are quite a number of little glitches all over. Especially when using larger fonts. Phil *From:*Philippe Back [mailto:p...@highoctane.be] *Sent:* mercredi 26 mars 2014 10:51 *To:* 'pharo-dev@lists.pharo.org' *Subject:* Fixing inconsistent buttons look in PharoUI I've made a pass at fixing the buttons look (border in some places, no border in others). Spec-generated buttons are using the ButtonModel and MorphicButtonAdapter but the defaultSpec fo the the ButtonModel is asking the borderWidth and borderColor from the model, which is all nice but should be looking like the standard PluggableButtonMorphs, which do have a border. So, aligned now. https://pharo.fogbugz.com/default.asp?13135 Slice in inbox: SLICE-Issue-13135-Inconsistent-look-of-buttons- across-tools-Border-no-border-PhilippeBack.1 Phil http://www.avast.com/ Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! http://www.avast.com/ est active. -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] [Fixed] Re: Random refactoring on UITheme or what?
Slice in the Inbox. https://pharo.fogbugz.com/f/cases/13118/Clean-up-the-mess-in-UITheme-hierarchy Thanks Hilaire Le 22/03/2014 18:11, Ben Coman a écrit : Hilaire Fernandes wrote: Sure. Oh, by the way I realize the Polymoprh examples where scalped in Pharo3 because of the protocol change of ListModel. This is really *not* nice
Re: [Pharo-dev] [Fixed] Re: Random refactoring on UITheme or what?
And I said that even if it would disturb Moose, we would just fix it in Moose. Going towards a slimmer system should take precedence over any convenience (at least for now) :). Cheers, Doru On Wed, Mar 26, 2014 at 1:37 PM, Marcus Denker marcus.den...@inria.frwrote: I already double checked with Doru that it does not disturb moose (no problem), so I will integrate it now. On 22 Mar 2014, at 20:33, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Slice in the Inbox. https://pharo.fogbugz.com/f/cases/13118/Clean-up-the-mess-in-UITheme-hierarchy Thanks Hilaire Le 22/03/2014 18:11, Ben Coman a écrit : Hilaire Fernandes wrote: Sure. Oh, by the way I realize the Polymoprh examples where scalped in Pharo3 because of the protocol change of ListModel. This is really *not* nice -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Nicer scrollbars [was RE: Fixing inconsistent buttons look in PharoUI]
On Wed, Mar 26, 2014 at 1:13 PM, Tudor Girba tu...@tudorgirba.com wrote: If you are at it, would you be interested in trying to provide a scrollbar without the arrow buttons, and with half the width? :) Doru Ah, like in Chrome. Well, I like the arrows :-) And I'l love the bars to be double the size. I planned to do something in that area, so, either way would work. Phil On Wed, Mar 26, 2014 at 12:39 PM, Goubier Thierry thierry.goub...@cea.fr wrote: Cool, you're giving me hope that one day I'll switch to the Pharo3 theme :) Thierry Le 26/03/2014 11:58, Philippe Back a écrit : And while I was at it, I made the scrollbars nicer. https://pharo.fogbugz.com/default.asp?13136 All of this made me notice that there are quite a number of little glitches all over. Especially when using larger fonts. Phil *From:*Philippe Back [mailto:p...@highoctane.be] *Sent:* mercredi 26 mars 2014 10:51 *To:* 'pharo-dev@lists.pharo.org' *Subject:* Fixing inconsistent buttons look in PharoUI I've made a pass at fixing the buttons look (border in some places, no border in others). Spec-generated buttons are using the ButtonModel and MorphicButtonAdapter but the defaultSpec fo the the ButtonModel is asking the borderWidth and borderColor from the model, which is all nice but should be looking like the standard PluggableButtonMorphs, which do have a border. So, aligned now. https://pharo.fogbugz.com/default.asp?13135 Slice in inbox: SLICE-Issue-13135-Inconsistent-look-of-buttons- across-tools-Border-no-border-PhilippeBack.1 Phil http://www.avast.com/ Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! http://www.avast.com/ est active. -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Crazy Smalltalk code snippets
On 24 Mar 2014, at 11:51 , Pavel Krivanek pavel.kriva...@gmail.com wrote: Who can find the most useful usage of this? thisContext instVarNamed: #receiver put: 42. self factorial GOTO statement in Pharo: FileStream stdout nextPutAll: 'Hello world'; lf. thisContext jump: -12. Let's collect the next ones :-) Cheers, -- Pavel evaluator: aMethodBody Uses a lightweight class to provide instance-specific value. |lightWeightClass | lightWeightClass := self class copy setSuperclass: MyBaseClass. lightWeightClass compile: aMethodBody classified: 'accessing'. lightWeightClass adoptInstance: self. evaluate: someThing “Will be replaced by specific behavior at runtime if appropriate” ^true Because, well, storing a block and evaluating that, is too much overhead. Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
[Pharo-dev] Using hierarchy in Nautilus broken?
In 30800, If I select a class, then select hierarchy, then select a greyed-out class up or down the hierarchy, the view and selection get unusable. Is that a well-known issue? Stephan
Re: [Pharo-dev] Crazy Smalltalk code snippets
I still like: what #magic isSymbol ifTrue: [#magic become: #(0)]. #magic at: 1 put: #magic first + 1. ^#magic first. Execute it multiple times, and make sure there is no other #magic symbol in the system ;-) Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Nicer scrollbars [was RE: Fixing inconsistent buttons look in PharoUI]
2014-03-26 9:44 GMT-03:00 p...@highoctane.be p...@highoctane.be: On Wed, Mar 26, 2014 at 1:13 PM, Tudor Girba tu...@tudorgirba.com wrote: If you are at it, would you be interested in trying to provide a scrollbar without the arrow buttons, and with half the width? :) +1 Ah, like in Chrome. Well, I like the arrows :-) And I'l love the bars to be double the size. I planned to do something in that area, so, either way would work. Like in Chrome... and almost everywhere else. The scrolling metaphor is so ingrained that in some cases even the bar isn't displayed until the scroll intent is initiated. Esteban A. Maringolo
[Pharo-dev] [pharo-project/pharo-core] 208a81: 30803
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 208a812bd59fbdf05505daed623bc3eda4b887eb https://github.com/pharo-project/pharo-core/commit/208a812bd59fbdf05505daed623bc3eda4b887eb Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-03-26 (Wed, 26 Mar 2014) Changed paths: M Morphic-Base.package/PluggableTextMorphWithLimits.class/instance/drawing/backgroundColorFor_.st M Morphic-Examples.package/WidgetExamples.class/README.md M Morphic-Examples.package/WidgetExamples.class/instance/examples/exampleBasicControls.st M Morphic-Examples.package/WidgetExamples.class/instance/examples/exampleOtherControls.st R Polymorph-Widgets.package/BlueUITheme.class/README.md R Polymorph-Widgets.package/BlueUITheme.class/class/accessing/baseColor.st R Polymorph-Widgets.package/BlueUITheme.class/class/accessing/basePassiveBackgroundColor.st R Polymorph-Widgets.package/BlueUITheme.class/class/accessing/baseSelectionColor.st R Polymorph-Widgets.package/BlueUITheme.class/class/accessing/darkBaseColor.st R Polymorph-Widgets.package/BlueUITheme.class/class/accessing/lightBaseColor.st R Polymorph-Widgets.package/BlueUITheme.class/class/accessing/lightSelectionColor.st R Polymorph-Widgets.package/BlueUITheme.class/class/accessing/themeName.st R Polymorph-Widgets.package/BlueUITheme.class/class/accessing/veryLightSelectionColor.st R Polymorph-Widgets.package/BlueUITheme.class/class/private/importGlamorousIcons.st R Polymorph-Widgets.package/BlueUITheme.class/class/private/importIcons_fromFolder_inClass_category_.st R Polymorph-Widgets.package/BlueUITheme.class/class/settings/newDefaultSettings.st R Polymorph-Widgets.package/BlueUITheme.class/class/settings/setPreferredShoutColors.st R Polymorph-Widgets.package/BlueUITheme.class/class/settings/setPreferredWorldBackground.st R Polymorph-Widgets.package/BlueUITheme.class/class/testing/isAbstract.st R Polymorph-Widgets.package/BlueUITheme.class/definition.st R Polymorph-Widgets.package/BlueUITheme.class/instance/accessing/windowActiveDropShadowStyle_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/basic-colors/subgroupColorFrom_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/basic-colors/taskbarButtonLabelColorFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/basic-colors/treeLineWidth.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles-buttons/buttonCornerStyleIn_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles-buttons/buttonNormalBorderStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles-scrollbars/scrollbarNormalThumbBorderStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles/configureWindowBorderFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles/configureWindowDropShadowFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles/dropListNormalBorderStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles/groupPanelBorderStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles/plainGroupPanelBorderStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles/tabLabelNormalBorderStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles/tabPanelBorderStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles/taskbarThumbnailCornerStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles/taskbarThumbnailNormalBorderStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/border-styles/textEditorNormalBorderStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/defaults/buttonMinHeight.st R Polymorph-Widgets.package/BlueUITheme.class/instance/defaults/buttonMinWidth.st R Polymorph-Widgets.package/BlueUITheme.class/instance/fill-styles-buttons/buttonNormalFillStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/fill-styles-buttons/buttonSelectedFillStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/fill-styles-buttons/menuItemInDockingBarSelectedFillStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/fill-styles-buttons/tabLabelNormalFillStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/fill-styles-buttons/tabLabelSelectedFillStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/fill-styles-scrollbars/scrollbarNormalFillStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/fill-styles-scrollbars/scrollbarNormalThumbFillStyleFor_.st R Polymorph-Widgets.package/BlueUITheme.class/instance/fill-styles/dockingBarNormalFillStyleFor_.st R
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30803 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] Using hierarchy in Nautilus broken?
Yes, I reopend case 13099 https://pharo.fogbugz.com/default.asp?13099nautilus is not refreshing package tree panel on certain operations, as its fix introduced this bug. (Maybe I should raise the priority) 2014-03-26 14:03 GMT+01:00 Stephan Eggermont step...@stack.nl: In 30800, If I select a class, then select hierarchy, then select a greyed-out class up or down the hierarchy, the view and selection get unusable. Is that a well-known issue? Stephan
Re: [Pharo-dev] Using hierarchy in Nautilus broken?
Same effect here. On Wed, Mar 26, 2014 at 2:03 PM, Stephan Eggermont step...@stack.nl wrote: In 30800, If I select a class, then select hierarchy, then select a greyed-out class up or down the hierarchy, the view and selection get unusable. Is that a well-known issue? Stephan
Re: [Pharo-dev] Crazy Smalltalk code snippets
Hi Stef, Thanks for the kind words! How would I go about doing that? frank On 26 March 2014 07:26, Pharo4Stef pharo4s...@free.fr wrote: Hi frank It would really great if you send an article on this to the ESUG workshop. I can help reviewing the draft if you want. Stef Yes: http://ss3.gemstone.com/ss/Control.html Last time I checked I did need to add a shim (see the ControlPharo package), but it did load cleanly and pass all its own tests. Control not only provides a convenient way of making partial continuations (of the shift/reset sort, if you're familiar with the literature), but also _delimited_ dynamic variables. As soon as you start stack-slicing with partial continuations, you quickly find that standard implementations of dynamic variables fail in all sorts of nasty ways. Fundamentally, normal dynamic variables _cannot_ work cleanly with partial continuations because they either close over too much of the dynamic environment, or too little. Here's some reading on the topic: [1] http://okmij.org/ftp/Computation/dynamic-binding.html [2] http://www.cs.rutgers.edu/~ccshan/dynscope/DDBinding.pdf [3] http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-express-delimited-dynamic-variables frank Cheers, -- Pavel -- best, Eliot
Re: [Pharo-dev] Nicer scrollbars [was RE: Fixing inconsistent buttons look in PharoUI]
On Wed, Mar 26, 2014 at 2:09 PM, Esteban A. Maringolo emaring...@gmail.comwrote: 2014-03-26 9:44 GMT-03:00 p...@highoctane.be p...@highoctane.be: On Wed, Mar 26, 2014 at 1:13 PM, Tudor Girba tu...@tudorgirba.com wrote: If you are at it, would you be interested in trying to provide a scrollbar without the arrow buttons, and with half the width? :) +1 Ah, like in Chrome. Well, I like the arrows :-) And I'l love the bars to be double the size. I planned to do something in that area, so, either way would work. Like in Chrome... and almost everywhere else. The scrolling metaphor is so ingrained that in some cases even the bar isn't displayed until the scroll intent is initiated. FWIW, Office 2013 has nice scrollbars with arrows. Along with supersmooth animations. Windows Explorer has others (which have cool arrows) and these (-) (-) (^) things that we should put into nautilus in addition to the history dropdown. Yeah, a new plugin feature :-) Phil Esteban A. Maringolo
Re: [Pharo-dev] Nicer scrollbars [was RE: Fixing inconsistent buttons look in PharoUI]
2014-03-26 10:27 GMT-03:00 p...@highoctane.be p...@highoctane.be: On Wed, Mar 26, 2014 at 2:09 PM, Esteban A. Maringolo emaring...@gmail.com Like in Chrome... and almost everywhere else. The scrolling metaphor is so ingrained that in some cases even the bar isn't displayed until the scroll intent is initiated. FWIW, Office 2013 has nice scrollbars with arrows. Along with supersmooth animations. Microsoft is very conservative in that regard. They aim at the broader range of END USERS, from the noviceto the computer literate one. I payed particular attention to this scrollbar UX in the past, and my personal research (watching people) shows that most of them use the mousewheel or simply drag the bar in mouse based UIs, and/or swipe up/down in touch based. I love supersmooth animations, but they're part of a whole transitions engine. Windows Explorer has others (which have cool arrows) and these (-) (-) (^) things that we should put into nautilus in addition to the history dropdown. What are the (-) (-) (^) you mention? :) Regards!
[Pharo-dev] CFP - IWST 2014
[Please accept our apologies if you receive multiple copies of this call] [Please send to interested colleagues / mailing-lists] CALL FOR PAPERS IWST14 -- International Workshop on Smalltalk Technologies Cambridge, England; August 19, 2014 http://www.esug.org/Conferences/2014/IWST14 --- Goals and scopes --- The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Participants are invited to submit research articles or industrial papers. This year we want to open two different tracks: one research track and one industrial track with less scientific constraints. We expect papers of three kinds: Short position papers describing emerging ideas Long research papers with deeper description of experiments and of research results. Industrial papers with presentation of real and innovative Smalltalk applications; this kind of paper should enlighten why Smalltalk is really appropriate for your application. We will not enforce any length restriction. Important Dates Submission deadline: June 15, 2014 Notification deadline: July 15, 2014 Workshop : August 19, 2014 All accepted papers will be published in ACM DL (To be confirmed) --- Topics --- We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: Aspect-oriented programming, Design patterns, Experience reports, Frameworks, Implementation, new dialects or languages implemented in Smalltalk, Interaction with other languages, Meta-programming and Meta-modeling, Tools --- Best Paper Award --- To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. We thank Lam Research Corporation for its financial contribution that makes it possible a price for the three best papers: 1000 USD for first place, 600 USD for second place and 400 USD for third place. The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be illegible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. --- Publication --- Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also contains links to useful informations on how to write effective submissions. --- Submission --- All submissions must be sent via easychair: https://www.easychair.org/conferences/?conf=iwst2014 --- Program chairs --- Alain Plantec (UMR 6265 Lab-STICC, University of Brest, France) Jannik Laval (Ecole des Mines de Douai, France) -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
[Pharo-dev] Access to voyage repository
Can anybody add me to voyage repo on smalltalkhub? thanks, Norbert
Re: [Pharo-dev] Access to voyage repository
done On 26 Mar 2014, at 10:48, Norbert Hartl norb...@hartl.name wrote: Can anybody add me to voyage repo on smalltalkhub? thanks, Norbert
Re: [Pharo-dev] Nicer scrollbars [was RE: Fixing inconsistent buttons look in PharoUI]
On Wed, Mar 26, 2014 at 2:38 PM, Esteban A. Maringolo emaring...@gmail.comwrote: 2014-03-26 10:27 GMT-03:00 p...@highoctane.be p...@highoctane.be: On Wed, Mar 26, 2014 at 2:09 PM, Esteban A. Maringolo emaring...@gmail.com Like in Chrome... and almost everywhere else. The scrolling metaphor is so ingrained that in some cases even the bar isn't displayed until the scroll intent is initiated. FWIW, Office 2013 has nice scrollbars with arrows. Along with supersmooth animations. Microsoft is very conservative in that regard. They aim at the broader range of END USERS, from the noviceto the computer literate one. I payed particular attention to this scrollbar UX in the past, and my personal research (watching people) shows that most of them use the mousewheel or simply drag the bar in mouse based UIs, and/or swipe up/down in touch based. I love supersmooth animations, but they're part of a whole transitions engine. Yes, true. But I am not doing any .NET and WPF anytime soon. Nor MFC. Windows Explorer has others (which have cool arrows) and these (-) (-) (^) things that we should put into nautilus in addition to the history dropdown. What are the (-) (-) (^) you mention? :) These: [image: Inline image 1] Doable for the methods history. And maybe the workspace previous contents since we now have little toolbars in Spec. Phil Regards! inline: ARROWS26-03-14 14-53-44.png
Re: [Pharo-dev] Access to voyage repository
Am 26.03.2014 um 14:53 schrieb Esteban Lorenzano esteba...@gmail.com: done thanks, Norbert On 26 Mar 2014, at 10:48, Norbert Hartl norb...@hartl.name wrote: Can anybody add me to voyage repo on smalltalkhub? thanks, Norbert
Re: [Pharo-dev] threading in Pharo
Eliot Miranda wrote: On Tue, Mar 25, 2014 at 10:21 AM, Eliot Miranda eliot.mira...@gmail.com wrote: Hi Igor, you have a point but I disagree. The scheduler is defined in the implementation section of the blue book. It could be more explicit, but the blue book scheduler is a known and simple system. In my threading work I've made sure to preserve its semantics (cooperative within priorities, preemptive across priorities, thread switch at activation of non-primitive sends and backward branches). The only serious bug I know of (that preempting sends a process to the back of its run-queue) was addressed in Cog and the VW VM. We can and should write up the semantics, but they're not undefined, they're simple and they do work. Oops. I lie. There is a serious bug with Semaphorecritical: and the like. There's a suspension point after signal and before block evaluation that can result in deadlock if a higher priority process signals the semaphore. Since the higher priority process is running the lower priority process never makes progress to run the ensure block or cvlear the flag or whatever it needs to do, and hence the system deadlocks. This requires thought ;-) So I do know of one outstanding bug. My grasp of concurrency controls hasn't been tested in 20 years, so naively I would say: If a lower priority process "L" holds** a semaphore when the higher priority process "H" signals the semaphore, temporarily raise the priority of the "L", or temporarily lower the priority of "H". Is there something simple that I missing? cheers -ben Eliot (phone) On Mar 25, 2014, at 10:11 AM, Igor Stasenko siguc...@gmail.com wrote: On 25 March 2014 17:31, Eliot Miranda eliot.mira...@gmail.com wrote: Hi Igor, On Tue, Mar 25, 2014 at 5:05 AM, Igor Stasenko siguc...@gmail.com wrote: On 24 March 2014 22:54, p...@highoctane.be p...@highoctane.be wrote: On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel alexandre.ber...@me.com wrote: I am working on a memory model for expandable collection in Pharo. Currently, OrderedCollection, Dictionary and other expandable collections use a internal array to store their data. My new collection library recycle these array instead of letting the garbage collector dispose them. I simply insert the arrays in an ordered collection when an array is not necessary anymore. And I remove one when I need one. Hm, is that really going to be worth the trouble? This technique reduces the consumption of about 15% of memory. At the end, #add: and #remove: are performed on these polls of arrays. I havent been able to spot any problem regarding concurrency and I made no effort in preventing them. I have a simple global collection and each call site of "OrderedCollection new can pick an element of my global collection. I have the impression that I simply need to guard the access to the global poll, which is basically guarding #add: #remove: and #includes: One of the AtomicCollections might be the right things for you? I will have a look at it. What is funny, is that I did not care at all about multi-threading and concurrency, and I have not spotted any problem so far. There isnt any multi-threading like in Java, you got a much more control version: cooperative on the same priority, preemptive between priorities. So, I am not surprised. And well, these operations are likely not to be problematic when they are racy, except when the underling data structure could get into an inconsistent state itself. The overall operations (adding/removing/searing) are racy on the application level anyway. However, much more interesting would be to know what kind of benefit do you see for such reuse? And especially, with Spur around the corner, will it still pay off then? Or is it an application-specific optimization? I am exploring a new design of the collection library of Pharo. Not all the (academic) ideas will be worth porting into the mainstream of Pharo. But some of them yes. Thanks for all your help guys! Youre great! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. An interesting method I stumbled upon which may help in understanding how these things do work. BlockClosurevalueUnpreemptively "Evaluate the
Re: [Pharo-dev] threading in Pharo
On 26 March 2014 15:04, Ben Coman b...@openinworld.com wrote: Eliot Miranda wrote: On Tue, Mar 25, 2014 at 10:21 AM, Eliot Miranda eliot.mira...@gmail.comwrote: Hi Igor, you have a point but I disagree. The scheduler is defined in the implementation section of the blue book. It could be more explicit, but the blue book scheduler is a known and simple system. In my threading work I've made sure to preserve its semantics (cooperative within priorities, preemptive across priorities, thread switch at activation of non-primitive sends and backward branches). The only serious bug I know of (that preempting sends a process to the back of its run-queue) was addressed in Cog and the VW VM. We can and should write up the semantics, but they're not undefined, they're simple and they do work. Oops. I lie. There is a serious bug with Semaphorecritical: and the like. There's a suspension point after signal and before block evaluation that can result in deadlock if a higher priority process signals the semaphore. Since the higher priority process is running the lower priority process never makes progress to run the ensure block or cvlear the flag or whatever it needs to do, and hence the system deadlocks. This requires thought ;-) So I do know of one outstanding bug. My grasp of concurrency controls hasn't been tested in 20 years, so naively I would say: If a lower priority process L holds** a semaphore when the higher priority process H signals the semaphore, temporarily raise the priority of the L, or temporarily lower the priority of H. Is there something simple that I missing? It really depends what you put into priority thing. In preemptive scheduling policy it means: threads with higher priority always preempt ones with lower one. That means that any low-priority task has no chances to advance, if there even single higher priority task that never stops. In shared-time scheduling that means: threads with higher priority has higher % of computing resources allocated (the exact amount/ratio can depend on policy). But shared-time scheduling good in another aspect: all tasks has chance to advance, if observed over some finite time frame, regardless of their priority. The semaphores and other synchronizing primitives is not really related to scheduling. They are orthogonal, as they just giving a control over yielding execution of task (basically halting it) until some condition met. cheers -ben -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Nicer scrollbars [was RE: Fixing inconsistent buttons look in PharoUI]
2014-03-26 10:55 GMT-03:00 p...@highoctane.be p...@highoctane.be: On Wed, Mar 26, 2014 at 2:38 PM, Esteban A. Maringolo emaring...@gmail.com wrote: 2014-03-26 10:27 GMT-03:00 p...@highoctane.be p...@highoctane.be: Windows Explorer has others (which have cool arrows) and these (-) (-) (^) things that we should put into nautilus in addition to the history dropdown. What are the (-) (-) (^) you mention? :) These: [image: Inline image 1] Doable for the methods history. And maybe the workspace previous contents since we now have little toolbars in Spec. That'd be nice. I miss the navigation history from Dolphin Browsers: http://www.object-arts.com/downloads/docs/system_browser.htm http://www.object-arts.com/downloads/docs/class_browser.htm Regards! inline: ARROWS26-03-14 14-53-44.png
Re: [Pharo-dev] When change on class with trait freeze
Hilaire Fernandes wrote: https://pharo.fogbugz.com/f/cases/13133/When-change-on-class-with-trait-freeze I've somewhat isolated the problem, as reported on the case. Its related to... TEasilyThemed methods size -- 164 and the sources being updated individually for each method. That is as far as I can take it on my own. cheers -ben
Re: [Pharo-dev] Font problem is still there
I didn't tried to debug it, i can't bet it would be easy (need to build a debug version of cairo first) but it worth trying. Meanwhile i will put workaround back. Thanks Igor. Let us know! Alexandre Hi! there's some kind of caching interference either in cairo or between cairo and freetype, when using identity transformation matrix and integral (integer) font sizes. and there is a simple workaround: canvas pathTransform restoreAfter: [ canvas pathTransform scaleBy: 1.1. draw text here ] this workaround was in font-rendering code, but then i removed it, because i thought problem was solved. Can we add this back please? This font problem is quite serious. It makes people laugh at Pharo... -- Best regards, Igor Stasenko. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Random refactoring on UITheme or what?
Hilaire Fernandes wrote: I will propose a simple hierarchy for the theme: UITheme +-UIPharoTheme +-UIVistaryTheme +-UIWateryTheme I will propose to delete all the other themes as they should belong to other package. Hilaire Just curious to learn... I saw mentioned somewhere that it was bad to subclass themes. What is inherently wrong with that? For example Pharo3Theme was inheriting from UIWateryTheme ? If I wanted my own theme, the same as UIThemeWatery but a different baseColor, should I do... UITheme subclass: MyTheme and copy all methods from UIThemeWatery then modify MyTheme class baseColor or do... UIThemeWatery subclass: MyTheme and add MyTheme class baseColor cheers -ben
Re: [Pharo-dev] Random refactoring on UITheme or what?
Ben, My personal opinion on that: - Pharo3Theme subclassing UIWatery was not necessary as these two themes have mostly nothing in common - Indeed if you want to only change a base color of watery theme, you have to subclass from it. - For DrGeo on tablet I needed a dedicated theme to remove the windows decoration, for positionning dialog centered on the top, etc., and with the look of watery; so I subclassed from watery. Thanks for the integration work Hilaire Le 26/03/2014 18:08, Ben Coman a écrit : Just curious to learn... I saw mentioned somewhere that it was bad to subclass themes. What is inherently wrong with that? For example Pharo3Theme was inheriting from UIWateryTheme ? If I wanted my own theme, the same as UIThemeWatery but a different baseColor, should I do... UITheme subclass: MyTheme and copy all methods from UIThemeWatery then modify MyTheme class baseColor or do... UIThemeWatery subclass: MyTheme and add MyTheme class baseColor cheers -ben -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] When change on class with trait freeze
The problem did not show up with Pharo 1.4 with the same big trait. Hilaire Le 26/03/2014 17:26, Ben Coman a écrit : Hilaire Fernandes wrote: https://pharo.fogbugz.com/f/cases/13133/When-change-on-class-with-trait-freeze I've somewhat isolated the problem, as reported on the case. Its related to... TEasilyThemed methods size -- 164 and the sources being updated individually for each method. That is as far as I can take it on my own. cheers -ben -- Dr. Geo http://drgeo.eu
[Pharo-dev] Redraw suggestion for Athens
I've been using Athens to render my applications and I've thought a bit about how the #changed mechanism might change when BitBlt rendering is replaced by Athens rendering. First, you must realize that a lot of the rendering in Morphic is highly specialized to deal with the slowness of BitBlt rendering. So, a morph that has changed in appearance (by moving, etc.) calls the #changed message on itself. This tells morphic that it needs to get rerendered when the screen is next being updated. The full bounds of the morph are then added to the damage recorder. When the UI loop gets around to it, the damage areas are rerendered in a relatively smart fashion. For instance, if a morph is opaque, none of the morphs behind it get rendered. Only the damage rectangles are copied to the canvas, which is then updated. With Athens, this strategy is problematic. Because Athens allows for arbitrary rotation and scaling, it is much more difficult to determine the bounds of a specific morph. Athens also can use local positioning as opposed to the global positioning currently used in Morphic. Igor argues that it is best not to try to figure this out but just to render everything when anything has changed. In my experience, that is a reasonable proposition. Athens rendering is fast enough that even full animation could be done reasonably. That would also simplify the #changed code and could pretty much eliminate the damage recorder. OK. That's enough setup. Now for the suggestion. One problem I still have with Athens rendering is that there is still a visual artifact that has to do with the screen refresh not being in sync with the UI loop. Half the screen renders the previous frame and the other half renders the current frame. While it only is noticeable when moving something fast, it still isn't nice. So, here's the suggestion. Have two Athens surfaces in memory that switch between being the one next to be rendered and the active one. When the screen refresh comes along, send it to the last one rendered (i.e., the active one). When a change happens, render the surface on the inactive one. When that is done, make it the active one. Thus, the screen update always has an accurate form. It also would mean less copying around of forms (i.e., cacheing). I'm not sure if this implementation is viable, but it seems like a fairly efficient strategy that Athens could enable. Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] Font problem is still there
Thanks, indeed :) Please keep us informed. Doru On Wed, Mar 26, 2014 at 5:57 PM, Alexandre Bergel alexandre.ber...@me.comwrote: I didn't tried to debug it, i can't bet it would be easy (need to build a debug version of cairo first) but it worth trying. Meanwhile i will put workaround back. Thanks Igor. Let us know! Alexandre Hi! there's some kind of caching interference either in cairo or between cairo and freetype, when using identity transformation matrix and integral (integer) font sizes. and there is a simple workaround: canvas pathTransform restoreAfter: [ canvas pathTransform scaleBy: 1.1. draw text here ] this workaround was in font-rendering code, but then i removed it, because i thought problem was solved. Can we add this back please? This font problem is quite serious. It makes people laugh at Pharo... -- Best regards, Igor Stasenko. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] Replacing SBCI buttons in Nautilus
I’ve been inspired by Philippe’s work on the UI and spend the afternoon replacing the SBCI bitmapped-backed buttons by normal ones. Stephan
[Pharo-dev] DateAndTime#= slow?
I'm grouping by date a resultset coming from the database, it cointains around 2000 dated objects. It is: myObject groupBy: #date. But turn's out that DateAndTime #= comparison is elegant object-wise but not performance-wise. Because it instantiates several other objects along the way. This is in the milliseconds range, but in the agregate of a couple of thousand of objects, it creates a lot of not-simple-objects (it is, not integers), and maybe because of that it isn't as fast as I'd expect. Did somebody experienced this too? Regards, Esteban A. Maringolo
Re: [Pharo-dev] Replacing SBCI buttons in Nautilus.
https://pharo.fogbugz.com/default.asp?13137 Name: SLICE-Issue-13137-Replace-SBCI-buttons-StephanEggermont.1 Author: StephanEggermont Time: 26 March 2014, 10:30:33.195511 pm UUID: 39080266-ad51-43f9-8ab4-5afe636d7372 Ancestors: Dependencies: Nautilus-StephanEggermont.709 Replace the bitmap-backed buttons through simpler ones
Re: [Pharo-dev] DateAndTime#= slow?
Yes, I’ve experienced this (in older Pharo versions mind you). We explicitly don’t use DateAndTime / Date / Timestamp in such cases but store an integer representation instead. We can always reify that if we need to and still have good comparison speeds. Cheers, Max On 26.03.2014, at 22:21, Esteban A. Maringolo emaring...@gmail.com wrote: I'm grouping by date a resultset coming from the database, it cointains around 2000 dated objects. It is: myObject groupBy: #date. But turn's out that DateAndTime #= comparison is elegant object-wise but not performance-wise. Because it instantiates several other objects along the way. This is in the milliseconds range, but in the agregate of a couple of thousand of objects, it creates a lot of not-simple-objects (it is, not integers), and maybe because of that it isn't as fast as I'd expect. Did somebody experienced this too? Regards, Esteban A. Maringolo
Re: [Pharo-dev] DateAndTime#= slow?
On 26 Mar 2014, at 22:21, Esteban A. Maringolo emaring...@gmail.com wrote: I'm grouping by date a resultset coming from the database, it cointains around 2000 dated objects. It is: myObject groupBy: #date. But turn's out that DateAndTime #= comparison is elegant object-wise but not performance-wise. Because it instantiates several other objects along the way. Not that I want to defend DataAndTime (I didn't implement and I am not using ZTimestamp for nothing), but I fail to see what is wrong with the code, how does it 'create several objects' (in Pharo 3) ? DateAndTime#hasEqualTicks: aDateAndTime ^ (self julianDayNumberUTC = aDateAndTime julianDayNumberUTC) and: [ (seconds = aDateAndTime secondsSinceMidnightUTC) and: [ nanos = aDateAndTime nanoSecond ] ] these are all inst vars comparisons. This is in the milliseconds range, but in the agregate of a couple of thousand of objects, it creates a lot of not-simple-objects (it is, not integers), and maybe because of that it isn't as fast as I'd expect. Did somebody experienced this too? Regards, Esteban A. Maringolo
[Pharo-dev] DateAndTime#= slow?
DateAndTime is a very good candidate for some slot-tricks, and should probably be a value object. Stephan
Re: [Pharo-dev] DateAndTime#= slow?
I'm using Pharo 2, a build one month old as much. Date (Timespan)#= comparand ^ self species = comparand species and: [ self start = comparand start start is a DateAndTime and: [ self duration = comparand duration ]] DateAndTime#= other self == other ifTrue: [ ^ true ]. (self species = other species) ifFalse: [ ^ false ]. ^ self asSeconds = other asSeconds and: [ self nanoSecond = other nanoSecond ] And the culprit (I guess): DateAndTime#asSeconds Return the number of seconds since the Squeak epoch ^ (self - (self class epoch)) asSeconds DateAndTime's class #epoch instantiates two DateAndTimes, one for julianDayNumber zero, and then other for the offset: DateAndTime class#epoch Answer a DateAndTime representing the Squeak epoch: 1 January 1901 ^ (self julianDayNumber: SqueakEpoch) offset: 0. The #asSeconds also incur in DateAndTime subtraction (operand #-), which doesn't seem to be tuned for performance either. Best regards! Esteban A. Maringolo
