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

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

by Ben Coman

I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben 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

GT + Dark Theme

by Marcus Denker

Hi, 40 475 now integrates the fixes for making GT work nicer with the Dark Theme. Thanks to all the contributors! Marcus

Feb. 5, 2015

Re: [Pharo-dev] How Stable is Pharo 4.0?

by Stephan Eggermont

Perfectly fine for daily use. At the moment there are no high-impact changes going on (like we had in 3 with RPackage and Opal) that take some time to stabilize. Once in a while there is a build that is less usable. As long as you follow the mailing list and commit often, no problem. Stephan

Feb. 5, 2015

Re: [Pharo-dev] ||

by Marcus Denker

> 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? 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â¦ 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. Marcus

Feb. 5, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40475 Home: https://github.com/pharo-project/pharo-core

Feb. 5, 2015

[pharo-project/pharo-core] 4edeed: 40475

by GitHub

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 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] How can I specify the bindings when evaluating an expression?

by Nicolai Hess

2015-02-05 2:20 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Nicolai Hess wrote > > We lost this feature in 40097 > > Which feature? Using bare associations instead of WorkspaceVariables? > Yes, maybe feature is the wrong word - ability? What is missing now is, convert an association into a "VariableBinding" similiar to WorkspaceVariable or GlobalVariable, that implements the code generation methods emitStore: and emitValue: > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/How-can-I-specify-the-bindings-when-evaluating-an-exp… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Feb. 5, 2015

Re: [Pharo-dev] ||

by Marcus Denker

>>> >>> Is this now used in Squeak? Is it worth the complexity? >> >> Squeak doesn't use ReadOnlyVariableBinding anymore. The bindings of >> classes are instances of the ClassBinding class. >> Without using separate class it's a bit cumbersome (and less OO) to decide >> if an assignment to a global variable should be allowed or not. E.g.: >> >> Foo := 1. >> >> should work if Foo is a global, but not a behavior. It should raise an >> error if it's a behavior. > > I have mixed feelings about that. In most Smalltalks one can write something > like the following and expect it to work. > > | original | > original := SomeClass. > [SomeClass := SomeReplacementClass. > ... some code involving SomeClass (typically a passed in Block) ... > ] ensure: [SomeClass := original] > > That is, the name of the thing is not the thing itself. > > Of course, as long as one could write /Smalltalk at: #SomeClass put: > SomeReplacementClass/, it would still be possible to achieve the same > effect. (And of course, "Smalltalk" could be any namespace.) > I think the original idea was to make the system more resilient for end-user Scripting. To make sure people do not do by accident True := nil. Marcus

Feb. 5, 2015

Re: [Pharo-dev] ||

by Marcus Denker

> 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. Marcus

Feb. 5, 2015

Re: [Pharo-dev] ImageWorkerTest>>#testError is failing

by Nicolai Hess

2015-02-05 3:17 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > Hi, > > a validation report > <https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/24207//artifact/val…> says > that ImageWorkerTest>>#testError is failing but I do not have that test in > my Pharo image and I do not know how to download it? Where is it come from? > How can I execute it in my image? > > Thanks, > Juraj > You can use the issue tracker image: https://ci.inria.fr/pharo/view/all/job/Pharo-4.0-Issue-Tracker-Image/

Feb. 5, 2015