2020-06-21 GnuCash IRC logs
00:53:05 <chris> CDB-Man: fwiw *most* reports offer average-cost, weighted-average etc for periodic sums / date-specific balances. only Transaction Report will attempt to convert amount using 'nearest pricedb' to target-currency
00:53:50 <CDB-Man> yeah, though my objective right now is to first get a solid accounting example
00:53:55 <chris> example: load transaction report, select *ALL* accounts for reporting, pick any period. choose a target currency eg CAD. result: all amounts are converted to CAD but the total isn't exaclty 0.00 CAD.
00:54:09 <CDB-Man> without that starting point which is correct, you can't (re)design gnucash
00:57:25 <chris> So: using your latest .xls do you think it's possible to create such a report as GAAP3 (1) or (2) using existing gnucash data structures? there's no daily USD/CAD in pricedb, and there's no yearly-average USD/CAD readily available
00:58:09 <chris> If you're willing to accept pricedb-nearest then I can have a try
00:58:24 <CDB-Man> dont bother yet until i finish gaap 4
00:58:31 <chris> ^ I thought so
00:58:32 <CDB-Man> which will have TRADING accounts
00:59:16 <CDB-Man> is pricedb nearest = nearest in time?
00:59:22 <CDB-Man> as in nearest to _report date_
01:00:00 <chris> ^ depends: on most reports eg balsheet/incomes-tatement it's nearest to report-date; on transaction report it's nearest to transaction-posting-date
01:00:16 <chris> ^ one of these longstanding idiosyncrasies
01:00:25 <CDB-Man> > on transaction report it's nearest to transaction-posting-date <-- ah so that's what you meant before, and this is very interesting
01:00:48 <CDB-Man> this might be usable to our advantage
01:01:17 <chris> https://github.com/Gnucash/gnucash/blob/maint/gnucash/report/report-system/trep-engine.scm#L1285
01:01:59 <chris> the TR is the only one to not offer 4 fx options
01:02:08 *** Mechtilde has joined #gnucash
01:02:25 <chris> (I cut my teeth on gnucash overhauling a complete pile of mess into this .scm)
01:03:13 <CDB-Man> well, actual transactions are the best way to get accurate pricedb
01:03:17 <CDB-Man> so this has its usages
01:03:52 <CDB-Man> err, that sentnece didnt make sense
01:04:08 <CDB-Man> well, actual transactions are the best way to get accurate prices per GAAP, for P&L anyways
01:06:01 <chris> fwiw if you're with TR you can help us: with a simple book with simple txns involving all 5 account types - asset/liab/equity/inc/exp - eg 1 opening bal equity->asset, 1 income->asset, 1 asset->expense, 1 loan repayment asset->liability, it would be nice to know if the Debit/Credit amounts in the Transaction Report are correct
01:08:57 <CDB-Man> well, GAAP 4 will be siple in the sense that it has simple transactions
01:09:07 <CDB-Man> yet compresenive in that it covers multiple transactipon types
01:09:22 <CDB-Man> it can be used ot diagnose multiple reports, since the answers will all be in the excel too
01:25:55 *** sbluhm has joined #gnucash
01:25:55 *** ChanServ sets mode: +v sbluhm
01:38:13 <chris> CDB-Man: are the amounts in the correct Dr/Cr column? https://imgur.com/a/Wnj1Ryi
01:39:37 <CDB-Man> yeah
01:40:03 <CDB-Man> though instead of spending directly from the checking account, perhaps spend from the creidt card
01:40:21 <CDB-Man> Dr Gas, Cr Credit card $230
01:40:28 <CDB-Man> then make a $200 payment to credit card
01:40:51 <CDB-Man> unless you were purposefully trying to create a debit balance liability
01:40:55 *** sbluhm has quit IRC
01:44:30 <chris> nice... prior to 2017 there were some big misunderstandings
01:45:06 <CDB-Man> chris when i look at attachment 373740, and do a compare in notepad++ to the version from last week's build, i think you already refeactored?
01:45:11 <CDB-Man> comment 60 that is
01:45:54 <chris> no I didn't refactor yet in daily builds.
01:46:12 <CDB-Man> no what i mean is
01:46:19 <CDB-Man> comment 60 vs 61
01:46:30 <CDB-Man> the only different is negation chang
01:46:54 <CDB-Man> but in reading comment 61, you make it sound like noth refactor + negation are changes between 61 and 60
01:47:01 <CDB-Man> like both*
01:47:22 <chris> yes: comment 60 is mainline+refactoring, comment 61 is mainline+refactoring+negation to fix bug 797796
01:47:57 <chris> mainline is still https://github.com/Gnucash/gnucash/blob/master/gnucash/report/commodity-utilities.scm#L467
01:48:23 <CDB-Man> ok, just wanted to be sure
01:48:39 <CDB-Man> so comment 60 vs current nightly, should generate no numerical differences
01:48:57 <CDB-Man> whereas comment 61 vs nightly, will generate a difference, hopefulyl fixing the SPY 10 shares issue
01:50:04 <chris> bingo yes
01:50:36 <chris> always confusing especially bugzilla doesn't allow amending comments
01:52:38 <CDB-Man> bugzilla feels ancient. for another project i have some involvement on, we use mantis
01:52:55 <CDB-Man> https://www.mantisbt.org/
01:53:02 <CDB-Man> much more modern, also free
01:53:11 <CDB-Man> GNU GPL
01:54:40 <CDB-Man> jralls: has gnucash considered a more modern bug tracker, such as mantis? https://www.mantisbt.org/ also GNU GPL, but with more modern tools, such as comment editing, more powerful workflow and dashboard, etc
01:55:37 <CDB-Man> okay, time to give your comment 60 and 61 a spin
01:56:44 *** fell has quit IRC
01:58:02 *** fell has joined #gnucash
01:58:03 *** ChanServ sets mode: +o fell
02:03:08 <CDB-Man> chris: your comment 60 and the original in the nightly are not the same
02:06:43 *** sbluhm has joined #gnucash
02:09:01 <CDB-Man> i feel like ive pointed this out before
02:13:14 <chris> you may need to add logging into your commodity-utilities.scm and attach the tracefile
02:13:56 <CDB-Man> if you have one that logs, im happy to run it
02:14:11 <CDB-Man> my book is too complex to try and replicate the issue in a clean book
02:14:30 <CDB-Man> (and of course too much personal data to just dump a full debug report)
02:15:13 <CDB-Man> if you want to printf every calculation at the bottom of the report or something, that works
02:15:44 <chris> ^ can't -- the price calculator doesn't have access to the report-html being generated
02:16:18 <CDB-Man> just saw your comment 67, i can add tha tin
02:16:25 <CDB-Man> where does the tracefile log to?
02:16:28 <CDB-Man> somewhere in appdata?
02:16:42 <chris> https://wiki.gnucash.org/wiki/Tracefile
02:17:58 *** sbluhm has quit IRC
02:19:06 <chris> you'll note that (gnc:pk ...) is the logger... you can omit sumlist if you feel the tracefile contains too much data
02:19:38 <CDB-Man> the tracefile itself will send too much data, i'll neex to xtract this part of the data from it
02:19:43 <chris> ^ to omit sumlist, you'll still ned to add the closing ")" to balance the parens. like accounting, in lisp all parens must balance :)
02:20:47 <CDB-Man> i dont mind sending the sumlist
02:20:55 <CDB-Man> i just dont want to send the wole tracefile
02:21:04 <CDB-Man> as last time i learned it lists every single account name in the register
02:21:15 <CDB-Man> several of which have my bank account numbers
02:23:17 <CDB-Man> okay, what am i looking for in this tracefile
02:23:21 <chris> https://pastebin.com/raw/ESHx30Vc
02:23:31 <chris> we want the raw SPY transactions
02:23:36 <chris> we want the raw SPY splits
02:24:53 <CDB-Man> that will help with trying to solve for the 0 SPY thing, but it still find it odd that your refactoring cause _other_ changes
02:25:16 <CDB-Man> note how in the screenshot the TRADING account toal is sidderent
02:25:24 <CDB-Man> becaus the value of all the other stocks changed
02:25:45 <CDB-Man> MSFT $1010.45 vs $1011.71
02:25:59 <chris> shucks
02:26:34 <CDB-Man> so befor you even get to the SPY issue
02:26:49 <CDB-Man> the fact that refactoring resulted in a net chnage... is its own issue
02:26:58 <CDB-Man> that's what ive been trying to poin tout
02:30:25 <chris> hmm all I can think now is for you to experiment - in commodity-utilities.scm between lines 559 and 568, change "(- value-amt)" to "value-amt" and "(- share-amt)" to "share-amt", either on the 1st pair, or 2nd pair, or both
02:31:36 <CDB-Man> your line numbers are always offset.... like your patch says @@508 but it's actuallt line 454 or so
02:32:19 <CDB-Man> i am modifying the comment 60 file right now
02:33:13 <CDB-Man> toggling the negatives on those, that would really only find differences between comment 60 vs 61, right?
02:33:23 <CDB-Man> or are you saying to try this in the mainline version
02:33:49 <CDB-Man> cause this difference in MSFT between mainline and comment 60 means your refactoring resulted in a net change
02:34:12 <CDB-Man> even before the negation fix (which is what you're suggesting i should try out via experimentation)
02:34:43 <CDB-Man> (not that the negation fix did anything; your comment 61 file still returned SPY $0 for me)
02:43:11 <chris> ^ would be on mainline commodity-utilities.scm
02:43:39 <chris> seems refactoring had error somewhere
02:46:43 <chris> which fx conversion are you using? doing the logging in gnc:get-exchange-cost-totals is for average-cost; in gnc:get-exchange-totals is for weighted-average
02:47:02 <CDB-Man> all of this is with average cost
02:47:41 <chris> it should be logging SPY splits
02:49:19 <chris> how about you run a Transaction Report on your SPY account
02:49:34 <chris> we can then try recreate
02:49:41 <chris> average-cost won't need pricedb populating
02:50:38 <CDB-Man> did you identify and fix your refactoring error?
02:50:58 <chris> no
02:51:05 <CDB-Man> does your comment 61 fix the jralls file?
02:51:13 <CDB-Man> cause he built that file using most of my SPY transactions
02:51:56 <chris> ^ yes it did fix it
02:52:47 <chris> ^ see comment 22
02:56:21 <CDB-Man> hmm..... i cant reproduce MSFT = 1010.45 anymore
02:56:34 <CDB-Man> odd, because i have not added any transactions nor updated price db...
02:59:30 <CDB-Man> maybe your refactoring is fine and it was a fluke//// but that doens tmake any sense
02:59:56 <CDB-Man> because i definitely complained about this a week or 2 ago as well
03:01:02 <chris> welcome to software development ;)
03:01:06 <CDB-Man> i dont see any logged SPY entries in the tracefile
03:01:23 <CDB-Man> all i see is "Rounding required when 'never round' specified." at the timestamp i run the report
03:02:03 <CDB-Man> ill just screenshot the transactions
03:02:23 <CDB-Man> but again, thats what jralls used to build his example, so that's also add
03:05:05 <CDB-Man> chris: https://i.imgur.com/A1kK7DV.png that is all my SPY transactions leading up to the failure date of 2014-06-02
03:06:26 <CDB-Man> though, i think you need the VALUE side of it, since this report doesnt show the $9.95 commissions being paid
03:06:35 <CDB-Man> the 0 unit 0 dollar split
03:07:27 <chris> maybe a screenshot of the register would have the information?
03:07:38 <CDB-Man> hmm, nvm, that was a non commissioned trade
03:07:40 <CDB-Man> 0.00 is accurate
03:07:48 <CDB-Man> carry on, no information missing
03:08:06 <CDB-Man> wait, no....
03:08:53 <CDB-Man> yeh, ill grab the registers instead
03:08:57 <CDB-Man> transaction reprot drops the info
03:12:50 <CDB-Man> chris: https://i.imgur.com/Bdp74ZG.png
03:14:24 <chris> Ok. I'll need to go soon, will try this one.
03:15:02 <CDB-Man> likewise
03:15:04 <CDB-Man> im heading ot bed
03:36:32 *** sbluhm has joined #gnucash
03:36:32 *** ChanServ sets mode: +v sbluhm
03:41:02 *** sbluhm has quit IRC
04:14:03 *** sbluhm has joined #gnucash
04:14:04 *** ChanServ sets mode: +v sbluhm
04:46:18 *** sbluhm has quit IRC
05:06:01 *** User_ has joined #gnucash
05:13:08 *** Aussie_matt has joined #gnucash
05:34:37 *** angel has joined #gnucash
06:40:37 *** angel has quit IRC
07:01:50 *** bobazY has joined #gnucash
07:02:17 <bobazY> register
07:02:20 <bobazY> help
07:02:37 *** bobazY has left #gnucash
07:04:19 *** Mechtilde has quit IRC
07:05:04 *** bobazY has joined #gnucash
07:05:04 *** ChanServ sets mode: +v bobazY
07:05:39 <bobazY> Hey all! Trying to get my gnucash working on centos8. It's not in the repos. Getting error: `CMake Error at CMakeLists.txt:354 (message): Neither guile 2.2 nor guile 2.0 were found GnuCash can't run without one of them. Ensure that one is installed and can be found with pkg-config.`
07:06:23 <bobazY> I have guile 2.0.14 installed. Wonder how I can get cmake find it?
07:08:32 *** Mechtilde has joined #gnucash
07:36:20 *** Mechtilde has quit IRC
08:00:02 *** User_ has quit IRC
08:20:40 <fell> bobazY: You need also the guile.dev[el] package.
09:12:38 *** Aussie_matt has quit IRC
09:29:32 *** Guest19 has joined #gnucash
09:34:27 *** Guest19 has quit IRC
09:39:04 *** o01eg has joined #gnucash
09:53:33 *** Mechtilde has joined #gnucash
10:25:10 *** sbluhm has joined #gnucash
10:25:10 *** ChanServ sets mode: +v sbluhm
10:27:25 *** gjanssens has joined #gnucash
10:27:25 *** ChanServ sets mode: +o gjanssens
10:35:42 <chris> gjanssens: I may leave the guile-3 merge to you; I'm not clever with CMake and gettext
10:35:55 <chris> (maybe after 4.0 is out)
10:36:26 <chris> I should be able to clear the deprecations afterwards... there's lots of them
10:53:43 *** Mechtilde has quit IRC
11:00:45 *** Mechtilde has joined #gnucash
11:07:09 *** sbluhm has quit IRC
11:18:50 <gjanssens> chris: ok, I think it's safer to do after 4.0
11:18:50 <gncbot> gjanssens: Sent 13 hours and 3 minutes ago: <chris> - the gnucash-cli can specify report by guid too. is it a code smell to leave the arg as is? gnucash-cli -R show -guid GUID would be more exact but I don't think is necessary
11:19:49 <gjanssens> Distros that insist on only shipping guile 3.0 can apply your patch to our release tarball then.
11:20:42 *** sbluhm has joined #gnucash
11:20:42 *** ChanServ sets mode: +v sbluhm
11:23:56 <gjanssens> chris: as for --guid, I don't think it's necessary either. It would help though if the help message mentions both name and guid are valid arguments
11:36:25 <fell> I have locked guile on tumbelweed, but others will have no guile2 anymore and be unable to build.
11:36:52 <fell> gjanssens ^
11:37:27 <jralls> CDB-Man: Gramps uses Mantis. /me hates it.
11:40:12 *** sbluhm has quit IRC
11:40:15 <jralls> fell, did you sort out your build problem with uk.po? It's working fine here.
11:41:46 <fell> maint had failed because you managed to duplicate a block.
11:43:24 <fell> you had not backported your 2. trial.
11:43:52 <jralls> 2. trial?
11:46:07 <fell> Ah, the first can be the result of merging maint.
11:48:15 <jralls> And I see you've thrashed all of the po files in maint. I hope we get no translations in the next week, it makes it a lot harder to merge new ones when you do that.
11:50:08 <fell> we should have done it before.
11:50:39 <fell> The reason: I know translators with an too old gettext.
11:50:40 <jralls> It also make it impossible to tell that you've already merged one. I wasted more than an hour yesterday resolving the conflicts from your reformatting uk.po only to find that the end result was missing only that block that was duplicated in the maint one.
11:52:34 *** craigbass76 has quit IRC
11:52:35 <jralls> For translators working from our git repo and submitting PRs it's OK because you can tell them to rebase. Please stop doing it to TP translations. They have their own toolset and standard options and they ignore our changes.
11:57:27 <jralls> That does bring up the issue of stale TP translations, which is most of them. Some we should probably drop altogether. I'll ask Benno if they have a policy for declaring translations obsolete.
11:58:49 <fell> from what i watched. if a langage team dissolves.
12:00:22 <jralls> It doesn't take a team to dissolve, they just need to lose the volunteer who worked on GnuCash. Then there's the urinating contest between the Arabic team (apparently Tunisian) and the Egyptian university a couple of years ago.
12:03:17 <chris> If a scm function is marked deprecated in 3.x it means we can remove in 3.90x right? eg gnc:html-table-col-headers
12:04:01 <jralls> chris, I thought that you'd already cleaned out the deprecated functions.
12:04:52 <chris> forgot this one
12:04:57 <jralls> But yes, we can remove it... except that I'm 99% done with the last 3.90x, next weekend is 4.0.
12:05:18 <fell> that would mean mark in 3.10 and remove in 3.9xx?
12:06:14 <jralls> I think all of them got marked earlier than 3.10.
12:08:09 <chris> definitely earlier than 3.10
12:26:23 <bobazY> > <fell> bobazY: You need also the guile.dev[el] package. /// I see. Too bad it's not in Centos8 it seems :(
12:44:49 <jralls> bobazY http://www.clacee.eu/content/os-tools/en/applications/gnucash/install-gnucash-3-8-on-centos-8.html
13:00:31 *** o01eg has quit IRC
13:06:42 *** o01eg has joined #gnucash
13:12:30 *** User has joined #gnucash
13:13:13 <bobazY> Thanks jralls . Went ahead and installed fedora, which has it in repo :)
13:13:43 <jralls> A wise choice IMO.
13:14:34 *** bobazY has quit IRC
13:16:33 <jralls> warlord, can you remove builds/win32/unstable/gnucash-3.906.setup.exe?
13:20:31 <warlord> jralls, done.
13:20:39 <warlord> Happy Father's Day to all fathers out there!
13:20:40 <jralls> Thanks.
13:20:47 <jralls> And to you too!
13:21:06 <warlord> thanks
13:21:12 <jralls> And to chris, who's 70% there!
13:39:26 *** User has quit IRC
13:46:43 *** sbluhm has joined #gnucash
13:46:43 *** ChanServ sets mode: +v sbluhm
14:15:59 <gjanssens> jralls: regarding the release notes - isn't 3.906 the sixth testing release ?
14:16:15 <gjanssens> And also the bit right after "New features" seems to be missing a part.
14:16:22 <jralls> Unfortunately no. There was no 3.901.
14:16:32 <gjanssens> It starts with "The intent is to have command categories with subcommands to better enable a richer command line capability as illustrated with the new report commands list and show."
14:16:44 *** shaggy has quit IRC
14:16:55 <gjanssens> That seems to be missing an introductory bullet summarizing that feature
14:17:06 <gjanssens> Ok on 3.901. I had missed that
14:17:35 <gjanssens> Or the long sentence should be moved to the end of the first bullet.
14:18:56 <jralls> "The intent..." is actually left over from a note about the rearrangement of the command line arguments in the 3.904 release. For 3.905 I integrated that into the following bullet, but missed deleting the explanation sentence.
14:19:00 <gjanssens> And as far as I can tell it's not correct either the gui tool (gnucash) responds to the same command line options.
14:19:46 <gjanssens> There are a number of common options, but certainly not all.
14:20:52 <gjanssens> gnucash has --add-price-quotes, which has been deprecated and will eventually be removed. And the report options won't be added to gnucash, only gnucash-cli.
14:22:37 <jralls> But the GUI tool has always responded to those options.
14:23:10 <gjanssens> Ok, let's define "those options"
14:23:27 <jralls> Everything except --rpeort, right?
14:24:26 <gjanssens> True.
14:24:31 <jralls> Though I'm not sure about --add-price-quotes/--quotes get. That's changed for both gnucash and gnucash-cli, right?
14:24:41 <gjanssens> No, only on gnucash-cli
14:25:02 <gjanssens> I didn't want to change gnucash to maintain backwards compatibility in the 4.0 release
14:25:30 <jralls> Which is fine, and means that only gnucash-cli is a new feature.
14:25:43 *** sbluhm has quit IRC
14:26:26 <gjanssens> Ok. So I find the final line of the first bullet confusing. It seems to suggest gnucash also can respond to --report, which it doesn't.
14:26:28 <jralls> So I think the notes are OK for that. But I do want to polish everything up this week for a more user-friendly 4.0 release.
14:27:18 <jralls> Ah, so it does.
14:27:42 <gjanssens> That line can probably just be removed
14:29:21 <gjanssens> Continuing my review: I think recently a few experimental reports have been demoted to experimental again, so the bullet about experimental reports being moved to replace the old ones may need some additional detailing.
14:31:24 *** dtux has joined #gnucash
14:32:02 <jralls> Yes. It needs more detail for 4.0, most users won't understand.
14:32:09 <gjanssens> And the bullet explaining how column widths are saved and reset for business options actually goes for *all* register type screens.
14:32:38 *** dtux has joined #gnucash
14:32:40 *** CDB-Man_ has joined #gnucash
14:32:40 *** ChanServ sets mode: +v CDB-Man_
14:32:47 *** dtux has quit IRC
14:33:11 <gjanssens> Oh, I see that is mentioned in other major code changes.
14:33:36 <gjanssens> I'm not sure it makes sense to split this up though
14:34:39 <jralls> Agreed.
14:34:56 *** CDB-Man has quit IRC
14:35:02 <gjanssens> Different topic: with the workaround we discovered to capture early startup console output on Windows, do we still need to carry the (disabled) code to attach a console to gnucash ?
14:36:36 <gjanssens> It's disabled because the __MSWIN_CONSOLE__ is not set
14:37:53 <jralls> I don't know offhand, nor do I remember the workaround.
14:38:50 <gjanssens> The workaround is to run gnucash from cmd.exe (not powershell) and use > and 2>&1 to redirect output to a file
14:39:19 <gjanssens> You can also pipe the output using | to some other processor.
14:41:07 <jralls> Odd that it doesn't work in powershell. MSWIN_CONSOLE surely doesn't belong in gnucash-core-app.cpp though, only gnucash.cpp would need it.
14:41:34 <gjanssens> The workarounds were found while debugging https://bugs.gnucash.org/show_bug.cgi?id=797791
14:42:10 <gjanssens> Yes, I agree MSWIN_CONSOLE doesn't belong in gnucash-core-app.cpp any more.
14:42:43 <gjanssens> Before my fix for 797791, gnucash-cli didn't ouput anything either, which is why the redirect option was still there.
14:43:10 <gjanssens> Well, the redirect code that's disabled by default I mean
14:44:09 *** jervin has joined #gnucash
14:45:14 <gjanssens> OTOH moving it to gnucash.cpp would mean any output due to locale issues would be output before the console is opened on Windows. I don't know if that then means the output is lost.
14:45:53 <jralls> The only reason I can think of to leave it in is for debugging because it lets log output got somewhere that you can see it during the debugging session. But the need for that is rare enough that perhaps it's not worth keeping.
14:46:42 <gjanssens> Hah, that's a use case I didn't think of
14:53:12 <gjanssens> I did a quick check and in gdb you can also redirect stdout to a file ('run --help > c:\gcdev64\debug.out' would output gnucash' help message to that file)
14:53:32 <jralls> Moving it would require rethinking construction a bit. The good news is that the localization output is the same for gnucash and gnucash-cli so if one wants to see it one can just run gnucash-cli.
14:53:33 <gjanssens> That's still not the same as getting the message in the console but close.
14:55:25 <gjanssens> jralls: right. So if we add the console in gnucash' constructor right before the call to configure_program_options we'd be good
14:55:37 <gjanssens> All common constructor issues could be debugged via gnucash-cli
14:56:44 <gjanssens> Any gnucash specific output could be redirected to a console console that gets attached as first thing in the gnucash-specific constructor.
14:56:56 <jralls> Yes. So the only question is whether it's worth keeping at all. I can't say that I've used it much.
14:57:09 <gjanssens> I have never used it.
14:57:22 <jralls> Let's just lose it then.
14:57:35 <gjanssens> I was about to recommend that as well :)
14:57:59 <gjanssens> It's in the commit history. If really needed it can temporarily be added for debugging purposes.
14:58:26 <jralls> That would require remembering that it's there...
14:58:41 <gjanssens> Heh, true enough...
14:58:54 *** frakturfreak has joined #gnucash
14:58:54 *** ChanServ sets mode: +v frakturfreak
14:59:05 <gjanssens> I'll remove it anyway
14:59:09 <jralls> OK.
15:00:52 <gjanssens> FTR I also had considered replacing the __MSWIN_CONSOLE__ define with a command line option --console.
15:01:07 <gjanssens> That however suffers the same isse that it comes way too late.
15:02:04 <jralls> Yes, plus doesn't have much of a value-add. Back to the 4.0 release. I think we need something a bit less dense than our usual release notes. I have no doubt that they make most user's eyes glaze over.
15:02:32 <gjanssens> Agreed.
15:04:17 <jralls> So how to present it? A panel with the new features on the home page, left up for maybe 6 months?
15:04:34 *** giuseppef has joined #gnucash
15:10:28 <giuseppef> Good evening, I am trying to use gnucash to comply with new accounts reporting schemes for Italian charities. The new "profit and loss" scheme is a two columns reports, but it is asked to have intermediate differences between sections. For example, there are 5 different sections in earnings (call it A, B, C, D, E) and 5 sections in costs (call it A, B, C, D, E too). In the final report I need to have one line with
15:10:29 <giuseppef> intermediate results of As and one line for intermediate result of Bs, and so on. I don't know how I could get this with gnucash.
15:12:41 <gjanssens> jralls: that's what we did in that past. Compared to alternatives (like adding a feature tour to the startup of gnucash) this is relatively little effort.
15:12:50 <gjanssens> So I'm fine continuing with this.
15:13:07 <jralls> OK. I don't think there's really enough to justify a feature tour.
15:13:30 <gjanssens> Neither do I. I was just thinking out of the box to come up with alternatives.
15:14:11 <jralls> giudeppef: I don't think any of the GnuCash reports support that. You'll need to assemble the pieces with separate reports and paste it together in a spreadsheet or word processor.
15:17:59 <giuseppef> thanks jralls. This is what I am doing now
15:20:01 *** storyjesse has quit IRC
15:26:31 *** shaggy has joined #gnucash
15:27:11 *** giuseppef has quit IRC
15:32:01 *** sbluhm has joined #gnucash
15:40:23 *** fell_laptop has joined #gnucash
15:40:23 *** ChanServ sets mode: +o fell_laptop
15:40:23 *** fell has quit IRC
16:13:16 *** sbluhm has quit IRC
16:14:02 *** dtux has joined #gnucash
16:23:39 *** Mechtilde has quit IRC
16:35:49 <gjanssens> chris: concerning the deprecations in guile 3.0, surely you understand we can only fix those for which the alternative is also in guile 2.0 ?
16:36:24 <gjanssens> gnucash still supports guile 2.0, so we should write guile code that works starting with guile 2.0
16:37:08 *** gjanssens has quit IRC
16:56:52 *** frakturfreak has quit IRC
17:03:15 *** User has joined #gnucash
17:06:52 *** o01eg has quit IRC
17:17:06 <CDB-Man_> jralls: i think i ask and you mentioned last week something about seeing of alphavantage could be queried for fx rates in the past. did you discover anything in that regard?
17:17:30 <CDB-Man_> ie, for a rate other than "live at that moment"
17:20:43 <jralls> CDB-Man_ I thought I'd replied. Yes, Alphavantage can return a time series for the last day, week, or month. See https://www.alphavantage.co/documentation/ and search for FX_.
17:21:09 <CDB-Man_> you might have, and I may have missed it
17:22:13 *** David has quit IRC
17:22:22 *** David has joined #gnucash
17:22:25 <CDB-Man_> excellent, so it is at least possible for the transaction exhcnage rate tool to query for an fx rate as at transaction date, in that at least the data is available
17:22:49 <CDB-Man_> rather than returning "today's rate timestamped at when you press the button"
17:23:30 <CDB-Man_> this will factor into the example that I am building for GAAP 4
17:23:42 <CDB-Man_> and on a side none, i will file this as an enhancemnet request
17:26:00 <jralls> Well, up to a point. Daily OHLC prices seem to be good for about 4 months, their example is at https://www.alphavantage.co/query?function=FX_DAILY&from_symbol=EUR&to_symbol=USD&apikey=demo.
17:26:59 <jralls> There's also weekly and monthly OHLC for longer periods. You could probably cobble together a "good enough" average.
17:27:08 <CDB-Man_> well, I'm thinking on 2 tracks here
17:27:20 <CDB-Man_> 1: to get the rate over a period, i.e. calendar 12 months
17:27:46 <CDB-Man_> but also 2: when editing the exhcnage rate of a single transaction, be able to quiery that day's rate for that 1 transaction
17:27:59 <CDB-Man_> which the API page here says "contain 20+ years of historical data"
17:29:01 <CDB-Man_> basically where I am going with this is, if I were to for example key in all the USD dividends i received in the month of May, based on my May 31st broker statement, into a CAD register account, that I can lookup the exact USDCAD rate on that day
17:29:09 <CDB-Man_> rather than having to do that myself separately
17:29:42 <CDB-Man_> in other words, if it is easy to record everything for P&L in home currency terms, then the need to find an annual average rate for a 12 month calendar period becomes moot
17:29:48 <jralls> The 20 years is for monthly *stock* prices, not FX.
17:29:51 <CDB-Man_> since... you've already reocrded ll P&L in CAD anyways
17:30:58 <CDB-Man_> well... that is disappointoing
17:31:47 <CDB-Man_> the FX_DAILY documentation doesn't specify how long. the examples of theirs that you linked goes for 4 months, hmm
17:32:22 <jralls> Maybe. FWIW the monthly FX example, https://www.alphavantage.co/query?function=FX_MONTHLY&from_symbol=EUR&to_symbol=USD&apikey=demo, goes back to 2001. But that's OHLC for the whole month, not daily prices.
17:32:36 <CDB-Man_> jralls: if you look at the "full" example, it goes further than 4 months https://www.alphavantage.co/query?function=FX_DAILY&from_symbol=EUR&to_symbol=USD&outputsize=full&apikey=demo
17:32:55 <CDB-Man_> this seems to be daily OHLC back to 2005
17:33:01 <CDB-Man_> 2001*
17:33:39 <jralls> OK. You'd only need to retrieve that once.
17:34:11 <CDB-Man_> and update on an ongoing basis as time progresses?
17:34:27 <CDB-Man_> or are you saying to pre-code it into the gnucash db?
17:35:35 <jralls> No, get the full historical prices once to fix up your old transactions. After that you can usually just get the 4-month ones for when you post your statement.
17:36:24 <CDB-Man_> as long as "fix up" does not modify transactions that are already coded with an fx rate in the register, yeah
17:38:11 <CDB-Man_> in an ideal situation, only BS accounts are ever recorded in non home register currency, and all P&L accounts are always in home currency. that at least gives the most accurate P&L data. Next best would be a period averge for P&L rather than nearest in time to report date. it still leaves the CAD -> USD -> SPY issue unsolved, but I'm still thinking about that; at least having the ability to lookup per transaction would make it easier to price a USD
17:38:11 <CDB-Man_> SPY purchase in CAD terms
17:38:30 <jralls> That would be a rare case in a book where transactions are recorded between two FX accounts. The issue is re-valuing those transactions in the home currency, right?
17:43:08 <CDB-Man_> > The issue is re-valuing those transactions in the home currency, right? <-- correct
17:43:25 <CDB-Man_> > That would be a rare case in a book where transactions are recorded between two FX accounts. <-- not entirely sure what you mean, perhaps an example to help explain
17:45:25 <CDB-Man_> people in europe for example i would expect may have triple currencies. for ezample someone in switzerland hacing to deal with franc (home currency), euros (all their neighbours) and euro denominated stocks). in north america of course CAD and USD denominated stocks. Chinese Yuan stocks for people in HK. etc
17:45:43 <CDB-Man_> s/currencies/commodities -- to generalize it more
18:06:54 *** dtux has quit IRC
18:12:31 <CDB-Man_> this GAAP 4 example is testing my patience
18:14:44 <jralls> You got "rare" backwards: You stipulated that "fixing up" wouldn't apply to cases where the split already has a price. That's not going to be true if the transaction is conducted entirely in one currency, as is the case with your USD stocks purchased from a USD cash account unless you start the transaction from a CAD account to force the transaction currency to CAD. (Which in turn prices the stock in CAD, not necessarily what you want.)
18:15:32 *** bertbob has quit IRC
18:16:59 <CDB-Man_> Ah, okay
18:17:59 <CDB-Man_> I think there was a lack of clarity from me as well
18:18:18 <CDB-Man_> CAD > USD > SPY was a display of funds flow
18:18:18 *** bertbob has joined #gnucash
18:18:18 *** ChanServ sets mode: +v bertbob
18:18:29 <CDB-Man_> Rather than a single transaction with those 3 splits
18:19:02 <CDB-Man_> In other words, exactly a you say, a purchase of USD stock with USD cash without any CAD splits
18:21:05 <jralls> Right. Before last week I would have thought that the right way to compute the basis of the SPY in CAD would be to use the weighted average cost of the USD in CAD, but you corrected me that the right thing to do is to convert the USD back to CAD at that day's rate, then price the SPY in CAD also using that day's rate.
18:21:50 <jralls> Starting the transaction in a CAD account will do that, but I'm not sure that it makes your books clearer and it sure blows up pricing the SPY with F::Q.
18:22:42 <CDB-Man_> I will also upload my excel stock cost basis accumulator tool to really reinforce how this works
18:22:55 <CDB-Man_> And it will consider variances in FX
18:23:05 <CDB-Man_> But that's for after dinner. Which is right now!
18:23:21 *** Cork has quit IRC
18:23:56 <CDB-Man_> I can foresee that Chris will want to attempt to convert than accumulator tool into a scheme report
18:24:05 *** JayC has quit IRC
18:24:19 <CDB-Man_> The tool hinges on having access to daily historical rates
18:26:17 <jralls> As chris has said before, this needs to be handled at a lower level than reports. That means C++ rather than Scheme.
18:26:29 *** phoenix has quit IRC
18:26:32 <CDB-Man_> Ah, missed that if he said it
18:27:28 <jralls> It will probably require some other changes to GnuCash's accounting model design too.
18:28:06 <CDB-Man_> Indeed, and that's why I want a really solid GAAP example first, as a basis, before trying to map anything to GNUCash
18:28:16 *** JayC has joined #gnucash
18:28:17 *** ChanServ sets mode: +v JayC
18:28:31 <CDB-Man_> I understand Chris' desire to see a solution now, but like I mentioned last night, hold your horses!
18:30:07 *** Cork has joined #gnucash
18:37:35 <CDB-Man_> I should also add that all this has yet to take any consideration of FIFO into account for those countries whose tax requirements mandate it...
18:45:57 *** Aussie_matt has joined #gnucash
19:00:10 <CDB-Man_> And further note that tax often departs from GAAP, in several tax jurisdictions...
19:20:37 <shaggy> On my great endeavor to compile gnucash on my windows 10 machine (as I don't have linux) I'm getting stuck on both the master and maint with guile trying to do a load-extension operation on a dll, which is failing. Any help would be appreciated. The error is In procedure dynamic-link: file: "libgnc-gnome", message: "The specified module could not be found." (this is on maint, in master the file libgnc_html) I tried a bunch of thin
19:20:37 <shaggy> gs to no avail such as the Hacking readme to use nm to get at the modules (list came out empty...) I'm also seeing non-ASCII characters in the debugging (posts out there suggest libunistring, but we're using the latest as far as I can tell.) ex. In ice-9/boot-9.scm:
19:20:38 <shaggy> 705:2 19 (call-with-prompt _ _ #<procedure default-prompt-handleâ–’>)
19:34:28 *** dtux has joined #gnucash
19:37:40 *** TownsendHardware has joined #gnucash
20:32:11 *** jervin has quit IRC
20:32:29 *** jervin has joined #gnucash
20:35:29 *** jervin has quit IRC
20:36:55 *** jervin has joined #gnucash
21:14:52 *** User has quit IRC
21:32:45 *** jost has quit IRC
21:39:41 *** phebus has joined #gnucash
21:39:41 *** ChanServ sets mode: +v phebus
21:46:50 *** jost has joined #gnucash
23:31:19 *** o01eg has joined #gnucash
23:45:53 <CDB-Man_> chris: have you simply tried using my template?
23:51:08 <CDB-Man_> whoops, comment 79 was jralls
23:51:40 <CDB-Man_> jralls: have you tried plugging in your example into the template?