- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GitHub code analytics tools

by Thierry Goubier

2016-10-28 11:07 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: > Hi! > > -------- Original Message -------- > > 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:) > > Well, that is in fact my point. I'd like to know options and alternatives. > If the easiest to setup and use is github's one, ok, that's no problem to > me. > > What bothers me the most from the github+filetree combination when > reviewing a pull request, is that it is a file-based review. And finally > you're reviewing the low-level export format, and I get a bit lost... Just > dreaming, maybe there is some tool out there where we can just provide a > kind of plugin to enhance the review? > Maybe a local copy of the pull request (it is just a branch in git terms, after all) and using Iceberg ? Thierry > > But for sure I do not want to do one from scratch :) > > 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. 28, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Thierry Goubier

2016-10-28 11:56 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ > Image here: http://files.pharo.org/get-files/60/pharo-64.zip > Thanks. > > this is still not official (thatâs why is not in official place) so there > are a couple of known problems: > > - version format is different, and that breaks some things in image that > depends on it to know what happens > - command line is different and probably youâll need to play a bit with > options (one or two dashes). > - UFFI has some failing tests (but most of it works). > > I would appreciate some help to report and/or fix the emerging problems. > I'll make myself a Makefile for it and test; if I see it stable enough, I'll try to use it on a regular basis and report. Thierry > > cheers, > Esteban > > On 28 Oct 2016, at 10:39, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > Hi all, > > anybody knows how to get (and test) the 64bits version of the Pharo vm and > image? > > Thanks, > > Thierry > > >

Oct. 28, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Esteban Lorenzano

VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ <http://bintray.com/estebanlm/pharo-vm/build#files/> Image here: http://files.pharo.org/get-files/60/pharo-64.zip <http://files.pharo.org/get-files/60/pharo-64.zip> this is still not official (thatâs why is not in official place) so there are a couple of known problems: - version format is different, and that breaks some things in image that depends on it to know what happens - command line is different and probably youâll need to play a bit with options (one or two dashes). - UFFI has some failing tests (but most of it works). I would appreciate some help to report and/or fix the emerging problems. cheers, Esteban > On 28 Oct 2016, at 10:39, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi all, > > anybody knows how to get (and test) the 64bits version of the Pharo vm and image? > > Thanks, > > Thierry

Oct. 28, 2016

Re: [Pharo-dev] GitHub code analytics tools

by Guille Polito

Hi! -------- Original Message -------- > > 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:) > Well, that is in fact my point. I'd like to know options and alternatives. If the easiest to setup and use is github's one, ok, that's no problem to me. What bothers me the most from the github+filetree combination when reviewing a pull request, is that it is a file-based review. And finally you're reviewing the low-level export format, and I get a bit lost... Just dreaming, maybe there is some tool out there where we can just provide a kind of plugin to enhance the review? But for sure I do not want to do one from scratch :) > 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. 28, 2016

Instructions for Pharo 6 64bits

by Thierry Goubier

Hi all, anybody knows how to get (and test) the 64bits version of the Pharo vm and image? Thanks, Thierry

Oct. 28, 2016

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. 28, 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. 28, 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. 28, 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