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

Re: [Pharo-dev] Dark Mode List

by Sven Van Caekenberghe

> 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] Dark Mode List

by Stephane Ducasse

I love your signature. Now how should I interpret you email :) 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 > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

Nov. 17, 2017

Dark Mode List

by Sven Van Caekenberghe

Although, de gustibus non est disputandum, I am happy we fit right in: https://www.darkmodelist.com <https://www.darkmodelist.com/> -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org <http://pharo.org/> http://association.pharo.org http://consortium.pharo.org

Nov. 17, 2017

[Pharo 7.0-dev] Build #302: 20707 Unused temps in WindowsStore, WaitfreeQueue, VersionnerProjectPanel,

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

There is a new Pharo build available! The status of the build #302 was: SUCCESS. The Pull Request #490 was integrated: "20707 Unused temps in WindowsStore, WaitfreeQueue, VersionnerProjectPanel, " Pull request url: https://github.com/pharo-project/pharo/pull/490 Issue Url: https://pharo.fogbugz.com/f/cases/20707 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 17, 2017

Re: [Pharo-dev] undocumented method is quest of comment

by Stephane Ducasse

Indeed no little action is worth a thousand words. Everybody plants its own seed. Tx nicolas and Pavel. Stef On Fri, Nov 17, 2017 at 3:00 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > One little action is worth a thousand words :) > > > 2017-11-17 11:51 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> >> https://github.com/pharo-project/pharo/pull/487 >> >> 2017-11-16 23:32 GMT+01:00 Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com>: >>> >>> It's not documented because hashing is complex... >>> The goal is to shuffle the receiver bits and distribute them over the >>> available 28bits used for hash codes. >>> why and how it does so is a tough subject, Andres Valloud wrote a whole >>> book on it ;) >>> >>> The basic operation which is emulated is relatively simple, but >>> implementation is overly complex, because it tries to avoid creating >>> LargeIntegers in 32bits VM >>> >>> *16384 is <=> bitShift: 14 >>> bitAnd 16383 is <=> isolating lowest 14 bits... >>> >>> While at it, one should also rewrite the method contents in order to use >>> the new primitive available >>> and profit by more efficient 64bit version for 64bit VM... >>> >>> Fortunately, one can still pick the methods from Squeak :) >>> then forget the original authors because it really does not matter, does >>> it? >>> >>> >>> 2017-11-16 22:25 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>> >>>> Hi guys >>>> >>>> I would love to have a better method comment for >>>> >>>> >>>> hashMultiply >>>> | low | >>>> low := self bitAnd: 16383. >>>> ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * >>>> low) bitAnd: 16383) * 16384)) >>>> bitAnd: 16r0FFFFFFF >>>> >>>> >>>> Some love? >>>> >>>> Stef >>>> >>> >> >

Nov. 17, 2017

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

by Peter UhnÃ¡k

> nor how difficult it would be to automatically report why the contribution > was rejected > For this GitHub and Gitlab have hooks so other services can tell whether something is failing. See checks for example here https://github.com/hpi-swa/smalltalkCI/pull/311#partial-pull-merging (travis, appveyor, coveralls) Peter

Nov. 17, 2017

Re: [Pharo-dev] undocumented method is quest of comment

by Nicolas Cellier

One little action is worth a thousand words :) 2017-11-17 11:51 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > https://github.com/pharo-project/pharo/pull/487 > > 2017-11-16 23:32 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> It's not documented because hashing is complex... >> The goal is to shuffle the receiver bits and distribute them over the >> available 28bits used for hash codes. >> why and how it does so is a tough subject, Andres Valloud wrote a whole >> book on it ;) >> >> The basic operation which is emulated is relatively simple, but >> implementation is overly complex, because it tries to avoid creating >> LargeIntegers in 32bits VM >> >> *16384 is <=> bitShift: 14 >> bitAnd 16383 is <=> isolating lowest 14 bits... >> >> While at it, one should also rewrite the method contents in order to use >> the new primitive available >> and profit by more efficient 64bit version for 64bit VM... >> >> Fortunately, one can still pick the methods from Squeak :) >> then forget the original authors because it really does not matter, does >> it? >> >> >> 2017-11-16 22:25 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> Hi guys >>> >>> I would love to have a better method comment for >>> >>> >>> hashMultiply >>> | low | >>> low := self bitAnd: 16383. >>> ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * >>> low) bitAnd: 16383) * 16384)) >>> bitAnd: 16r0FFFFFFF >>> >>> >>> Some love? >>> >>> Stef >>> >>> >> >

Nov. 17, 2017

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

by Peter UhnÃ¡k

On Fri, Nov 17, 2017 at 2:48 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > It seems to me that you could technically enforce with github/travis: > - save the result of previous code critics > - pass the code critics on travis > - diff with previous > - reject any contribution creating new critics > I don't know how difficult it is to implement, nor how difficult it would > be to automatically report why the contribution was rejected (tell which > phase and provide a link to the console output...) > This isn't really job for GitHub; but for an outside service --- e.g. look at Coveralls.io (that you can use on Pharo code) But having something like https://landscape.io/ would be really sweet... (or the billion other tools that exist for the most widely used langs). Peter

Nov. 17, 2017

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

by Nicolas Cellier

It seems to me that you could technically enforce with github/travis: - save the result of previous code critics - pass the code critics on travis - diff with previous - reject any contribution creating new critics I don't know how difficult it is to implement, nor how difficult it would be to automatically report why the contribution was rejected (tell which phase and provide a link to the console output...) 2017-11-17 13:03 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Ok. Now, how is one using those super tools? > You mean Quality Assistant for example? > > Phil > > 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

Re: [Pharo-dev] [Pharo 7.0-dev] Build #299: 20603-Integration-of-new-bytecode-set-Sista-V1-by-default-green-tests

by Cyril Ferlicot

The title of this integration is misleading and Clement Bera clarified it in the Pull Request comments: Here is a copy of his comment: Â«Just to clarify. This slice makes all tests green which means the bytecode set is ready for integration, it does not integrate it. Integration of the new bytecode set is now difficult in Pharo 7 with the Bootstrap followed by the code loaded with Hermes that should be modified. I wish I had integrated it in Pharo 6 (at this point it was just a single slice with a single DoIt) so I could have done it very quickly but it's not the case. The main advantages of the new bytecode set over the existing one are: - Increased size of bytecode instructions limitation (jump size, number of inst var, number of literals, etc.) - Support for Lowcode/Sista inlined primitives - Support for FullBlockClosure - Easier to decode (instructions sorted by number of bytes, simpler closure instruction, etc.) - Bytecode instructions to push immediate objects instead of wasting bytes/literal slots - No more DoubleExtendedDoAnything bytecode crapÂ» On Fri, Nov 17, 2017 at 12:35 PM, <ci-pharo-ci-jenkins2(a)inria.fr> wrote: > There is a new Pharo build available! > > The status of the build #299 was: SUCCESS. > > The Pull Request #484 was integrated: "20603-Integration-of-new-bytecode-set-Sista-V1-by-default-green-tests" > Pull request url: https://github.com/pharo-project/pharo/pull/484 > > Issue Url: https://pharo.fogbugz.com/f/cases/20603 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Nov. 17, 2017