February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ||

by Thierry Goubier

2015-02-05 11:14 GMT+01:00 kilon alios <kilon.alios(a)gmail.com>: > And there is also the matter of hardware evolution. > > When I was running Pharo on my 2007 imac 20'' with dual core 2.GHZ , > Morphic was slow. And by slow I mean that I could see it was struggling to > move windows around. I could see windows flickering trying to render > themselves moving around. > > But now with my 2014 imac even though the screen is double the size and > the resolution much bigger (27'' retina) , Morphic is now quite fast. The > reason is of course the fact that the CPU is a quad core at 3 Ghz thats > almost a 3x times increase in speed and it really shows. > > Even when Pharo take full the huge area of 27'' Morphic is responsive and > quite fast. > Which means if I see you complaining of speed issues, then it must be really bad :) Thierry

Feb. 5, 2015

Re: [Pharo-dev] ||

by kilon alios

And there is also the matter of hardware evolution. When I was running Pharo on my 2007 imac 20'' with dual core 2.GHZ , Morphic was slow. And by slow I mean that I could see it was struggling to move windows around. I could see windows flickering trying to render themselves moving around. But now with my 2014 imac even though the screen is double the size and the resolution much bigger (27'' retina) , Morphic is now quite fast. The reason is of course the fact that the CPU is a quad core at 3 Ghz thats almost a 3x times increase in speed and it really shows. Even when Pharo take full the huge area of 27'' Morphic is responsive and quite fast. 8 cores are not much further down the road either. And unlike the native GUI of MACOS , Morphic does not take advantage of GPU acceleration that can offer speed us even 10 times compared to a modern CPU. So I think that even if we keep performance in Pharo at same level, things will get noticeably better through the evolution of hardware alone. I do agree that Efficiency and especially ease of use must be the main focus. On Thu, Feb 5, 2015 at 11:55 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 05 Feb 2015, at 10:46, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > > > > > 2015-02-05 10:12 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > > > On 05 Feb 2015, at 10:04, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > > > > > > > >> On 04 Feb 2015, at 22:04, Levente Uzonyi <leves(a)elte.hu> wrote: > > >> > > >> A single parser is a nice goal, but performance is top priority for > Shout, because it should do it's job real-time. When it starts lagging > behind, then people just turn it off, because it doesn't help them. > > >> Can those parsers (SHRBTextStyler and a Smalltalk parser written > using PetitParser) parse an average method in less than 20ms on an average > machine? > > > > > > I have not yet benchmarked itâ¦ PetitParser as it is is too slow, but > we will soon have a faster version (factor 10). > > > > > > We should do some benchmarks. For using, it seems ok. With a fast > machine + JIT, which does not say much of course. > > > (there is a setting 'AST based coloringâ in Pharo3 and Pharo4, but it > is turned off by default). > > > > > > One thing that is nice with the AST is that it can be used for other > things, too. e.g. in Pharo we have a menu that is defined > > > by the AST nodes and structural navigation in the editor. > > > > > > > Another way to see it: How would the original Smalltalk be designed if > they would have had 4GB RAM in 1978? > > > > Badly for today's machines :) > > > > > > What fascinates me still is that Smalltalk used the existing resources > (even building their own machines) to an > > extreme, while today we are obsessed to find reasons why we can not do > anything that makes the system > > slower or use more memory than yesterday. And that even with resources > growing every yearâ¦ > > > > You're spoiled by your nice and expensive macbooks :) > > > > Honestly, on some of today's machines, you'd better avoid long methods > or GT tools stuff because they are slow. > > > > SmaCC code generation is slow. > > > > PluggableTreeMorph is slow. > > > > Nautilus is slow. > > > > Loading large configurations is slow. > > > > Roassal complex graphs are slow. > > > > Serge's modeling stuff is slow. > > > > PetitParser has performance problems. > > > > BitBlt is slow (and Cairo has bugs). > > > > > > This is why we e.g. now have a meta object describing every instance > variable in Pharo. I am sure there are people > > who will see these ~7000 objects as pure wasteâ¦ while I would say that > we have already *now* the resources to be > > even more radical. > > > > Being radical in the context of Pharo is offering to remove stuff or > layers :):) > > > > Thierry > > It is obviously a compromise (or a continuum) between abstractions and > performance. > > But there should remain a focus on efficiency (not just speed but also > memory), it is hard to fix these things years later. > > > >

Feb. 5, 2015

Re: [Pharo-dev] Metacello + Filetree

by Thierry Goubier

Hi Sebastian, filetree only gives you access to the latest version of your packages, and you can't access the history without access to the underlying version control system you are using. This access for Metacello is available in two ways: via Metacello github:// and bitbucket:// urls and tags or branches (but you need to be using either github or bitbucket), or via GitFileTree if you are using git. Thierry 2015-02-05 11:03 GMT+01:00 Sebastian Tleye <sebastian.tleye(a)gmail.com>: > Hi, > > I am using a filetree repository for my project, also I have created a > first stable version using the versioner tool. > Everything was working fine until I commited more changes, now when I want > to install the stable version is throwing an error saying that cannot > resolve the package that it needs, however if I load the development > version it works perfectly. > > To clarify a little, > > The development version tries to load > Phadeo-ImporterExporters-SebastianTleye.12 and it works perfectly. The > stable version tries to load Phadeo-ImporterExporters-SebastianTleye.10 and > it throws an error saying that it cannot be resolve. > > Any Idea of what is happening? > I read that filetree and Metacello are compatibles so I don't know what's > the problem > Hi sebastian > > Thanks in advance > > SebastiÃ¡n Tleye >

Feb. 5, 2015

Re: [Pharo-dev] Metacello + Filetree

by Yuriy Tymchuk

The problem here is that filetree only has the last version, so if you are on a commit with 12th, monticello cannot access 10th. I have created a guide some time ago on how to use metacello + github, maybe it can be useful for you: http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo… Uko > On 05 Feb 2015, at 11:03, Sebastian Tleye <sebastian.tleye(a)gmail.com> wrote: > > Hi, > > I am using a filetree repository for my project, also I have created a first stable version using the versioner tool. > Everything was working fine until I commited more changes, now when I want to install the stable version is throwing an error saying that cannot resolve the package that it needs, however if I load the development version it works perfectly. > > To clarify a little, > > The development version tries to load Phadeo-ImporterExporters-SebastianTleye.12 and it works perfectly. The stable version tries to load Phadeo-ImporterExporters-SebastianTleye.10 and it throws an error saying that it cannot be resolve. > > Any Idea of what is happening? > I read that filetree and Metacello are compatibles so I don't know what's the problem > > Thanks in advance > > SebastiÃ¡n Tleye

Feb. 5, 2015

Metacello + Filetree

by Sebastian Tleye

Hi, I am using a filetree repository for my project, also I have created a first stable version using the versioner tool. Everything was working fine until I commited more changes, now when I want to install the stable version is throwing an error saying that cannot resolve the package that it needs, however if I load the development version it works perfectly. To clarify a little, The development version tries to load Phadeo-ImporterExporters-SebastianTleye.12 and it works perfectly. The stable version tries to load Phadeo-ImporterExporters-SebastianTleye.10 and it throws an error saying that it cannot be resolve. Any Idea of what is happening? I read that filetree and Metacello are compatibles so I don't know what's the problem Thanks in advance SebastiÃ¡n Tleye

Feb. 5, 2015

Re: [Pharo-dev] ||

by Sven Van Caekenberghe

> On 05 Feb 2015, at 10:46, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-02-05 10:12 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 05 Feb 2015, at 10:04, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > >> On 04 Feb 2015, at 22:04, Levente Uzonyi <leves(a)elte.hu> wrote: > >> > >> A single parser is a nice goal, but performance is top priority for Shout, because it should do it's job real-time. When it starts lagging behind, then people just turn it off, because it doesn't help them. > >> Can those parsers (SHRBTextStyler and a Smalltalk parser written using PetitParser) parse an average method in less than 20ms on an average machine? > > > > I have not yet benchmarked itâ¦ PetitParser as it is is too slow, but we will soon have a faster version (factor 10). > > > > We should do some benchmarks. For using, it seems ok. With a fast machine + JIT, which does not say much of course. > > (there is a setting 'AST based coloringâ in Pharo3 and Pharo4, but it is turned off by default). > > > > One thing that is nice with the AST is that it can be used for other things, too. e.g. in Pharo we have a menu that is defined > > by the AST nodes and structural navigation in the editor. > > > > Another way to see it: How would the original Smalltalk be designed if they would have had 4GB RAM in 1978? > > Badly for today's machines :) > > > What fascinates me still is that Smalltalk used the existing resources (even building their own machines) to an > extreme, while today we are obsessed to find reasons why we can not do anything that makes the system > slower or use more memory than yesterday. And that even with resources growing every yearâ¦ > > You're spoiled by your nice and expensive macbooks :) > > Honestly, on some of today's machines, you'd better avoid long methods or GT tools stuff because they are slow. > > SmaCC code generation is slow. > > PluggableTreeMorph is slow. > > Nautilus is slow. > > Loading large configurations is slow. > > Roassal complex graphs are slow. > > Serge's modeling stuff is slow. > > PetitParser has performance problems. > > BitBlt is slow (and Cairo has bugs). > > > This is why we e.g. now have a meta object describing every instance variable in Pharo. I am sure there are people > who will see these ~7000 objects as pure wasteâ¦ while I would say that we have already *now* the resources to be > even more radical. > > Being radical in the context of Pharo is offering to remove stuff or layers :):) > > Thierry It is obviously a compromise (or a continuum) between abstractions and performance. But there should remain a focus on efficiency (not just speed but also memory), it is hard to fix these things years later.

Feb. 5, 2015

Re: [Pharo-dev] ||

by Thierry Goubier

2015-02-05 10:12 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 05 Feb 2015, at 10:04, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > >> On 04 Feb 2015, at 22:04, Levente Uzonyi <leves(a)elte.hu> wrote: > >> > >> A single parser is a nice goal, but performance is top priority for > Shout, because it should do it's job real-time. When it starts lagging > behind, then people just turn it off, because it doesn't help them. > >> Can those parsers (SHRBTextStyler and a Smalltalk parser written using > PetitParser) parse an average method in less than 20ms on an average > machine? > > > > I have not yet benchmarked it... PetitParser as it is is too slow, but we > will soon have a faster version (factor 10). > > > > We should do some benchmarks. For using, it seems ok. With a fast > machine + JIT, which does not say much of course. > > (there is a setting 'AST based coloring' in Pharo3 and Pharo4, but it is > turned off by default). > > > > One thing that is nice with the AST is that it can be used for other > things, too. e.g. in Pharo we have a menu that is defined > > by the AST nodes and structural navigation in the editor. > > > > Another way to see it: How would the original Smalltalk be designed if > they would have had 4GB RAM in 1978? > Badly for today's machines :) > > What fascinates me still is that Smalltalk used the existing resources > (even building their own machines) to an > extreme, while today we are obsessed to find reasons why we can not do > anything that makes the system > slower or use more memory than yesterday. And that even with resources > growing every year... > You're spoiled by your nice and expensive macbooks :) Honestly, on some of today's machines, you'd better avoid long methods or GT tools stuff because they are slow. SmaCC code generation is slow. PluggableTreeMorph is slow. Nautilus is slow. Loading large configurations is slow. Roassal complex graphs are slow. Serge's modeling stuff is slow. PetitParser has performance problems. BitBlt is slow (and Cairo has bugs). > > This is why we e.g. now have a meta object describing every instance > variable in Pharo. I am sure there are people > who will see these ~7000 objects as pure waste... while I would say that we > have already *now* the resources to be > even more radical. > Being radical in the context of Pharo is offering to remove stuff or layers :):) Thierry

Feb. 5, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 4edeed: 40475

by Nicolai Hess

2015-02-05 10:09 GMT+01:00 GitHub <noreply(a)github.com>: > Branch: refs/heads/4.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 4edeed0d881e8347a3cc294babe23f0949aa68a7 > > https://github.com/pharo-project/pharo-core/commit/4edeed0d881e8347a3cc294b… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2015-02-05 (Thu, 05 Feb 2015) > > Changed paths: > R > GT-SpotterExtensions-Core.package/extension/Class/instance/spotterActDefault.st > R > GT-SpotterExtensions-Core.package/extension/Class/instance/spotterClassInstanceVariablesFor_.st > R > GT-SpotterExtensions-Core.package/extension/Class/instance/spotterInstanceVariablesFor_.st > R > GT-SpotterExtensions-Core.package/extension/Class/instance/spotterPackageFor_.st > R > GT-SpotterExtensions-Core.package/extension/Class/instance/spotterSubclassesFor_.st > R > GT-SpotterExtensions-Core.package/extension/Class/instance/spotterSuperclassesFor_.st > R > GT-SpotterExtensions-Core.package/extension/Class/instance/spotterUsedTraitsFor_.st > A > GT-SpotterExtensions-Core.package/extension/TBehavior/instance/spotterClassInstanceVariablesFor_.st > A > GT-SpotterExtensions-Core.package/extension/TBehavior/instance/spotterInstanceVariablesFor_.st > A > GT-SpotterExtensions-Core.package/extension/TBehavior/instance/spotterSubclassesFor_.st > A > GT-SpotterExtensions-Core.package/extension/TBehavior/instance/spotterSuperclassesFor_.st > A > GT-SpotterExtensions-Core.package/extension/TBehavior/instance/spotterUsedTraitsFor_.st > A > GT-SpotterExtensions-Core.package/extension/TClass/instance/spotterActDefault.st > A > GT-SpotterExtensions-Core.package/extension/TClass/instance/spotterClassMethodsFor_.st > A > GT-SpotterExtensions-Core.package/extension/TClassDescription/instance/spotterPackageFor_.st > R > GT-SpotterExtensions-Core.package/extension/Trait/instance/spotterActDefault.st > R > GT-SpotterExtensions-Core.package/extension/Trait/instance/spotterCompositionFor_.st > R > GT-SpotterExtensions-Core.package/extension/Trait/instance/spotterTraitUsersFor_.st > A > GT-SpotterExtensions-Core.package/extension/TraitBehavior/instance/spotterCompositionFor_.st > A > GT-SpotterExtensions-Core.package/extension/TraitBehavior/instance/spotterTraitUsersFor_.st > Ah, No! This are changes I uploaded for issue 14608 <https://pharo.fogbugz.com/default.asp?14608> ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to Spotter methods Please, can someone look at this changes, I am unsure if use of TBehavior is correct, maybe this spotter methods should go to Behavior instead? Why are they integrated (automatically)? > M Glamour-Morphic-Brick.package/GLMMorphBrick.class/instance/as yet > unclassified/onRemovedFrom_.st > M > Glamour-Morphic-Brick.package/extension/Pharo3DarkTheme/instance/brickThemer.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/ > script475.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/ > update40475.st > M > ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 40475 > 14866 Integrate GTools > https://pharo.fogbugz.com/f/cases/14866 > > http://files.pharo.org/image/40/40475.zip > > >

Feb. 5, 2015

Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?

by Sven Van Caekenberghe

> On 05 Feb 2015, at 10:36, Ben Coman <btc(a)openInWorld.com> wrote: > > I personally would prefer to be able to use exponents. No sure what the big picture is. > cheers -ben Of course exponents are still supported ;-) The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose. > On Thu, Feb 5, 2015 at 12:27 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys, > > In Pharo 2.0, the expression "Number readFrom: '2.5850009999999998e+04' " would answer 25850.01 , but in Pharo 3.0 it answers: 2.5850009999999997 which is a kind of WTF to me. > > Checking the differences it seems in Pharo 2.0 ExtendedNumberParser (used from Number >> readFrom: ) implemented: > > allowPlusSign > ^true > > However, in Pharo 3.0 it seems subclasses of NumberParser have been merged directly in NumberParser class (and so Number >> readFrom: uses this class now). > > But.. (and this is the difference), NumberParser implements: > > allowPlusSign > ^false > > So I wonder...was this on purpose or a side effect? Why would we want to reject using + as part of the exponential notion?? > > So in my case now I must do an override to: > > NumberParser >> allowPlusSignInExponent > ^ true > > Thoughts? > > > -- > Mariano > http://marianopeck.wordpress.com >

Feb. 5, 2015

Re: [Pharo-dev] GT + Dark Theme

by Tudor Girba

Nice! Doru On Thu, Feb 5, 2015 at 10:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > 40 475 now integrates the fixes for making GT work nicer with the Dark > Theme. > > Thanks to all the contributors! > > Marcus > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 5, 2015