2015-10-05 GnuCash IRC logs

01:11:16 *** MechtiIde has joined #gnucash
01:44:35 *** MechtiIde has quit IRC
01:48:19 *** MechtiIde has joined #gnucash
02:14:21 *** MechtiIde has quit IRC
03:07:56 *** mlncn_ has joined #gnucash
03:23:39 *** joe has quit IRC
03:30:21 *** nomeata has joined #gnucash
03:31:00 *** uXus has quit IRC
04:29:01 *** uXus has joined #gnucash
04:53:52 *** fabior has joined #gnucash
05:04:55 *** mikee has quit IRC
05:06:07 *** mikee has joined #gnucash
05:06:07 *** gncbot sets mode: +o mikee
06:53:32 *** Jimraehl1 has left #gnucash
06:54:08 *** Jimraehl1 has joined #gnucash
07:01:30 *** VuvuzelaExpert has joined #gnucash
07:04:18 <VuvuzelaExpert> Hi, I'd like some advice on how to record a discount on a debt. I have the following accounts: Liabilities:Stuent Loan, Expenses:Education. I paid off the loan in full by recording as a transaction from the Expenses acct to the Liabilities account. I was given a 10% discount for paying in full. I've recorded this as a transaction in the reverse direction. However this looks odd in an expense bar chart as it comes up as a "negative" bar. Is there
07:04:18 <VuvuzelaExpert> a more canonical way to do this?
07:05:15 <VuvuzelaExpert> Thanks in advance to anyone with the patience to read the above.
07:08:08 *** mlncn_ has quit IRC
07:13:43 <VuvuzelaExpert> Correction: the Liabilities account opening balance was created with a transaction from Expenses, and was ultimately paid off with a transaction from my Assets:Bank account. Sorry for any lack of clarity, it's late where I am.
07:19:14 *** uXus has quit IRC
07:22:27 *** uXus has joined #gnucash
07:50:25 *** joe has joined #gnucash
07:53:53 *** fabior has quit IRC
07:56:34 *** fabior has joined #gnucash
07:57:39 *** fabior has quit IRC
09:11:51 *** fell__ has joined #gnucash
09:14:07 *** fell_ has quit IRC
09:16:32 *** fabior has joined #gnucash
10:10:58 <warlord> VuvuzelaExpert: how you record the 10% discount may be affected by local tax rules which I cannot comment to. You have a few options on how to record the 10% discount; you could record it as income or you could record it as equity.
10:11:13 <warlord> e.g. income:discount -> liabilities:loan
10:11:28 <warlord> or equity:loan discounts -> liabilities:loan
10:11:48 <warlord> ... this would offset the difference in loan principal versus what you paid off
10:48:18 *** gjanssens has joined #gnucash
10:48:18 *** ChanServ sets mode: +o gjanssens
11:16:25 *** gjanssens has quit IRC
11:45:07 *** MechtiIde has joined #gnucash
11:58:37 *** nomeata has quit IRC
12:34:50 *** gjanssens has joined #gnucash
12:34:50 *** ChanServ sets mode: +o gjanssens
13:08:05 <jralls> gjanssens, warlord: I've solved 755902 and determined that 756045 isn't a regression, so I intend to release 2.6.9 ASAP. Is there anything else pressing that should go into it?
13:33:16 <MechtiIde> so fast a next release?
13:40:34 <warlord> MechtiIde: yes, because File -> Save As is broken on Windows.
13:40:57 <warlord> jralls: I can't think of anything. Fixing the Windows and Mac issues really.
13:40:57 <MechtiIde> ok
13:41:38 <jralls> MechiIde: Plus some more of your translations get to the users!
13:43:14 <MechtiIde> in the nightly builds the chapter Credit Card isn't visible in the German version
13:43:35 <gjanssens> jralls: I haven't seen anything else that's blocking, so go for it
13:44:32 <MechtiIde> I'm not sure if this is a problem in Makefile.am?
13:50:32 <warlord> MechtiIde: was it a new file? If so, did you add it to the build?
13:51:32 <MechtiIde> it was ch_cc.xml I add it to gnucash-guide.xml
13:52:11 <MechtiIde> I'm not sure how the file Makefile.am works
13:52:23 <gjanssens> Mechtilde, warlord: it's not an issue with Makefile.am
13:52:47 <gjanssens> When running the build locally (after pulling the latest branch head) it's there
13:53:07 <warlord> when was it pushed to head?
13:53:31 <gjanssens> The issue is that maint hasn't been merged into master after the cc chapter was added
13:53:35 <gjanssens> I'll do that in a minute
13:53:45 <MechtiIde> ok
13:54:40 *** fabior has quit IRC
13:55:50 <gjanssens> Done. The chapter will appear in tomorrow's build.
13:55:59 <MechtiIde> thanks
13:56:24 <gjanssens> warlord: would it make sense to set up separate builds for maint and master ?
13:56:47 <gjanssens> Now that we have switched to git, we tend to work on both branches more independently
13:57:08 <gjanssens> (maint and master for gnucash-doc, that is)
13:58:13 <jralls> gjanssens: Rats, ch_cc.xml was in de/Makefile.am but ch_cbook.xml wasn't, so it needs another merge. I'll do it after I tag the release.
13:58:17 <warlord> Oh. Hmm...
13:58:35 <warlord> I only build master
13:58:42 <gjanssens> Oops. Didn't see that one
13:58:44 <warlord> .. why do we have multiple doc branches?
13:59:14 <gjanssens> warlord: because documentation on the stable release shouldn't contain information on master features only
13:59:47 <gjanssens> So at some point the two branches tend to divert slightly
13:59:49 <jralls> At some point the branches will diverge operationally. They don't now. In any case the nightlies should be against maint rather than master.
14:00:35 <gjanssens> That would at least make more sense, as we don't release the master branch of gnucash itself either
14:00:53 <jralls> The documentation nightlies, that is. There hasn't been any work done on documentation master since we created it, only merges from maint.
14:01:16 <gjanssens> So the minimal action is probably to switch branches on your nightly builds to maint
14:03:02 <gjanssens> And as as followup the docs.phtml page on the website should get a minor fix.
14:03:29 <gjanssens> It currently states: Every night a server builds the documentation from the current contents of the GnuCash *subversion* repository
14:03:36 <gjanssens> that's git now
14:03:40 <gjanssens> and
14:03:56 <gjanssens> ...User Documentation for the current unstable version of GnuCash
14:04:18 <gjanssens> That 'current' unstable should be changed to something else
14:04:29 <gjanssens> I'm not sure how to properly say that in English
14:23:30 *** MechtiIde has quit IRC
14:59:51 <Simon> any idea why this would happen with 2.6.8 when adding price quotes? Wrong type to apply: #<<gnc-numeric> num: 151940000 denom: 100000000> http://s85.org/cMTJpRbI (2.6.7 was ok)
15:00:00 *** fabior has joined #gnucash
15:04:38 <jralls> Simon: Well, that's timely. I guess I need to fix that before releasing 2.6.9. How were you adding the quotes, from the command line or the Price Editor window?
15:06:19 <Simon> with gnucash --add-price-quotes
15:06:20 <jralls> Simon: And what is it a quote for?
15:06:40 <Simon> I don't know what that specific quote is for but I could guess based on the price
15:09:24 <Simon> it's a quote for USD in GBP
15:09:35 <Simon> 1/15194 GBP is 1 USD
15:10:29 <jralls> OK, a currency. That was the important bit.
15:17:10 <jralls> Sigh. Works OK for me. Could you do `echo '(currency "USD" "GBP")' | gnc-fq-helper` (mind the quotes, discard the ` but keep the others)?
15:18:12 <Simon> (("GBP" (symbol . "GBP") (gnc:time-no-zone . "2015-10-05 20:17:51") (last . 1.5149) (currency . "USD")))
15:18:15 <Simon> it doesn't always fail
15:18:48 <Simon> but it has happened twice so far on two different days
15:19:36 <jralls> Simon: Oh, great. Intermittent is so much fun. How often do you run it per day?
15:23:07 <Simon> 02:15, 04:36, 18:08, 21:27 UK time
15:23:48 <Simon> it failed at 18:08 and 21:28 yesterday, with two different prices
15:24:16 <Simon> (it then couldn't run again because the file was locked)
15:28:13 <jralls> Is your computer on UK time? That control path is TZ sensitive.
15:30:20 <Simon> yes
15:30:28 <jralls> Has it failed today?
15:30:33 <Simon> no
15:31:36 <Simon> would it help if I capture all calls to gnc-fq-helper?
15:32:55 <jralls> No, it's not in gnc-fq-helper, it's in the Scheme file that converts gnc-fq-helper's output into a price entry. What OS are you on?
15:34:50 <Simon> Linux
15:35:01 <Simon> Ubuntu 15.04
15:39:30 <jralls> OK. The file in question is /usr/share/gnucash/scm/gnucash/price-quotes.scm, the /usr part might be different if you're using a self-built GnuCash.
15:41:41 <Simon> it's still at /usr/share/gnucash/scm/gnucash/price-quotes.scm but it should be using /usr/lib/x86_64-linux-gnu/gnucash/gnucash/scm/ccache/2.0/gnucash/price-quotes.go
15:42:07 <jralls> Right, but that's compiled and hard for humans to read.
15:44:46 <jralls> warlord, gjanssens: A little Scheme help, please. The line that's throwing the error is
15:45:07 <jralls> (set! price (gnc-numeric-invert(price))))))
15:45:13 <jralls> but it should be
15:45:26 <jralls> (set! price (gnc-numeric-invert price)))))
15:45:29 <jralls> right?
15:49:53 <gjanssens> jralls: yes
15:50:03 <gjanssens> (price) would be evaluated as if it's a function
15:50:25 <gjanssens> and the result of the evaluation is passed as argument to gnc-numeric-invert
15:50:42 <gjanssens> But price is a variable, so it shouldn't be evaluated
15:50:47 <gjanssens> Good catch
15:51:12 <Simon> for some reason it's also not storing a price for today's date
15:51:26 <jralls> Perfect, thanks. A gnc-numeric won't evaluate as a function, which is exactly the error.
15:51:57 <jralls> gjanssens: I had help: http://www.troubleshooters.com/codecorn/scheme_guile/hello.htm pointed the way. That page is a keeper!
15:54:03 <gjanssens> That's an interesting page indeed. I've bookmarked it right away
15:54:38 <jralls> Simon: Are you sure it's not storing CURRENCY>GBP>USD? And while you're looking, do you have a CURRENCY>USD>GBP stored for yesterday?
15:55:01 <gjanssens> Different topic - I need some brains to pick on testing the csv importer...
15:55:18 <gjanssens> The meat of the importer is loading a csv file and converting the contents into a set of transactions
15:56:08 <gjanssens> So I presume that sensible tests are best created by writing some real csv files and testing whether they import correctly
15:56:42 <gjanssens> Verifying the "correctly" part is what I'm wondering about
15:56:51 <gjanssens> How should I do that ?
15:57:17 <gjanssens> Match each import file with some kind of list of transactions that I expect to see after the import test ?
15:57:58 <gjanssens> Should I set these up in the fixture ? Or write some custom struct to hold that information ?
15:58:08 <gjanssens> My concern is also maintainability
15:58:27 <gjanssens> If in the future someone finds a bug in the csv importer and wants to add a test for the fix
15:58:44 <gjanssens> It should be relatively straight forward to do so.
15:59:22 <gjanssens> I worry that if the test data exists in two locations (one csv file to import and one data set somewhere else to verify against) it would become non-obvious.
15:59:30 <gjanssens> Any thoughts on this ?
16:00:59 <Simon> jralls: I do have an entry for yesterday
16:01:11 <jralls> gjanssens: Best to keep it all in the test file. You should be able to pass a string to a function and get a Transaction* back that you can compare to a Transaction* created by a custom setup().
16:01:59 <Simon> jralls: and yes there is an entry in the other direction for today
16:02:07 <gjanssens> jralls: so you mean I shouldn't be loading a csv file at that point ?
16:02:09 * Simon deletes it and tries again
16:02:34 <gjanssens> That is test the successful loading of a csv file independently ?
16:03:50 <gjanssens> If so, I'll have to rewrite parts of the csv importer.
16:04:18 <gjanssens> It uses GMappedFile as datatype to store the csv file to parse in
16:04:43 <gjanssens> I'm not aware of a way to fool GMappedFile to simply work on a string instead of a file
16:05:34 <Simon> it's now storing GBP to USD instead of USD to GBP :/
16:05:55 <Simon> I'd prefer the latter because otherwise all the currencies would appear under GBP
16:06:54 <jralls> Simon: Roger, but we need to store in the direction where the value is > 1 to preserve significant digits. Not so important for USD <-> GBP, but very important for currencies with large ratios.
16:07:41 <jralls> However, if you already have a price in the DB in the other direction, it will modify that price instead. That's the bug you just found.
16:08:08 <gjanssens> https://developer.gnome.org/glib/unstable/glib-File-Utilities.html#g-mapped-file-new
16:08:11 <jralls> That's also why it didn't happen every time.
16:08:55 <Simon> aah.
16:09:01 <jralls> gjanssens: Yeah, I know about GMappedFile. It's used in glib's TZ database code that I rewrote a couple of years ago.
16:09:09 <jralls> I don't like it much.
16:09:19 <Simon> I could really do with an option to not try to get quotes again
16:09:36 <Simon> I have to run it several times a day in case one of them fails or is too early, or I have the file open
16:09:54 <gjanssens> jralls: what's the advantage of GMappedFile over plainly loading a file's contents ?
16:10:43 <jralls> Simon: Too hard. So what we do now is keep only one quote, and per your request here a couple of months ago, an F::Q quote will overwrite a transaction-based one but not the other way around.
16:13:32 <Simon> aah
16:13:51 * Simon is tempted to write a patch to allow the transaction-based prices to be optional
16:13:53 <jralls> gjanssens: Speed, supposedly. You get this block of memory that you can cast into a struct. Using it with a string file is a Really Dumb Idea.
16:14:18 <gjanssens> Ok, so that part will be rewritten :)
16:14:39 <gjanssens> Are there memory management advantages in case of huge files ?
16:14:43 <jralls> Simon: Why? It gets overwritten anyway.
16:15:10 <gjanssens> That is, will GMappedFile prevent out of memory issues by not attempting to load the complete file at once ?
16:15:27 <gjanssens> (My question may reveal my total ignorance on the internal details...)
16:15:42 <gjanssens> Or is that just not relevant for GnuCash ?
16:16:13 <jralls> gjanssens: I don't know, but even if it does it would be filling up VM and causing swap hell. Not a good idea.
16:17:24 <jralls> As for GC relevance, probably none. It's one of those low-level tweaks that should be used only if really necessary and only with careful profiling and testing.
16:17:40 <gjanssens> Ok. Thanks for the feedback
16:17:42 <Simon> jralls: I'm almost always entering transactions for days that have already downloaded quotes
16:17:56 <Simon> jralls: as the information I'm getting for them is usually provided the next day
16:18:10 <gjanssens> I'll look into changing that part and making csv import easier to test as a result.
16:19:06 <jralls> On the subject of CSV, Bob Fewell's got some bugs in with patches for the importer. If you're going to rework it (C++? Please?) you should coordinate with him.
16:19:53 <jralls> Simon: In that case the transaction quote won't get written. Only quotes entered directly in the Price Editor will overwrite F::Q quotes.
16:21:51 <jralls> So your already-downloaded F::Q quote (the last one you get for that day, F::Q quotes will overwrite older F::Q quotes so that there's only one) will be presented in the Transfer Dialog as a default, but you can of course change it to make your transaction balance.
16:22:12 <gjanssens> jralls: current work is on writing unit tests for the existing importer
16:22:24 <gjanssens> The target is to fully rewrite the csv importer in c++
16:22:51 <gjanssens> The former is currently done on the maint branch, the latter will have to happen on master
16:23:24 <gjanssens> So it may be that my first corrections will still be in C to be able to continue writing tests
16:23:47 <Simon> jralls: I usually duplicate a transaction and modify the amount/shares
16:23:56 <gjanssens> I will check with Bob Fewell on the patches and his plans for the importer
16:26:03 <jralls> gjanssnes: OK. So for testing the existing code as a way to ensure that you don't break anything, the easy way is to create a CSV file and an XML file. Import the CSV, write out XML, compare the XML to the "golden" XML. Unit test any functions that are tractable for testing.
16:28:12 <jralls> Simon: So using the non-currency register with cells for amount, price, and value. No Transfer Dialog defaults, then, but the transaction price still won't overwrite an existing F::Q price.
16:29:45 <gjanssens> jralls: that's a more pragmatic approach, thanks
16:29:58 <jralls> Simon: However, currency registers can only use the Transfer Dialog. Either way, the F::Q price won't get overwritten.
16:30:53 <gjanssens> As for Bob's patches - they are enhancements not bug fixes so in theory they should go into master
16:31:25 <gjanssens> Which means I'd better apply them (after testing of course) before I start working on a c++ version of the importer.
16:31:41 <gjanssens> Or would you consider these for maint ?
16:31:45 <jralls> gjansssens: It's unfortunately the only approach if you can't unit test important pieces. Otherwise you have to refactor without having tests to protect you.
16:32:11 <jralls> No, they should go in master, but if you're preparing to rewrite in C++ that's for master too.
16:32:25 <gjanssens> Of course
16:32:46 <gjanssens> I'm not there yet, so Bob's patches can go in beforehand still
16:32:57 <gjanssens> I'll check on them somewhere in the next few days
16:33:13 <Simon> jralls: no it doesn't overwrite it, but it does still add it
16:33:25 <jralls> OK, do you want to take that on? I did a code review and then got buried in bugs.
16:33:39 <gjanssens> One advantage of writing the unit tests so far has been that I learned the csv importer in more depth
16:33:44 <jralls> Simon: So you're winding up with two prices on one day?
16:33:50 <Simon> jralls: yes
16:33:51 <gjanssens> I'll take that part yes
16:35:02 <jralls> gjanssnes: Yes, I've learned a lot about the engine and QOF from writing unit tests.
16:35:27 <jralls> Simon: Currency, stock, or both? Are both in the same direction?
16:35:41 <jralls> Both txn and FQ, I mean.
16:36:08 <Simon> stock
16:36:56 <Simon> direction? the stock prices are always listed under their own price section
16:38:11 <gjanssens> Time to call it a day... See you guys
16:38:21 <gjanssens> jralls: good luck with the 2.6.9 work
16:40:20 *** gjanssens has quit IRC
16:45:30 <jralls> Simon: Got it. I'll look into that, but not for 2.6.9.
16:50:53 *** fabior has quit IRC
16:54:34 *** fabior has joined #gnucash
17:49:03 *** fabior has quit IRC