|
Robin Anil
2010-05-29, 15:11
Grant Ingersoll
2010-05-29, 17:30
Benson Margulies
2010-05-29, 17:50
Robin Anil
2010-05-29, 17:58
Jake Mannix
2010-05-29, 18:11
Sean Owen
2010-05-29, 18:17
Jake Mannix
2010-05-29, 18:34
Sean Owen
2010-05-29, 19:13
Jake Mannix
2010-05-29, 19:59
Ted Dunning
2010-05-29, 20:01
Jake Mannix
2010-05-29, 20:06
Grant Ingersoll
2010-05-29, 21:14
Jake Mannix
2010-05-29, 21:19
Ted Dunning
2010-05-29, 20:00
Jake Mannix
2010-05-29, 20:09
Ted Dunning
2010-05-29, 20:20
Benson Margulies
2010-05-29, 20:24
Jake Mannix
2010-05-29, 20:24
Sean Owen
2010-05-29, 18:11
Sean Owen
2010-05-29, 21:12
Jake Mannix
2010-05-29, 21:22
Grant Ingersoll
2010-05-29, 21:29
Ted Dunning
2010-05-30, 04:06
Benson Margulies
2010-05-30, 15:03
Sean Owen
2010-05-30, 15:10
Grant Ingersoll
2010-06-01, 14:45
Robin Anil
2010-06-02, 06:16
Ted Dunning
2010-06-02, 06:37
Isabel Drost
2010-06-11, 14:33
Sean Owen
2010-05-29, 21:35
Jake Mannix
2010-05-29, 21:47
Robin Anil
2010-05-29, 23:49
|
-
Cleanup MathRobin Anil 2010-05-29, 15:11
Math module clearly doesn't conform to the style guidelines. Does it
make sense to go and clean it entirely or should we do it for the ones we use, when we use it? Robin +
Robin Anil 2010-05-29, 15:11
-
Re: Cleanup MathGrant Ingersoll 2010-05-29, 17:30
On May 29, 2010, at 11:11 AM, Robin Anil wrote: > Math module clearly doesn't conform to the style guidelines. Does it > make sense to go and clean it entirely or should we do it for the ones > we use, when we use it? > > I'm not a big fan of massive formatting changes. It breaks a lot of otherwise good patches. I usually apply them right as I'm about to commit on the files I have open. -Grant +
Grant Ingersoll 2010-05-29, 17:30
-
Re: Cleanup MathBenson Margulies 2010-05-29, 17:50
There are arguments in both directions. In my view, the ideal is:
1) declare a target date. 2) everyone clears the deck of patches. 3) Reformat Grant's proposal, which goes 1) have a reason to modify some particular bit 2) check in patch 3) check in reformat before someone else starts a patch is not bad, either. On Sat, May 29, 2010 at 1:30 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote: > > On May 29, 2010, at 11:11 AM, Robin Anil wrote: > > > Math module clearly doesn't conform to the style guidelines. Does it > > make sense to go and clean it entirely or should we do it for the ones > > we use, when we use it? > > > > > > I'm not a big fan of massive formatting changes. It breaks a lot of > otherwise good patches. I usually apply them right as I'm about to commit > on the files I have open. > > -Grant +
Benson Margulies 2010-05-29, 17:50
-
Re: Cleanup MathRobin Anil 2010-05-29, 17:58
Correct me If I am wrong, I believe there are no conflicts for many of the
following top violators (except the matrix/linalg which Jake may have some changes). So there shouldn't be a problem with formatting these. Is anyone working on any of these classes? Robin filename l m h number trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java> 0 224 0 224 trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java> 0 220 0 220 trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java> 0 215 0 215 trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java> 0 104 0 104 trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java> 0 88 0 88 trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java> 0 84 0 84 trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java> 0 82 0 82 trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java> 0 71 0 71 trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java> 0 68 0 68 trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java> 0 57 0 57 trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java> 0 54 0 54 trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java> 0 51 0 51 trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java> 0 48 0 48 trunk/math/src/main/java/org/apache/mahout/math/function/Functions.java<file/trunk/math/src/main/java/org/apache/mahout/math/function/Functions.java> 0 47 0 47 trunk/math/src/main/java/org/apache/mahout/math/jet/random/Poisson.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Poisson.java> 0 47 0 47 trunk/math/src/main/java/org/apache/mahout/math/jet/random/Binomial.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Binomial.java> 0 43 0 43 trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileCalc.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileCalc.java> 0 40 0 40 trunk/math/src/main/java/org/apache/mahout/math/jet/random/sampling/RandomSampler.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/sampling/RandomSampler.java> 0 38 0 38 trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Formatter.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Formatter.java> 0 38 0 38 trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix3D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix3D.java> 0 38 0 38 trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/MersenneTwister.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/MersenneTwister.java> 0 28 0 28 trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/LUDecompositionQuick.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/LUDecompositionQuick.java> 0 26 0 26 trunk/math/src/main/java/org/apache/mahout/math/Partitioning.java<file/trunk/math/src/main/java/org/apache/mahout/math/Partitioning.java>025025 trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/EigenvalueDecomposition.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/EigenvalueDecomposition.java> 0 24 0 24 trunk/math/src/main/java/org/apache/mahout/math/decomposer/hebbian/HebbianSolver.java<file/trunk/math/src/main/java/org/apache/mahout/math/decomposer/hebbian/HebbianSolver.java> 0 23 0 23 trunk/math/src/main/java/org/apache/mahout/math/AbstractVector.java<file/trunk/math/src/main/java/org/apache/mahout/math/AbstractVector.java> 0 21 0 21 trunk/math/src/main/java/org/apache/mahout/math/jet/random/Distributions.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Distributions.java> 0 21 0 21 trunk/math/src/main/java/org/apache/mahout/math/matrix/DoubleFactory2D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/DoubleFactory2D.java> 0 21 0 21 trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Descriptive.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Descriptive.java> 0 20 0 20 trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Statistic.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Statistic.java> 0 20 0 20 trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/SeqBlas.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/SeqBlas.java> 0 19 0 19 trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/SingularValueDecomposition.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/SingularValueDecomposition.java> 0 19 0 19 trunk/math/src/main/java/org/apache/mahout/math/jet/math/IntFunctions.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/IntFunctions.java> 0 18 0 18 +
Robin Anil 2010-05-29, 17:58
-
Re: Cleanup MathJake Mannix 2010-05-29, 18:11
Erggg..... once I again I will state that I strongly prefer Grant's
approach. Do findbugs and formatting "errors" actually cause people physical pain? Why does this keep coming up? -jake ps. no I doubt anyone is working on those files. Doesn't change my opinion of massive formatting checkins. On Sat, May 29, 2010 at 10:58 AM, Robin Anil <[EMAIL PROTECTED]> wrote: > Correct me If I am wrong, I believe there are no conflicts for many of the > following top violators (except the matrix/linalg which Jake may have some > changes). So there shouldn't be a problem with formatting these. Is anyone > working on any of these classes? > > Robin > filename l m h number > > trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java> > 0 224 0 224 > > trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java> > 0 220 0 220 > > trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java> > 0 215 0 215 > > trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java> > 0 104 0 104 > > trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java> > 0 88 0 88 > > trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java> > 0 84 0 84 > > trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java> > 0 82 0 82 > > trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java> > 0 71 0 71 > > trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java> > 0 68 0 68 > > trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java> > 0 57 0 57 > > trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java> > 0 54 0 54 > > trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java> > 0 51 0 51 > > trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java> > 0 48 0 48 > > trunk/math/src/main/java/org/apache/mahout/math/function/Functions.java<file/trunk/math/src/main/java/org/apache/mahout/math/function/Functions.java> > 0 47 0 47 > > trunk/math/src/main/java/org/apache/mahout/math/jet/random/Poisson.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Poisson.java> > 0 47 0 47 > > trunk/math/src/main/java/org/apache/mahout/math/jet/random/Binomial.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Binomial.java> > 0 43 0 43 > > trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileCalc.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileCalc.java> > 0 40 0 40 > > trunk/math/src/main/java/org/apache/mahout/math/jet/random/sampling/RandomSampler.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/sampling/RandomSampler.java> > 0 38 0 38 > > trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Formatter.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Formatter.java> +
Jake Mannix 2010-05-29, 18:11
-
Re: Cleanup MathSean Owen 2010-05-29, 18:17
Agree, which is why I'd rather just nail this once rather than dribble it in.
It's reasonable to say you just don't think the formatting and style stuff matters, but I find it does, indirectly, from a "broken windows policy" perspective. If your code *looks* a bit uneven and inconsistent, people have less compunction about checking in more uneven code (since it already is) and have a general sense that it's alright to check in stuff that's maybe not as completely baked as would be ideal -- since it looks like anything goes. And I don't think we're spending too *much* time thinking about design and such. So is it so painful to let someone else touch up, on everyone's behalf, the code base? we really should have been checking in better code from the get-go. Turned around... I also don't see the argument against cleaning this up. Do you have a patch? fine, we can wait until you're ready check in. This is a real no-skin-off-your-nose change so, ? On Sat, May 29, 2010 at 2:11 PM, Jake Mannix <[EMAIL PROTECTED]> wrote: > Erggg..... once I again I will state that I strongly prefer Grant's > approach. > > Do findbugs and formatting "errors" actually cause people physical pain? > > Why does this keep coming up? > > -jake > > ps. no I doubt anyone is working on those files. Doesn't change my > opinion of massive formatting checkins. > > On Sat, May 29, 2010 at 10:58 AM, Robin Anil <[EMAIL PROTECTED]> wrote: > >> Correct me If I am wrong, I believe there are no conflicts for many of the >> following top violators (except the matrix/linalg which Jake may have some >> changes). So there shouldn't be a problem with formatting these. Is anyone >> working on any of these classes? >> >> Robin >> filename l m h number >> >> trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java> >> 0 224 0 224 >> >> trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java> >> 0 220 0 220 >> >> trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java> >> 0 215 0 215 >> >> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java> >> 0 104 0 104 >> >> trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java> >> 0 88 0 88 >> >> trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java> >> 0 84 0 84 >> >> trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java> >> 0 82 0 82 >> >> trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java> >> 0 71 0 71 >> >> trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java> >> 0 68 0 68 >> >> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java> >> 0 57 0 57 >> >> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java> >> 0 54 0 54 >> >> trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java> >> 0 51 0 51 >> >> trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java> +
Sean Owen 2010-05-29, 18:17
-
Re: Cleanup MathJake Mannix 2010-05-29, 18:34
Ok, I'm done wasting time on this issue. People want to reformat
huge swaths of code, have a blast. On Sat, May 29, 2010 at 11:17 AM, Sean Owen <[EMAIL PROTECTED]> wrote: > Agree, which is why I'd rather just nail this once rather than dribble it > in. > > It's reasonable to say you just don't think the formatting and style > stuff matters, but I find it does, indirectly, from a "broken windows > policy" perspective. If your code *looks* a bit uneven and > inconsistent, people have less compunction about checking in more > uneven code (since it already is) and have a general sense that it's > alright to check in stuff that's maybe not as completely baked as > would be ideal -- since it looks like anything goes. > > And I don't think we're spending too *much* time thinking about design > and such. So is it so painful to let someone else touch up, on > everyone's behalf, the code base? we really should have been checking > in better code from the get-go. > > Turned around... I also don't see the argument against cleaning this > up. Do you have a patch? fine, we can wait until you're ready check > in. This is a real no-skin-off-your-nose change so, ? > > On Sat, May 29, 2010 at 2:11 PM, Jake Mannix <[EMAIL PROTECTED]> > wrote: > > Erggg..... once I again I will state that I strongly prefer Grant's > > approach. > > > > Do findbugs and formatting "errors" actually cause people physical pain? > > > > Why does this keep coming up? > > > > -jake > > > > ps. no I doubt anyone is working on those files. Doesn't change my > > opinion of massive formatting checkins. > > > > On Sat, May 29, 2010 at 10:58 AM, Robin Anil <[EMAIL PROTECTED]> > wrote: > > > >> Correct me If I am wrong, I believe there are no conflicts for many of > the > >> following top violators (except the matrix/linalg which Jake may have > some > >> changes). So there shouldn't be a problem with formatting these. Is > anyone > >> working on any of these classes? > >> > >> Robin > >> filename l m h number > >> > >> > trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java> > >> 0 224 0 224 > >> > >> > trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java> > >> 0 220 0 220 > >> > >> > trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java> > >> 0 215 0 215 > >> > >> > trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java> > >> 0 104 0 104 > >> > >> > trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java> > >> 0 88 0 88 > >> > >> > trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java> > >> 0 84 0 84 > >> > >> > trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java> > >> 0 82 0 82 > >> > >> > trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java> > >> 0 71 0 71 > >> > >> > trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java> > >> 0 68 0 68 > >> > >> > trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java> > >> 0 57 0 57 > >> > >> > trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java> +
Jake Mannix 2010-05-29, 18:34
-
Re: Cleanup MathSean Owen 2010-05-29, 19:13
Nobody asked you to spend any time on anything though. Does it mess up a
patch? Say so and nothing would happen until ready. So not sure what other issue is lurking here but lets discuss if needed rather than feel funny about it. This should be easy and fun. On May 29, 2010 2:35 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote: Ok, I'm done wasting time on this issue. People want to reformat huge swaths of code, have a blast. On Sat, May 29, 2010 at 11:17 AM, Sean Owen <[EMAIL PROTECTED]> wrote: > Agree, which is why I'd ra... +
Sean Owen 2010-05-29, 19:13
-
Re: Cleanup MathJake Mannix 2010-05-29, 19:59
We've been through it before: making massive formatting
changes can: a) break patches. Biggest reason, not the case here. But the point is that it sets (grr, continues) a precedent: what if someone was on vacation and not reading emails, and we all said, "I'm not touching that module, go ahead and reformat", and because they were away for the 3-day period in which the discussion happened, their patches are totally trashed. And don't say this is a "one time thing", because if we decide to change some rule later, some of the current code may be "in violation" of the new rule, or if we adopt another project, the first step is always: see if it works first, then worry about formatting later. b) screw up svn modification history and IDE support of showing diffs, which trying to track down who changed something, it basically suddenly becomes "Robin/Sean did!" as the answer to every file. And frankly, I just hate having people (even not-me people!) running around just autoformatting stuff for the sake of it. It makes it the opposite of "easy and fun" for me. But as I said, I really don't feel like giving this a "-1" followed by a big backing-up-of-all-of-my-points as to "why", so I'll stick with the tried-and-true passive-aggressive Apache "-0" as my vote on this, and leave it at that, not really wanting to discuss it too much further. -jake On Sat, May 29, 2010 at 12:13 PM, Sean Owen <[EMAIL PROTECTED]> wrote: > Nobody asked you to spend any time on anything though. Does it mess up a > patch? Say so and nothing would happen until ready. So not sure what other > issue is lurking here but lets discuss if needed rather than feel funny > about it. This should be easy and fun. > > On May 29, 2010 2:35 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote: > > Ok, I'm done wasting time on this issue. People want to reformat > huge swaths of code, have a blast. > > > On Sat, May 29, 2010 at 11:17 AM, Sean Owen <[EMAIL PROTECTED]> wrote: > > > Agree, which is why I'd ra... > +
Jake Mannix 2010-05-29, 19:59
-
Re: Cleanup MathTed Dunning 2010-05-29, 20:01
Jake,
How about I buy you a beer to convert you to a +0? (yes, this is a bribe) On Sat, May 29, 2010 at 12:59 PM, Jake Mannix <[EMAIL PROTECTED]> wrote: > But as I said, I really don't feel like giving this a "-1" > followed by a big backing-up-of-all-of-my-points as to > "why", so I'll stick with the tried-and-true > passive-aggressive Apache "-0" as my vote on this, > and leave it at that, not really wanting to discuss it > too much further. > +
Ted Dunning 2010-05-29, 20:01
-
Re: Cleanup MathJake Mannix 2010-05-29, 20:06
On Sat, May 29, 2010 at 1:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> Jake, > > How about I buy you a beer to convert you to a +0? > > (yes, this is a bribe) > An entire beer for but a two-epsilon change in my vote? That's a pretty high BeerPerVote ratio, I better grab that before the market sees how inflated it is. I'm actually in mountain view right now, BTW! -jake > > On Sat, May 29, 2010 at 12:59 PM, Jake Mannix <[EMAIL PROTECTED]> > wrote: > > > But as I said, I really don't feel like giving this a "-1" > > followed by a big backing-up-of-all-of-my-points as to > > "why", so I'll stick with the tried-and-true > > passive-aggressive Apache "-0" as my vote on this, > > and leave it at that, not really wanting to discuss it > > too much further. > > > +
Jake Mannix 2010-05-29, 20:06
-
Re: Cleanup MathGrant Ingersoll 2010-05-29, 21:14
Hey, I objected too!
On May 29, 2010, at 4:01 PM, Ted Dunning wrote: > Jake, > > How about I buy you a beer to convert you to a +0? > > (yes, this is a bribe) > > On Sat, May 29, 2010 at 12:59 PM, Jake Mannix <[EMAIL PROTECTED]> wrote: > >> But as I said, I really don't feel like giving this a "-1" >> followed by a big backing-up-of-all-of-my-points as to >> "why", so I'll stick with the tried-and-true >> passive-aggressive Apache "-0" as my vote on this, >> and leave it at that, not really wanting to discuss it >> too much further. >> +
Grant Ingersoll 2010-05-29, 21:14
-
Re: Cleanup MathJake Mannix 2010-05-29, 21:19
On Sat, May 29, 2010 at 2:14 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
> Hey, I objected too! > See! I knew the micro-vote market would never sustain epsilon-valued prices for long! But the SEC can pry that beer from my cold dead hands, I say! -jake +
Jake Mannix 2010-05-29, 21:19
-
Re: Cleanup MathTed Dunning 2010-05-29, 20:00
I am sympathetic to Jake's point of view in general, but I think that the
math stuff is a bit of a special case. I have had two patches recently that could have been affected. One was adding test cases and correcting some of the distribution code (a kind angel committed that already). Another is beginning of work on stochastic matrices. I am happy to rebase any work that I have pending. On Sat, May 29, 2010 at 12:13 PM, Sean Owen <[EMAIL PROTECTED]> wrote: > Nobody asked you to spend any time on anything though. Does it mess up a > patch? Say so and nothing would happen until ready. So not sure what other > issue is lurking here but lets discuss if needed rather than feel funny > about it. This should be easy and fun. > > On May 29, 2010 2:35 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote: > > Ok, I'm done wasting time on this issue. People want to reformat > huge swaths of code, have a blast. > +
Ted Dunning 2010-05-29, 20:00
-
Re: Cleanup MathJake Mannix 2010-05-29, 20:09
On Sat, May 29, 2010 at 1:00 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> I am sympathetic to Jake's point of view in general, but I think that the > math stuff is a bit of a special case. > The math (Colt) stuff is a special case, and in fact, is one which will lull us into a sense of security by having warnings go away, because it's still way low on test coverage. But, we did go an run my nice "auto-deprecator" ruby script on it, so we at least still have those warnings... *shrug* That code still has way more issues than just formatting, it's done in an entirely different style, was aimed at compiling against, like jdk1.2, and really needs some care and attention, and maybe possibly even some *use* at some point! -jake > > I have had two patches recently that could have been affected. One was > adding test cases and correcting some of the distribution code (a kind > angel > committed that already). Another is beginning of work on stochastic > matrices. > > I am happy to rebase any work that I have pending. > > On Sat, May 29, 2010 at 12:13 PM, Sean Owen <[EMAIL PROTECTED]> wrote: > > > Nobody asked you to spend any time on anything though. Does it mess up a > > patch? Say so and nothing would happen until ready. So not sure what > other > > issue is lurking here but lets discuss if needed rather than feel funny > > about it. This should be easy and fun. > > > > On May 29, 2010 2:35 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote: > > > > Ok, I'm done wasting time on this issue. People want to reformat > > huge swaths of code, have a blast. > > > +
Jake Mannix 2010-05-29, 20:09
-
Re: Cleanup MathTed Dunning 2010-05-29, 20:20
On Sat, May 29, 2010 at 1:09 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:
> The math (Colt) stuff is a special case, and in fact, is one which will > lull > us > into a sense of security by having warnings go away, because it's still way > low on test coverage. But, we did go an run my nice "auto-deprecator" > ruby script on it, so we at least still have those warnings... > It isn't just lack of test cases leading to deprecations. I had a use just now for some of the code and in the process of adding test cases to get rid of the deprecations found it wasn't quite right. If dipping into 4 routines uncovers 1 medium to minor bug, there must be quite a few more of those lurking. > *shrug* That code still has way more issues than just formatting, it's > done in an entirely different style, was aimed at compiling against, like > jdk1.2, and really needs some care and attention, and maybe possibly > even some *use* at some point! > Indeed. +
Ted Dunning 2010-05-29, 20:20
-
Re: Cleanup MathBenson Margulies 2010-05-29, 20:24
I found, as you will recall, a certain number of surprises in the
collections subset. You might say that we collectively took out a loan at the credibility bank by incorporating this stuff, deprecations or no, and might be well-advised to try to find time to write tests and repair problems (or remove dubious stuff altogether). On Sat, May 29, 2010 at 4:20 PM, Ted Dunning <[EMAIL PROTECTED]> wrote: > On Sat, May 29, 2010 at 1:09 PM, Jake Mannix <[EMAIL PROTECTED]> wrote: > >> The math (Colt) stuff is a special case, and in fact, is one which will >> lull >> us >> into a sense of security by having warnings go away, because it's still way >> low on test coverage. But, we did go an run my nice "auto-deprecator" >> ruby script on it, so we at least still have those warnings... >> > > It isn't just lack of test cases leading to deprecations. I had a use just > now for some of the code and in the process of adding test cases to get rid > of the deprecations found it wasn't quite right. If dipping into 4 routines > uncovers 1 medium to minor bug, there must be quite a few more of those > lurking. > > >> *shrug* That code still has way more issues than just formatting, it's >> done in an entirely different style, was aimed at compiling against, like >> jdk1.2, and really needs some care and attention, and maybe possibly >> even some *use* at some point! >> > > Indeed. > +
Benson Margulies 2010-05-29, 20:24
-
Re: Cleanup MathJake Mannix 2010-05-29, 20:24
On Sat, May 29, 2010 at 1:20 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> > It isn't just lack of test cases leading to deprecations. I had a use just > now for some of the code and in the process of adding test cases to get rid > of the deprecations found it wasn't quite right. If dipping into 4 > routines > uncovers 1 medium to minor bug, there must be quite a few more of those > lurking. > Wouldn't this be all the more reason to leave that code "ugly" so that as we dig in and use it bit by bit, adding test cases and fixing bugs, we also "pretty-ify" it? Following the "broken-window" analogy, don't go fixing a bunch of windows in a neighborhood where you don't even know if the floorboards on the abandoned houses are rotten out. Fix the windows when that particular house is "move-in-ready". -jake > > > > *shrug* That code still has way more issues than just formatting, it's > > done in an entirely different style, was aimed at compiling against, like > > jdk1.2, and really needs some care and attention, and maybe possibly > > even some *use* at some point! > > > > Indeed. > +
Jake Mannix 2010-05-29, 20:24
-
Re: Cleanup MathSean Owen 2010-05-29, 18:11
I'd prefer to have a quick big-bang change, if indeed there aren't any
outstanding patches. (If only to retroactively justify the fact that I just did the same to core and examples.) I think this is something we should focus on fixing up now, then going forward we can actually pay attention to checkstyle warnings. On Sat, May 29, 2010 at 1:50 PM, Benson Margulies <[EMAIL PROTECTED]> wrote: > There are arguments in both directions. In my view, the ideal is: > > 1) declare a target date. > 2) everyone clears the deck of patches. > 3) Reformat > > Grant's proposal, which goes > > 1) have a reason to modify some particular bit > 2) check in patch > 3) check in reformat before someone else starts a patch > > is not bad, either. > > > On Sat, May 29, 2010 at 1:30 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote: > >> >> On May 29, 2010, at 11:11 AM, Robin Anil wrote: >> >> > Math module clearly doesn't conform to the style guidelines. Does it >> > make sense to go and clean it entirely or should we do it for the ones >> > we use, when we use it? >> > >> > >> >> I'm not a big fan of massive formatting changes. It breaks a lot of >> otherwise good patches. I usually apply them right as I'm about to commit >> on the files I have open. >> >> -Grant > +
Sean Owen 2010-05-29, 18:11
-
Re: Cleanup MathSean Owen 2010-05-29, 21:12
I agree which is why I am not excited by the task of scrubbing the details
but dont mind if someone else does at all. I already had my way with core and examples which are more interesting. They're now pretty in line with checkstyle rules. Better still in math would be to chuck out the pieces we haven't found a use for and don't suppose there will be a use for soon. Then care about the rest. What would happen if I suggest we delete anything still deprecated? On May 29, 2010 4:25 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote: On Sat, May 29, 2010 at 1:20 PM, Ted Dunning <[EMAIL PROTECTED]> wrote: > > It isn't just lack o... Wouldn't this be all the more reason to leave that code "ugly" so that as we dig in and use it bit by bit, adding test cases and fixing bugs, we also "pretty-ify" it? Following the "broken-window" analogy, don't go fixing a bunch of windows in a neighborhood where you don't even know if the floorboards on the abandoned houses are rotten out. Fix the windows when that particular house is "move-in-ready". -jake > > > > *shrug* That code still has way more issues than just formatting, it's > > done in an ent... +
Sean Owen 2010-05-29, 21:12
-
Re: Cleanup MathJake Mannix 2010-05-29, 21:22
On Sat, May 29, 2010 at 2:12 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
> > Better still in math would be to chuck out the pieces we haven't found a > use > for and don't suppose there will be a use for soon. Then care about the > rest. What would happen if I suggest we delete anything still deprecated? > -1 on that idea. We don't currently use the QR decompositions in there, for example, but it would be really silly to have to re-code them all over again as soon as we found we needed it. -jake +
Jake Mannix 2010-05-29, 21:22
-
Re: Cleanup MathGrant Ingersoll 2010-05-29, 21:29
I'd say this:
I'll go for it if you can go through all of JIRA and assure me there are little to no issues open against it that need to be fixed. It's not even necessarily the active ones. Either that or promise to update/fix them once the reformat is done. I still, however, think it is pointless unless we have a process in place that automatically reformats every commit, as it is bound to be one of those annoying little things that prevents people from contributing b/c they have to have the formatting just right in order to contribute. -Grant On May 29, 2010, at 5:22 PM, Jake Mannix wrote: > On Sat, May 29, 2010 at 2:12 PM, Sean Owen <[EMAIL PROTECTED]> wrote: > >> >> Better still in math would be to chuck out the pieces we haven't found a >> use >> for and don't suppose there will be a use for soon. Then care about the >> rest. What would happen if I suggest we delete anything still deprecated? >> > > -1 on that idea. We don't currently use the QR decompositions in > there, for example, but it would be really silly to have to re-code them all > over > again as soon as we found we needed it. > > -jake +
Grant Ingersoll 2010-05-29, 21:29
-
Re: Cleanup MathTed Dunning 2010-05-30, 04:06
I would agree mildly with 80% of the result, grump about 10% and tear hair
about 10%. I don't know which 10% at the moment. But it wouldn't hurt for one or more of us to go through and mark up a list of things we can see a use for. On Sat, May 29, 2010 at 2:12 PM, Sean Owen <[EMAIL PROTECTED]> wrote: > What would happen if I suggest we delete anything still deprecated? +
Ted Dunning 2010-05-30, 04:06
-
Re: Cleanup MathBenson Margulies 2010-05-30, 15:03
I wasn't here when you all picked up Colt, but I wonder if we want to
pick a middle ground between carrying around @deprecated code that no one feels like testing and deleting it altogether. Work went into IP clearance and all that. I'd identifying the things that look furthest from useful and moving them to a separate 'attic', from which they could be recovered in case someone found a use for them. By the way, howcome 'taste' has a BitSet distinct from either the JDK class or the collection BitVector? On Sun, May 30, 2010 at 12:06 AM, Ted Dunning <[EMAIL PROTECTED]> wrote: > I would agree mildly with 80% of the result, grump about 10% and tear hair > about 10%. I don't know which 10% at the moment. > > But it wouldn't hurt for one or more of us to go through and mark up a list > of things we can see a use for. > > On Sat, May 29, 2010 at 2:12 PM, Sean Owen <[EMAIL PROTECTED]> wrote: > >> What would happen if I suggest we delete anything still deprecated? > +
Benson Margulies 2010-05-30, 15:03
-
Re: Cleanup MathSean Owen 2010-05-30, 15:10
On Sun, May 30, 2010 at 11:03 AM, Benson Margulies
<[EMAIL PROTECTED]> wrote: > I wasn't here when you all picked up Colt, but I wonder if we want to > pick a middle ground between carrying around @deprecated code that no > one feels like testing and deleting it altogether. Work went into IP > clearance and all that. I'd identifying the things that look furthest > from useful and moving them to a separate 'attic', from which they > could be recovered in case someone found a use for them. (It is always resurrectable from SVN too.) > By the way, howcome 'taste' has a BitSet distinct from either the JDK > class or the collection BitVector? Purely for speed and size -- mostly skipping range checks, cutting out fields, etc. It mattered enough since it got used so much. +
Sean Owen 2010-05-30, 15:10
-
Re: Cleanup MathGrant Ingersoll 2010-06-01, 14:45
On May 30, 2010, at 11:10 AM, Sean Owen wrote: > On Sun, May 30, 2010 at 11:03 AM, Benson Margulies > <[EMAIL PROTECTED]> wrote: >> I wasn't here when you all picked up Colt, but I wonder if we want to >> pick a middle ground between carrying around @deprecated code that no >> one feels like testing and deleting it altogether. Work went into IP >> clearance and all that. I'd identifying the things that look furthest >> from useful and moving them to a separate 'attic', from which they >> could be recovered in case someone found a use for them. > > (It is always resurrectable from SVN too.) A bit harder to find, though. > >> By the way, howcome 'taste' has a BitSet distinct from either the JDK >> class or the collection BitVector? > > Purely for speed and size -- mostly skipping range checks, cutting out > fields, etc. It mattered enough since it got used so much. Those are the reasons Lucene has one too! +
Grant Ingersoll 2010-06-01, 14:45
-
Re: Cleanup MathRobin Anil 2010-06-02, 06:16
https://issues.apache.org/jira/browse/HADOOP-6668
Check this out. This looks like a clean way to solve this issue in Mahout as well. If we annotate each package as public stable, private stable, public unstable, and so on and so forth, and keep only the stable ones in the javadoc, Users will find the documentations a lot more readable. Plus developers can keep adding experimental stuff with bad style as long as it is not marked visible. We can keep separate quality levels for each visibility. Mahout will always attract experimental code, so instead of driving it away and waiting for the quality to go up before committing, we can annotate it at the least quality level and when it improves, we can change the annotation along with the improvements. I can help creating a patch like this, if everyone is onboard Robin +
Robin Anil 2010-06-02, 06:16
-
Re: Cleanup MathTed Dunning 2010-06-02, 06:37
I think that this is fine. Essentially this is a more fine grained approach
to what we have been doing with deprecated. The real virtue of this is that it promotes visibility of the known good stuff and thus exerts a good social pressure. I do think that we need to push for code quality as quickly as is reasonable, but definitely at the patch level, we should encourage contributors to post early versions. On Tue, Jun 1, 2010 at 11:16 PM, Robin Anil <[EMAIL PROTECTED]> wrote: > https://issues.apache.org/jira/browse/HADOOP-6668 > > Check this out. This looks like a clean way to solve this issue in Mahout > as > well. If we annotate each package as public stable, private stable, public > unstable, and so on and so forth, and keep only the stable ones in the > javadoc, Users will find the documentations a lot more readable. Plus > developers can keep adding experimental stuff with bad style as long as it > is not marked visible. We can keep separate quality levels for each > visibility. Mahout will always attract experimental code, so instead of > driving it away and waiting for the quality to go up before committing, we > can annotate it at the least quality level and when it improves, we can > change the annotation along with the improvements. > > I can help creating a patch like this, if everyone is onboard > > Robin > +
Ted Dunning 2010-06-02, 06:37
-
Re: Cleanup MathIsabel Drost 2010-06-11, 14:33
On Tue Ted Dunning <[EMAIL PROTECTED]> wrote:
> I think that this is fine. Essentially this is a more fine grained > approach to what we have been doing with deprecated. +1 from me as well. The approach also clearly separates stable, but in future versions no longer supported code (deprecated) from experimental, but in future versions better supported code. Should make it easier for the user to decide which pieces of Mahout to use. Isabel +
Isabel Drost 2010-06-11, 14:33
-
Re: Cleanup MathSean Owen 2010-05-29, 21:35
That sounds fine to me.
But I sense there's no particular motivation to ever address this stuff - hearing objections to even style changes. What is the game plan you envision then? When is it OK to touch any of this? Honestly the code quality in this project is not yet professional. Its much better than a lot of projects. But I participate to make code that is better than anything a professional organization is capable of. So this sentiment is not the best to hear. This is not amateur hobby code, it ought to be world class! On May 29, 2010 5:23 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote: On Sat, May 29, 2010 at 2:12 PM, Sean Owen <[EMAIL PROTECTED]> wrote: > > Better still in math would... -1 on that idea. We don't currently use the QR decompositions in there, for example, but it would be really silly to have to re-code them all over again as soon as we found we needed it. -jake +
Sean Owen 2010-05-29, 21:35
-
Re: Cleanup MathJake Mannix 2010-05-29, 21:47
On Sat, May 29, 2010 at 2:35 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
> That sounds fine to me. > > But I sense there's no particular motivation to ever address this stuff - > hearing objections to even style changes. > > What is the game plan you envision then? When is it OK to touch any of > this? > "OK"? It's always ok to *fix* it, I'm just saying it's not terribly helpful to "fix" the style errors without fixing the underlying code, and I'm saying it's not ok to just remove it because we haven't gotten around to fixing it up just yet. > Honestly the code quality in this project is not yet professional. It's better than the "professional" code I've seen in many companies whose code I've read or had to use. It has rough parts which are untended, just like codebases, except there are actually far fewer of these in our codebase, and in fact ours has the benefit of that code not actually being used right now, unlike corporate environments where the code gets embedded in some system which is in use and can *never* be removed, leaving its bugs as little time-bombs. > Its much > better than a lot of projects. But I participate to make code that is > better > than anything a professional organization is capable of. > Great, excellent. > So this sentiment is not the best to hear. This is not amateur hobby code, > it ought to be world class! > Totally agree. I just don't agree on a) how to get there, code-wise, and b) how to get there - motivation-of-contributors/commiters-wise. -jake +
Jake Mannix 2010-05-29, 21:47
-
Re: Cleanup MathRobin Anil 2010-05-29, 23:49
This is terrible! I went to sleep on this side of the world and people on
the other side have already bartered votes for beer. For being the reason of the getting a vote call going by mistake, I object this reflexive behavior and instead propose for a transitive one. If we are not going to touch (use, format, delete or make api compatible) many of these deprecated code. Instead, how about marking stuff as @deprecated. So that it is clear to new developers reading the code that those module are not to be examined. Robin +
Robin Anil 2010-05-29, 23:49
|