| *** mlncn has quit IRC | 00:41 | |
| *** bkuhn has quit IRC | 03:09 | |
| *** nesciens has quit IRC | 03:50 | |
| *** mlncn has joined #npoacct | 04:35 | |
| *** tgnit has joined #npoacct | 04:48 | |
| *** tgnit has quit IRC | 05:18 | |
| *** tgnitidle has joined #npoacct | 05:18 | |
| *** tgnitidle has quit IRC | 05:27 | |
| *** tgnit has joined #npoacct | 05:29 | |
| *** tgnit has quit IRC | 11:56 | |
| *** tgnit has joined #npoacct | 12:32 | |
| *** bkuhn has joined #npoacct | 12:37 | |
| *** mlncn has quit IRC | 13:23 | |
| *** mlncn has joined #npoacct | 14:15 | |
| *** bkuhn is now known as bkuhnIdle | 14:22 | |
| *** bkuhnIdle is now known as bkuhn | 15:14 | |
| bkuhn | tgnit: tbm and I are taking a look at your new code now. :) | 15:24 |
|---|---|---|
| tgnit | bkuhn: thanks | 15:24 |
| tgnit | bkuhn: please don't mind the formatting, i will clean up later | 15:25 |
| bkuhn | :) | 15:26 |
| bkuhn | tgnit: what does has_commodity() method do? | 15:27 |
| bkuhn | I mean, when does it return true? | 15:27 |
| bkuhn | (I am just wondering when an amount *doesn't* have a commodity in ledger) | 15:27 |
| tgnit | if does not have a null commodity ie no commodity attached to it | 15:27 |
| bkuhn | tgnit: That probably almost never happens, right? | 15:27 |
| bkuhn | If I say $N, or X EUR, etc. | 15:28 |
| bkuhn | it's always going to have a commodity. | 15:28 |
| * bkuhn didn't even know it was valid to put things into ledger without a commodity attached. ;) | 15:28 | |
| tbm | you can say 100 but johnw says this is a bad idea | 15:28 |
| bkuhn | What do you know, you can! | 15:28 |
| tgnit | bkuhn: just to be on safe side :) | 15:29 |
| * bkuhn tried it. | 15:29 | |
| bkuhn | tgnit: nope, you're right , absoultely. | 15:29 |
| bkuhn | I was just surprised it was valid. | 15:29 |
| bkuhn | But I just tried it. | 15:29 |
| bkuhn | Now that I think about it, I think I've had errors before where I missed a $ and it was confusing. :) | 15:29 |
| tgnit | bkuhn : it happens | 15:31 |
| tgnit | there are several other places which we may have to such code, but this one works for our case. | 15:33 |
| tbm | tgnit: I haven't tested your patch yet. but I looked at the last one. So does this do rounding? | 16:13 |
| tbm | tgnit: does it work? | 16:13 |
| tbm | tgnit: are you sure this is the right location to do the rounding? (just asking... I don't know... you've done the debugging ;) | 16:13 |
| *** nesciens has joined #npoacct | 16:15 | |
| tgnit | i feel it is the place for the type of transaction we are looking | 16:17 |
| tbm | ok, good | 16:17 |
| tgnit | tbm: there are several other cases too, so need to add at different places | 16:18 |
| tbm | so if your patch is working, can you commit a test case to the test suite | 16:18 |
| tgnit | tbm: i added some results to npo you can look at the order in debug | 16:20 |
| tgnit | yes I can | 16:20 |
| tgnit | don't i need to cleanup first? those debug statements | 16:21 |
| tbm | well, if you want to submit upstream, you have to clean up the code. But you can add a test case now | 16:22 |
| tbm | the debug statements and the test case are unrelated | 16:22 |
| tgnit | ya not upstream right now, i can add it to my fork | 16:23 |
| tgnit | won't the test case fail without the patch in the upstream? they build regularly | 16:24 |
| tbm | sorry if I wasn't clear. I meant: can you add a test case to _your_ repo | 16:25 |
| tbm | not upstram | 16:25 |
| tgnit | ok i do it right away | 16:33 |
| tgnit | tbm: added some tests, working fine | 16:52 |
| tgnit | tbm: the test you presented, i have seen such case. | 16:53 |
| tgnit | there are other place where we need to round | 16:54 |
| tgnit | ledger call several function dynamically depending on cases. | 16:54 |
| bkuhn | tgnit: You may want to start keeping separate branches for various things. | 17:06 |
| bkuhn | For example, you could keep the DEBUG statements in a branch -- as I mentioned in my comment, those are upstreamable. | 17:06 |
| bkuhn | and then you can just rebase your other changes on top of them regularly. | 17:06 |
| tgnit | today i was just thinking of that :) | 17:06 |
| bkuhn | I suspect right now you want at least two branches: | 17:06 |
| bkuhn | One to add DEBUG stateemnts | 17:06 |
| bkuhn | One to work on this specific feature. | 17:07 |
| tgnit | yes | 17:07 |
| bkuhn | and the one the feature will regularly rebase. | 17:07 |
| bkuhn | but when you want to add a DEBUG statement, switch branches, add it, then come back to your feature branch and rebase | 17:07 |
| bkuhn | If you do this as rote procedure, the rebasing should be clean. | 17:07 |
| tgnit | i will do it right away. | 17:08 |
| bkuhn | tgnit: I'd suggest right now (or maybe tomorrow, if it's getting late there), maybe taking a step back, starting with a clean fork, and cherry-picking out your changes. | 17:08 |
| bkuhn | as you do that, you can fix the code formatting issues tbm raised, and start adding tests. | 17:08 |
| bkuhn | etc. | 17:08 |
| tgnit | ok | 17:08 |
| tgnit | oki | 17:08 |
| bkuhn | And I agree with tbm: | 17:09 |
| bkuhn | It's good to get started with test cases. | 17:09 |
| bkuhn | add them, and show them to be failing. | 17:09 |
| bkuhn | then, write the feature. | 17:09 |
| bkuhn | It's basically TDD, which I think is useful here. | 17:09 |
| bkuhn | You could start with tbm's test case. | 17:10 |
| bkuhn | Add it to ledger's existing test suite. | 17:10 |
| bkuhn | In a way that it fails. | 17:10 |
| bkuhn | but would pass as a test if the feature is implemented properly. | 17:10 |
| tgnit | bkuhn: the test case tbm suggested i have seen something similar. there are several places rounding can take place | 17:10 |
| bkuhn | that will give you a target. | 17:10 |
| tgnit | 17:10 | |
| bkuhn | tgnit: I understand. | 17:10 |
| bkuhn | So each thing your feature fixes, you should have a test case. | 17:10 |
| tgnit | bkuhn: just read. got you too | 17:10 |
| bkuhn | As it stands, when I look at what you've done so far, it's not clear which type of test case your solution so far solves. | 17:11 |
| bkuhn | I get your point that for 'precision' directive to work fully, you'll need to round in more places. | 17:11 |
| bkuhn | But there must be a "reason" that you felt the place you added the round work: | 17:11 |
| bkuhn | What I'd like to see in the git log is: | 17:11 |
| bkuhn | * Adding of a test case. If you check out that revision, and run tests, the test case fails. | 17:12 |
| bkuhn | * Adding of the feature. | 17:12 |
| tgnit | yes, i understand. i think we should discuss on the irc and mailing list for other test cases meanwhile i should pick old tests from baseline to work according to precision | 17:12 |
| bkuhn | * the test case passes | 17:12 |
| bkuhn | tgnit: You could redo this work even with the precision directive as a way to get used to the procedure: | 17:12 |
| bkuhn | start a fresh branch. | 17:12 |
| bkuhn | Add a test case that has a precision directive in it. | 17:12 |
| tgnit | ok | 17:13 |
| bkuhn | The test will fail, because no directive exists. | 17:13 |
| bkuhn | verify that test fails. | 17:13 |
| bkuhn | Add your first commit that just makes the directive. | 17:13 |
| bkuhn | Then, commit that, and see that the test now passes. | 17:13 |
| bkuhn | and you can modify that same test case as you add the next part of the feature. | 17:13 |
| bkuhn | so the initial test case probably is just on eline | 17:13 |
| bkuhn | "precision 2" | 17:13 |
| bkuhn | which fails by itself, because it's invalid directive. | 17:13 |
| bkuhn | then you bring in your commit that adds the precision directive | 17:14 |
| bkuhn | and then the test passes. | 17:14 |
| bkuhn | then modify the test again to add something that your current change solves with regard to precision. | 17:14 |
| bkuhn | it should fail, because you haven't added the code | 17:14 |
| bkuhn | then bring in the code. | 17:14 |
| bkuhn | tgnit: does that procedure make sense? | 17:14 |
| tgnit | yes test driven development? | 17:15 |
| bkuhn | Basically, yes. | 17:15 |
| bkuhn | It's not pure TDD. | 17:15 |
| bkuhn | TDD has a lot of stuff to it. | 17:15 |
| bkuhn | But this one procedure, which is taken from TDD, makes it much easier to do patch review. | 17:15 |
| bkuhn | Because you can see what the patch feature wants to do by looking at the tests. | 17:15 |
| bkuhn | I don't really go into programming fads (TDD, Extreme, pair programming, etc.)... but most of them have something to them that's useful. | 17:15 |
| tgnit | yes, i got it. | 17:16 |
| bkuhn | the TDD stuff is useful in that it focuses the work and makes the commit history clear as to what's trying to be done. | 17:16 |
| bkuhn | which is why I suggest it to you here. | 17:16 |
| bkuhn | So, go for that, and see how it goes. | 17:16 |
| bkuhn | No need to try to get it done today, I know it's getting late there. | 17:16 |
| bkuhn | But make that your top priority to reorganize the work so far in that way, and let me and tbm know when you have a result. | 17:16 |
| tgnit | bkuhn: sorry to mess things up. they should become clear from now on. | 17:16 |
| tgnit | absolutely | 17:17 |
| bkuhn | tgnit: nothing is messed up; you're learning, that's the point of this. :) | 17:17 |
| tgnit | ;) | 17:17 |
| *** mlncn has quit IRC | 17:37 | |
| *** mlncn has joined #npoacct | 17:49 | |
| *** mlncn has quit IRC | 18:05 | |
| *** mlncn has joined #npoacct | 18:33 | |
| *** mlncn has quit IRC | 18:42 | |
| *** mlncn has joined #npoacct | 18:43 | |
| *** mlncn has quit IRC | 19:30 | |
| *** mlncn has joined #npoacct | 20:16 | |
| *** bkuhn is now known as bkuhnIdle | 20:30 | |
| *** bkuhnIdle is now known as bkuhn | 21:42 | |
| *** jelmer has quit IRC | 21:43 | |
| *** jelmer has joined #npoacct | 21:43 | |
| *** mlncn has quit IRC | 22:44 | |
| *** jelmer_ has joined #npoacct | 22:48 | |
| *** jelmer has quit IRC | 22:52 | |
| *** mlncn has joined #npoacct | 23:07 | |
| *** mlncn has quit IRC | 23:29 | |
Generated by irclog2html.py 2.12.1 by Marius Gedminas - find it at mg.pov.lt!