You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mahout.apache.org by Jake Mannix <ja...@gmail.com> on 2010/01/28 06:13:30 UTC
too... much... coding...
What do you do when your "svn stat | wc -l" returns "66", and you have fixes
for 6 of your 7 open bugs? I'd like to check in, but I've also done some
local rearranging:
colt's got DoubleDoubleFunction, we have BinaryFunction. colt's got
DoubleFunction, we have UnaryFunction. Same exact interface signatures.
Obviously must be merged cleanly (done locally <check!>, took some fancy
intellij-foo [not really]). Both of these belong pushed down into
o.a.m.math.function, as does all the bunch of implementations that live in
o.a.m.math.jet.math.Functions (done locally <check!>)...
Should I go through the trouble of pulling apart all these checkins, or can
I just add a wad of new unit tests, and make sure everything passes? Y'all
trust me? :)
-jake
Re: too... much... coding...
Posted by Jake Mannix <ja...@gmail.com>.
oooh, holey round-off errors, batman! Quick quiz:
- d = -7.105427357601002E-15
- Math.sqrt(d) == ?
yuck. Something which is no longer particularly close to zero!
On Wed, Jan 27, 2010 at 10:12 PM, Jake Mannix <ja...@gmail.com> wrote:
> Okeedokee, trigger fired.
>
> Folks might want to svn up sometime soon.
>
> -jake
>
>
> On Wed, Jan 27, 2010 at 9:30 PM, Ted Dunning <te...@gmail.com>wrote:
>
>> Sounds like a good idea to do as a batch.
>>
>> On Wed, Jan 27, 2010 at 9:13 PM, Jake Mannix <ja...@gmail.com>
>> wrote:
>>
>> > Should I go through the trouble of pulling apart all these checkins, or
>> can
>> > I just add a wad of new unit tests, and make sure everything passes?
>> Y'all
>> > trust me? :)
>> >
>>
>>
>>
>> --
>> Ted Dunning, CTO
>> DeepDyve
>>
>
>
Re: too... much... coding...
Posted by Jake Mannix <ja...@gmail.com>.
Okeedokee, trigger fired.
Folks might want to svn up sometime soon.
-jake
On Wed, Jan 27, 2010 at 9:30 PM, Ted Dunning <te...@gmail.com> wrote:
> Sounds like a good idea to do as a batch.
>
> On Wed, Jan 27, 2010 at 9:13 PM, Jake Mannix <ja...@gmail.com>
> wrote:
>
> > Should I go through the trouble of pulling apart all these checkins, or
> can
> > I just add a wad of new unit tests, and make sure everything passes?
> Y'all
> > trust me? :)
> >
>
>
>
> --
> Ted Dunning, CTO
> DeepDyve
>
Re: too... much... coding...
Posted by Ted Dunning <te...@gmail.com>.
Sounds like a good idea to do as a batch.
On Wed, Jan 27, 2010 at 9:13 PM, Jake Mannix <ja...@gmail.com> wrote:
> Should I go through the trouble of pulling apart all these checkins, or can
> I just add a wad of new unit tests, and make sure everything passes? Y'all
> trust me? :)
>
--
Ted Dunning, CTO
DeepDyve
Re: too... much... coding...
Posted by Jake Mannix <ja...@gmail.com>.
On Thu, Jan 28, 2010 at 6:08 AM, Grant Ingersoll <gs...@apache.org>wrote:
>
> On Jan 28, 2010, at 12:13 AM, Jake Mannix wrote:
>
> > What do you do when your "svn stat | wc -l" returns "66", and you have
> fixes
> > for 6 of your 7 open bugs? I'd like to check in, but I've also done some
> > local rearranging:
>
> Hmmm, my brain can usually only handle one or two fixes at a time! FWIW,
> though, I usually keep separate checkouts or just do one at a time otherwise
> you can end up w/ a whole mess of interlinked changes.
That's what I've done in the past too - I have currently 15
trunk-with-patch-foo checkouts, and that turned into a bit of a mess too.
But at least last night, the issue was that in doing vector perf work, as
soon as I stepped a broken unit test through the debugger, I tracked down
maybe 4 new bugs, and I knew I'd lose them if I made separate checkouts for
each one.
> (This is one of the major reasons I like using Maven: I can simply point
> IntelliJ at the fresh checkout and create a new project with all the right
> setup w/o any of the hassle of configuring dependencies, etc.)
>
Yep, that is very helpful, I do that too. Although still unweildy to keep
track of which checkout has which patch applied and which ones have been svn
upped more recently than others...
> For me, it works best to create patches often and put them up on JIRA and
> then to revert my sandbox and start on the next one.
>
Yeah, I agree with that in principle, actually. I think my OCD, when it
sees little bugs in all of my checkouts (each one fixed in one particular
other checkout), I forget which bug have been fixed, which ones have not
even been reported, and which ones are fixed in a separate checkout.
For big changes, I've been trying to learn git better, and that worked
really well for my decomposer import - I kept one git repo in one directory,
git pull'ed off of git.apache.org all the time into my local trunk, and then
spun off a bunch of different local branches which I periodically merged my
trunk into, and created patches based off of this repo, posted to JIRA when
tests were passing.
The nice thing about this is that I only had *one* directory for all of the
branches, and by "git branch foo", the local directory would change itself
around, and I didn't even need to open a new IntelliJ project - it would
pick up the changes for the new branch on the fly (this didn't work too well
with eclipse, as you have to remember to tell it to "refresh" the project,
and that sometimes takes forever to rebuild etc. - the rebuilding indexes
in IntelliJ was far quicker).
> If, however, the changes are all related, then the right thing to do,
> probably, is to link them in JIRA so that people are aware of the changes.
>
What if they're not really related, but are in all the same classes and in
methods only two or three lines apart (making it really hard to make sure
you have patches which don't collide/conflict)?
> At any rate, since you've already made the commit, that's fine too!
No, I really would want to learn a good technique at playing nice with the
repository/the Apache Way/the Mahout Way, while still moving quickly on a)
fixing little bugs, and b) making progress on bigger issues workable (even
when I see the same little bug UNFIXED while on each bigger issue checkout).
I know most of this is my own psychology: combine working in big spurts with
OCD annoyance at seeing unfixed issues in the code I'm digging into, and you
get my issues. This should hopefully resolve itself as we stabilize, and I
see less little unfixed bugs. :)
-jake
Re: too... much... coding...
Posted by Grant Ingersoll <gs...@apache.org>.
On Jan 28, 2010, at 12:13 AM, Jake Mannix wrote:
> What do you do when your "svn stat | wc -l" returns "66", and you have fixes
> for 6 of your 7 open bugs? I'd like to check in, but I've also done some
> local rearranging:
Hmmm, my brain can usually only handle one or two fixes at a time! FWIW, though, I usually keep separate checkouts or just do one at a time otherwise you can end up w/ a whole mess of interlinked changes. (This is one of the major reasons I like using Maven: I can simply point IntelliJ at the fresh checkout and create a new project with all the right setup w/o any of the hassle of configuring dependencies, etc.)
For me, it works best to create patches often and put them up on JIRA and then to revert my sandbox and start on the next one.
If, however, the changes are all related, then the right thing to do, probably, is to link them in JIRA so that people are aware of the changes.
At any rate, since you've already made the commit, that's fine too!
-Grant