2018-01-26 GnuCash IRC logs

01:21:19 *** jotrago has joined #gnucash
01:30:26 *** fell has quit IRC
01:31:30 *** fell has joined #gnucash
02:01:40 *** codesmythe has quit IRC
02:23:53 *** marusich has quit IRC
02:25:55 *** fekepp1 has joined #gnucash
02:28:43 *** fekepp has quit IRC
02:28:44 *** fekepp1 is now known as fekepp
02:30:58 *** tlaxkit has joined #gnucash
02:32:59 *** Mechtilde has joined #gnucash
02:33:28 *** jotrago has quit IRC
02:33:34 *** jotrago has joined #gnucash
02:39:16 *** jotrago has quit IRC
02:39:21 *** jotrago has joined #gnucash
02:41:02 *** fekepp has quit IRC
03:00:40 *** fekepp has joined #gnucash
03:06:08 *** Mechtilde has quit IRC
03:34:37 *** gjanssens has joined #gnucash
03:34:37 *** ChanServ sets mode: +o gjanssens
03:35:00 <gjanssens> .
03:46:07 *** fabior has joined #gnucash
04:05:20 *** fabior has quit IRC
04:13:33 *** tlaxkit has quit IRC
05:29:59 *** fabior has joined #gnucash
06:18:34 *** User has joined #gnucash
06:32:01 *** User has quit IRC
06:36:21 *** Mechtilde has joined #gnucash
06:39:51 <gjanssens> jralls: I'm revising our HACKING file. It suggests devs can't use 'gdb /path/to/gnucash' but should use '/path/to/gnucash-gdb' instead. Is that still correct now you have removed the startup script for gnucash on OS X ?
06:45:41 *** gour has joined #gnucash
06:47:19 *** gour has left #gnucash
07:03:08 *** fabior has quit IRC
07:05:33 *** Jimraehl1 has joined #gnucash
07:06:16 *** Jimraehl1 has left #gnucash
07:15:05 *** oozer has joined #gnucash
07:22:30 *** gncbot sets mode: +o fell
07:23:04 *** Mechtilde has quit IRC
07:52:08 <warlord> .
08:07:13 <fell> warlord, wunderful: https://code.gnucash.org/docs/MASTER/
08:13:32 *** chris has joined #gnucash
08:17:50 <fell> (hello chris)
08:18:41 <chris> (hello 'fell)
08:19:18 <chris> I'm still brainstorming how exactly to generate .scm testing suite
08:19:52 <fell> what told rgmerk you?
08:20:13 *** chris has quit IRC
08:20:55 *** chris has joined #gnucash
08:21:38 <chris> ah nothing yet
08:23:00 <chris> but I wish to do this right and generalisable
08:24:46 <fell> At least I like your cleanup of the reports
08:28:03 <chris> thank you, there's a lot more that could be done
08:28:30 <warlord> fell: yeah, somehow the checkout repo got corrupted.
08:28:50 <chris> ah the wizard is here
08:33:35 <chris> warlord: another compatibility flag to fix book-closing adds more clutter!
08:47:37 *** oozer has quit IRC
08:57:35 <gjanssens> chris: I think a first step in starting a unittest framework is to make the code unit testable.
08:58:01 <gjanssens> You pointed out there are two big functions in the TR (the option generator and the renderer)
08:58:25 <gjanssens> I believe these are too big a chunks to sensibly unit test
08:58:55 <gjanssens> IIRC the renderer is subdivided in many smaller functions. But right now they are not exposed in the global context of the TR
08:59:41 <gjanssens> That would be one possible way to split up: move the renderer sub functions into the global scope of the file
09:00:12 <gjanssens> Or perhaps guile has mechnisms to reach those functions directly, but that's beyond my guile knowledge
09:00:46 <gjanssens> Then you could mock each sub function instead.
09:00:57 <gjanssens> That would reduce the number of possible variations to test.
09:03:29 <chris> agree... in retrospect, the big refactoring got rid of most of these top-level functions because I was tired of going back and forth, and sincerely believed that inlining them was preferable
09:04:06 <chris> I can break the renderer into multiple steps
09:04:20 <chris> and test each part with some customised options feeder
09:05:39 <gjanssens> Heh, we all learn by doing...
09:05:50 <chris> e.g. part one - (define options-list->get-selected-accounts), part two (define from-selected-accounts-get-splits), part three (define from-splits-list-make-table)
09:05:51 <gjanssens> I didn't consider unit testing either when I reviewed your work
09:08:25 <warlord> chris: i'm sure there is lots of clutter around. Of course all these "munge the data on read" functions can never go away, because you never know how old a data file you might want to read.
09:09:21 <chris> developers of previous reports e.g. net-barcharts.scm had created some specialised functions to calculate sums for intervals, and have upgraded them into one of the *-utilities.scm for use in only their report - this is rather annoying
09:09:30 <warlord> I've never been sure how to unit test a report. I feel it's more of an integration test required, which is much harder to script.
09:12:34 <gjanssens> chris: why is that annoying ? They mmay have genually believed the functions would be more generally useful but no other report eventually picked them up.
09:12:58 * gjanssens has no experience with integration tests...
09:13:05 <warlord> == gjanssens
09:13:38 <warlord> gjanssens: unit tests are to test individual functions. integration tests tend to test integration of multiple APIs or subsystems.
09:14:07 <warlord> I dont see how you could test a renderer without being able to feed it different sets of data, which is more of an integration test IMHO.
09:14:52 <warlord> I'm also not sure how one would test an options generator, short of just making sure it doesn't die when given reasonable inputs. But I'm not sure how you would test that the output looked okay.
09:15:48 <fell> running the w3c test?
09:15:59 <chris> I figured they were 'annoying' because they have special use that only the writer genuinely understands, and were not documented thoroughly enough to be useful elsewhere
09:17:02 <chris> ^ chris has thought of all the above meanings for unit testing reports
09:17:42 <gjanssens> chris: that's a fair enough definition of annoying :(
09:18:46 <chris> (1) send options with 'reconciled-date' #t/#f - tests whether the html includes the words "Reconciled Date"... (2) send options with 'sortkey=weekly' and daily transactions of $1 and tests whether the html includes "$7.00"
09:18:47 <chris> etc
09:20:20 <chris> prime example of an annoying function gnc:account-get-comm-value-interval only used in net-line/barchart.scm account-piecharts.scm - and this annoying function comes with its posse of helper functions
09:21:26 <gjanssens> warlord: well the renderer generates its output in several stages: there are parts that generate a header, a footer, a table, a table row,... then there are also parts that don't generate html like output but track totals and such. They all could in theory be tested in more detail before testing the whole. Although I don't know the exact structure of the TR code to really tell what would be a sensible split
09:25:22 <chris> if I had my way and time, I'd refactor all of them and reallocate each helper function into my own hierarchy :D
09:32:03 <gjanssens> chris: you have carte blanche :)
09:32:22 <chris> don't tempt me, wife will ask for divorce
09:32:57 <chris> but to be seirous the TR needs a genuine functional test more than anything
09:33:54 *** kus has joined #gnucash
09:36:18 <chris> in my mind, if the underlying Gnucash API can be trusted to be mostly stable, then TR will just need separation into logical steps as above (e.g. options->accountlist, accountlist->splitlist, splitlist-> filteredsplits, filteredsplits->html-table) and each can have a reasonable number of combination testing
09:39:48 *** fekepp has quit IRC
10:29:02 <warlord> But do we need scheme syntactic sugar for those methods, vs just calling the wrapped C/C++ APIs?
10:32:52 *** luc14n0 has quit IRC
10:32:57 *** luc14n0 has joined #gnucash
10:33:00 <chris> huh, the wrapped C APIs are inadequate for chris's requirements for TR... plus C does not do HTML
10:35:46 * chris needs to hit the sack
10:35:52 <chris> thanks all for valuable advice
10:36:04 <warlord> chris: If they are inadequate should they be extended?
10:36:40 <warlord> e.g., I see no reason to have a split->date scheme function when you can call xaccTransGetDate(xaccSplitGetTrans(s)) --- effectively.
10:37:20 <warlord> But yes, certainly an options->accountlist is PROBABLY something for scheme -- but one could imagine that python might want that too, making a C API a worthwhile effort.
10:37:33 *** oozer has joined #gnucash
10:42:19 <chris> hmm this means that options.scm gets converted to C and SWIGified
10:43:17 <chris> then python can be used for reports.
10:43:59 <chris> not my forte
10:44:12 <chris> ok need to go!
10:44:15 <chris> night all
10:44:17 <warlord> Oh, right, options are still a scheme construct. I keep forgetting that gjanssens only converted Prefs, not Options.
10:44:19 <warlord> Good night.
10:44:39 <gjanssens> Bye chris
10:44:44 *** chris has quit IRC
10:45:41 <gjanssens> warlord: yeah, options is still on the to do list...
10:47:14 <warlord> N oworries.
10:54:45 *** ArtGravity has joined #gnucash
11:20:07 *** Cuare has joined #gnucash
12:46:41 *** Mechtilde has joined #gnucash
13:03:32 <gjanssens> Yay, figured out why guile 2.2 was causing ci to break! I think we can now claim to support guile 2.2
13:03:52 <warlord> YAY! (What was it?)
13:10:28 <fell> Only after a test unit ;-)
13:16:56 <gjanssens> warlord: It was the test-cashflow-barchart unit test
13:17:39 <gjanssens> While it worked fine under guile 2.0, it broke under guile 2.2 because suddenly date formatting got locale sensitive
13:18:28 <gjanssens> So the test output would have dates in the form 27-01-18 instead of 27/01/18
13:18:45 <gjanssens> which the validation code expected.
13:19:23 <gjanssens> Don't know why this changed between the two guile versions, but explicitly setting locale to "C" at the start of the test fixed it.
13:19:46 <gjanssens> I discovered this solution in one of the equivalent tests that did work fine...
13:22:37 <fell> Huh, shouldn't C expect 01/27/18?
13:24:00 <fell> gjanssens ^
13:30:22 <gjanssens> fell: that's possible. That actual numbers aren't checked. Just that there should be 6 digits, grouped per 2 and separated by a slash
13:33:00 <fell> A covering test would run a loop for e.g. *_BE:"-",C:"/",de_DE:"."; ...
13:39:22 <gjanssens> fell: patches welcome :)
13:39:35 <gjanssens> I just fixed what was there
13:40:17 <fell> Today I try to understand https://wiki.gnucash.org/wiki/Building#Building:_CMake
13:59:34 *** MrKeuner has quit IRC
13:59:51 *** Mechtilde has quit IRC
14:00:38 <gjanssens> fell you may be interested in "cmake -G"Eclipse CDT4 - Ninja"
14:01:35 <gjanssens> (adding a few more options as needed)
14:01:55 <fell> Then I get only CDT files and no normal makefiles?
14:02:07 <gjanssens> That would tell cmake to generate project files for Eclipse
14:02:27 <fell> ninja sounds eo dangerous ;-)
14:03:04 <gjanssens> I'm not sure whether cmake will only build CDT files, but I suspect it would also generate the relevant ninja files
14:03:14 <fell> do you still prefer out of source or is a hidden build dir sufficient?
14:03:19 <gjanssens> I'd run it first in a separate build directory
14:05:02 <fell> BTW I defined my own git xclean, which ignores the eclipse files and dirs.
14:18:35 <gjanssens> fell: there is no real reason to keep your eclipse files in the source directory...
14:18:48 <gjanssens> I have just run the experiment
14:19:08 *** frakturfreak has joined #gnucash
14:19:32 <gjanssens> Here are the steps I took
14:20:01 <gjanssens> First a few directory definitions I'll use in the subsequent commands
14:20:16 <jralls> gjanssens: I don't ever use gnucash-gdb, so I don't know. Also Apple distributes https://lldb.llvm.org/ instead of gdb so it wouldn't do me much good.
14:20:44 <gjanssens> - srcdir: the source directory (your git clone of the gnucash repo)
14:21:09 <gjanssens> - builddir: the target directory in which to build gnucash and also where cmake will be run
14:21:31 <gjanssens> - wsdir: the eclipse workspace
14:21:45 <gjanssens> - installdir: where gnucash will be installed
14:22:12 <gjanssens> I suggest you keep the 4 directories seperate, none should be a subdirectory of any other
14:22:28 <gjanssens> You can group them if you like in one base directory
14:22:36 <gjanssens> So
14:22:48 <gjanssens> Step 1: clone gnucash into srcdir
14:23:04 <gjanssens> Step 2: make the builddir and wsdir
14:23:27 <gjanssens> Step 3: cd into builddir (I assume it's next to srcdir in basedir)
14:24:34 <gjanssens> Step 4: run cmake like so: cmake -DCMAKE_BUILD_TYPE=debug -G"Eclipse CDT4 - Ninja" -DCMAKE_INSTALL_PREFIX=../installdir ../srcdir
14:24:59 <gjanssens> Note I assume installdir is also next to srcdir and builddir. If not adjust paths as needed
14:25:45 <gjanssens> Step 5: start eclipse and open/create wsdir workspace. Again, be sure builddir, srcdir and installdir are not subdirectories of wsdir
14:26:18 <gjanssens> Step 6: once the workspace is open in eclipse choose File->Import...
14:27:07 <gjanssens> Step 7: Select "General->Existing Projects into Workspace" as import option and click next
14:28:00 <gjanssens> Step 8: As "root directory" choose builddir, make sure "Copy to workspace" is *not* checked and click finish
14:28:27 <gjanssens> Wait a while and voila, eclipse is ready for gnucash development with cmake and ninja-build
14:29:04 <gjanssens> This method will not write a single file in the source directory so you will be free to use all git commands there without risking to damage your eclipse project.
14:29:22 <fell> Interesting approach
14:30:18 <gjanssens> Yes, I found some help on SO for the importing part: https://stackoverflow.com/questions/11645575/importing-a-cmake-project-into-eclipse-cdt#11665963
14:30:54 <gjanssens> Feel free to copy this to a wiki page that explains how to develop gnucash on eclipse
14:31:53 <gjanssens> Oh, and if you prefer to continue with Makefiles rather than Ninja, you can change -G"Eclipse CDT4 - Ninja" to -G"Eclipse CDT4 - Unix Makefiles"
14:32:42 <gjanssens> jralls: ok, then I should probably just drop the extra OS X specific remark from the HACKING file
14:32:55 <jralls> OK.
14:35:46 <gjanssens> Oh, I already did
14:36:02 <gjanssens> Guess I got carried away this morning...
14:38:10 <jralls> No worries.
14:56:46 *** bob_ has joined #gnucash
15:00:04 *** gjanssens is now known as gjanssens_afk
15:02:01 *** Mechtilde has joined #gnucash
15:44:03 *** KaiForce has joined #gnucash
15:49:17 *** frakturfreak has quit IRC
15:51:42 *** Grav has joined #gnucash
15:52:33 *** ArtGravity has quit IRC
16:00:18 *** fabior has joined #gnucash
16:08:32 *** Mechtilde has quit IRC
16:35:46 *** frakturfreak has joined #gnucash
16:40:17 <fell> hm, I installed a gmock package pair and still get
16:40:18 <fell> CMake Error at common/cmake_modules/GncAddTest.cmake:168 (MESSAGE):
16:40:19 <fell> GMOCK not found. Please install it or set GMOCK_ROOT
16:45:44 *** bob_ has quit IRC
16:48:59 *** meb has quit IRC
16:53:38 <fell> Anyway, good night, until later.
16:53:42 *** fell is now known as fell_afk
17:33:55 *** fabior has quit IRC
17:34:55 *** O01eg has quit IRC
17:40:51 *** gjanssens_afk has quit IRC
17:45:01 *** KaiForce has quit IRC
17:51:32 *** oozer has quit IRC
17:52:02 *** O01eg has joined #gnucash
17:52:23 *** oozer has joined #gnucash
18:07:23 *** oozer has quit IRC
18:09:21 *** jonas has quit IRC
18:10:16 *** oozer has joined #gnucash
18:44:43 *** jonas has joined #gnucash
18:45:07 *** Grav has quit IRC
18:57:51 *** frakturfreak has quit IRC
21:05:27 *** Derperperd has quit IRC
21:05:51 *** Derperperd has joined #gnucash
21:10:18 *** oozer has quit IRC
22:02:41 *** kus has quit IRC
23:57:21 *** Derperperd has quit IRC
23:57:38 *** Derperperd has joined #gnucash