October 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] CI's down ?

by Marcus Denker

I added an issue: https://pharo.fogbugz.com/f/cases/19245/Pharo-Contribution-CI-slaves-Config… <https://pharo.fogbugz.com/f/cases/19245/Pharo-Contribution-CI-slaves-Config…> > On 25 Oct 2016, at 13:41, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > They seem to fail to install new VM's > > ... > Creating starter scripts pharo and pharo-ui > On a 64-bit system? You must install the 32-bit libraries > Try `sudo aptitude install ia32-libs` or see http://pharo.org/gnu-linux-installation#64-bit-System-Setup for more info > ... > > Something must have changed (I know, lot's of moving parts) > >> On 25 Oct 2016, at 10:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> I have restarted the jenkins. >> >> Lets hope it works better. >> >> Marcus >> >>> On 24 Oct 2016, at 11:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> It seems that since a couple of days the CI's are down ? >>> >>> https://ci.inria.fr/pharo-contribution/ >>> >>> >>> >> >> > >

Oct. 28, 2016

Re: [Pharo-dev] GitHub code analytics tools

by phil＠highoctane.be

One difference is that it is not limited to GitHub so one can pick stuff from GitHub, GitLab, Bitbucket, local things etc: The comments tool is quite nice. There also the integration with their other apps but this is orthogonal to the original question. Phil On Fri, Oct 28, 2016 at 12:02 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Phil, > > This looks very similar to the code review tool available in GitHub itself > ... so the primary difference is in the workflow or do see an advantage > that you are reducing the number of overall commits (by using arc?) or ??? > Dale > > On 10/27/2016 01:49 PM, phil(a)highoctane.be wrote: > > 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] roundTo: strange behavior

by Martin McClure

On 10/27/2016 01:53 PM, phil(a)highoctane.be wrote: > Yes, I was working at a large insurance company and some C code that did > calculations on lots and lots of entries triggered an audit due to > sizeable discrepancies in monetary terms. [...] > > Also there is the banker's > rounding. https://www.eecis.udel.edu/~breech/contest.inet.fall.07/problems/bankers-ro… > <https://www.eecis.udel.edu/%7Ebreech/contest.inet.fall.07/problems/bankers-…> > > Yes! When we were re-doing our ScaledDecimal implementation a few years ago, I moved GemStone to Banker's Rounding (round-to-even). It's fairly simple to implement, and is important to avoid biases in complex computerized calculations. I suspect that the "standard" rounding rule (if the digit is 5, round up) is a leftover from manual arithmetic -- if you're doing, say, long division, and you get a five, and the remainder is non-zero, you know that the quotient is actually greater than that, so you round up. And if you *don't* know what those digits beyond the 5 are, you round up anyway, because the only time you don't is if they're *all* zeroes. But with computer math it's easy to figure out whether all the digits will be zeroes or not, so we can use the better rounding rule. Regards, -Martin

Oct. 27, 2016

Re: [Pharo-dev] GitHub code analytics tools

by Dale Henrichs

Phil, This looks very similar to the code review tool available in GitHub itself ... so the primary difference is in the workflow or do see an advantage that you are reducing the number of overall commits (by using arc?) or ??? Dale On 10/27/2016 01:49 PM, phil(a)highoctane.be wrote: > 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". > > 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 > <mailto:dale.henrichs@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 <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] roundTo: strange behavior

by phil＠highoctane.be

Yes, I was working at a large insurance company and some C code that did calculations on lots and lots of entries triggered an audit due to sizeable discrepancies in monetary terms. I turned out that the code compiled on a x86 PC didn't gave the same results as the same code compiled on the mainframe. Given enough loops and runs, the skew became too large to ignore. This led to some serious finger pointing and head scratching from de devs. They found the root cause but, like, 2 months after they started looking. Also there is the banker's rounding. https://www.eecis.udel.edu/~breech/contest.inet.fall.07/problems/bankers-ro… Phil On Thu, Oct 27, 2016 at 11:15 AM, Guille Polito <guillermopolito(a)gmail.com> wrote: > I am also for what Martin says :). > > And also: I'd argue that you NEVER EVER want to use simple Floats for > financial applications. In financial applications you really need > precision, and Floats have hardware limitations that do not provide > precision. > > I thought ScaledDecimal (which I never used in Pharo) was meant to provide > high-precision decimal numbers to the expense of using an internal > representation that is not tied to the hardware limitations. > > -------- Original Message -------- > > > > > > > On 10/27/2016 10:34 AM, Nicolas Cellier > wrote: > > > > > > > > 2016-10-27 9:51 GMT+02:00 Denis > Kudriashov <dionisiydk(a)gmail.com>: > > >> >> >> >> 2016-10-27 8:31 GMT+02:00 >> Martin McClure <martin(a)hand2mouse.com>: >> >> >>> I think roundTo: is OK. #round: is not, and >>> should be deprecated (at least for Floats). >>> For Floats, the idea of rounding to a specific >>> number of decimal digits is a fantasy. Here's >>> why: Floats cannot exactly represent most >>> common decimal fractions. For example: >>> >>> >>> 0.1 -- not representable >>> >>> 0.2 -- not representable >>> >>> 0.3 -- not representable >>> >>> 0.4 -- not representable >>> >>> 0.5 -- hey, representable! >>> >>> 0.6 -- not representable >>> >>> 0.7 -- not representable >>> >>> 0.8 -- not representable >>> >>> 0.9 -- not representable >>> >>> 1.0 -- representable. >>> >>> >>> *Printing* a Float to a specific rounded >>> decimal format is a sensible idea, and should >>> be encouraged. But trying for a "rounded >>> Float" *number* just can't be done exactly >>> (except by converting to a Fraction). >>> >>> >>> Fractions can be rounded to exact decimal >>> fractions, so something like "myFraction >>> roundTo: 1/100" makes sense. But the current >>> implementation of round: on Fraction that >>> converts to a Float just gets you the misery >>> detailed above. >>> >>> >>> >>> >>> >>> On >>> 10/26/2016 01:00 PM, Nicolas Cellier wrote: >>> >>> >>> >>> >>> 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) >>> >>> >>> >>> >>> >>> >>> The double rounding problem is not the >>> fundamental problem, the fundamental problem is >>> that what is desired does not exist, because >>> Floats cannot exactly represent most decimal >>> fractions. So this can't really fix it. >> >> >> >> >> >> Exactly. Thank's for good explanation >> >> >> > > > > > 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. > > And we MUST do our best to round correctly to the NEAREST > Float that is 0.1e0, 0.2e0, ... 1.0e0 > > > > > If user asked to round a Fraction or > ScaledDecimal, then it's different. > > We'd better keep the exactness and use ScaledDecimal rather > than convert to a Float. > > > > > That's exactly these two things that the SLICE posted in inbox > is doing. > > > > > i completely agree (well, i would have preferred a pure Fraction > result in the pure Fraction case instead of a ScaledDecimal, but > so what) > > > werner > > p.s. a pure Fraction result in the pure Fraction case would also > insure that the rest of Number is more or less independent of the > not very useful ScaledDecimal > > > > > > > > > >

Oct. 27, 2016

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