November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo and special unary selectors

by Thierry Goubier

Le 17/11/2017 Ã 10:14, Nicolas Cellier a Ã©critÂ : > > > 2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com > <mailto:g.cotelli@gmail.com>>: > > I would really like to see % removed as a binary selector and > available to use in unary or keyword ones. The only implementor in a > Pharo 6 image is: > > Â % aNumber > > Â Â Â ^ self \\ aNumber > > > +1, such alias has nothing to do in Kernel > > So it's juts aliasing \\ , and % most widespread usage in the real > world is por percentages (the use in modular arithmetic is more a > programming thing that math notation I think). > > And for allowing more Unicode code points for selector names I'm > totally in for Symbols, Arrows, Math Symbols, etc... We just need to > analyse the ones that makes sense as binary selectors, and the ones > allowed for unary and keyword ones. This will allow us to write > pretty cool DSLs. > > Just my opinion. > > This could also be the case for punctuation like ! and ? > > The idea of Torsten is more generic, any combination of binary char > could be used. > From what I understand from https://en.wikipedia.org/wiki/LR_parser we > would just have to scan one more token ahead for deciding if unary or > binary, and could preserve our simple shift reduce steps... The Smalltalk parsers being handwritten, there wouldn't be shift/reduces to contend with, and, anyway, the lexer doesn't shift/reduce; it would simply creates a token up to the next separator (that is goble up the next space/cr/end of line dot/closing parenthesis/etc...) > So it seems doable for resolving the send. Sort of. The parser difficulty would be this one: anObject % print Is this a binary selector with a print argument or two unary selectors? Using the symbol table when you parse would solve it, but that is certainly not context free... > More problematic would be the declaration of method, if we have both a > unary + and a binary +, we will need new syntax for marking the difference. In most cases, distinguishing between unary + declaration and binary + declaration would be doable: + whatever is the start of a binary selector + ^ self is the start (or the declaration of) an unary selector. But writing + self Can be interpreted as either unary plus doing self, or binary + method definition... > Whether it's worth or not is another matter... Well, one should probably try to implement the various parsers for that (extend RB, extend the SmaCC Smalltalk parser, extend the Petit Parser) to see how much complexity it would bring. Coming up with strange interpretations one could do with that syntax can be helpfull as well. Regards, Thierry > On Fri, Nov 17, 2017 at 6:32 AM, Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>> wrote: > > Hi, > > just something to think about: one thing I always liked about > Smalltalk is that it allows for nice DSL's. We have nice things > like a unit framework in Pharo, ... > > In the most simple case one can easily implement own units just > by providing a unary messages: > > Â 1 m > Â 1 second > Â 1 px > Â 1 EUR > > One can easily implement an own Money class with a currency and > then do polymorphic tricks like > > Â 10 EUR + 20 EUR > > But we can currently can not implement special unary selectors > (including special unary selectors with unicode) like: > > Â 100 % > Â 20 $ > Â 40 â¬ > Â 12 â°Â (for promille) > > Especially things like 20 % would be nice for layout issues or > other (Bloc comes to mind). > > Maybe we should put that on the roadmap of Pharo because IMHO it > would be cool to support such things in the > future. Dont know how much effort it currently means on the > technical level but maybe others can comment. > > Thx > T. > > >

Nov. 17, 2017

Re: [Pharo-dev] Pharo and special unary selectors

by Nicolas Cellier

2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com>: > I would really like to see % removed as a binary selector and available to > use in unary or keyword ones. The only implementor in a Pharo 6 image is: > > % aNumber > > ^ self \\ aNumber > > +1, such alias has nothing to do in Kernel So it's juts aliasing \\ , and % most widespread usage in the real world is > por percentages (the use in modular arithmetic is more a programming thing > that math notation I think). > > And for allowing more Unicode code points for selector names I'm totally > in for Symbols, Arrows, Math Symbols, etc... We just need to analyse the > ones that makes sense as binary selectors, and the ones allowed for unary > and keyword ones. This will allow us to write pretty cool DSLs. > > Just my opinion. > > This could also be the case for punctuation like ! and ? The idea of Torsten is more generic, any combination of binary char could be used. >From what I understand from https://en.wikipedia.org/wiki/LR_parser we would just have to scan one more token ahead for deciding if unary or binary, and could preserve our simple shift reduce steps... So it seems doable for resolving the send. More problematic would be the declaration of method, if we have both a unary + and a binary +, we will need new syntax for marking the difference. Whether it's worth or not is another matter... On Fri, Nov 17, 2017 at 6:32 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Hi, >> >> just something to think about: one thing I always liked about Smalltalk >> is that it allows for nice DSL's. We have nice things >> like a unit framework in Pharo, ... >> >> In the most simple case one can easily implement own units just by >> providing a unary messages: >> >> 1 m >> 1 second >> 1 px >> 1 EUR >> >> One can easily implement an own Money class with a currency and then do >> polymorphic tricks like >> >> 10 EUR + 20 EUR >> >> But we can currently can not implement special unary selectors (including >> special unary selectors with unicode) like: >> >> 100 % >> 20 $ >> 40 â¬ >> 12 â° (for promille) >> >> Especially things like 20 % would be nice for layout issues or other >> (Bloc comes to mind). >> >> Maybe we should put that on the roadmap of Pharo because IMHO it would be >> cool to support such things in the >> future. Dont know how much effort it currently means on the technical >> level but maybe others can comment. >> >> Thx >> T. >> >> >

Nov. 17, 2017

Re: [Pharo-dev] Pharo and special unary selectors

by Gabriel Cotelli

I would really like to see % removed as a binary selector and available to use in unary or keyword ones. The only implementor in a Pharo 6 image is: % aNumber ^ self \\ aNumber So it's juts aliasing \\ , and % most widespread usage in the real world is por percentages (the use in modular arithmetic is more a programming thing that math notation I think). And for allowing more Unicode code points for selector names I'm totally in for Symbols, Arrows, Math Symbols, etc... We just need to analyse the ones that makes sense as binary selectors, and the ones allowed for unary and keyword ones. This will allow us to write pretty cool DSLs. Just my opinion. On Fri, Nov 17, 2017 at 6:32 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > just something to think about: one thing I always liked about Smalltalk is > that it allows for nice DSL's. We have nice things > like a unit framework in Pharo, ... > > In the most simple case one can easily implement own units just by > providing a unary messages: > > 1 m > 1 second > 1 px > 1 EUR > > One can easily implement an own Money class with a currency and then do > polymorphic tricks like > > 10 EUR + 20 EUR > > But we can currently can not implement special unary selectors (including > special unary selectors with unicode) like: > > 100 % > 20 $ > 40 â¬ > 12 â° (for promille) > > Especially things like 20 % would be nice for layout issues or other (Bloc > comes to mind). > > Maybe we should put that on the roadmap of Pharo because IMHO it would be > cool to support such things in the > future. Dont know how much effort it currently means on the technical > level but maybe others can comment. > > Thx > T. > >

Nov. 17, 2017

[Pharo 7.0-dev] Build #304: 20704-remove-garbageCollect-from-PharoClassInstallermigrateClassestousing

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #304 was: SUCCESS. The Pull Request #489 was integrated: "20704-remove-garbageCollect-from-PharoClassInstallermigrateClassestousing" Pull request url: https://github.com/pharo-project/pharo/pull/489 Issue Url: https://pharo.fogbugz.com/f/cases/20704 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 17, 2017

Re: [Pharo-dev] Dark Mode List

by Pavel Krivanek

2017-11-17 16:35 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > ahhh. > :) > I think that we should have nice white theme and a nice dark new theme > for Pharo 70. > Because we need to see the difference. Since Pharo 60 was dark by default > Pharo 70 should be white by default so that the "others" people can argue > :) > The switch of the theme is part of this PR: https://github.com/pharo-project/pharo/pull/498/files To switch the theme for every release is a good way how to force people to support both of them well. -- Pavel > Personally I used the default either white or dark. > > I'm really interested by the future Bloc theme if you see what I mean. > Stef > > On Fri, Nov 17, 2017 at 4:15 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > >> On 17 Nov 2017, at 16:11, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> > >> I love your signature. > >> Now how should I interpret you email :) > > > > I like how Pharo looks in the Dark Theme. It is very cool. > > > >> On Fri, Nov 17, 2017 at 3:59 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Although, de gustibus non est disputandum, I am happy we fit right in: > >> > >> https://www.darkmodelist.com > >> > >> <Screen Shot 2017-11-17 at 15.52.06.png> > >> > >> -- > >> Sven Van Caekenberghe > >> Proudly supporting Pharo > >> http://pharo.org > >> http://association.pharo.org > >> http://consortium.pharo.org > >> > >> > >> > >> > >> > > > > > >

Nov. 17, 2017

Little Chapter on Hash methods

by Stephane Ducasse

Hi As part of a large effort to offer more documentation to Pharo and clean all the nearly finish works I started but never finishr. In the tips and tricks booklet, I added a simple chapter on hash. Comment and PullRequests are welcome. Stef

Nov. 17, 2017

Re: [Pharo-dev] Dark Mode List

by Stephane Ducasse

ahhh. :) I think that we should have nice white theme and a nice dark new theme for Pharo 70. Because we need to see the difference. Since Pharo 60 was dark by default Pharo 70 should be white by default so that the "others" people can argue :) Personally I used the default either white or dark. I'm really interested by the future Bloc theme if you see what I mean. Stef On Fri, Nov 17, 2017 at 4:15 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 17 Nov 2017, at 16:11, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> I love your signature. >> Now how should I interpret you email :) > > I like how Pharo looks in the Dark Theme. It is very cool. > >> On Fri, Nov 17, 2017 at 3:59 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Although, de gustibus non est disputandum, I am happy we fit right in: >> >> https://www.darkmodelist.com >> >> <Screen Shot 2017-11-17 at 15.52.06.png> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> > >

Nov. 17, 2017

Re: [Pharo-dev] [Pharo-users] why is adding instance variables so slow?

by Stephane Ducasse

tx guys On Fri, Nov 17, 2017 at 10:59 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > with Yuriy and Miroslava we have tried to finish a pull request for > conversion of rules to Renraku. But we had to face to a strange failing > tests. It was not clear on the first sight but these tests were failing > because of time-outs. Then we realized that the reason for this may be in > big amount of records in the ASTCache. After some investigation with Denis > we discovered that the real reason is in the presence of garbageCollect call > in PharoClassInstaller>>#migrateClasses:to:using: and the big ASTCache only > made this call significantly slower. > > It looks like Denis proved that the removal of this garbageCollect call is > safe. So we should try to remove it in Pharo 7 because it evidently makes > performance issues. > > -- Pavel > > > 2017-04-16 8:48 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> Hi, >> >> Please letâs move this discussion on pharo-dev. And keep going :) >> >> Cheers, >> Doru >> >> >> >> >> > On Apr 14, 2017, at 12:09 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> > wrote: >> > >> > >> > 2017-04-14 11:09 GMT+02:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: >> > Hi, I think the problem was not clearly explained. This is the scenario >> > that is problematic. >> > This scenario does not happen in the new Spur implementation of >> > forwarding, but I think is happening in the old one. >> > >> > 1. You have, let's say 3 instances of ClassA. >> > 2. You add a new instance variable to ClassA. It produces >> > 2a. A new ClassAv2 is created with the instances variables of ClassA >> > and the newone >> > 2b. 3 Instances of ClassAv2 are created >> > 2c. The values of the instance variables of ClassA are copied to the >> > ones in ClassAv2 (the ones missing are left in nil). >> > 2d. The 3 instances of ClassA are becomed forward to the 3 instances >> > of ClassAv2 >> > 2e. The ClassA is becomed forward ClassAv2 >> > >> > I still not see why my example not reflects all these steps. I checked >> > also scenario with class becoming: >> > >> > c1 := Class1 new. >> > c2 := Class2 new. >> > c1 becomeForward: c2. >> > Class1 becomeForward: Class2. >> > Class2 allInstances "=>#(aClass2)" >> > >> > It also works in Cog >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "What we can governs what we wish." >> >> >> >> >> >

Nov. 17, 2017

Re: [Pharo-dev] Pharo Quality: raising the quality level in Pharo 7 and onwards

by Stephane Ducasse

Hi torsten Thanks for raising this. I would like to add two points: - Comment methods with examples: This is why I introduced >>> look at at:at: I should fix flatCollect: btw To me this is super important to document even the classes that we all know. Because newcomers don't know. - For the categorisation. I did a pass on the method categoriser and it is really usable now. about the categorisation did you look at the little tools analyser I did in the package AutomaticCategory Cat MCSmalltalkhubRepository owner: 'StephaneDucasse' project: 'AutomaticMethodCategorizer' user: '' password: '' ProtocolAnalyzer self new statisticFor: #printOn: {377->#printing. 3->#accessing. 1->#ui. 1->#private. 1->#transmitting} self new statisticFor: #initialize { {867->#initialization. 85->#'initialize-release'. 12->#'as yet unclassified'. 8->#initializing. 6->#accessing. 3->#'instance initalization'. 1->#'initalize-release'. 1->#testing. 1->#'class initialization'. 1->#'updating screen'. 1->#actions. 1->#drawing. 1->#displaying. 1->#tests. 1->#shout} ] ] ] !! Miscategorized methods Now we can get a list of all miscategorized method definitions. [ [ [ self new findInconsistenciesForASelector: #initialize thatIsNotInProtocol: 'initialization' ]]] !! Fixing miscategorized methods [ [ [ self new fixInconsistenciesOf: #printOn: toBeInProtocol: 'printing' ] ] ] Now we could set some task forces. For myself I have - finish to clean users of asLayoutFrame. What we could do is to check the protocols we want and run the tool and fix. Stef On Fri, Nov 17, 2017 at 11:52 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > when we forked Pharo back in the days (2008) one of the primary goals of Pharo was and still is to provide a CLEAN SYSTEM. > > Now after nearly 10 years we have done already an amazing job. But we are still not there. > > While it is a good thing that we rewrite parts of the image, work on bootstrap and new shiny tools I unfortunately see the > effect that even some newly written code has flaws or is not meeting some basic quality standards like: > > - having class comments > - no uncategorized methods anymore > - not having unused temps or unused instance variables > - tests in a separate package than the code (to be able to have minified versions without tests) > - class instance variable naming in lowercase > - ... > > Meanwhile in Pharo 6 and 7 there are nice tools inside to check your code. So USE THEM. > > Some of you have already seen that I continue to do more and more of such cleanups in the system in various Pharo 7 > contributions. Believe me: this is a boring task and one can earn much more applause for other nice and more amazing > contributions - but the dirty job needs to be done to clean up the house. > > I also started to integrate some more "Release Tests" to make sure the things cleaned now stay clean over time and > is not violated again by new Pull requests or new package inclusions. > > Because some of these cleanups were already done in Pharo 5 and 6 - but violated again by new contributions we now need > to enforce that the image stays at that qualit level. Because I do not want to waste my time to do it over and over again! > > See package "ReleaseTests" or code like > > ProperMethodCategorizationTest, ProperlyImplementedClassesTest, #testAllClassInstanceVariablesStartLowercase and other > > which was written to ensure we not only GET better but also STAY better in the future. Thanks to Pavel, Marcus, Esteban > and others for reviewing and integrating. > > Still there is a long journey in front of us, some examples: > > 1. Unused Temps > > CompiledMethod allInstances select: [:m | m ast temporaries anySatisfy: [:x | x binding isUnused ]]. => over 200 still > > 2. Uncategorized methods > > Object allSubclasses select: [:each | (each selectorsInProtocol: Protocol unclassified) notEmpty ] => over 200 still > > 3. Many many more uncommented classes. We need a special reminder to people who can write many code lines a day but > are not able to spend a minute to write a class comment. > > 4. ... > > One person will require too much time ... several contributors helping with one contribution a day or a week will already change > the game and make it possible again. Why not have a clean base image meeting basic criterias by the end of the year 2017 and > ensuring with tests that we continue clean in 2018? > > Would'nt this be a nice birthday present to Pharos 10 years anniversary in 2018? > > How can you help: > ================= > > a) you can check you own packages using the provided quality tools and before you integrate new features just cleanup your code > first > > b) even as beginners you can help cleaning up such easy things and with simple cleanup pull requests help moving Pharo 7 forward > > c) you can think of other short snippets that reveal design or code flaws and post them here > Then we can fix these in the image too and have the rules enforced using a separate release test > > d) lets discuss and define quality criterias and note them somewhere > > e) ideally you can reveal problems, open bugs, clean them up and then write Release tests to ensure we stay clean > > > We should and need to definitely raise the bar. I would even be more radical to enforce more quality: > > - in the worst case we should not accept contributions or put new versions of packages into the image > when they do not meet basic criterias, that is the idea of the release tests > > - if parts of the community are not seeing this as a necessity then in the worst case we need to fork Pharo again > into another next level CLEANED UP system ;) > > > So PLEASE HELP!!! Otherwise this will KILL US and it also will be and ENDLESS journey for a few people to try to clean the house. > So PLEASE HELP before you work on the next shiny feature that might still violates the basics making this an impossible journey for others > to move forward on that frontier. > > Bye > T. >

Nov. 17, 2017

[Pharo 7.0-dev] Build #303: 20711 Unused temps in RubTextEditor, RubParagraph, RubMethodEditingExample, ReflectiveMethod, RxMatcher

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #303 was: SUCCESS. The Pull Request #494 was integrated: "20711 Unused temps in RubTextEditor, RubParagraph, RubMethodEditingExample, ReflectiveMethod, RxMatcher" Pull request url: https://github.com/pharo-project/pharo/pull/494 Issue Url: https://pharo.fogbugz.com/f/cases/20711 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 17, 2017