2017-12-29 GnuCash IRC logs
00:01:42 *** CDB-Man has quit IRC
00:02:08 *** CDB-Man has joined #gnucash
00:04:11 *** storyjesse has joined #gnucash
00:34:18 *** pilotauto has quit IRC
01:18:16 *** storyjesse has quit IRC
01:22:33 *** Mechtilde has joined #gnucash
01:30:14 *** fell has quit IRC
01:31:17 *** fell has joined #gnucash
01:31:37 *** chris has joined #gnucash
01:32:21 <chris> .
01:32:22 <gncbot> chris: Sent 10 hours and 3 minutes ago: <lmat> Regarding gncBillTermComputeDueDate if I'm understanding you correctly, the only uses would be by end users. Yeah, I'll just convert them, and our end users can ask for help if they need it.
01:32:23 <gncbot> chris: Sent 5 hours and 25 minutes ago: <jralls> Have you run tests on your time64-ftw work? I'm getting failures in test-category-report, test-standard-net-barchart, and test-standard-net-linechart.
01:32:45 <chris> lmat- exactly what I thought, this function is used by C only
01:35:45 <chris> jralls - yes I found this failure - caused by f23cf27 which I'm 99% sure fixes another 1970 bug; I think I'll eventually either remove this commit and do further testing or amend the unit tests
02:06:47 *** fekepp has joined #gnucash
02:14:27 *** Mechtilde has quit IRC
02:57:28 *** hoijui has joined #gnucash
03:28:36 *** fekepp has quit IRC
03:28:53 *** fekepp has joined #gnucash
03:40:39 *** gjanssens has joined #gnucash
03:40:39 *** ChanServ sets mode: +o gjanssens
04:23:56 *** Mechtilde has joined #gnucash
04:44:25 *** fabior has joined #gnucash
04:50:37 *** fekepp has quit IRC
05:00:37 *** noah has joined #gnucash
05:03:23 *** fekepp has joined #gnucash
05:08:20 *** noah has quit IRC
05:15:55 <gjanssens> .
05:18:21 <chris> jralls - my f23cf27 in time64-ftw does fix a bug and fixes the networth barchart for dates < 1970 - I'll try fix the unit tests
06:04:25 *** storyjesse has joined #gnucash
06:21:22 *** noah has joined #gnucash
06:25:05 *** noah has quit IRC
06:25:46 *** noah has joined #gnucash
06:51:20 *** fekepp has quit IRC
06:53:02 *** fekepp has joined #gnucash
07:01:03 *** noah has quit IRC
07:16:14 *** User has joined #gnucash
07:24:17 *** fekepp has quit IRC
07:49:00 *** fabior has quit IRC
07:54:29 *** noah has joined #gnucash
08:23:59 *** Mechtilde has quit IRC
08:49:44 *** noah has quit IRC
08:54:40 *** noah has joined #gnucash
09:12:07 *** noah has quit IRC
09:13:41 *** karelk has joined #gnucash
09:34:54 *** Jimraehl1 has joined #gnucash
09:37:15 <lmat> jralls: Actually, probably struct time64 { int64_t val; }
09:37:30 <lmat> or... struct kvp_time { int64_t val; };
09:41:21 *** fabior has joined #gnucash
09:47:42 *** hoijui has quit IRC
10:04:21 *** kael has joined #gnucash
10:20:48 *** soeffing has joined #gnucash
10:23:25 *** kael has quit IRC
10:48:32 *** ArtGravity has joined #gnucash
11:02:22 *** Mechtilde has joined #gnucash
11:07:23 *** soeffing has quit IRC
11:47:59 *** Mechtilde has quit IRC
11:51:09 *** Mechtilde has joined #gnucash
12:01:13 *** kus has joined #gnucash
12:01:37 *** kael has joined #gnucash
12:07:40 *** fabior has quit IRC
12:09:05 *** fabior has joined #gnucash
12:19:46 *** soeffing has joined #gnucash
12:20:29 *** storyjesse has quit IRC
12:30:18 *** kael has quit IRC
12:49:20 <gjanssens> jralls: do you think 10 unstable releases would be sufficient ? Or do you expect us to require more ?
12:50:54 * gjanssens is checking the old releases...
12:51:10 <gjanssens> Hmm, we had 11 for 2.5 so 10 is probably a bit sharp.
13:01:21 <jralls> gjanssens: Yeah, it depends on how testing goes in the last few weeks before the major release.
13:05:14 <jralls> chris: Reverting f23cf27 does indeed allow the tests to pass.
13:07:29 <gjanssens> jralls: while thinking about release stuff like the version numbers it occurred to me it may be useful to add release tags in gnucash-on-windows and gnucash-on-osx as well to indicate which exact commit was used to generate the platform installers.
13:08:03 <gjanssens> I'm not sure our nightly build server needs updating to take this into account
13:08:55 <gjanssens> To start we can simply do it after the fact (that is after it did a successful release build)
13:09:18 <jralls> We could add tags, though there's generally a commit named "Release x.y.z" for updating gnucash.modules and on Mac Info.plist.
13:09:48 <jralls> Would tags add anything useful?
13:09:51 <gjanssens> Oh, indeed :S
13:10:39 <gjanssens> On the other hand the same is true in the gnucash repo itself.
13:10:54 <gjanssens> Does the gnucash-on-windows get a similar typical release commit ?
13:11:39 <gjanssens> Yes it does
13:11:55 <gjanssens> Silly me. We use jhbuild on Windows as well now
13:12:12 <jralls> gjanssens: in (min-date (car (list-min-max dates <))), what does the trailing '<' do?
13:12:32 <gjanssens> Wow. Let me check
13:13:03 *** Mechtilde has quit IRC
13:14:23 <gjanssens> jralls: It's an operator that is passed as an argument. The list-min-max function uses this operator to sort the dates passed in.
13:15:11 <gjanssens> list-min-max is defined as (define (list-min-max list ordered?) ....
13:15:54 <gjanssens> It's body then uses (ordered? a b) which guile will interpret as (< a b) in the case above
13:16:16 <gjanssens> Looks like advanced guile stuff...
13:17:26 <jralls> It's probably perfectly clear to proper schemers/lispers. I have trouble getting my brain to accept that an operator can be used as a parameter.
13:18:01 <jralls> Though I guess it's no different from passing a function pointer as a callback in C.
13:27:18 <gjanssens> Yes, it's surprising for me as well. I had to go read the code to understand it. And by chance I saw chris use a similar technique in his improved TR, so I happened to encounter it twice in one week :)
13:31:29 <gjanssens> jralls: does it ever happen there are fixup commits after the one updating gnucash.modules ? Or do you then automatically/always update gnucash.modules again as well ?
13:37:06 <jralls> The release builds are from the release tarball, so the timing of the commits isn't really relevant. I suppose that means I could commit and push the change to gnucash.modules then discover that I needed to update a dependency and push another change. If I'm building entirely on my own VMs then I just won't push anything until everything is ready, but doing the windows build on Derek's VM means that I have to push the rele
13:37:06 <jralls> ase commit and then go run the release build from that.
13:40:08 *** Mechtilde has joined #gnucash
13:40:34 *** kael has joined #gnucash
13:40:49 *** meb has quit IRC
13:42:50 *** kael has quit IRC
13:44:08 *** kus has quit IRC
13:45:32 *** Mechtilde has quit IRC
13:55:25 <soeffing> jralls: would you have a few minutes to talk about the plans for the price sources in the report system, and particularly bug #775368 ?
13:57:21 <jralls> soeffing: Not right now, but 775368 is on my list to do something about.
14:00:00 <soeffing> could you briefly point me in the direction you'd like to take? Reintroduce the old way of calculating the prices? I just got the latest sources today and was trying to understand the code and your changes, wondering if I might be able to help somehow..
14:00:26 <soeffing> Though I figured that guile is not my friend :-/
14:02:30 <soeffing> oth, if you already have an idea how to proceed I don't want to spend time going in a completely different direction
14:02:32 <jralls> Mine either. :-(
14:03:48 <jralls> I don't have a strategy yet, but I think that the "right" answer is probably something like the original one but restricted to the account that one is balancing at the moment.
14:09:33 *** Mechtilde has joined #gnucash
14:10:26 *** frakturfreak has joined #gnucash
14:12:06 *** kael has joined #gnucash
14:19:02 <soeffing> jralls: thanks. Seems that this will result in exchange rates finally being calculated on a per account basis? i.e. rates for the same commodity could be different if used in more than one account? Wow, that's getting complicated now, I see the point...
14:19:25 <soeffing> When you find the time to look into that, I'd be more than glad to join the discussion..
14:23:59 <jralls> soeffing: Right. I hope some time in January.
14:27:05 <soeffing> thanks!
14:27:58 *** bertbob has quit IRC
14:30:56 * lmat is ruthlessly rooting out timespec.
14:35:47 *** bertbob has joined #gnucash
14:39:02 *** bertbob has quit IRC
14:43:33 * jralls applauds lmat!
14:43:51 <gjanssens> lmat: \o/
14:44:00 * jralls just hopes he doesn't get lost in the weeds...
14:44:27 <lmat> I have a commit that passes tests (except the scm ones)...vide my time64-ftw :-)
14:44:50 <lmat> I had to use a very sharp machete on the weeds... I'm hopeful there isn't too much collateral damage.
14:44:57 <lmat> got another commit coming...
14:44:57 <jralls> lmat: You need to pull in chris's changes too.
14:46:24 <lmat> jralls: Yes, I'm on top of his time64-ftw.
14:48:32 *** fabior has quit IRC
14:49:39 <jralls> lmat: You can get all tests to pass by reverting f23cf27 or maybe rebasing without it. I've been working on the "right" fix for a couple of hours and I've made a little progress but I think I should get the other PRs and patches in instead.
14:50:28 <lmat> okay
14:54:21 *** bertbob has joined #gnucash
14:54:45 <jralls> gjanssens: I think that timespec cleanup is something that we can keep working on after "feature freeze". Do you agree?
15:02:57 *** yuriks has quit IRC
15:10:29 * chris feels proud to be here, although always behind in conversation
15:11:50 *** kael has quit IRC
15:12:21 *** kael has joined #gnucash
15:13:49 <jralls> chris: I found one of the problems exposed by f23cf27: In category-barchart.scm, line 339, gnc:time64-end-day-time should be gnc:time64-start-day-time.
15:15:27 <jralls> chris: Unfortunately that's not the only one and even test-standard-category-report's asset-test still fails.
15:19:51 <chris> jralls good catch. this passed me by during conversion.
15:24:01 <chris> jralls struggling to debug the unit tests- is ninja check the only command to run them? there's no debug output that can be triggered?
15:26:42 <chris> it's also in my TODO list for January to go through the price-calculators
15:28:58 <gjanssens> jralls: TBH I haven't really followed the timespec cleanup. How far is that "feature"? I presume you'd want it in before 3.0 (using the new numbering scheme already :)
15:29:06 <jralls> chris: https://pastebin.com/JTJHcUWZ Note that $SRCROOT points to the parent directory of the gnucash sources.
15:30:21 <chris> lmat there's a timepair function that I could use time64 for - gnc_pricedb_lookup_day and gnc_price_set_time
15:30:30 <jralls> gjanssens: I'm thinking that it's not a feature (hmm, that doesn't sound right), it's maintenance work on completing the work begun by creating time64.
15:34:04 <chris> there's still a crasher by running Report > Business > {Employee|Customer|Vendor} Report that I found while testing t64 -- this crasher has existed for a while back.
15:37:34 *** yuriks has joined #gnucash
15:41:24 <gjanssens> jralls: oh, and the time64 was introduced a while back in your refactoring of gnc-date-time, right ?
15:42:16 <gjanssens> Then yes, I agree it's a continuation of work already started and waiting to be finished.
15:43:16 <gjanssens> Ideally it should come with additional unit tests in many areas where we replace timespec with time64, but I realize this is about every corner of the code :(
15:44:26 *** yuriks has quit IRC
15:46:09 <jralls> gjanssens: While I agree that every corner of the code needs unit tests, in the case of timespec->time64 it's just dropping the always-0 tv_nsec field so there's no real change to anything. And since it is indeed every corner of the code a lot of the existing unit tests get changed along with the rest.
15:47:10 *** yuriks has joined #gnucash
15:47:28 <gjanssens> jralls: good
15:51:47 * gjanssens is quite happy with the TZ fixes from a couple of weeks back
15:52:18 <gjanssens> There's no need any more to remember to add TZ=LA-timezone-I-always-forget before ninja-build check
15:56:40 <jralls> Indeed. I keep forgetting to remove that from the travis build instructions.
15:59:32 * lmat just remembered to remove it from his personal build script. Thanks!
16:00:40 <chris> lmat just a minor observation looking through your ongoing time64 - we created a time64 gncEntryGetDateTT a couple of weeks ago, which means scheme will have minor collateral damage temporarily until I fix
16:01:16 <jralls> chris: The crash is from qof-book-get-option being called with book = NULL from somewhere in scheme.
16:05:38 <chris> jralls yes I figured that out but can't find it within the report scm - I'll see about debugging this in next couple weeks
16:05:49 <lmat> chris: okay. on my time64-ftw, gncEntryGetDateTT -> gncEntryGetDate (and there is no timespec version).
16:06:05 <lmat> chris: and I have taken down the other time64-required variants.
16:06:33 <jralls> chris: It's in the option setting code in app-utils, either options.scm or business-options.scm.
16:06:49 <lmat> chris: Oh yeah, are you going to be able to make tests pass on your time64-ftw? jralls identified a commit that, when reverted, allows the tests to pass.
16:08:40 <chris> lmat yes I'm aware of this commit - maybe best revert it because it's technically a bugfix (for dates<1970) and not strictly timepair->time64 related -- I can't figure out yet what is failing in the tests
16:09:38 <lmat> chris: Okay, I'll rebase it out on my time64-ftw branch.
16:12:45 *** Mechtilde has quit IRC
16:20:25 <lmat> chris: Just pushed. Tests pass on there.
16:30:29 <chris> lmat ok np - still not sure how to perform this joint branch - I'll fix scheme breakages caused by API changes, which means your branch won't compile until I fix them? or, alternatively you & jralls can avoid renaming API until this project is done? (which means gncEntryGetDateTT should stay for now, and when it's all done we can do a mass-rename) ?
16:36:16 <lmat> chris: hmm... I'm working on top of your time64-ftw (rather than back behind where I was working). I guess that means I'll only fix any name breakages that are revealed by unit tests (which may not be very many).
16:36:22 <lmat> chris: Perhaps I'll refrain from renaming functions then.
16:38:38 <chris> ok
16:51:49 *** hoijui has joined #gnucash
16:52:41 <jralls> chris: Found it. owner-report.scm line 760 calls (gnc:options-fancy-date book) without setting book.
16:55:27 <jralls> Hmm, that's not quite true. book is set on the line before with (gnc-account-get-book account), and account is set with (opt-val owner-page acct-string). I think that's probably what's not getting set.
17:08:11 *** karelk has quit IRC
17:11:56 <jralls> chris: How do I test if book is NULL? I want to do (if book (gnc:options-fancy-date book)), but that ran it anyway. BTW, it's in a let* block.
17:15:02 <chris> jralls: there's (null? book) but it may not match C's null exactly - in scheme null? means empty-list '()
17:20:24 <lmat> TODO: create a template for adding things to kvp value so that we don't have to use gvalue ><
17:21:17 <jralls> Yeah, and a lot of other places. GValue is pretty evil.
17:23:11 <lmat> Opaque black box where useful data go to hide :'(
17:25:16 <chris> ok gentlemen will be out all day mountaineering :)
17:25:21 *** chris is now known as chris_away
17:26:51 <jralls> chris_away: Is time64-ftw at a good point to merge?
17:28:05 *** ArtGravity has quit IRC
17:29:02 <chris_away> jralls - right now, no :) it uses API which will be rendered obsolete when functions are renamed (eg gncEntryGetDateTT->gncEntryGetDate); there are still residual timepairs unrelated to reports (eg gnc-pricedb-lookup-day); it modifies the old transaction.scm which has just been upgraded
17:33:13 <chris_away> perhaps I'll ask lmat to convert gnc-pricedb-lookup-day and gnc-price-set-time to time64 ASAP -- and of course the commit f23cf27 must be removed. I'll aim to clean all this up tonight and let you know when it can be merged
17:34:12 <jralls> chris_away: OK, have a good hike!
17:41:59 *** gjanssens has quit IRC
17:44:24 *** chris_away has quit IRC
18:04:32 *** Mechtilde has joined #gnucash
18:16:26 *** hoijui has quit IRC
18:49:57 *** kael has quit IRC
19:06:16 *** Mechtilde has quit IRC
19:16:13 *** soeffing has quit IRC
19:47:37 *** frakturfreak has quit IRC
21:39:42 *** User has quit IRC
23:09:28 *** kus has joined #gnucash
23:40:26 *** storyjesse has joined #gnucash
23:42:14 *** kael has joined #gnucash