Tuesday, 2014-06-17

*** mlncn has quit IRC00:03
*** bkuhn is now known as bkuhnIdle01:28
*** bkuhnIdle is now known as bkuhn02:16
*** tgnit has quit IRC03:17
*** mlncn has joined #npoacct03:30
*** tgnitidle has quit IRC03:30
*** mlncn has quit IRC03:40
*** mlncn has joined #npoacct03:50
*** tgnit has joined #npoacct03:50
*** mlncn has quit IRC04:11
*** paroneayea has quit IRC07:25
*** garrison has quit IRC08:05
*** tbm has quit IRC10:16
*** ChanServ has quit IRC10:16
*** scott_gonzalez has quit IRC10:17
*** tgnit has quit IRC10:17
*** mlinksva has quit IRC10:17
*** joar has quit IRC10:17
*** tgnit has joined #npoacct10:21
*** tbm has joined #npoacct10:21
*** mlinksva has joined #npoacct10:21
*** joar has joined #npoacct10:21
*** ChanServ has joined #npoacct10:21
*** scott_gonzalez has joined #npoacct10:21
*** dickson.freenode.net sets mode: +oo joar ChanServ10:21
*** nesciens has joined #npoacct12:49
*** mlncn has joined #npoacct13:39
*** mlncn has quit IRC13:56
*** mlncn has joined #npoacct14:24
*** bkuhn has joined #npoacct14:45
*** tgnitt has joined #npoacct15:31
tgnittyesterday we discussed earlier abount rounding problems in accounting,15:33
tgnittmany of which does not occur in ledger15:33
tgnittBut there are some desirable improvements that can be made, as described in the post on ledger-cli group by Martin https://groups.google.com/forum/#!topic/ledger-cli/EYhx03B4XqY/discussion15:34
tgnittIf an accountant truncates the totals of individual accounts and produces a different result.the ledger here will be off by few cents practically but as the statement grows, the difference  will grow too. ledger produces correct result but it is not the desired result.  The transactions were truncated before calculations whereas ledger rounds only the displayed results.  Also the rounding method usually adopted is the bankers roundin15:34
tgnittThere are two things that are needed. a. Control over reporting precision via command line or directive and b. Setting rounding mode or truncation mode for the amounts which are above the required display precision.15:35
bkuhnThat sounds interesting to me.15:35
tgnittThis is important because sometimes people adopt different practices to make financial statements and truncation is an important operation.15:35
bkuhntbm: does this fit with what we were talking about  yesterday?15:35
tgnittAs I have already mentioned that ledger does not have many of the rounding problems, truncation knowingly introduce to truncation error to match other financial statements. Ledger is a multi-purpose accounting program so it probably does not focus financial accounting needs alone.15:35
tgnittfirst step should be to take control of display precision. The displayed amounts must be increased or decreased to desired precision irrespective of how the amounts were written in journals. By providing a command line option we will ensure that default behavior of ledger does not change. When this option is used it should use correct rounding to adjust the amount like it does now.15:36
tgnittCurrently provided directive to format reporting of a commodity does not overrule display amount and the higher precision of the two is adopted. A new directive can be added here to.15:37
tgnitt With this switch we can provide a rounding mode switch but this is a difficult one. It may require significant changes but a lighter option is to add a filter to truncate or use a custom rounding mode. This filter will be applied prior to calculations uniformly to the posts. But this may violates the principle of balancing the transaction and corner cases need to be discussed.15:37
bkuhnThis makes sense to me, but I'm curious tbm's view too. :)15:37
tgnittbkuhn: me too .15:37
bkuhnHe may not be online yet.15:37
bkuhnI expect he'll be here soon.15:37
tbmI'm not sure why D should reduce the precision you see.  Is there a use case for this?15:38
bkuhnand he's here (!)15:38
tbmI can see an argument for D increasing the precision (as it does now), but I'm not sure about reducing it15:38
tgnittI had seen it earlier , suppose you have amounts reporting upto 8 decimal places but as a standard you want to calculate to two decimal places.15:39
bkuhntbm: I think I'm ok with it, but it may introduce regressions for some people.  We should discuss it on the ledger-cli mailing list before proposing an actual change.15:40
tgnittreport the results with two decimal places.15:40
bkuhnThe documentation for D says nothing about rounding, FWIW.15:40
tbmD is just about _display_ precision.  It's not about rounding15:40
bkuhnBut, tbm, the problem is that display precision is "the precision" for most purposes.  That's what the reports use15:41
tbmI think in this example, they should specify rounding to 2 decimals15:41
tgnittI know current ly rounding is not controlled by any option.15:41
bkuhnBut I may be biased by my personal use cases: I never end up showing our auditors the raw ledger data: just the reports15:41
tbmwhy not start with the thing that everyone seems to agree on: some directive for the "commodity directive"15:41
tbmso you can say something like15:41
tbmcommodity USD15:41
tbm  precision 215:42
tbmor whatever15:42
tbmlet's try to solve the problem in https://groups.google.com/forum/#!topic/ledger-cli/EYhx03B4XqY/discussion15:43
tbmsince that's an easy one15:43
tbm2012-01-01 *15:43
tbm   A                        1 AAA @@ 10.00 EUR15:43
tbm   A                        1 BBB @@ 20.00 EUR15:43
tbm   C15:43
tbmP 2012-07-01 AAA 10.123 EUR15:43
tbmP 2012-07-01 BBB 20.123 EUR15:43
tbmso ledger will do: 10.123 + 20.123 = 30.24615:44
tbmand since D is 1000.00 EUR, it will show 30.2515:44
tbmwhereas I want 30.2415:44
tbmif we had something like15:44
tbmcommodity EUR15:44
tbm  precision 215:44
tbmledger should do:15:45
tbm1 AAA is 10.123 EUR == 10.12 EUR15:45
tbm1 BBB is 20.123 EUR == 20.12 EUR15:45
tbmand the result is 30.24 EUR15:45
tbmthe commodity directive can be added in textual.cc: see instance_t::commodity_directive15:45
tbmand johnw mentioned some filter tgnitt could implement.  Do you know how?15:46
tgnitttbm: should not this directive try to solve the current problem. According to documentation , ledger observes certain things such as amounts to set display precisioin. Results are rounded according to this precision. D directive also increases this precision and there is no command line option to do this.15:46
tgnitttbm: let us consider display precision and rounding problem separately for a minute.15:47
tbmtgnitt: what I'm talking about is rounding, right?15:47
*** paroneayea has joined #npoacct15:48
tgnittsupppose we add a directive which forcefully set this display precision. Then after this default thing what ledger do is correct rounding.15:48
tbmby default, ledger keeps all precision, and I don't want that.  I want it to round to 2 digits all the time.15:48
tgnitttbm: this is what the second part of the function.15:49
tgnitttbm: johnw said the without changing the overall structure of ledger for this, a filter should be added so that it truncates or round according to the set precision before calculations.15:50
tgnittIf you want ledger should not store this, it will mean it should not use the rational number representation15:51
tgnittwhich is a strong point of ledger.15:51
bkuhntbm: why do you think we *need* ledger to round/truncate after each calculation?15:53
tgnittNow what if we add a filter? if we knowingly round or truncate each amount it will add some truncation or rounding error which I want to find out,15:53
bkuhntgnitt: I am not sure I understood that last point.15:53
bkuhn(the part about "if we knowingly round .. want to find out"15:53
tgnittI am looking for an example to know whether it can affect balancing of transaction if we round or truncate before calculations.15:55
bkuhnah, I see.15:55
bkuhntbm: you and I were talking about the balancing issue yesterday.15:55
tbmbkuhn: well, because this is how it's done in real world15:55
tbmbkuhn: when do you get half a cent?  it's always rounded15:55
bkuhntbm: well, banks do that.15:56
bkuhnI agree.15:56
* bkuhn starts wondering if we need different rounding rules for the type of account. :)15:56
tbmbkuhn: that's what johnw suggested.  A directive based on commodity, but also for accounts15:56
tbmI'm not sure we need the latter but maybe there's a use case15:57
tgnitttbm: does broker or accountants truncate before calculations ?15:57
bkuhnI suspect we don't actually KNOW the answer to that.15:57
bkuhnIn fact, I suspect accountants just don't worry about it.15:57
bkuhnMy discussions with them is that they just don't care about rounding because it's "immaterial"15:57
tbmwell, let's take my example above15:57
tbmyou have 1 AAA and:15:57
tbmP 2012-07-01 AAA 10.123 EUR15:57
tbmI doubt anyone would say this is worth 10.123 EUR15:58
tbmI'm prety sure most people would say it's worth 10.12 EUR15:58
tbmso I'd like ledger to truncate/round to 2 digits15:58
bkuhnOk, so I'm not grokking this.15:58
bkuhnAre you saying that when you buy a bunch of AAA in succession15:59
bkuhnyou want each one worth 10.12, not 10.123?15:59
tbmre tgnitt: "If you want ledger should not store this, it will mean it should not use the rational number representation"15:59
tbmno, the way ledger stores things internally is fine15:59
bkuhnSo, then I'm missing something you're trying to say. :)15:59
tbmbut when it sees P 2012-07-01 AAA 10.123 EUR and I specify rounding 2, it should round/truncate before storing15:59
bkuhnI apologize if I'm being dense.15:59
tbmbkuhn: no16:00
bkuhnoh, hm, I think I'm starting to understand what you're saying, tbm.16:00
* bkuhn considers whether this is a good idea.16:00
tbmyou have to differentiate between the exchange rate specified with P16:00
tbmthat should have whatever precision it has16:00
tbmif I have 1 AAA and the pricedb says that 1 AAA == 10.123 EUR16:00
tgnitttbm: I want to know what if you 1000 AAA @ 10.123  EUR ? do you calculate it @10.12 EUR or round after it?16:01
tbmthen how much is it worth?16:01
tbmwell, it's only worth 10.12 EUR because I cannot have 0.003 EUR16:01
tbmso at this point ledger should round/truncate16:01
tbmbut of course, if I have 2 AAA at 10.123 EUR, then it should be 20.25 and not 20.2416:01
tbm2 * 10.123 = 20.24616:01
tbmrounded 2 precisions => 20.2516:01
bkuhntbm: Actually, I think the root of your point is regarding mixing extra precision between commodity.16:02
tbm1000 AAA you'd have 10123.0016:02
bkuhnThat's why it bothers you.16:02
tbmbkuhn: no16:02
bkuhnare you sure.16:02
tbmbkuhn: shares can have lots of precision16:02
tgnitttbm: what you are saying is achievable by adding a filter , the point is that we should add a command line option as well as directive for this.16:02
tbmbut in real life, when you buy/sell something, it's rounded to 2 digits16:02
tbmsame with your currency rates, btw16:02
bkuhnoh, ok.16:02
bkuhnI'm starting to get what you are saying.16:03
tbmbkuhn: let me take an example16:03
bkuhn(but keep going, I'm slowly getting there)16:03
tbmfrom conservancy ledger:16:03
tbm    Accrued:Accounts Receivable:Conservancy    €23.43 {=$1.3639}16:03
tbmso the eur to $ exchange rate is 1.363916:03
tbmbut what does that mean in practice?16:03
tbmwhen you have 1 EUR, how many $ will you get?16:03
tbmyou won't get $1.363916:03
tbmyou'll get $1.3616:04
bkuhntgnitt: I probably agree with you, *but* we also have to able to explain WHY we're adding this filter -- which is why I'm digging deep here to understand tbm.16:04
tbmhowever, if you have 1000 EUR, the precision of the exchange rte matters: 1000 * 1.3639 = 1363.9016:04
bkuhntbm: Ok, you've convinced me.16:04
tbmso there's a good argumnt for pricedb entries to be very precise16:04
tbmbut once we convert some value to another value, we have to round16:04
tbmso, back to the example:16:05
tbmif I have 1 EUR and the exchange rate is 1.3639, I do NOT want ledger to store 1.3639 internally - it should just round/truncate and store 1.3616:05
bkuhnYeah, this goes back to my thinking of types of accounts.16:05
tbmdo even if I set display_precision  D $1000.0000, I still want to see $1.3600016:06
bkuhntbm: If I just accrued a bunch of stuff...16:06
tbmand not $1.363916:06
tgnitttbm: so you want this post calculations , right ?16:06
bkuhn.... I want to accruals to propagate the precision.16:06
tbmtgnitt: yes16:06
tgnittbkuhn:  me too trying to get his point .16:06
bkuhntbm: but, you mean post calculations per transaction.16:06
bkuhnbecause once you balance the transaction, you want rounding propagated forward.16:06
tbmbkuhn: no, you don't want to propagate the precision.16:06
tbmif I understand correctly16:07
bkuhner, rather let me state that better16:07
bkuhnIn a given transaction, we finish calculations with all appropriate precision .16:07
bkuhnThen, do rounding on both sides at the end when we're sure it balances.16:07
bkuhntbm: is that what you're suggesting?16:07
bkuhnIf so, my worry about that is this:16:08
bkuhnFor bank accounts, sure.16:08
bkuhnI expect the rounding, that's what the bank will do and I want the transaction to match the statement number16:08
tgnitttbm: lets say after calculations , you first convert to floating point in accordance with the displayed amount. Round it and convert it back to rational . To do per calculation?16:08
bkuhnBut, if I am accruing a bunch of money in EUR for someone.16:08
bkuhnI actually want the precision propagated across their transactions.16:08
bkuhntbm: because, to use my example from Conservancy's  ledger:16:09
tgnitttbm: and the price remains same  without rounding , only the amounts are changed.16:09
bkuhnSomeone goes on a trip to Europe from the USA16:09
bkuhnthey spend a bunch of EUR at different USD rates16:09
bkuhnI want to know how much it really cost us over the group of transactions in currency conversion costs16:09
bkuhnI don't want it rounded each time16:09
tbmbkuhn: yeah, I think this is something I disagree with but go on16:09
bkuhnbut when I get to the point where I pay them back, I would want what you suggest, because the final amount is done.16:10
bkuhn... and it's on the bank statement16:10
bkuhnso I want the transaction to balance properly AND match the bank statement16:10
bkuhnSo it's almost like I want to group transactions into a "super transactions"16:10
bkuhn"super transaction"  rather16:10
bkuhnthat gets rounded at the end of that group16:10
bkuhnI don't know if I actually need this.16:11
bkuhnBut I think I would work with your feature OFF if it were a "blunt instrument" and rounded after each transaction.16:11
bkuhntbm: did I miss something?16:11
bkuhn(I don't have an example handy, but it should be possible to construct one where we "miss" the true cost of all the currency conversions over many transactions because we rounded too early)16:11
bkuhnAm I making any sense?16:12
tbmyes.  Just thinking about it16:12
bkuhnAnyway , as a meta-issue:16:13
bkuhnI think we need to build that list we discussed of the rounding features we want.16:13
bkuhnand propose them to the mailing list ultimately (but maybe email them around between the three of us first)16:14
bkuhnWe're discussing in detail on particular rounding feature here.16:14
bkuhnbut there might be others.16:14
tbmyeah we need more use cases to think through this stuff16:14
bkuhntbm: are you still able to write that up for me and tgnitt to review?16:14
tbmin the meantime, I think tgnitt should look into adding a commodity directive to specify rounding and look into implementing that filter16:14
bkuhntgnitt: I agree with tbm: It's clear you'll need to know how to add that filter.16:15
tbmso bkuhn I have an example now16:15
bkuhnSo you might as well make a branch and start working with that, but don't send a merge request to ledger-cli upstream until we've finished the conversationa bout it.16:15
bkuhntgnitt: ^^16:15
tbmD $100.0016:15
tbm2014-06-15 Test 116:15
tbm    Liabilities:Payable                       €-19.86 {=$1.3869} @ $1.386916:15
tbm    Expenses16:15
tbm2014-06-16 Test 216:15
bkuhns/merge request/pull request/ :)  -- sorry, mixing my github and gitorious terminology.  ledger-cli is github. :)16:15
tbm    Liabilities:Payable                       €-19.86 {=$1.3869} @ $1.386916:15
tbm    Expenses16:16
tgnittbkuhn:  I will work on it, but  what I know works pre calculations, need to know how the system work  on per calculation basis.16:16
tbmbkuhn: so you're saying you want to keep precision16:16
bkuhntgnitt: and this is a coding task, so it should be easier you to roll through than writing stuff. ;)16:16
tbmif I ask you on 2014-06-15 how much you spent, you'll say $27.5416:16
tgnittbkuhn :)16:16
bkuhntbm: let me play with it on ledger for a minute16:17
tbmand if I ask you how much you spent on 2014-06-16, you'll again say $27.5416:17
tbmso you spent $27.54 twice16:17
tbmand 2 * $27.54 = $55.0816:17
tbmso we all agree16:17
tbmbut now I ask you: how much do you OWE16:17
tbmand now you're going to say: I owe $55.0916:18
tbmso you spent $55.08, but you owe $55.0916:18
tbmso where does this extra penny come from?16:18
tbmit was never an expensive16:18
bkuhnI see16:18
bkuhnthis is broken.16:18
tbmand then you say "oh, this is rounding, because I really spent $27.544"16:18
bkuhnYou've convinced me. :)16:18
bkuhnexamples help. :)16:18
bkuhnthis alone makes it confusing:16:19
bkuhnbirch:~$ ledger -V -f ~/tmp/y.ledger -e 2014/06/17 reg16:19
bkuhn2014-06-15 Test 1               Liabilities:Payable         $-27.54      $-27.5416:19
bkuhn                                Expenses                     $27.54            016:19
bkuhn2014-06-16 Test 2               Liabilities:Payable         $-27.54      $-27.5416:19
bkuhn                                Expenses                     $27.54            016:19
bkuhnbirch:~$ ledger -V -f ~/tmp/y.ledger -e 2014/06/17 bal16:19
bkuhn              $55.09  Expenses16:19
bkuhn             $-55.09  Liabilities:Payable16:19
bkuhn                   016:19
bkuhnthe reg and bal report have DIFFERENT results (!)16:19
bkuhnthat shouldn't happen.16:19
bkuhntgnitt: does that convince you?16:19
bkuhntbm: I suspect we have to leave the default behavior as is.16:20
tgnittbkuhn: I got his point , This is rounding per calculation with each amount.16:20
tbmok, I should do some real work, but I'll work on some use cases soon16:20
tbmbkuhn: yes, leave the default but add an option16:20
bkuhntgnitt: right, I got that early.  But I didn't understand why it mattered at first.16:20
bkuhnThis is why it matters:16:20
bkuhnbecause two reports don't line up.16:20
bkuhnbecause ledger is propagating the precision in one report (bal) but not in another (reg)16:21
bkuhntbm: I thought the reg report was doing an <Adjustment> entry in such cases... do you know when it does an Adjustment entry?16:21
tgnittbkuhn: My argument is that you will never be off by more than a dollar in current situation if it isn't material .16:21
bkuhntgnitt: well, I could easily see us being off a lot more than that in this situation: Imagine 1,000  of these transactions.16:22
tgnittbkuhn: but since we knowingly introduce rounding error, after lots of transactions it will16:22
tbmbkuhn: no, maybe this is a bug.  Because it's done with -X '$'16:22
tbmzsh: exit 25    ledger -f f reg ex -X '$'16:22
tbm66523:tbm@jirafa: ~] ledger -f f2 reg ex  -X '$'16:22
tbm2014-06-15 Test 1               Expenses                     $27.54       $27.5416:22
tbm2014-06-16 Test 2               <Adjustment>                  $0.01       $27.5516:22
bkuhntbm: maybe.16:23
bkuhntbm: maybe open a bug about this?16:23
tgnittbkuhn: how this is a bug? it is not the expected behavior of ledger right ?16:24
bkuhntbm: I'm using an older ledger, I don't get the adjustment at all.16:24
tbmbkuhn: I'll add it to my todo list16:24
bkuhntgnitt: I see why you're saying that.16:24
bkuhnand you're right, it sort of is expected.16:25
bkuhnThe problem is that it's a consequence of using the integer rationals and rounding at different times for different  reports.16:25
bkuhntgnitt: Ultimately, the reg report is rounding for each transaction, while the 'bal' report isn't.16:26
bkuhnSo, in some sense, the reg report is doing what tbm is suggesting.16:26
tgnittbkuhn: it does round before displaying remainder amount. also balances according to it, I think.16:27
bkuhnYeah, I think the behavior of ledger is ok.16:28
tbmbkuhn: it's always rounding to the display precision.  But in case of reg, it rounds down (24.544) whereas int he otehr case it rounds up (49.088)16:28
tbmyou can set D $100.000 to see what the real values are16:28
bkuhntbm: right, that's the point that convinced me you're right we need this feature.16:28
bkuhntgnitt: yeah, there may be no bug in ledger per se here... the behavior is just odd if one doesn't know what's going on in ledger's internals.16:29
bkuhnEverything looks right to me, because you and johnw have explained to me ledger's internals.16:29
bkuhnBut to the average user, they don't understand what is happening.16:29
bkuhnand the behavior might be wrong for their use case.16:29
bkuhnso I'm convinced that tbm's idea for the feature is one we should have. :)16:29
tbmso I want proper rounding, so it doesn't even store 24.544 - it should store 24.5416:29
tbmand when I do D $100.000 I want to see $24.54016:30
tbmand not $24.54416:30
bkuhntbm: Yup, I'm convinced this is a optional  feature we need. :)16:30
bkuhnAnd I think tgnitt's right that there is no bug here.16:30
tbmyes, no bug16:30
bkuhnjust a missing feature.16:30
bkuhntbm: so you're going to add this to the list of other rounding features and email it around to me and tgnitt?16:30
bkuhnand tgnitt, you can start looking into how to implement this one on your own branch on github?16:31
tbmbkuhn: what would you call the feture in the commodity directive?  precision?  what do you call it when you only want 2 digits of precision16:31
tgnitttbm: any explanation, why it does so with -X '$' ?16:31
tbmtgnitt: you mean generate the adjustment?  I don't know why it's generated with -X $ but not without16:31
bkuhn(I've got -X '$' and -V doing the same thing in the example)16:32
tbmsignificant figure?16:32
bkuhnoh, I see.16:32
bkuhnyou're right16:32
bkuhnthat part is a bug16:32
bkuhn$ ledger -f ~/tmp/y.ledger -e 2014/06/17 reg  exp16:32
bkuhn2014-06-15 Test 1               Expenses                     $27.54       $27.5416:32
bkuhn2014-06-16 Test 2               Expenses                     $27.54       $55.0916:32
bkuhnthe adjustment should be printed16:32
tgnitttbm:  I think rather than asking number of decimal places, we should keep it like D option , parse it from there .16:32
bkuhnI mean, the feature we're talking about is probably best called "round per transaction"16:33
bkuhnor something like that16:33
bkuhnhow we encode it with the 'C' directive is an interesting question, and I have no suggestions.16:33
tbmtgnitt: good point but I'm not sure.  D is about the display format, really16:34
tbmD $10,100.0016:34
tbmD $10100.0016:34
tgnittbkuhn: whatever we name this directive, but if we keep it to accept input in the way 'D' option works. it will be more familiar to the user. I also think we can reuse the parsing logic.16:34
tbmwill give different formats16:34
tbmwhereas we only care about how many digits after the comma16:35
tbmso I think something like "foo 2" makes more sense16:35
tgnitttbm: we will just focus on the precision. I think in both cases it is the same.16:35
tbmjust an integer specifying the precision16:35
tgnitttbm: at the same time accepting the input in the format of 'D'16:35
tgnitttbm: what should foo '0' means ?16:36
bkuhnOk, this is an UI detail, I'm going to defer to tbm.  I'm bad at UI. :)16:36
tbmtgnitt: actually, we need 016:36
tbmtgnitt: 0 means no rounding (the default behaviour)16:37
bkuhnmeanwhile, I'll open the bug regarding -X/_V and 'D' Adjustment thing16:37
tbmwell, maybe not "need" but it's useful16:37
bkuhntbm: you had the bug in current master, right?16:38
bkuhnI'm behind on the version I'm using.16:38
bkuhnI'll file it against 3.0.316:38
tgnitttbm: got it.16:39
tgnitttbm: can you tell me the difference between pre and post handlers?16:42
tgnittfilter we were talking about was a pre post handler.16:43
tbmtgnitt: I don't know, sorry16:44
bkuhnI submitted the bug http://bugs.ledger-cli.org/show_bug.cgi?id=105416:48
bkuhnmeanwhile, tgnitt , best place to answer that pre/post handler question is #ledger... others there might  know, even though johnw isn't around. :)16:48
tgnittbkuhn : right16:48
*** tgnit has quit IRC18:09
*** mlncn has quit IRC18:23
*** mlncn has joined #npoacct18:28
*** nesciens has quit IRC18:58
*** garrison has joined #npoacct19:32
*** bkuhn is now known as bkuhnIdle20:17
*** mlncn has quit IRC20:18
*** bkuhnIdle is now known as bkuhn21:13
*** mlncn has joined #npoacct21:18
*** mlncn has quit IRC21:22
*** bkuhn has quit IRC22:24
*** bkuhn has joined #npoacct22:36

Generated by irclog2html.py 2.12.1 by Marius Gedminas - find it at mg.pov.lt!