2007-04-05 GnuCash IRC logs
00:00:03 <nbinont> I might take a look at it - if I have a chance
00:00:30 <warlord> sure.
00:00:42 <hampton3> jsled: are you going to pull the -Wno-unused flag? I just finished a full compile without it.
00:01:44 *** benoitg has joined #gnucash
00:01:44 *** gncbot sets mode: +o benoitg
00:06:44 *** benoitg has quit IRC
00:25:02 *** nbinont has quit IRC
00:29:53 *** cortana has quit IRC
00:39:26 <dbr> ok unix gurus, how do I get rid of the first 500,000 lines in a text file without opening it? My debug file is 8.2GB and neither bbedit nor vim seems to like it. I can see about 766,000 lines in bbedit, but the time codes show I'm at least a minute from the end of the file.
00:40:45 <warlord> split?
00:41:41 <dbr> that would do. Do you mean I should 'man split'?
00:41:48 <warlord> yes
00:51:48 <dbr> hmm. split slows down after a while. the first five 100,000 line files were fast. It's out past a million lines and proceeding slowly.
00:52:33 <warlord> huh
00:53:47 <dbr> damn. should have timed it. getting from file xai to xaj took at least a couple minutes. but it's done now. wheeeeee.
00:55:51 <warlord> cool. there ya go.
00:55:59 <warlord> ok, i need to go to bed.
00:56:00 <warlord> good night
00:56:01 <dbr> well. the reason it slowed down is the lines got longer. The first 7 files were less than 10MB each. The ninth file is 4.05GB
00:56:09 <dbr> goodnight. thanks for the help
00:56:13 *** warlord is now known as warlord-afk
01:07:54 *** hampton3 has left #gnucash
01:13:51 <dbr> jsled: so the 'formatting hits' of which you spoke were the like 43,000 spaces inserted between * 00:27:08 DEBUG <gnc.gui> and [enter gnc-tree-model-price.c:gnc_tree_model_price_iter_next()]?
01:32:35 *** conrad has quit IRC
02:23:37 *** wrodrigues has joined #gnucash
02:36:37 <wrodrigues> -2
02:38:54 *** wrodrigues has quit IRC
02:38:58 *** wrodrigues has joined #gnucash
02:44:08 *** dbr has quit IRC
02:55:20 *** wrodrigues has quit IRC
03:19:02 *** RallyU has joined #gnucash
03:27:00 *** RallyU has quit IRC
03:43:20 *** ErKa has joined #gnucash
04:11:50 *** ceplma has joined #gnucash
04:19:10 *** goibhniu has joined #gnucash
04:30:12 *** conrad has joined #gnucash
04:30:12 *** gncbot sets mode: +o conrad
04:31:12 *** Ardonik has quit IRC
04:40:21 *** Ardonik has joined #gnucash
04:49:34 *** cortana has joined #gnucash
06:02:57 *** _gunni_ has joined #gnucash
06:40:49 *** warlord-afk is now known as warlord
06:54:37 *** Ardonik has quit IRC
07:01:46 *** Ardonik has joined #gnucash
07:17:59 *** ErKa has quit IRC
08:01:54 *** twunder has joined #gnucash
08:04:03 *** Ardonik has quit IRC
08:11:33 *** Ardonik has joined #gnucash
08:17:22 *** BlackBsd has joined #GnuCash
08:42:03 *** IanL has joined #gnucash
08:51:28 *** BlackBsd has quit IRC
09:04:50 *** ErKa has joined #gnucash
09:22:40 <jsled> gncbot: tell dbr, right; at debug-level, the ENTER and LEAVE macros do log, and they try to maintain indent.
09:22:40 <gncbot> jsled: The operation succeeded.
09:36:03 <warlord> jsled: but 43000 levels of recursion?
09:36:46 <warlord> That feels like a very long recursion... Perhaps something is recursing that really should iterate?
09:37:48 <jsled> no, it's probably un-balanced ENTER/LEAVE pairs incrementing the indent level.
09:37:52 <jsled> (without decrementing it)
09:39:07 <warlord> Ahh, that could be it, too.
09:39:29 <warlord> I guess we'd need to see the call trace to see what's imbalanced.
09:39:46 <warlord> Oh, and do YOU have any idea what "coding convensions" esodan is talking about?
09:40:27 <jsled> It's not too bad to just go through $(find . -name '*.c' |xargs grep "ENTER") and manually match up the "LEAVES" ... just horrendously tedious.
09:40:54 <jsled> I think g_return_{val_}if_fail(...) bite us in more than a few places.
09:41:17 <warlord> we really need a gnc_return_{,val_}if_fail() macro.
09:41:19 <jsled> Oh, probably that it's not gnc_account_[...] and there's no properties and ...
09:42:15 <warlord> Oh, but the functions I created _ARE_ gnc_account_[...]
09:42:16 <jsled> I created a gnc_leave_return{_val}_if_fail ... in qoflog.,h
09:42:23 <jsled> Oh, I didn't even look.
09:42:51 <jsled> I've never seen evidence that Daniel understands that it can be done in steps.
09:43:07 <jsled> Or that our conventions trump "gobject" conventions.
09:43:19 <warlord> see, eg, http://svn.gnucash.org/trac/changeset/15785
09:44:23 <warlord> Well, he does seem to talk the talk, even if he doesn't walk the walk..
09:44:33 *** Ardonik has quit IRC
09:45:22 *** ceplma has quit IRC
09:48:37 <warlord> when we talk about taking steps he agrees.. but the code he commits doesn't match what I thought we agreed to.
09:51:09 <warlord> anyways, hopefully you can take a look at my branch in the next couple days to make sure you think I'm on the right track..
09:51:20 <warlord> (hopefully you, hampton, and chris can all do so)
09:51:24 * jsled nods
09:52:10 *** Ardonik has joined #gnucash
09:56:58 *** ceplma has joined #gnucash
10:32:55 *** ceplma has quit IRC
10:46:43 *** ceplma has joined #gnucash
10:56:46 *** andi5 has joined #gnucash
10:56:46 *** gncbot sets mode: +o andi5
11:02:49 *** ceplma has quit IRC
11:14:08 *** ceplma has joined #gnucash
11:17:24 <andi5> warlord: did you play with google translator? ;-)
11:19:50 <warlord> No, why?
11:20:00 <warlord> (i did use babelfish for a few words)
11:24:11 <andi5> well, do me a favor and put it into a number... 0 for "i clicked on spanish, wrote my sentence and pressed translate!" to 10 for "i just needed to check what suffix to use pluperfect with" :-)
11:27:25 <warlord> 7
11:27:31 <warlord> why?
11:27:34 * hampton nods too
11:27:54 <andi5> out of curiosity, do not mind :)
11:30:44 <warlord> ok
11:31:00 <warlord> I figured I should try to get it across to him and there's clearly a language issue..
11:32:41 <jsled> I'm not sure there is.
11:40:15 <jsled> andi5: do you know/use libchipcard at all?
11:40:34 <jsled> in particular, do you know if libchipcard3 is suitable?
11:40:47 <andi5> know: yes, use: no .... suitable for what?
11:41:01 <jsled> aqbanking, I suppose.
11:41:08 <andi5> i think it builds fine, iirc
11:41:13 <jsled> (gentoo's looking to move from v2 to v3)
11:41:19 * chris laughs out loud at andi5's 0..10 question.
11:43:34 <andi5> jsled: http://www.libchipcard.de says Stable: 3.0.2 ... i think it is sane to build it ; but i do not use it, you know
11:44:13 * jsled nods.
11:44:21 *** ErKa has quit IRC
11:50:20 *** IanL has quit IRC
11:58:44 *** ceplma has quit IRC
11:59:47 *** ceplma has joined #gnucash
12:08:46 *** ErKa has joined #gnucash
12:13:54 <jsled> <andi5> jsled: i sill wonder whether you will do me a favor and make monday the first weekday in the sxed :-)
12:13:55 <jsled> done. :)
12:14:20 <andi5> jsled: yeeehaw :) thanksomaniac... will test it soon
12:17:37 *** ceplma has quit IRC
12:30:48 <andi5> warlord: has nbinont emailed you for an sf dev account / upload rights already?
12:31:27 <warlord> andi5: yep
12:31:34 <warlord> that's already been handled.
12:31:43 <andi5> great!
12:32:02 <warlord> :)
13:38:48 <andi5> [ot] fc6 has 2.0.5, but ubuntu feisty does not... *grrr*
13:39:53 <warlord> well, fc didn't go to a development release of gtkhtml and NOT NOTICE.
13:41:09 <andi5> oh, using development releases seems to be part of the plan
13:41:21 <jsled> I think they noticed ... as per the comments on that bug, they intentionally track the development releases of libs during their development series.
13:42:00 <jsled> I think fault continues to lie with the gtkhtml folks.
13:45:28 <andi5> juhu... mo di mi do fr sa so ... even on windows :)
13:46:51 <warlord> yay
14:00:01 <andi5> hampton: after you have fixed the price editor, i think there is still a problem with the tree view in the commodities dialog... i just want to let you know :) ....
14:00:31 <hampton> just fixed that two days ago
14:02:55 <andi5> oh... now i see you touched gnc-tree-model-commodity.c .... here is a quick test: open gnucash --nofile , open security editor, click a few times "show national currencies" and watch the triangle go away :)
14:05:11 <hampton> lovely. the GtkTreeFilter code strikes again.
14:05:18 <hampton> I'll look at it.
14:05:22 <andi5> thanks
14:14:33 <warlord> hampton: if you get the chance could you view the branches/gobject-engine-dev-warlord branch changes?
14:14:48 <hampton> planning to do that tonight
14:16:04 <warlord> Thanks.
14:42:42 *** pimienta has joined #gnucash
14:44:52 *** |gunni| has joined #gnucash
14:44:52 <warlord> Is there any reason we're talkin OTR?
14:44:58 <jsled> no...
14:45:20 <jsled> I've been waiting until we get our student allocation to figure out who's going to mentor whom, but I guess the "willing to mentor" is reverseable, &c.
14:45:22 <chris> ok
14:46:05 <chris> you don't think the student allocation is influenced by many mentors have volunteered?
14:46:44 <chris> s/by many/by how many/
14:47:07 <jsled> Not by my reading of the FAQ ... but frankly this business is a bit too opaque for my tastes.
14:49:06 <aj> fwiw, i've seen some suggestion that allocations will be influenced by number of apps that have mentors already assigned, and how many projects the orgs have asked for
14:49:21 <aj> but they seem to be in the final phases of getting a number out now anyway
14:50:30 <aj> (for debian, we've got a bunch clicked willing to mentor, and have tentatively assigned mentors to the projects we'd like to see accepted, we'll presumably get less slots than that though)
14:50:33 *** pepe__ has quit IRC
14:50:37 <warlord> Well, I put down '10' for the org.
14:51:02 <warlord> I guess I'd be willing to mentor Dogtail.. But I dont /know/ dogtail.. So I couldn't really help much on that side of things.
14:53:42 <aj> have you seen the read-bean wiki? www.read-bean.com/ospowiki -- the MentoringBestPractices page might be a good start fwiw...
14:53:43 *** _gunni_ has quit IRC
14:54:04 *** twunder has quit IRC
14:54:43 *** twunder has joined #gnucash
14:54:45 <warlord> no, i have not...
14:55:41 <aj> err, red-bean, sorry
14:58:05 <warlord> heh
15:03:06 *** benoitg has joined #gnucash
15:03:06 *** gncbot sets mode: +o benoitg
15:04:22 *** dbr has joined #gnucash
15:05:01 <andi5> jsled: WRT unbalanced enter/leave -> http://pastebin.ca/raw/425824 .... i simply started and quitted gnucash
15:06:21 <jsled> andi5: Oh... is that from $awk'ing the log output, or...?
15:06:37 *** benoitg has left #gnucash
15:07:17 <andi5> jsled: http://pastebin.ca/raw/425828 .... slow, but works
15:08:15 <andi5> sorry, http://pastebin.ca/raw/425829
15:09:12 <warlord> interesting.
15:09:37 <andi5> i guess i should install python again
15:26:44 *** jvik has joined #gnucash
15:27:12 <dbr> Is the script output more useful than my potentially clipping out the point in my logs where indenting went nuts?
15:27:50 <dbr> about half of my million lines of output were fine, and then the log went nuts.
15:28:14 <dbr> stripping space runs took the log from 8.8GB to 123MB
15:29:44 <jvik> Hi. Can anyone tell me how to split a transaction in a liability->credit card account? Or do I have to enter each item from a CC purchase seperately with an additional tax expense?
15:30:09 <andi5> dbr: i am working on a little python script right now, it should be a lot faster than the (other) hackery above :)
15:31:14 <dbr> jvik: I just enter things in CC accounts essentially the same way I do in checking accounts. Just keep adding splits until the transaction covers all the events
15:31:29 <dbr> and balances...
15:32:56 <warlord> jvik: it's just like entering a split transaction in any other account. See the docs.
15:33:13 <dbr> andi5: sounds good. I can't get to my logs right now anyway :) I can use either of the scripts/hacks when I get home tonight.
15:35:07 <jvik> dbr, that's what I was trying to do. I'm a bit new to this double entry thing, not sure in this instance what balancing should come to.
15:35:49 <jvik> dbr, In the split trans example (itemized from a paycheck) the splits are balanced by a transfer
15:35:55 <jvik> from an income account.
15:36:09 <warlord> jvik: the sum of the debis must equal the sum of the credits.
15:36:23 <dbr> jvik: since gnucash balances everything for you, having a transaction balanced means that gnucash doesn't have an extra split at the bottom for the otherwise unbalanced portion
15:36:42 <jvik> dbr, I would think I would want these splits balanced by a transfer from checking?
15:36:52 <jsled> jvik: Expense:[...] probably.
15:37:01 <jsled> Unless it's a CC payment.
15:37:16 <jvik> From expense to CC?
15:37:23 <jsled> In which case it'd be a {Assets:Checking, Liabilities:CC} transcation
15:37:32 <jsled> Right. you're buying stuff using the CC?
15:37:45 <jvik> Yes.
15:37:48 <jsled> Expenses.
15:38:43 <jvik> Ah. So then there would be eventual transactions from checking to expense accounts?
15:38:54 <dbr> no checking to CC
15:39:07 <dbr> er, "no, checking to CC"
15:39:16 <warlord> It's CC->Expense(s).. And then later Checking->CC
15:40:12 <jvik> I'm going to try again
15:42:09 *** sjc has joined #gnucash
15:47:07 <andi5> jsled, dbr: http://pastebin.ca/425888 ... it even has a bit of new info -> http://pastebin.ca/raw/425890
15:48:00 <jsled> awesome.
15:48:36 <jvik> Ok, so I enter a split trans in the CC account, 2 entries to expense accounts, for 20 and 40
15:49:08 <jvik> gnucash adds an additional trans: imbalance for $60
15:49:58 <warlord> jvik: then you didn't balance it yourself.
15:50:07 <jsled> Right. You should change that from Imbalance to the CC account you're in the register of.
15:50:55 <jsled> (or another account and watch the transaction disappear from the register when you enter it, but that's generally weird)
15:51:25 <jsled> (though useful if you're most-of-the-way-done-entering a transaction in the wrong register....)
15:53:09 <hampton> Can't someone just fix wino-doze so it doesn't choke on printing a null string? :-(
15:53:55 <jvik> Now I've ended up with one split line in the increase column for $40, one for $20
15:54:12 <hampton> This never-ending stream of workarounds for what should just be a single line fix in a library is just sad.
15:54:19 <jvik> Another split line with $60 in the decrease column
15:55:04 <jvik> And when the trans is saved it shows $20 on the increase line and the balance goes up $20
15:55:08 <warlord> hampton: it's not just windows. Solaris will die on printing a null string, too.
15:55:34 <warlord> jvik: you need to manually remove the "Imbalance-USD" split.
15:56:11 <hampton> OK. But how hard is it to fix a single line in the libc print function, as opposed to every single application having to police every single call to printf? :-(
15:56:40 <warlord> well, there IS that..
15:56:45 <warlord> but it's not just windows.
15:57:06 <warlord> (i'm surprised the g_printf routines dont check it)
15:57:34 <jsled> We don't use g_printf.
15:57:47 <dbr> andi5: thanks. I'll turn it loose on my log in a couple hours.
15:58:03 <andi5> ok
15:58:05 <jsled> It's fprintf we call.
15:58:19 <jvik> I delete the imbalance item, save it, and the imbalance just re-appears
15:58:37 <warlord> jvik: that's because you didn't manually balance the transaction.
15:59:09 <jvik> The transaction or the line item?
15:59:32 <jsled> (hmm... g_log might call g_printf, actually. We get the message already interpolated.)
15:59:36 <jsled> the whole transaction.
15:59:36 <warlord> the transaction. All the line items have to sum to 0. (or.. the left-hand items and the right-hand items have to sum to the same amount)
15:59:57 <warlord> jsled: well, regardless... whatever g_log calls, it should get fixed THERE.
16:00:04 <hampton> hmm, time for "sed -e '/printf/g_printf/g'" ?
16:00:22 <warlord> hampton: I dont think that'll help.
16:00:32 <warlord> I think the g_printf routines are similarly broken..
16:01:01 <warlord> But perhaps we want an audit of everywhere we find %s
16:01:21 <hampton> Well, glog() ends up in lib/libqof/qof/qoflog.c:log4glib_handler() which uses fprintf.
16:01:56 <hampton> I don't know what happens to the original parameters before it gets to that function.
16:02:27 <dbr> hasn't andi5 been mostly forced into policing %s?
16:02:33 <dbr> for windows
16:02:33 <jvik> jsled, ok, then the CC balance doesn't change and when I pay the CC bill and transfer money
16:02:38 <jvik> to the CC account?
16:02:59 <dbr> CC balance should be changing by $60
16:03:11 <hampton> dbr: yes. his last fix what sparked my complaint
16:03:17 <jsled> Sure it does.
16:03:23 <hampton> not that he fixed it, but that he had to fix it.
16:03:25 <andi5> dbr: i guess we can test it by running gnucash with --log gnc=debug --log qof=debug --logto /dev/null (from within msys)
16:04:24 <warlord> jvik: Have you read the GnuCash Concepts and Tutorial Guide?
16:04:55 <jsled> http://www.gnucash.org/docs/v2.0/C/gnucash-guide/cc-enterpay1.html
16:05:06 <warlord> or http://cvs.gnucash.org/docs/guide/txns-registers1.html#txns-registers-multiaccount2
16:09:23 <dbr> andi5: somewhere other than /dev/null though, right?
16:09:37 <jvik> warlord, Yes, actually I have, and worked through the examples. There isn't an example
16:09:46 <jvik> of a split CC transaction, though.
16:09:58 <jsled> jvik: it works exactly the same as any other.
16:10:47 <jsled> When you buy stuff using a Credit Card, you balance against Expenses.
16:11:29 <jsled> I'm not quite sure why it's only going up $20 if you have a total of $60 in the column; maybe you can post a screen-cap?
16:11:37 <dbr> jvik: the column headings for amounts in a CC register are "payment" and "charge" (I think). You'll be charging the CC and paying the expenses when you make a purchase with a CC
16:11:46 <warlord> jvik: a CC split transaction is just like every other split transaction.
16:12:19 <andi5> dbr: /dev/null should be fine, i will test it right soon.... another alternative is to log to stderr and use `exetype gnucash-bin windows" (or so) to mute gnucash (may be unnecessary, depending on the default subsystem used, i guess windows)
16:12:35 <jvik> dbr, my headings are Tot Decrease (left col) and Tot Increase (right col) and Balance
16:12:50 <warlord> jvik: move down to a different line.
16:13:35 <jvik> Right. Decrease (left) Increase (right)
16:13:54 <andi5> dbr: yep, crashes with /dev/null.... you can use that file only from within msys, of course
16:14:02 <warlord> Right. So your CC is on the right, and the expenses on the left.. and the column sums should match.
16:14:18 <jsled> jvik: what register view are you in?
16:14:59 <jvik> jsled, Basic ledger
16:15:10 <jsled> With the Split toolbar button pressed, presumablye?
16:15:26 <jvik> Yes, when splitting a trans
16:16:23 <jvik> Then the columns are tot decrease and tod increase
16:17:27 <jvik> I've probably got a basic confusion going, but what?
16:17:37 <jsled> a screen cap would help.
16:17:38 <warlord> jvik: ignore the column labels.
16:18:05 <jvik> On a simple cc trans I enter the amt in the right column and the balance goes up that much
16:18:39 *** dbr is now known as dbr-afk
16:18:45 <jvik> I'd think on a split trans I'd enter the amts in the right column and the balance would go up the total amount
16:18:58 <warlord> jvik: no......
16:19:07 <jvik> ah?
16:19:13 <warlord> you would enter the CC split on the right side, and all the expenses on the left.
16:20:03 <jvik> The CC split being what - the total charge to the credit card?
16:20:08 <warlord> Of course
16:20:54 <jvik> Ahh. Being equivalent to the transfer from Income in the paycheck example
16:21:03 <warlord> EXACTLY!
16:21:22 <warlord> Like we said, it's exactly the same, only the accounts are different.
16:21:45 <jvik> Everybody, I really appreciate the help.
16:22:11 <jvik> I've now figured out what "only the accounts are different" comes to :-)
16:24:53 <warlord> good
16:35:39 *** twunder has quit IRC
16:41:25 *** lasindi_ has joined #gnucash
16:41:25 *** lasindi has quit IRC
16:45:01 <andi5> hm... i am thinking about changing some stuff in gnc-date.c .... does someone (jsled?) have special desires / comments? :) ... i am open to anything
16:45:26 <jsled> Remove it and replace its callers with g_date_... ?
16:45:26 <jsled> :)
16:46:22 <chris> And why doesn't GnuCash handle stardates? :?
16:47:00 <jsled> andi5: what are you thinking of? and why me?
16:47:26 <andi5> jsled: because you recently hacked sxes and might have some strong opinion :)
16:48:15 <andi5> well, i strongly dislike the buffer handling of strftime and friends, ... i also wonder whether we need all these functions in gnc-date.c, and whether we need it *there*
16:49:10 <andi5> i wondered about gnc_print_date, ... it seems not only to be not thread-safe, but also pretty dangerous (overwrites buffer on next call)
16:49:58 <jsled> certainly static-buffer removal is a good thing.
16:50:07 <jsled> I'm sure many of those special-case functions are still used.
16:50:44 <jsled> Maybe not. Maybe some {cscope-find-functions-calling-this-function}'s would help pare it down.
16:52:28 *** jvik has left #gnucash
16:55:32 <warlord> Eh, gnucash isn't thread-safe anyways
16:55:39 <andi5> ok, i will try to make small steps and will see where they will bring me
17:12:57 <warlord> Ok.
17:27:54 *** andi5 has left #gnucash
17:42:29 <warlord> Hmm... test-lots fail in "make check" in trunk now.
18:04:23 *** andi5 has joined #gnucash
18:04:24 *** gncbot sets mode: +o andi5
18:07:48 <warlord> andi5: did you make any changes that might've caused test-lots to start failing in a PERR() log?
18:08:29 <jsled> The thing I'm thinking of is r15791
18:09:04 <jsled> Though looking at it again, that doesn't make much sense.
18:09:24 <warlord> No, that doesn't make sense...
18:10:17 <warlord> I think the last full check I did was at 15770...
18:10:32 <warlord> (and I'm fairly sure it worked then)
18:17:22 *** dbr-afk is now known as dbr
18:17:30 <warlord> off for a while
18:17:31 <andi5> why does not that make sense? 15770 < 15791
18:17:40 *** dbr has quit IRC
18:17:59 <andi5> and: not that i know of
18:18:31 <warlord> andi5: that changset doesn't make sense as the culprit..
18:18:36 *** warlord is now known as warlord-afk
18:23:24 *** hampto1 has joined #gnucash
18:23:24 *** gncbot sets mode: +o hampto1
18:25:24 *** ian has joined #gnucash
18:26:43 <ian> hi all! Is there any way yet to to preprocess the strings received by online actions (aqbanking)?
18:27:33 <ian> This would help finding matches during import and would make the description much more readable.
18:28:29 <jsled> I don't believe there is such a mechanism, but I'm not all that familiar with aqbanking. ("yet"?)
18:30:07 <ian> Also, some programmable import rules would be nice.
18:35:51 <jsled> so would a pony.
18:35:54 <jsled> :)
18:41:36 *** IanN has joined #gnucash
18:42:27 <IanN> is there any way of adding new currencies to GnuCash?
18:44:04 <jsled> IanN: IIRC by editing src/engine/iso-4217-currencies.scm and rebuilding.
18:44:20 <jsled> I don't believe there's a way to do so at runtime.
18:45:21 <IanN> bah, I just want a currency for my supermarket club points system
18:46:04 <jsled> Does a non-currency commodity work?
18:47:13 <jsled> (Hmmm ... is there a (recent) bug about this?)
18:49:36 * IanN goes to look at non-currency commodities
18:50:25 *** ErKa has quit IRC
18:53:07 *** dbr has joined #gnucash
18:55:58 <dbr> two biggies and a few stray small offenders http://www.pastebin.ca/426154 from my logs
19:08:26 *** BlackBsd has joined #GnuCash
19:08:27 <IanN> jsled: does not seem to let you set a non-currency to an account
19:08:53 <hampto1> you have to change the account type from bank to stock or mutual fund
19:13:33 <hampto1> dbr: I'll commit something shortly
19:16:15 <IanN> hampto1: ah, thanks
19:16:50 <IanN> right, is it a known bug that edit exchange rate only works from one side of the transaction?
19:17:12 <dbr> hampto1: while your here, can you think of any reason finance::quote would fail while being run not-from-a-terminal, but succeed when run from a terminal window on a mac?
19:18:18 <dbr> that's what led me into the logging fray in the first place, and I still don't see any indication in gnucash logs of a problem there
19:21:38 <hampto1> IanN: doesn't sound familiar. did you check bugzilla?
19:22:02 <hampto1> dbr: Path?
19:22:41 <IanN> hampto1: no, not a show stopper for me, just got to remember to do it on the currency side
19:22:51 <hampto1> f::q doesn't know or care that the terminal is there.
19:22:58 <dbr> hampto1: I'll try that, but some folks have reported that even if the source the init.sh file with the non-terminal version, the error still appears. I'll dig some more.
19:23:30 <dbr> gnucash does find f::q, even if though it fails at retrieving quotes.
19:23:52 <hampto1> I was wondering if f::q is failing to find something.
19:23:54 <IanN> hmmm, it's fun trying to convert from MS Money (spsh)
19:24:17 <hampto1> have you tried taking gnucash out of the equation by using gnc-fq-dump?
19:24:28 <dbr> is f::q gdb-able in a similar way to gnucash?
19:24:59 <dbr> not yet, but that's from a terminal anyway...
19:25:00 <hampto1> perl has a debugger, but I don't remember how to use it
19:25:09 <IanN> does gnucash have a forecast cash flow report?
19:27:21 <hampto1> I think the existing cash flow report is actual, not forecast. There's a budget report, but I'm not sure that's what you want.
19:27:42 <IanN> does gnucash have a concept of closed accounts (i.e. accounts no longer in use but not wanted deleted)
19:28:26 <hampto1> you can mark accounts in gnucash as placeholder accounts and it won't let you add/change transaction.
19:29:04 <IanN> no budget report is not what I need, I need to see what effects future scheduled transactions will have on the balance of various accounts
19:30:24 <IanN> hmmm, I suppose setting as placeholder and hidden would do the equivalent of marking as closed
19:31:58 *** dbr is now known as dbr-afk
19:32:39 <IanN> is http://bugzilla.gnome.org the correct address?
19:32:52 <jsled> yes.
19:33:04 <IanN> oops, i think it's broken then
19:33:07 <jsled> (though it appears that it's still down....)
19:33:27 <jsled> they're the the midst of system upgrades this week.
19:34:15 <IanN> oh well I will have to try and remember all my "enhancement" requests ;-)
19:35:02 <IanN> though most are just stealing features that are available in MS Money which might be useful
19:36:01 <IanN> i never realised I had 100+ accounts in MS Money :-S
20:16:23 *** IanN has left #gnucash
20:19:36 <hampto1> dbr: r15829 balances ENTER/LEAVE on the worst calls in your pastebin
20:28:04 *** andi5 has left #gnucash
20:52:14 *** lasindi_ has quit IRC
20:52:24 *** lasindi has joined #gnucash
21:11:10 *** lasindi_ has joined #gnucash
21:11:10 *** lasindi has quit IRC
21:16:44 *** |gunni| has quit IRC
21:21:57 <jsled> right. flyspell-prog-mode is nifty
21:22:27 <jsled> (add-hook 'c-mode-hook '(lambda () (flyspell-prog-mode)))
21:23:14 <jsled> It's funny how in the last year everything has started to do realtime spell checking. x-chat, emacs, evolution, firefox.
21:28:02 <jsled> Maybe, it's funny how that's *only* happened in the last year.
21:31:59 *** sjc has quit IRC
22:14:36 *** cgibreak has joined #gnucash
22:15:07 <cgibreak> Hey all. Anyone know how to view the budget's i've previously made?
22:15:16 <cgibreak> *budgets
22:17:49 <jsled> File > Open > Open Budget...
22:18:00 <jsled> s/...$//
22:18:03 <cgibreak> lol, thx. Now i feel dumb
22:18:39 *** cgibreak has quit IRC
22:30:56 *** BlackBsd has quit IRC
22:37:58 <jsled> hampto1: nice.
22:43:52 *** warlord-afk is now known as warlord
22:47:41 <warlord> hampto1: good find.
22:51:55 <hampto1> andi5 narrowed it down to Klee's patch that I applied.
22:52:48 <hampto1> It occurred to me that xaccSplitOrder orders credits before debits and that's what was probably causing the problem.
22:53:20 <warlord> Ah
22:53:32 <warlord> I wonder... what happens in a credit lot vs. a debit lot?
22:55:12 <hampto1> That was the problem. A credit lot worked fine. A debit lot failed when the credits were reordered before the debits.
22:55:34 <hampto1> or vice-versa. /me can never remember which are credits and which are debits
22:57:05 <dbr-afk> hampto1: not only does r15829 balance the vast majority of the enter/leave calls, logging performance is practically snappy. Thanks.
22:57:10 *** dbr-afk is now known as dbr
22:57:33 <hampto1> That's because you aren't printing lines prefixed with 7000 blanks each. :-)
22:58:23 <dbr> yeah. I had tens of thousands of blanks between the time stamp and label
22:59:15 <warlord> dbr: yeah... 43000 IIRC
22:59:30 <warlord> hampto1: ahh, so it works with both credits and debits now?
22:59:35 <dbr> that was just one line about 3/4 of the way through
23:00:34 <hampto1> warlord: it should. unless someone modifies the date on a split that moves it prior to the split that opened the lot.
23:01:38 <warlord> Well, think about the invoice system..
23:01:51 <warlord> It's POSSIBLE that a "payment" opens the lot, instead of the invoice...
23:02:02 <warlord> (this is possible for both Customer Invoices nad Vendor Bills)
23:03:18 <hampto1> The sign of the lot (+ or -) is set by the first split added to the lot. If you put a transaction with a different sign first the lots code will complain.
23:03:41 <hampto1> s/put a transaction/reorder the splits to put a split/
23:04:33 <warlord> "the sign of the lot"?
23:04:44 <hampto1> credit or debit
23:05:50 <warlord> Hmm, I haven't looked at that code in a while... where does that sign matter?
23:06:52 <hampto1> If you open a lot with a 2000 credit, the first split in the lot is a credit and all the other entries in the lot should be debits. If you reorder the splits so the credit isn't first. the code complains. See cap-gains.c:840
23:06:53 <warlord> (the business code can create a lot from an over-payment, so that would be an inverse-signed lot.. but I dont think the business code cares about it. Or at least it never used to care)
23:07:52 <hampto1> If you open a lot with a 2000 debit, the first split in the lot is a debit and all the other entries in the lot should be credits. Again, if you reorder the splits so the original split (in this case the debit) isn't first. the code complains.
23:07:55 <warlord> What about a 100 credit.. then a 2000 debit.. then more credits.. (and then maybe another debit)
23:08:21 <hampto1> My understanding is that by definition those are different lots.
23:08:33 <warlord> They can't be
23:08:36 <warlord> (in my case)
23:08:41 <hampto1> The 2000 debit is split: 100 to close the first lot, 1900 to open a second lot.
23:09:24 <hampto1> The credits are then applied against the 1900 debit lot.
23:09:48 <hampto1> All zero crossings create new lots.
23:10:24 <warlord> Hmm.... The business code doesn't work that way.
23:10:58 <hampto1> AFAICT that's how Linas' lots code works.
23:11:31 <hampto1> I have no problem it you want to change it.
23:11:45 <warlord> Let me use business terminology. In the NORMAL case, you post an Invoice, and then post payments.. and if you overpay it then creates one more transaction that transfers to/from itself.
23:12:47 <warlord> in the LOT sense.. in the normal case.. the invoice opens the lots.. the payments reduce the lot.. and at the end the final payment may cause another transaction that looks like an invoice and a payment, where the "invoice" is attached to the invoice lot to make it 0, and the "payment" part creates a new lot.
23:13:02 <warlord> Now, this NEW lot starts with what looks like a "payment"..
23:13:14 <warlord> then it would get invoiced...
23:13:33 <hampto1> Its an payment. Over. ;-)
23:13:52 <warlord> ??
23:14:06 <hampto1> joke. payent. over. over-payment.
23:14:32 <warlord> Sorry... too much blood in my tequilla.
23:18:57 <warlord> I wonder if the cap-gains code is interacting with the business code in a way that causes these strange problems periodically>?
23:53:07 <hampto1> http://i145.photobucket.com/albums/r202/danjoke/GuesswhoIranintotoday.jpg
23:58:07 <dbr> there are some sick folk out there
23:59:34 <hampto1> i thought it was rather funny, but then I didn't create the picture