2019-12-08 GnuCash IRC logs
00:02:48 *** Gerd has quit IRC
00:22:33 *** Mechtilde has joined #gnucash
00:27:45 *** Mechtilde has quit IRC
00:41:58 *** Mechtilde has joined #gnucash
00:42:44 *** Gerd has joined #gnucash
00:44:45 *** FH_thecat has quit IRC
01:05:13 *** Gerd has quit IRC
01:05:58 *** FH_thecat has joined #gnucash
01:07:25 *** sbluhm has joined #gnucash
01:07:25 *** ChanServ sets mode: +v sbluhm
01:12:40 *** sbluhm has quit IRC
02:31:55 *** sbluhm has joined #gnucash
02:31:56 *** ChanServ sets mode: +v sbluhm
02:40:10 *** sbluhm has quit IRC
02:54:37 *** Gerd has joined #gnucash
03:02:38 *** obscurans has quit IRC
03:05:38 *** obscurans has joined #gnucash
03:06:04 *** ChanServ sets mode: +v obscurans
03:19:55 *** omnireq_ has quit IRC
03:20:05 *** omnireq_ has joined #gnucash
03:22:46 *** FH_thecat has quit IRC
03:33:04 *** Gerd has quit IRC
03:36:33 *** Gerd has joined #gnucash
03:41:25 *** omnireq_ has quit IRC
03:42:15 *** omnireq_ has joined #gnucash
03:53:37 *** sbluhm has joined #gnucash
03:59:48 *** Gerd has quit IRC
04:03:25 *** omnireq_ has quit IRC
04:04:56 *** omnireq_ has joined #gnucash
04:05:45 *** pohly has joined #gnucash
04:19:02 *** gjanssens has joined #gnucash
04:19:03 *** ChanServ sets mode: +o gjanssens
04:25:55 *** omnireq_ has quit IRC
04:26:06 *** omnireq_ has joined #gnucash
04:32:44 *** Gerd has joined #gnucash
04:57:05 *** Gerd has quit IRC
06:02:57 *** FH_thecat has joined #gnucash
06:31:09 *** Han has joined #gnucash
06:52:44 *** chris has quit IRC
07:00:42 *** Mechtilde has quit IRC
07:01:05 *** Han has quit IRC
07:11:06 *** chris has joined #gnucash
07:11:06 *** ChanServ sets mode: +v chris
07:14:56 *** Mechtilde has joined #gnucash
07:21:29 *** FH_thecat has quit IRC
07:25:50 <gjanssens> .
07:26:37 *** sbluhm has quit IRC
07:27:27 <chris> gjanssens merging maint to master: gnc-ui-util.c cannot access gnc-features.c functions. I suppose this is a benign side effect of your recent changes? I can safely #include "gnc-features.h" in gnc-ui-util.c ?
07:30:06 *** fabior has joined #gnucash
07:32:34 *** oozer has joined #gnucash
07:32:41 *** sbluhm has joined #gnucash
07:36:01 *** oozer has quit IRC
07:37:30 <gjanssens> chris: gnc-features.h lives in engine, gnc-ui-utils.c in app-utils
07:37:52 <gjanssens> app-utils is allowed to depend on engine, so yes you can safely include gnc-features.h in there
07:38:17 <chris> is there a canonical hierarchy that I can rely on?
07:38:47 <chris> (the reason for above is the unreversed-budget work needs further amendments for master)
07:40:18 *** oozer has joined #gnucash
07:59:00 <gjanssens> (Got called away for a minute...)
07:59:41 <gjanssens> In theory you should additionally validate that the build rules for app-utils are properly set up to find the headers and libraries in engine, but in practise that's already done so no need to worry about this.
08:00:39 <gjanssens> The "formal" hieararchy is core-utils/backends/engine/app-utils
08:00:49 <gjanssens> But with the move to cmake this has loosened a bit
08:01:13 <gjanssens> In cmake we define targets and targets depend on other targets
08:02:16 <gjanssens> In the cmake rules for libgncmod-app-utils you'll find this target depends on the gnc-engine target for example
08:02:44 <gjanssens> That in turn means gnc-engine can't depend on the gncmod-app-utils target.
08:07:56 <chris> which CMake file are you referring to/
08:10:01 <gjanssens> Sorry - https://github.com/Gnucash/gnucash/blob/master/libgnucash/app-utils/CMakeLists.txt#L74
08:10:38 <gjanssens> This list of libraries is later passed to the target_link_libraries command https://github.com/Gnucash/gnucash/blob/master/libgnucash/app-utils/CMakeLists.txt#L98
08:11:17 <gjanssens> That tells cmake the gnc-app-utils target depends on all of the elements in the library list.
08:11:59 <gjanssens> This list is a mix of other targets (such as gnc-engine) and flags set by external dependencies (like GIO_LDFLAGS)
08:12:29 <gjanssens> I see I have been mixing library and target names from maint and master in my earlier explanations. Sorry for the confusion.
08:13:00 <chris> That's fine, it'll be clearer eventually :)
08:13:21 <gjanssens> Perhaps also nice to know: for C/C++ library targets the library that is effectively created on linux will be lib<targetname>.so
08:13:45 <gjanssens> So if there's a target named gnc-app-utils, that will eventually produce a library named libgnc-app-utils.so
08:14:22 <gjanssens> By the way I have just come across a few commands to make a visual representation of the dependency tree.
08:15:45 <gjanssens> It's a fairly impressive svg file...
08:16:03 <gjanssens> Hopefully we can simplify our dependency graph some more over time
08:16:28 <gjanssens> Unfortunately imgur won't take svg files...
08:18:34 *** oozer has quit IRC
08:18:35 <chris> maybe pastebin ;)
08:19:27 *** oozer has joined #gnucash
08:24:11 *** fabior has quit IRC
08:26:15 <gjanssens> I'm preparing in wiki page to hold the current dependency graphs and instructions to generate them yourself.
08:30:27 <warlord> .
08:33:27 *** mikee has joined #gnucash
08:34:08 *** mikee has quit IRC
08:41:28 <gjanssens> Hey warlord, just the person I needed :)
08:41:48 <gjanssens> I would like to upload two svg files to our wiki, but that file format is not allowed
08:42:15 <gjanssens> Can I add this format myself or do you have to update a list somewhere on the server ?
08:43:10 *** jervin has joined #gnucash
08:46:26 *** jervin has quit IRC
08:46:56 *** sbluhm has quit IRC
08:52:57 <warlord> Uh oh
08:53:12 <warlord> Um, honestly, I don't know.
08:53:23 <warlord> You can try adding it. It's PROBABLY in a special page somewhere.
08:53:40 <chris> jralls we shall await and see https://lists.gnu.org/archive/html/guile-user/2019-12/msg00020.html
08:53:47 <chris> @tell jralls we shall await and see https://lists.gnu.org/archive/html/guile-user/2019-12/msg00020.html
08:53:47 <gncbot> chris: The operation succeeded.
08:58:39 <gjanssens> warlord: I'll need your help - see this page: https://www.mediawiki.org/wiki/Manual:Image_administration#SVG
09:00:12 <gjanssens> It requires editing a local config file and making sure one of the suggested image converters is installed on the server
09:01:41 <gjanssens> chris: while waiting for the required wiki configuration, I have sent two visualizations to the devel list
09:07:06 <warlord> gjanssens, I'm not sure when I'll have time to look at that; I'm getting on a plane this afternoon.
09:07:51 <gjanssens> warlord: np. It's not that urgent.
09:12:05 *** User__ has joined #gnucash
09:20:19 *** sbluhm has joined #gnucash
09:20:19 *** ChanServ sets mode: +v sbluhm
09:22:40 *** obscurans has quit IRC
09:24:25 *** Han has joined #gnucash
09:24:31 *** boldstripe has quit IRC
09:25:14 <chris> @tell jralls I've made a discovery....... structs are directly accessible from guile
09:25:14 <gncbot> chris: The operation succeeded.
09:32:43 *** User__ has quit IRC
09:33:06 <chris> @tell jralls given the struct { Split *car; gpointer *cdr } splitpair_s, guile will create the functions splitpair-s-car-get / splitpair-s-car-set / splitpair-s-cdr-get / splitpair-s-cdr-set
09:33:06 <gncbot> chris: The operation succeeded.
09:34:50 <chris> how interesting...
09:37:33 *** sbluhm has quit IRC
09:38:08 <gjanssens> That would of course be swig generating these functions to use in guile...
09:38:43 *** obscurans has joined #gnucash
09:38:50 <gjanssens> Out of curiosity was that a cpp file or a plain c file ?
09:38:53 <chris> C
09:39:06 <gjanssens> Ok, interesting indeed
09:39:34 <gjanssens> And isn't a GList a struct ?
09:40:25 <chris> yes, however SWIG will convert the GList to an SCM list
09:40:31 <gjanssens> So I'd assume you could directly use glist-data-get and glist-next-get if we wrap glist
09:40:41 <gjanssens> Hmm, that's probably because we tell it to ?
09:40:55 <chris> yes I think so... but this will break pretty much everything .scm
09:41:26 <chris> see my Guile REPL playground https://pastebin.com/raw/YC2HpY8J ... run by loading datafile, running report including a Guile REPL server
09:42:19 <chris> yes, however SWIG will convert the GList to an SCM list --> that's not automatic BTW; it's what base-typemaps.i does and I'm not 100% happy about
09:43:33 <chris> you'll see in my playground, I defined pair to be (xaccAccountSplitsPair acc)
09:44:26 <chris> then I typed in emacs: "splitspair<TAB>" to see whether I could access splitspair_s via (system foreign) API, and splitspair-s-car-get splitspair-s-cdr-get etc just popped up :)
09:45:02 <chris> also (gnc:dump-book) etc works well, i.e. interactive GnuCash playground
09:45:34 * chris is a leet h4cker
09:45:53 <gjanssens> :)
09:46:44 <gjanssens> The thing is this reinforces jralls' earlier suggestion there's no need to write wrapper functions for each of the functions that return a GList
09:47:59 <chris> agree, just need to think how to make a safe transition
09:48:37 <chris> lots of GLists in API calls
09:48:41 <gjanssens> What we need to find is how to tell guile (via swig) what the actual data type is of the more specialized GList definitions like SplitList, AccountList
09:48:47 <gjanssens> I know
09:52:05 <chris> I've also found that defining struct { Split *car; splitpair_s *cdr } splitpair_s; is not possible isn't it? A C struct cannot have a recursive variable? This puts a spanner in the works in my implementation
09:53:22 <chris> gtg soon
09:56:05 *** waeking has quit IRC
10:01:45 <gjanssens> That may indeed be an issue
10:02:00 <gjanssens> I also don't know how write support would work
10:02:22 <gjanssens> Or more precisely - adding elements to the list or removing them
10:07:28 <gjanssens> However it looks like you can have a struct having a data member of struct itself:
10:08:15 *** jralls has joined #gnucash
10:08:55 *** ChanServ sets mode: +o jralls
10:08:57 <gjanssens> chris: https://pastebin.com/NyxcDS7Y
10:08:58 <jralls> .
10:08:58 <gncbot> jralls: Sent 1 hour and 15 minutes ago: <chris> we shall await and see https://lists.gnu.org/archive/html/guile-user/2019-12/msg00020.html
10:08:59 <gncbot> jralls: Sent 43 minutes ago: <chris> I've made a discovery....... structs are directly accessible from guile
10:09:00 <gncbot> jralls: Sent 35 minutes ago: <chris> given the struct { Split *car; gpointer *cdr } splitpair_s, guile will create the functions splitpair-s-car-get / splitpair-s-car-set / splitpair-s-cdr-get / splitpair-s-cdr-set
10:10:19 <chris> gjanssens you're right the getters and setters were created from CPP's .H files
10:10:23 <chris> Oops
10:10:38 <jralls> chris, C structs absolutely can have recursive ptrs. typedef struct (int bar, foo* next} foo; is the common way to create a single-linked list.
10:10:40 <chris> ah nice one
10:11:52 <gjanssens> jralls: I think that should be typedef struct (int bar, struct foo* next} foo; or typedef struct _foo foo; struct _foo (int bar, foo* next};
10:12:20 <gjanssens> At least my compiler complained about your version as requiring struct before foo*next
10:12:43 <gjanssens> But the idea stands
10:14:38 *** FH_thecat has joined #gnucash
10:17:08 <jralls> Yeah, probably the typedef first so foo is a known symbol.
10:19:56 <gjanssens> Indeed
10:27:06 <jralls> chris, about your email to guile-user: They'll answer the question about C access by pointing at the C interface in https://www.gnu.org/software/guile/manual/html_node/Pairs.html#Pairs.
10:27:31 *** jervin has joined #gnucash
10:33:02 *** jervin has quit IRC
10:41:23 <jralls> chris: Re https://bugs.gnucash.org/show_bug.cgi?id=797279, if the base language of a report is RTL then the report should be laid out RTL, even if the numbers are displayed LTR.
10:43:23 <jralls> gjanssens: I wonder if there's a way to convince dot to lay out those dependency graphs a bit more vertically.
10:44:37 <gjanssens> jralls: that would indeed be more useful. I haven't experimented much with it yet. Just learned about the existence ...
10:47:35 <chris> dot -Grankdir=LR
10:47:46 <chris> nite all
10:53:50 <gjanssens> Good night chris
10:54:33 <jralls> Gnight, chris.
10:56:12 <gjanssens> Looks better indeed :)
11:07:44 <jralls> gjanssens: You can also tell dot -Tpng to get a png that you can put on the wiki without needing warlord to reconfigure it.
11:10:29 <gjanssens> True, but I figured an svg would be more useful considering the size of the graph. svg allows zooming in.
11:11:02 <gjanssens> I can do so for now until warlord finds time to do the configurations.
11:13:48 <gjanssens> Output is actually reasonable. For a readable graph, the size is 8.8Mb for png vs 386K for svg
11:14:15 *** fell has joined #gnucash
11:14:15 *** ChanServ sets mode: +o fell
11:17:20 <gjanssens> Duh, won't work either. 8.8Mb is bigger than the server allows :(
11:18:09 <gjanssens> And even a jpeg version is still 3.3M
11:18:17 <gjanssens> While server only allows 2M
11:18:24 <gjanssens> Will wait for warlord.
11:18:32 <gjanssens> There are more pressing matters to attend to...
11:19:13 <jralls> Indeed.
11:24:42 *** Mechtilde has quit IRC
11:29:58 *** User__ has joined #gnucash
11:37:15 *** User__ has quit IRC
11:39:25 *** Mechtilde has joined #gnucash
12:21:23 <fell> gjanssens, you should link Dependency Graphs fom other pages.
12:22:56 <gjanssens> fell: ok. Suggestions ?
12:23:36 <fell> Good question
12:24:51 <fell> https://wiki.gnucash.org/wiki/GnuCash#Documentation_for_Developers ?
12:29:49 *** Gerd has joined #gnucash
12:30:18 *** fell has quit IRC
12:30:25 *** fell has joined #gnucash
12:30:25 *** ChanServ sets mode: +o fell
12:31:56 <gjanssens> fell: ok, that seems like a reasonable start
12:34:21 <gjanssens> done
12:34:41 *** Gerd has quit IRC
12:34:47 *** Gerd has joined #gnucash
12:36:53 *** jralls has quit IRC
12:37:15 *** jralls has joined #gnucash
12:40:15 *** jralls has quit IRC
12:48:59 *** jralls has joined #gnucash
12:50:09 *** storyjesse has quit IRC
12:53:26 *** sbluhm has joined #gnucash
12:53:26 *** ChanServ sets mode: +v sbluhm
13:18:33 *** fell has quit IRC
13:19:03 *** fell has joined #gnucash
13:19:04 *** ChanServ sets mode: +o fell
13:21:53 *** Han has quit IRC
13:22:12 *** fell has quit IRC
13:22:21 *** Han has joined #gnucash
13:26:28 *** fell has joined #gnucash
13:26:28 *** ChanServ sets mode: +o fell
13:34:29 *** User__ has joined #gnucash
13:43:13 *** fell has quit IRC
13:43:14 *** fell_laptop has joined #gnucash
13:43:14 *** ChanServ sets mode: +o fell_laptop
13:52:10 *** fell has joined #gnucash
13:52:11 *** ChanServ sets mode: +o fell
13:52:19 *** fell_laptop has quit IRC
13:53:37 *** Han has quit IRC
13:56:29 *** FH_thecat has quit IRC
14:20:12 *** Han has joined #gnucash
14:27:47 *** frakturfreak has joined #gnucash
14:27:47 *** ChanServ sets mode: +v frakturfreak
14:31:57 *** boldstripe has joined #gnucash
14:34:02 *** monkeyjuice has joined #gnucash
14:35:09 *** boldstripe_ has joined #gnucash
14:35:23 *** boldstripe has quit IRC
14:35:23 *** boldstripe_ is now known as boldstripe
14:40:40 *** Gerd has quit IRC
14:40:49 *** boldstripe_ has joined #gnucash
14:41:03 *** boldstripe has quit IRC
14:41:03 *** boldstripe_ is now known as boldstripe
14:41:09 *** oozer has quit IRC
14:41:34 *** jervin has joined #gnucash
15:10:29 *** jervin has quit IRC
15:19:59 <fell> gjanssens: because the Dependency Graphs are a floating target, how about the update policy?
15:21:08 <fell> Perhaps we should add them to the API generation?
15:22:27 <fell> ... instead of adding them to the wiki.
15:23:27 <fell> How time consuming are they?
15:29:56 <gjanssens> It takes 5 to 10 seconds to run
15:30:37 <gjanssens> It's not worth automating. The wiki has the commands to generate them and I wanted to add two charts for illustration purposes only.
15:31:08 <gjanssens> I won't spend more time on it than this.
15:34:39 *** gjanssens has quit IRC
15:44:33 *** Mechtilde has quit IRC
15:45:05 *** Mechtilde has joined #gnucash
15:48:07 *** Mechtilde has quit IRC
16:00:54 *** bertbob has quit IRC
16:04:20 *** omnireq_ has quit IRC
16:04:28 *** bertbob has joined #gnucash
16:04:29 *** ChanServ sets mode: +v bertbob
16:10:06 *** bertbob has quit IRC
16:26:18 *** sbluhm has quit IRC
16:27:47 *** oozer has joined #gnucash
16:28:33 *** User__ has quit IRC
16:54:50 *** Gerd has joined #gnucash
16:56:32 *** pohly has quit IRC
16:57:51 *** Gerd has quit IRC
16:58:11 *** Gerd has joined #gnucash
17:07:24 *** jervin has joined #gnucash
17:11:17 *** warlord has quit IRC
17:12:19 *** bzbarsky has quit IRC
17:18:34 *** frakturfreak has quit IRC
17:26:45 *** jralls has quit IRC
17:42:18 *** chf has quit IRC
17:45:29 *** chf has joined #gnucash
17:51:10 *** sbluhm has joined #gnucash
17:51:11 *** ChanServ sets mode: +v sbluhm
18:22:05 *** boldstripe has quit IRC
18:32:25 *** sbluhm has quit IRC
18:34:32 *** bertbob has joined #gnucash
18:34:33 *** ChanServ sets mode: +v bertbob
19:24:45 *** tonysoar has joined #gnucash
19:36:03 *** tonysoar has quit IRC
19:36:55 *** tonysoar has joined #gnucash
19:59:30 *** Gerd has quit IRC
20:04:02 *** jervin has quit IRC
20:21:27 *** warlord has joined #gnucash
20:36:36 <CDB-Man> hmm, is anyone else seeing this? on the budget report, for budgeted income items, in the total column its treating actuals as negatives (so as credits), causing a massive variance
20:37:26 <CDB-Man> for example on the monthly detaiols, budgeted income is $+5K and actual income is $+5k so that's fine, but in the totals column total budget for the year is $+60k vs actuals of $-60k, causing me a $-120k variance
20:37:30 <CDB-Man> it was fine in 3.6
20:38:37 *** oozer has quit IRC
20:39:26 <CDB-Man> ill try one of the nightlies
20:40:12 <CDB-Man> looks like the bug exists at https://bugs.gnucash.org/show_bug.cgi?id=797448
20:40:48 <CDB-Man> err, https://bugs.gnucash.org/show_bug.cgi?id=797418
21:07:17 <CDB-Man> fixed in the nightly!
21:10:23 <CDB-Man> hmm, chris, did you already have a bug ticket for some of your new reports? for the multicolumn balanse shee, a positive balance in current year retained earnings is showing as a negative (as a credit), instead of being set absolute. in other words, a net profit is reducing my equity. sign reversal
21:16:33 *** fell_laptop has joined #gnucash
21:16:34 *** fell has quit IRC
21:16:34 *** ChanServ sets mode: +o fell_laptop
21:21:03 <CDB-Man> https://bugs.gnucash.org/show_bug.cgi?id=797520 bug submitted
21:23:34 *** obscurans has quit IRC
21:26:20 *** jervin has joined #gnucash
21:27:30 *** tonysoar has quit IRC
21:38:13 *** obscurans has joined #gnucash
21:42:14 *** warlord has quit IRC
21:43:37 *** warlord has joined #gnucash
22:15:51 *** bzbarsky has joined #gnucash
22:16:03 *** ChanServ sets mode: +v bzbarsky
22:21:38 *** warlord has quit IRC
22:23:01 *** omnireq has joined #gnucash
22:23:31 *** omnireq has quit IRC
22:23:41 *** omnireq has joined #gnucash
22:24:42 *** omnireq has quit IRC
22:50:54 *** oliver has quit IRC
22:52:37 *** oliver has joined #gnucash
22:57:52 *** omnireq has joined #gnucash
23:36:22 <CDB-Man> chris: is the "receivable aging" report still very much draft? I'm getting some weird behaviour where all of my prepayments have already been applied, but the report still says they out open/outstanding. not sure if i can recreate it in a new file since it's quite complex, but I can try maybe...
23:38:54 *** FH_thecat has joined #gnucash
23:39:48 <CDB-Man> it seems like there isnt any logic yet to apply prepayments against outstanding AR. the receivable aging report shows no AR invoices outstanding, but the prepayments reflect as outstanding/unapplied
23:48:37 *** miklcct has quit IRC
23:48:40 *** miklcct has joined #gnucash
23:48:40 *** ChanServ sets mode: +v miklcct
23:56:35 <CDB-Man> aha, after a lot of heartache, I've managed to create a sample file for this
23:56:44 <CDB-Man> i'll open a ticket, with file and screenshots :)