- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GitHub code analytics tools

by phil＠highoctane.be

For code reviews, Phabricator and Arcanist are nice. This is like Facebook for code. Facebook uses this thing internally. As for FB, there are "apps". [image: Inline image 3] Differential is the part of Phabricator for doing the reviews. The key idea is that you cannot commit to the repo directly. You use "arc diff" to create a "revision" that you post to the system. You get a number for this. Not a long git commit id, but a real number (e.g. 610). Code review ensues, where people can put comments etc through a web interface. Comments can be at any level: file, line of code (click and add comment on the line). We were doing Zend Framework 2 and so PSR-2 standards applied. There was a check happening before even being able to submit, so be compliant or do not pass. A pain, but ultimately catched a few bugs that could have been nasty. Once the review is successful, a user with the proper permissions will do an "arc land" Once arc land was done, the differential landed on the github repo, and the CI could pick it up for official packaging. All in all, it is a nice workflow when lots of people are working at once on a code base. Also allows to limit the amount of crap ending up in the official repo due to devs not having a clue (happened). I used the toolset for a project where the developers where remote and it worked well (team size: Belgium 3 people, Romania 10+). Code was in Github private repo. https://secure.phabricator.com/ One can look around. HTH Phil On Thu, Oct 27, 2016 at 7:21 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Guillermo, > > Apparently you don't like the github browser-based code review tool? > > What are your objections? > > Do you know of a better tool that is out in the wild or do you just have > visions that code review could be better? > > Better tools are always possible, but it is sometimes nice to use a tool > that you didn't have to build from scratch while creating the better tool:) > > Dale > On 10/27/2016 05:06 AM, Guillermo Polito wrote: > > I would like to have a good code review tool, before having to do one > ad-hoc... > > On Thu, Oct 27, 2016 at 1:50 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hi. >> >> With future transition to github I ask myself what tools we will have out >> of the box. >> I google a bit and found these nice service http://ghv.artzub.com. >> Try to search guillep and then pharo-core. It looks really nice. >> >> What other online services you know to analyse github projects? >> > > >

Oct. 27, 2016

Re: [Pharo-dev] GitHub code analytics tools

by Dale Henrichs

Guillermo, Apparently you don't like the github browser-based code review tool? What are your objections? Do you know of a better tool that is out in the wild or do you just have visions that code review could be better? Better tools are always possible, but it is sometimes nice to use a tool that you didn't have to build from scratch while creating the better tool:) Dale On 10/27/2016 05:06 AM, Guillermo Polito wrote: > I would like to have a good code review tool, before having to do one > ad-hoc... > > On Thu, Oct 27, 2016 at 1:50 PM, Denis Kudriashov > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > Hi. > > With future transition to github I ask myself what tools we will > have out of the box. > I google a bit and found these nice service http://ghv.artzub.com. > Try to search guillep and then pharo-core. It looks really nice. > > What other online services you know to analyse github projects? > >

Oct. 27, 2016

Re: [Pharo-dev] GitHub code analytics tools

by Alexandre Bergel

We would be happy to contribute on this. What are the requirements you need? Cheers, Alexandre > On Oct 27, 2016, at 9:06 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > I would like to have a good code review tool, before having to do one ad-hoc... > > On Thu, Oct 27, 2016 at 1:50 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > Hi. > > With future transition to github I ask myself what tools we will have out of the box. > I google a bit and found these nice service http://ghv.artzub.com <http://ghv.artzub.com/>. > Try to search guillep and then pharo-core. It looks really nice. > > What other online services you know to analyse github projects? >

Oct. 27, 2016

Re: [Pharo-dev] GitHub code analytics tools

by Alexandre Bergel

Hi! We are currently developing some visualizations of Git repository. Our current effort uses matrixes in which authors, number of commits, and time are represented. It is still early work. Alexandre > On Oct 27, 2016, at 8:50 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > With future transition to github I ask myself what tools we will have out of the box. > I google a bit and found these nice service http://ghv.artzub.com <http://ghv.artzub.com/>. > Try to search guillep and then pharo-core. It looks really nice. > > What other online services you know to analyse github projects?

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by test

Hi Martin, of course you are right, but i find it irritating and difficult to remember, if i can calculate something with one kind of number and not with next one, especially Floats & Fractions. imo they should behave similarly, that makes them easier to use for simple minds like me, for example if i compare results with Floats & Fractions. werner On 10/27/2016 06:12 PM, Martin McClure wrote: > On 10/27/2016 04:12 AM, test wrote: >> i would prefer if #round: will not be deprecated in Floats. in some >> cases Float>>#round: can be useful, eg optimization problems where >> one searched value describes the size of a screw, that exists only in >> certain sizes. > > #roundTo: can be used for this (and is specified by ANSI Smalltalk, > for those who care). If the screws only come in 16th inch increments, > for instance, then "roundTo: 0.0625" will give you an exact result, > since 16ths *are* exactly representable as floats. > > OTOH, #round: (not in ANSI) appears to promise something that cannot > be delivered for Floats, so is misleading, and it spreads the kind of > confusion that resulted in this thread. > > That's why I favor deprecating #round: for Floats. > > Regards, > > -Martin >

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Martin McClure

On 10/27/2016 04:12 AM, test wrote: > i would prefer if #round: will not be deprecated in Floats. in some > cases Float>>#round: can be useful, eg optimization problems where one > searched value describes the size of a screw, that exists only in > certain sizes. #roundTo: can be used for this (and is specified by ANSI Smalltalk, for those who care). If the screws only come in 16th inch increments, for instance, then "roundTo: 0.0625" will give you an exact result, since 16ths *are* exactly representable as floats. OTOH, #round: (not in ANSI) appears to promise something that cannot be delivered for Floats, so is misleading, and it spreads the kind of confusion that resulted in this thread. That's why I favor deprecating #round: for Floats. Regards, -Martin

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Martin McClure

On 10/27/2016 01:34 AM, Nicolas Cellier wrote: > Nonetheless, if user asked to round a Float, we must give him back a > Float. > We ain't gonna answer a ScaledDecimal because we think that it's > better for him: we don't know what is better for him. Right, the result of #round: should always be the same kind of number as the receiver. Regards, -Martin

Oct. 27, 2016

Re: [Pharo-dev] GitHub code analytics tools

by Guillermo Polito

I would like to have a good code review tool, before having to do one ad-hoc... On Thu, Oct 27, 2016 at 1:50 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > With future transition to github I ask myself what tools we will have out > of the box. > I google a bit and found these nice service http://ghv.artzub.com. > Try to search guillep and then pharo-core. It looks really nice. > > What other online services you know to analyse github projects? >

Oct. 27, 2016

GitHub code analytics tools

by Denis Kudriashov

Hi. With future transition to github I ask myself what tools we will have out of the box. I google a bit and found these nice service http://ghv.artzub.com. Try to search guillep and then pharo-core. It looks really nice. What other online services you know to analyse github projects?

Oct. 27, 2016

Re: [Pharo-dev] roundTo: strange behavior

by stepharo

Thanks ***A LOT*** nicolas. > I've put a single slice in the inbox for the 3 issues because they all > are related. > See slice comment: > > For Float, implement guard to prevent overflow (15471), and use exact > representation for intermediate results (asFraction) so as to avoid > double rounding problems (15473) > > For Fraction (15472), choose an exact representation for result rather > than Float. This is because such method is particularly usefull for > financial/monetary applications. > > 2016-10-26 17:28 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > > > Le 26/10/16 Ã 14:52, Nicolas Cellier a Ã©crit : >> Sorry for being slow minded, >> yes of course financial apps is exactly the case where round: >> would be usefull and NEEDS to be exact. > > so what is the solution? > I'm lost again. > >> Hi Nicolas, >> yes, i know. suppose you calc some financial thing and one >> intermediate result will be in $. you have to round this >> Fraction-result to 2 decimals. now you use this to further >> calc basepoints as the final result. you have to convert this >> to 3 decimals. looking at this final result with 2 decimals >> can be be irritating for a moment, if you debug the calcs. >> and <g> btw i never use scaledDecimals. >> werner >> >> >> On 10/26/2016 02:06 PM, Nicolas Cellier wrote: >>> >>> >>> 2016-10-26 13:11 GMT+02:00 test <wkassens(a)libello.com >>> <mailto:wkassens@libello.com>>: >>> >>> Hi Nicolas, >>> regarding rounding Fractions: >>> i use fractions if i want to get an exact result (eg for >>> comparing the result with Float calculations). if >>> #round: returns a Float all further calcs (with >>> Fractions) will get contaminated, since the rest will >>> become Floats too. Hence the "asScaledDecimal: >>> numberOfWishedDecimal" seems better to me, but i wonder >>> why these transformations at the end are necessary at >>> all? just for the looks? i'd suppose every person, who >>> knows how to use Fractions, also knows how to append a >>> #asScaledDecimal: to a result by himself, should he want >>> that. >>> >>> taking as an example financial calcs that first use 2 >>> decimals. occasionaly the final result will be >>> basepoints, often small ones like 0.003. with >>> scaledDecimals the result would be (ok, look like) 0 >>> since scaledDecimals also contaminate the calc. of >>> course one could correct this simply with an >>> #asScaledDecimal:3 at the end. nevertheless a first look >>> at the zero result would surprise me for a tenth of a >>> second. >>> werner >>> >>> >>> Hi Werner, >>> I don't know the purpose of round: at all. >>> Most often this kind of message was used before printing >>> probably because lack of versatile formatted print messages. >>> In Squeak I replaced most usages of roundTo: by >>> printShowing(Max)DecimalPlaces:. >>> Now if it has been added in Pharo and other languages, there >>> must be some use cases I presume. >>> Maybe the analysis could be carried on these use cases? >>> >>> Beware, converting a Fraction asScaledDecimal will NOT round. >>> Only the printString is rounded, but the number keeps its >>> whole precision. >>> Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s. >>> >>> ScaledDecimals as they are now are just Fraction with a >>> different printString... >>> Not very much added value. >>> >>> Nicolas >>> >>> On 10/26/2016 09:58 AM, Nicolas Cellier wrote: >>>> >>>> >>>> 2016-10-26 9:14 GMT+02:00 stepharo <stepharo(a)free.fr >>>> <mailto:stepharo@free.fr>>: >>>> >>>> Hi nicolas >>>> >>>> So what is the solution? We can integrate fast a >>>> solution. >>>> I would really like to see them fix in Pharo 60. >>>> I'm writing a book for newbie and this is the third >>>> time I change one chapter >>>> so may be I should stop and throw away this chapter. >>>> >>>> >>>> 1) for Fraction: >>>> >>>> round: numberOfWishedDecimal >>>> v := 10 raisedTo: numberOfWishedDecimal. >>>> ^ ((self * v) rounded / v) asFloat >>>> >>>> or just replace asFloat if you wish to remain exact: >>>> >>>> round: numberOfWishedDecimal >>>> v := 10 raisedTo: numberOfWishedDecimal. >>>> ^ ((self * v) rounded / v) asScaledDecimal: >>>> numberOfWishedDecimal >>>> >>>> 2) for Float, it is in 15471: >>>> >>>> round: numberOfWishedDecimal >>>> | v maxNumberOfDecimals | >>>> maxNumberOfDecimals := self class precision - 1 - >>>> (self exponent max: self class emin). >>>> maxNumberOfDecimals < numberOfWishedDecimal ifTrue: >>>> [^self]. >>>> v := 10 raisedTo: numberOfWishedDecimal. >>>> ^ ((self asFraction * v) rounded / v) asFloat >>>> >>>> or if Fraction already answers a Float: >>>> >>>> round: numberOfWishedDecimal >>>> | maxNumberOfDecimals | >>>> maxNumberOfDecimals := self class precision - 1 - >>>> (self exponent max: self class emin). >>>> maxNumberOfDecimals < numberOfWishedDecimal ifTrue: >>>> [^self]. >>>> ^ self asFraction round: numberOfWishedDecimal >>>> >>>> It's slower than current implementation, but will round >>>> exactly to the nearest Float. >>>> It's possible to have faster implementation up to 22 >>>> decimals if you provide a fused-multiply-accumulate >>>> primitive... >>> >>> >> >> > >

Oct. 27, 2016