2007-08-10 GnuCash IRC logs
00:08:13 *** Wilddev has quit IRC
00:37:51 *** warlord has joined #gnucash
00:37:51 *** gncbot sets mode: +o warlord
00:53:41 <dbr> anybody besides Hampton work with the new check printing code?
00:54:49 <warlord> hampton did all of it.
00:55:39 <dbr> any ETA on when he might be around?
00:56:41 <dbr> I guess I could just go hit it with my sledge hammer and see what happens...
00:57:51 <warlord> Send him an email?
00:57:55 <warlord> I haven't seen him in a while
00:58:08 <dbr> I'll give that a try.
00:58:23 <dbr> on another subject I did finally figure out how to tell gtk to use letter-sized paper by default
00:58:52 <dbr> export LC_MESSAGES=en_US.UTF-8
01:00:16 <dbr> wahoo. That one's been bugging me for a ridiculous amount of time. Became critical with gtkprint changes.
01:00:51 <warlord> WEIRD!
01:00:57 <warlord> Can you send that out to the list?
01:02:27 <dbr> sure
01:02:41 <warlord> okay, gotta run.
01:02:43 *** warlord is now known as warlord-afk
01:03:20 <dbr> I'll have to look into whether it fixes the problem in the gnomeprint realm too.
01:20:54 *** dbr has quit IRC
01:34:05 *** antonv has quit IRC
03:15:41 *** Jaran has quit IRC
03:15:44 *** Jaran|zZzZzZz has joined #gnucash
03:40:35 *** zarchne has quit IRC
04:28:32 *** Esaj has joined #gnucash
07:21:18 *** andi5 has joined #gnucash
07:21:19 *** gncbot sets mode: +o andi5
07:25:24 *** warlord-afk is now known as warlord
07:35:35 *** cortilap has joined #gnucash
07:53:54 *** Demitar has quit IRC
08:01:11 *** twunder has joined #gnucash
09:15:01 *** franz has joined #gnucash
09:23:33 *** kielein has joined #gnucash
09:34:26 *** franz has quit IRC
09:40:13 *** andi5 has quit IRC
09:55:40 *** warlord has quit IRC
10:06:31 *** gelf has joined #gnucash
11:02:05 *** gunnicom_ has joined #gnucash
11:04:07 *** warlord has joined #gnucash
11:04:08 *** gncbot sets mode: +o warlord
11:58:42 *** andi5 has joined #gnucash
11:58:43 *** gncbot sets mode: +o andi5
12:01:34 <andi5> jsled: this is not the first time i wonder: http://bugzilla.gnome.org/show_bug.cgi?id=465348 speaks about 2.0.5 and we mark it as dup of a bug fixed in 2.0.3... hmmm :)
12:02:35 <jsled> hmm indeed. And the version number probably came from bugbuddy, so it's not user error.
12:03:04 <jsled> should we reopen one or the other?
12:03:32 <andi5> if there is one with a bit more info...
12:03:53 <warlord> Are you sure it's 2.0.5?
12:04:05 <warlord> Does debian HAVE 2.0.5?
12:04:20 <andi5> if it is not 2.0.5, how can bug-buddy _guess_ 2.0.5?
12:04:35 <jsled> "Debian lenny/sid" what'd sid again?
12:04:43 <andi5> sid == unstable
12:05:10 <jsled> http://www.us.debian.org/releases/lenny/
12:05:50 <jsled> http://packages.debian.org/unstable/gnome/gnucash
12:05:53 <jsled> Yup. 2.0.5.
12:07:43 <andi5> "keep marking"... actually, i found only this one bug with version 2.0.5 ;-)
12:15:38 <jsled> andi5: I've had that as a todo for a long time. I think it's a great idea.
12:16:16 <jsled> I think someone should create a private key and simply give both parts to the other core devs. We should all sign it, of course.
12:17:57 <warlord> Signing tarballs is fine with me.
12:18:06 *** Esaj has quit IRC
12:18:14 <andi5> "give" meaning from hand to hand or (crypted mail && telephone) or ...?
12:18:58 <jsled> Yeah, I'd probably do it as an encrypted attachment for each recipt.
12:20:26 <andi5> jsled: you would? :)
12:21:18 <jsled> andi5: that's what I'd do, yes.
12:21:40 <andi5> ok... once more: _you_ would? ;-)
12:21:45 <jsled> heh.
12:22:38 <jsled> I could, yes.
12:23:27 <jsled> not just this moment, but hopefully later today or this weekend.
12:23:40 <jsled> speaking of which, gotta go get some lunch. biab.
12:23:48 <andi5> bye :)
12:33:10 *** warlord has quit IRC
12:46:11 *** Demitar has joined #gnucash
12:51:30 *** andi5 has quit IRC
13:04:37 *** gunnicom| has joined #gnucash
13:05:57 *** cortilap has quit IRC
13:11:52 *** Demitar has quit IRC
13:13:32 *** gunnicom_ has quit IRC
13:16:58 *** Esaj has joined #gnucash
13:44:06 *** micah1_8 has joined #gnucash
13:44:14 <micah1_8> hello all
13:45:00 <jsled> hello.
13:45:22 <micah1_8> I'm having some trouble with the windows version of gnucash--- when I print an invoice using the default stylesheet, the date printed is missing the day. (eg. August,,2007)
13:46:29 <micah1_8> any thoughts?
13:46:34 *** Demitar has joined #gnucash
13:57:43 <micah1_8> am I the only one who's seeing this?
13:58:35 <jsled> I've not seen it reported before. But that's not the same thing.
14:05:17 <micah1_8> hmmm...
14:06:29 <micah1_8> Yeah, I looked all through the interwebs and I haven't found anyone with this same problem.
14:08:36 <micah1_8> I was hoping somebody here could point me to a solution.
14:09:24 <micah1_8> I'm wondering if somehow the date formula has gotten messed up... but you'd think I'd see a variable (%e, or something) in place of the day.
14:11:02 <jsled> The report is build via string concat, not variable interpolation.
14:11:09 <jsled> So, it's not unreasonable.
14:12:14 <micah1_8> also, this probably isn't the place for this, but, wouldn't it be nice if the company information on the invoice also showed the company phone number?
14:12:38 <micah1_8> I guess I should look at setting up a custom invoice stylesheet.
14:14:23 *** warlord has joined #gnucash
14:14:23 *** gncbot sets mode: +o warlord
14:16:32 *** Esaj has quit IRC
14:20:50 <micah1_8> well thanks anyway, I've gotta go, but I'll probably be back.
14:21:10 *** micah1_8 has left #gnucash
14:24:59 *** Esaj has joined #gnucash
14:36:46 *** jakin has joined #gnucash
15:25:37 *** nomeata has joined #gnucash
15:32:46 *** sjc has joined #gnucash
16:00:05 *** findlay has joined #gnucash
16:00:07 <findlay> got it
16:00:10 <jsled> :)
16:00:14 <findlay> :)
16:01:39 <jsled> [ot] ugh. http://www.boingboing.net/2007/08/10/guiliani_freedom_is_.html
16:07:25 *** warlord has quit IRC
16:33:48 *** nixtrib has joined #gnucash
16:34:10 <nixtrib> hi
16:39:40 *** twunder has quit IRC
16:54:41 <jsled> hello.
16:59:33 *** _jakin_ has joined #gnucash
17:03:13 *** warlord has joined #gnucash
17:03:14 *** gncbot sets mode: +o warlord
17:04:33 *** nomeata has quit IRC
17:08:56 *** jakin has quit IRC
17:21:55 *** kielein has quit IRC
17:39:26 *** pecisk has quit IRC
17:44:14 *** nbinont_ has joined #gnucash
17:53:57 *** nbinont has quit IRC
18:11:28 *** greg has joined #gnucash
18:14:31 <greg> I am having trouble when importing QIF files. I import the file to my checking account and go through the screens. In particular, I match dunplicate transactions, but when I 'finish' I have 2 transactions; one with the original date when I entered it and a second identical but with the import date. Is there a way to avoid this? Thanks
18:15:22 *** nixtrib has left #gnucash
18:17:57 <warlord> greg: how far apart are the two dates? If you marked it as a duplicate then it shouldn't import the second one. but if the dates are too far apart then it wont consider them the same.
18:19:46 <greg> Ah...I'll have to look, but that may me it as I tend to import the past 30 days. I'm just learning gnucash (just switched to Linux), so it very well be me. I'll try again and only import the last couple of days.
18:21:29 <warlord> ok
18:22:24 <greg> Thank-you. Thanks for the help.
18:22:30 *** greg has quit IRC
18:22:31 <warlord> you';re welcome
18:41:55 *** andi5 has joined #gnucash
18:41:56 *** gncbot sets mode: +o andi5
18:43:18 <andi5> hi... i am currently playing with the old register code (just trying to track down a few things, not that i understand anything :-)) ... may someone want to take at a one-liner?
18:44:03 <warlord> maybe. depends on the one-liner ;)
18:44:11 <andi5> http://pastebin.ca/raw/652967
18:44:16 *** Esaj has quit IRC
18:46:44 <andi5> the idea is to hide some one-split txns from the general ledger
18:47:52 <andi5> but there are still too many when one opens the general ledger
18:48:36 <andi5> (at least the reproduction seems to be slowed down a bit now ;-))
18:48:43 <andi5> +rate
18:51:41 <warlord> I would add another line, "blank_split = NULL" after the destroy ... just to be clear.
18:52:07 <andi5> yeah
18:52:22 *** Esaj has joined #gnucash
18:52:50 <warlord> other than that... sure
18:53:31 <andi5> i will try to catch the other empty txns, and if i succeed, then send chris the patches for review.... i really do not like that code :-D
18:55:16 <andi5> i mean chris, because iirc he was the last one touching it
18:55:28 <warlord> right
18:58:14 * chris shivers.
18:58:26 *** jpeach has joined #gnucash
18:58:30 <andi5> *g*
18:59:00 <jpeach> When gnucash crashes, how do I use the logs to recover the changes made in the session? Or is that no possible?
18:59:14 <andi5> gnucash does not crash
18:59:22 <andi5> ;-)
18:59:58 <jpeach> Agreed :) but on the rare chance that it does... not do to any fault in the code
19:00:09 <andi5> bad memory, you are right
19:00:16 <warlord> jpeach: File -> Import -> Log Replay
19:00:30 <andi5> does that reliably work for certain actions?
19:00:35 <jpeach> warlord, thanks!
19:00:49 <andi5> i have got the feeling it is rather flaky (never actually tested it myself)
19:00:49 <warlord> Note that it ONLY works for register-based transaction entry.
19:01:10 <warlord> It works fine for MOST cases. It does have issues with certain things.
19:01:25 <andi5> xfer dialog entries are ok as well, i guess?
19:01:57 <jpeach> warlord: What about creation and paying invoices?
19:07:39 <chris> andi5: It's been a while since I've looked that code, but, IIUC, that's not right.
19:08:25 <chris> andi5: In that block, the edited transaction is going to be committed.
19:09:07 <chris> specifically, the blank, pending transaction will be committed.
19:09:24 *** andi6 has joined #gnucash
19:09:25 *** gncbot sets mode: +o andi6
19:10:12 <chris> and the blank split will join the new transaction.
19:10:59 <chris> oh great, now I'll be out-numbered.
19:11:05 <andi6> *g*
19:12:19 <chris> so, I'd expect that that change would mean that you couldn't add splits to the blank transaction.
19:12:41 <andi6> hm... that is still possible
19:12:56 <chris> or, more correctly, that edits to the blank split in the blank transaction would be dropped.
19:13:02 <warlord> andi5: yes.
19:13:31 <warlord> jpeach: nope. if you did any business entries then they're lost and you need to re-enter them, and indeed replaying the log will cause your books to be wrong.
19:14:12 <jpeach> wardlord: thanks
19:14:48 <warlord> Save early, save often
19:15:08 <andi6> chris: i had the scenario that pending_trans was NULL, but the blank_split_guid simply forgot, read "leaked"
19:15:09 <jpeach> Rarely a need to save, gnucash does not crash often.
19:15:53 <jpeach> Is there a way to process a single payment that pays multiple invoices? The way I do it now is enter a separate payment for each invoice and use the same cheque number.
19:17:10 <andi6> chris: what does this "if (!gnc_table_current_cursor_changed (reg->table, FALSE))" stand for, btw?
19:17:32 *** andi5 has quit IRC
19:17:37 *** andi6 is now known as andi5
19:19:12 <chris> andi5: I think it means "if the cursor hasn't moved since our last save"
19:20:14 <andi5> the cursor is "the whole yellow line", simply speaking?
19:20:20 <warlord> yes
19:20:23 <chris> yeah
19:20:28 <andi5> k
19:23:01 <chris> If pending_trans is null, then we probably shouldn't be dropping the blank split.
19:23:33 <andi5> so when is pending_trans not null in that case, so that my change causes data loss?
19:24:02 <chris> but how could xaccTransIsOpen(trans) be true then?
19:24:36 <andi5> one moment... there is one empty txn at the end of registers, right?
19:24:49 <andi5> the blank split is the empty split at the end of a txn?
19:24:54 <chris> (biab, bedtime for kids)
19:24:58 <andi5> :(
19:25:56 <andi5> but the former cannot be the parent of the latter, if the cursor is not at the end of the register...
19:26:04 <andi5> so, i have a naming conflict here :)
19:29:11 <chris> what do you mean? the blank trans is the parent of the blank split whenever the cursor is anywhere in the blank trans.
19:29:42 <andi5> but why do i read blank_trans=xaccSplitGetParent(blank_split) then?
19:30:33 * andi5 is a bit konfuz'd
19:39:06 *** jpeach has left #gnucash
19:39:48 *** gunnicom| has quit IRC
19:40:56 <chris> andi5: I think the blank split remains in the blank trans until the pending trans is committed.
19:41:32 <warlord> I think the blank_split is always attached to the "current transction", which may or may not be the "blank_trans"
19:41:56 <chris> So, even when the blank split row appears in an existing transaction, the blank split is still part of the blank trans.
19:42:11 <chris> (which is different from what warlord just said)
19:42:47 <andi5> so i see the blank_split two times if the cursor is not on the blank one?
19:43:19 <andi5> e.g. in general ledger more
19:43:24 <andi5> mode, even
19:43:41 * chris actually opens gnucash. :)
19:44:13 <andi5> wow.... sounds a bit like pandora's box
19:44:47 <chris> yeah, I guess it's like you're seeing the blank trans twice.
19:44:54 <chris> er, blank split, I mean.
19:45:24 <andi5> ok... i guess i will have to reevaluate a lot of code again now :)
19:46:37 <chris> so, if I'm right, that explains blank_trans = xaccSplitGetParent (blank_split).
19:48:06 <andi5> great... short question: when does the currently selected txn become pending_trans? once i start typing something in a field of it?
19:48:38 <chris> oh, if we're on a trans that's being edited in another register, then pending_trans could be null while xaccTransIsOpen(trans) is true.
19:50:12 <andi5> that answers your question from above, right?
19:51:53 <chris> yes.
19:52:08 <andi5> so what if i added xaccTransCommitEdit(trans) and return TRUE?
19:52:25 <chris> the currently selected trans becomes pending in 1 of 3 ways...
19:52:26 *** warlord is now known as warlord-afk
19:52:56 <chris> (and if you think this is bad now, you should have seen it before I worked on it. It's much better than it was, believe it or not.)
19:53:15 * andi5 grabs his tux to keep him warm
19:53:47 <chris> (no, commiting the trans is not right)
19:54:05 <chris> 1) during autocompletion.
19:54:38 <chris> 2) when the nicely factored out gnc_split_register_begin_edit_or_warn() is called.
19:56:11 * chris scrambles to figure out 3)
19:56:24 <andi5> (10 types of people?)
19:58:10 <chris> 3) if we go to save the blank trans, it becomes pending. :)
19:58:13 <chris> tada!
19:59:12 <chris> (3 is from split-register.c:1388)
20:01:06 <chris> ok, scratch my explanation about multiple registers.
20:01:31 *** _jakin_ has quit IRC
20:01:40 <andi5> ok, my left hand scratches my head, the right one your explanation
20:02:00 <chris> in your case, pending_trans == null, and trans is open, and trans == blank_trans, right?
20:02:12 <andi5> yep
20:02:32 <andi5> and the cursor did not change.... i do not understand that at all, but hey :)
20:02:49 <andi5> i _moved_ it :-D
20:03:49 <andi5> ah.... it is not that the cursor did not _move_, but that the moved cursor contents did not _change_ :-)
20:04:01 *** Esaj has quit IRC
20:04:14 <chris> that could be.
20:06:34 <chris> andi5: um, are you debugging strange behavior in the GL?
20:06:42 <andi5> yes
20:07:05 <chris> wow, I just poked at the GL, and it did some very strange things.
20:07:13 <andi5> yes...
20:07:31 <chris> just by moving around it went from 3 transactions up to 5 and then down to 1.
20:07:37 <chris> all empty.
20:07:49 <andi5> yes.... my (incorrect) patch reduces that problem
20:09:43 <chris> the GL doesn't get extra lines unless you've opened another register first, huh?
20:10:45 <andi5> yep... i guess you see all the blank splits from other registers... but maybe only ledgers show them
20:10:57 <andi5> or something like that
20:14:08 <chris> I don't know what's up with that.
20:15:04 <andi5> chris: http://pastebin.ca/raw/653038 ?
20:15:13 <chris> there is one blank trans per open register.
20:17:10 <chris> I was thinking about that but here's what I'm thinking...
20:19:00 <chris> nevermind, I forgot what I was thinking.
20:19:13 <andi5> did you say anything?
20:19:44 <chris> 653038 looks more reasonable.
20:20:36 <chris> If the blank split _was_ edited, it will be correctly committed.
20:21:29 <chris> and if it wasn't edited, I don't see any problems with destroying it.
20:22:10 <chris> but, what's been happening to it if it wasn't editted?
20:22:35 <chris> Is it being destroyed by the scrubber?
20:22:55 <andi5> the scrubber is issued while committing?
20:23:00 <chris> yes
20:23:15 <andi5> well, if pending_trans is NULL, there _is no_ commit
20:23:43 <chris> not true.
20:23:56 <chris> if (trans == pending_trans || blank_edited) ...
20:24:11 <andi5> (02:22:12) chris: but, what's been happening to it if it wasn't editted?
20:24:47 <chris> right, but trans == blank_trans != null
20:25:08 <chris> and it will be committed in line 1350.
20:25:40 <chris> oh, wait, that's only if it was edited.
20:25:56 <andi5> iff pending_trans is non-NULL
20:26:08 <andi5> ok, well... ==trans ;-)
20:26:57 <andi5> so where is the hidden data loss?
20:27:07 <andi5> which would be introduced by this change
20:27:08 <chris> but, the trans is still open.
20:27:52 <chris> and it's still the blank trans.
20:28:10 <andi5> maybe the whole blank_trans has to be destroyed?
20:28:20 <andi5> that sounds... incorrect :)
20:28:30 <chris> so, why should we drop the blank split at all?
20:28:58 <andi5> because it is regenerated on gnc_split_register_load
20:29:31 <chris> only if we null out the guid, though.
20:29:31 <andi5> if we unset info->blank_split_guid
20:30:00 <andi5> we must do it if we want to commit the blank trans, right?
20:30:11 <chris> absolutely.
20:30:36 <chris> but if we know that we won't...
20:32:44 <andi5> is it possible that trans == blank_trans != pending_trans, and info->blank_split_edited==TRUE?
20:33:10 <chris> so maybe... if ((trans == pending_trans) || blank_edited) { null the guid }
20:34:10 <chris> I don't think that is (or should be ) possible.
20:34:21 <andi5> hm... if trans==pending_trans!=blank_trans, does blank_split belong to trans at all?
20:35:07 <chris> no, blank_split always belongs to blank_trans, remember?
20:35:15 <andi5> yes... so why null it?
20:35:28 <andi5> i'd say... null it if edited
20:36:20 <andi5> because if it is edited, then it should be committed as well, and we need a new blank_{split,trans}
20:37:17 <chris> well, what if trans == pending_trans != blank_trans and blank_edited == true?
20:37:44 <chris> we'd still null it then.
20:38:22 <andi5> i am not sure.... that stems from a _save call earlier, right? ... why does that split still not belong to pending_trans?
20:40:23 <andi5> ah..... i just read line ~1420
20:40:55 <chris> heh, my cursor is sitting on that line, but I'm still trying to remember what it does.
20:41:19 <andi5> blinking?
20:41:22 <chris> oh, reading the comment helps.
20:42:06 <andi5> well, my line numbers may not be accurate any more
20:42:18 <chris> xaccTransAppendSplit (trans, split)
20:42:42 <andi5> so we do not see blank_split twice, right?
20:43:37 <chris> I guess not.
20:43:46 <andi5> hehe
20:45:33 <chris> but I'm not sure that means that trans == pending_trans != blank_trans and blank_edited == true is impossible.
20:45:56 <andi5> i have to admit that i am too tired to get any further today
20:46:09 <andi5> i am totally missing documentation
20:46:22 <andi5> a simply glossary... ;-)
20:46:30 <chris> thanks for reminding me why I had src/register so much. :-P
20:46:39 <chris> s/had/hate/
20:48:44 * andi5 checks the timeline for some branches
20:51:16 <andi5> seems like there is always space for improvements, right?
20:51:29 <chris> uh, yeah.
20:52:46 <andi5> well, ok... i have come to the point again where i do not want to touch the register code at all
20:53:08 <chris> andi5: I really never fully groked the register code. My strategy was to add assertions.
20:54:02 <andi5> chris: may i pm you?
20:54:12 <chris> sure
21:05:59 *** andi5 has quit IRC
21:37:38 *** sjc has quit IRC
21:48:25 *** forest has joined #gnucash
21:49:53 *** forest has joined #gnucash
21:52:22 <forest> Hello. I'm using GNUcash to keep track of a checking account in China and a CD in the US; everything seems to work as far as conversions go, except in my Equity account it adds all the values together without converting them, giving me a nonsense balance. Is this a known bug? Is there a way I can fix it?
22:02:28 <forest> I'm using version 2.0.5, perhaps I should upgrade to 2.2.0? Yes? I'll give it a try.
23:10:45 *** warlord-afk is now known as warlord
23:11:01 <warlord> forest: you need two equity accounts; one for USD and one for the chinese currency
23:35:37 *** fefe has joined #gnucash
23:35:48 <fefe> hi guys
23:36:49 <fefe> quick question i didnīt find in the faq: is it possible to add a new currency to gnucash?
23:37:08 <warlord> why would you need to? ISO defines all the currencies on the planet
23:37:19 <warlord> you can create any (non-currency) commodity you want
23:37:49 <fefe> well, i am in chile and they use some unit called UF
23:38:28 <fefe> and many prices are expressed in UF instead of the official currency which is pesos
23:38:43 <fefe> you can also have bank deposits in UF
23:38:48 <warlord> What's "UF"?
23:39:01 <fefe> "unidad de fomento"
23:39:19 <warlord> fefe: Is that defined by ISO?
23:39:38 <fefe> it corresponds to some amount of pesos and itīs adjusted monthly to the iflation rate
23:39:47 <fefe> i donīt know. I suppose not
23:40:25 <warlord> well, you can treat it like any other commodity (like a stock or bond).. keeping that of the #units you have. But no, you cannot add currencies.
23:42:16 <fefe> hm, but i canīt use it as an unit of an account, no?
23:42:42 <warlord> sure you can. just need to use a "Stock" or "Mutual" account.
23:42:59 <fefe> a, interesting
23:43:29 <fefe> i guess i can find details about it in the Investments chapter of the documentation, no?
23:44:16 <warlord> yeah, or the "stock" sections
23:44:35 <fefe> cool, thx
23:44:49 <fefe> i am thinking about switching from quicken back to gnucash :)
23:44:56 <warlord> ok
23:44:59 <warlord> BACK to..??
23:46:14 <fefe> yeah, i had used gnucash long ago, but sometime i gave up using linux on the desktop so i switched to quicken
23:46:43 <fefe> been waiting for a windows port since then :)
23:47:09 <warlord> Oh
23:50:32 <fefe> thereīs no way to import a quicken file with multiple currencies to gnucash, no?
23:51:12 <fefe> i understand that you have to export the data to a QIF file and that doesnt support multiple curencies
23:53:22 <warlord> I beleive that's true, yes.