2023-06-27 GnuCash IRC logs

00:17:20 *** Milou[m] has joined #gnucash
00:19:11 *** sunyibo[m] has joined #gnucash
00:21:33 *** Ablu[m] has joined #gnucash
00:25:29 *** PeterScholtens[m] has joined #gnucash
01:15:19 *** fell has quit IRC
01:15:47 *** jervin has quit IRC
01:16:37 *** fell has joined #gnucash
01:16:37 *** ChanServ sets mode: +o fell
01:21:51 *** gandalf has joined #gnucash
04:27:35 *** jralls has quit IRC
04:57:45 *** bertbob has quit IRC
05:03:05 *** bertbob has joined #gnucash
05:03:06 *** ChanServ sets mode: +v bertbob
06:20:41 *** narman has joined #gnucash
07:29:45 *** Aussie_matt has joined #gnucash
09:44:41 *** giuseppef has quit IRC
10:09:41 *** jralls has joined #gnucash
10:09:41 *** ChanServ sets mode: +o jralls
10:09:42 *** gandalf1 has joined #gnucash
10:10:09 *** gandalf has quit IRC
10:10:09 *** gandalf1 is now known as gandalf
10:23:39 *** cproo12 has joined #gnucash
10:23:39 *** ChanServ sets mode: +v cproo12
11:04:47 *** Aussie_matt has quit IRC
12:29:05 *** cproo12 has quit IRC
12:58:23 *** ArtGravity has joined #gnucash
12:58:23 *** ChanServ sets mode: +v ArtGravity
13:24:04 *** palerider has joined #gnucash
13:24:14 *** palerider has left #gnucash
13:33:59 <jralls> .
14:28:13 *** gandalf1 has joined #gnucash
14:28:40 *** gandalf has quit IRC
14:28:41 *** gandalf1 is now known as gandalf
14:30:42 *** gour has quit IRC
14:32:09 *** gour has joined #gnucash
14:32:09 *** ChanServ sets mode: +v gour
15:10:13 <Simon> the test file libgnucash/backend/xml/test/test-files/xml2/every.gml2 has transactions where a stock is the currency
15:10:35 <Simon> xaccSplitSetValue() thinks the denominator is 1 instead of 100000 because it doesn't expect that scenario
15:10:53 <Simon> if it detected this it could use the right denominator for the value
15:11:33 <Simon> is it normal for debug messages to leak gnc_numeric_to_string() allocations?
15:13:09 <jralls> Simon, "normal" makes it a loaded question. ;-) Debug messages *shouldn't* leak, but past contributors have been lazy.
15:13:55 *** gandalf has quit IRC
15:18:25 <jralls> As for xaccSplitSetValue getting the denominator, it uses get_currency_denom that in turn uses the account's common_currency SCU. For non-currency commodidties the common_currency is the commodity of the first parent denominated in a currency.
15:22:33 <Simon> some of the macros in qoflog.h for _MSC_VER have invalid syntax and will never compile
15:23:13 <Simon> it is annoying not to have an easy way to check if debug logging is enabled and then do a debug log without checking again :/
15:23:34 <Simon> so I either allocate/deallocate something when not debugging, or have to check twice when debugging
15:24:04 <jralls> OK, So? There's tons of unmarked stuff that won't compile with MSVS too.
15:25:37 <jralls> qof_log_check(QofLogModule, QofLogLevel)
15:25:52 <Simon> __attribute__(cleanup) would be useful in code that isn't C++ yet
15:26:01 <Simon> the problem is not the check but the DEBUG()
15:26:19 <Simon> unless I define another name for DEBUG()
15:27:52 <jralls> Does clang support __attribute__((cleanup(function)))?
15:28:03 <Simon> yes
15:28:08 <Simon> no supported by msvc
15:28:27 <Simon> actually it isn't ideal
15:28:40 <Simon> because I think it'll call g_free() unconditionally
15:28:48 <Simon> even when not debugging
15:29:27 <jralls> According to https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#:~:text=The%20cleanup%20attribute%20runs%20a,type%20compatible%20with%20the%20variable. it calls whatever function you pass to it.
15:30:14 <Simon> yes but the problem is I don't want the overhead of calling g_free(NULL) if not debugging
15:30:27 <Simon> in some places there are 3 or 4 of these
15:30:59 <jralls> As for the DEBUG macro, it also calls qof_log_check(log_module, QOF_LOG_DEBUG). So just wrap your allocation and free clauses in that too.
15:31:03 <Simon> if I want to just call g_free(NULL) unconditionally I can already do that with (string_ptr = ...) in the printf
15:31:28 <Simon> if (DEBUG_LOGGING) {
15:31:30 <Simon> char *string_ptr = gnc_numeric_to_string (exchange_rate);
15:31:32 <Simon> PDEBUG("exchange_rate is %s", string_ptr);
15:31:34 <Simon> g_free (string_ptr);
15:31:36 <Simon> }
15:31:55 <Simon> I made PDEBUG() an unconditional DEBUG(), which is consistent with PERR() and PWARN() but not PINFO() which is conditional
15:32:49 <jralls> That should work.
16:08:45 <Simon> argh
16:09:11 <Simon> need to do something about the every.gml2 file
16:09:26 <Simon> the canonical version has transaction values of X/1 where X>1
16:09:43 <Simon> - <split:value>-2684000/100000</split:value>
16:09:44 <Simon> + <split:value>-27/1</split:value>
16:10:05 <Simon> is this ok?
16:10:08 <jralls> No.
16:11:07 <Simon> could you look at https://github.com/Gnucash/gnucash/pull/1694 and work out what to do then
16:11:19 *** Robert847 has joined #gnucash
16:11:19 *** ChanServ sets mode: +v Robert847
16:11:26 <Simon> if every2.gml is loaded and then saved, it loses its split values like that
16:11:55 <Simon> specifically because xaccSplitSetValue() uses the currency denominator 1 instead of the commodity denominator 100000
16:12:46 <jralls> As it should, values must be currencies. The problem would be that the currency SCU is 1 instead of 100.
16:13:31 <Simon> there are far more than the instances of xaccSplitSetValue() being logged
16:13:31 <jralls> This sounds like the problem chris is complaining about in invoices.
16:13:52 <Simon> diff libgnucash/backend/xml/test/test-files/xml2/every.gml2 libgnucash/backend/xml/test/test-files/xml2/every.gml2-canonical
16:15:13 <Simon> everything in that file is in currency IRR
16:15:34 <Simon> which has SCU 1
16:22:06 *** Robert847 has quit IRC
16:22:56 *** Robert847 has joined #gnucash
16:22:56 *** ChanServ sets mode: +v Robert847
16:27:03 <Robert847> I crashed Pidgin so I am starting over. Release 4.8 of GnuCash CSV importer does not like dates in the form "Apr 23, 2023". Does release 5.3 have the same problem?
16:32:43 <Simon> FAILURE compare_compressed_files /Users/runner/work/gnucash/gnucash/libgnucash/backend/xml/test/test-load-save-files.cpp:169 /Users/runner/work/gnucash/gnucash/libgnucash/backend/xml/test/test-files/xml2/ms-money.gml2-canonical and
16:32:45 <Simon> /Users/runner/work/gnucash/gnucash/libgnucash/backend/xml/test/test-files/xml2/ms-money.gml2-test-compressed~ are different
16:32:50 <Simon> I have no easy way of testing that
16:33:05 <Simon> for some reason only one of the files is failing?
16:34:14 <jralls> Robert847 I don't think any of the date logic has changed.
16:35:44 <Robert847> the closest format is mm-dd-yyyy, which is not working unless I manually change the date to something like 04/23/2023 before importing.
16:36:24 <jralls> Simon, I guess you're trying to get rid of the numeric error GNC_ERROR_OK in converting errors. Changing out IRR for some currency with an SCU of 100 strikes me as the most straightforward way.
16:36:40 <Simon> I'm not trying to do that
16:36:53 <Simon> I need a copy of the file equivalent to it being saved, to test saving
16:37:19 <Simon> (I'm not modifying the original file)
16:37:36 <Simon> whether it's IRR or USD doesn't really matter, it's still going to truncate those values in some way
16:38:17 <Robert847> TY jralls
16:38:55 *** Robert847 has left #gnucash
16:39:40 <jralls> Simon, Ah, I see. That's a very brittle way to test.
16:41:11 <Simon> yes but there should be *a* test of saving and I need to know it has saved correctly
16:41:37 <Simon> and if the output has changed it should really be reviewed to understand why
16:41:45 <Simon> in case it's unintended
16:43:22 <jralls> Right, but it should be a round-trip test, and it should be with something in the current file format. Those xml/test/test-files examples are very old schemas intended to show that GnuCash can still read the old formats.
16:45:17 <jralls> It's not at all an error that GnuCash would change them.
16:46:09 <Simon> I didn't say it wasy
16:46:16 <Simon> I said it write something *different* it might be
16:46:44 <Simon> can you provide a sample file that can be used for this testing?
16:46:58 <Simon> I will change it to only run on specific files
16:52:56 <jralls> Simon, how about https://gist.github.com/jralls/1a55f8bbc50647e8afdc75ac2c2d6cce
17:01:05 *** gour has quit IRC
17:03:24 <Simon> should the timezone in the file be +0000 for everyone?
17:03:59 <Simon> <invoice:opened>
17:04:01 <Simon> - <ts:date>2010-12-07 00:00:00 -0800</ts:date>
17:04:03 <Simon> + <ts:date>2010-12-07 08:00:00 +0000</ts:date>
17:04:05 <Simon> </invoice:opened>
17:04:07 <Simon> <invoice:posted>
17:04:09 <Simon> - <ts:date>2010-12-07 00:00:00 -0800</ts:date>
17:04:11 <Simon> + <ts:date>2010-12-07 08:00:00 +0000</ts:date>
17:04:13 <Simon> </invoice:posted>
17:05:08 <Simon> even if I set TZ=US/Pacific it still changes them
17:06:49 <jralls> Hmm, yes, ISTR removing the local TZs from the save a few years ago.
17:09:34 <jralls> The time should be 10:59:00 too to keep the date from jumping around in different TZs. If you look at a transaction posted date you might see that change.
17:10:47 <Simon> yes:
17:10:49 <Simon> <trn:date-posted>
17:10:51 <Simon> - <ts:date>2018-02-23 02:59:00 -0800</ts:date>
17:10:53 <Simon> + <ts:date>2018-02-23 10:59:00 +0000</ts:date>
17:10:55 <Simon> </trn:date-posted>
17:13:16 <jralls> OK, so that file is from between the two. Looks like we need the business dates fixed to use neutral_time. Nobody's complained so I guess posting bills & invoices on vacation isn't as common as paying household bills.
18:38:03 *** jervin has joined #gnucash
19:43:06 *** jervin has quit IRC
19:51:02 *** Aussie_matt has joined #gnucash