2017-08-16 GnuCash IRC logs

00:17:09 *** kael has joined #gnucash
00:23:31 *** kael has quit IRC
00:29:42 *** bertbob has quit IRC
00:32:47 *** Mechtilde has joined #gnucash
00:44:26 *** bertbob has joined #gnucash
01:02:32 *** bertbob has quit IRC
01:16:15 *** bertbob has joined #gnucash
01:32:54 *** Mechtilde has quit IRC
01:34:36 *** bertbob has quit IRC
01:48:29 *** bertbob has joined #gnucash
01:54:56 *** bhardwajs has quit IRC
01:56:08 *** bhardwajs has joined #gnucash
02:31:43 *** bhardwajs has quit IRC
03:05:54 *** Unhammer has joined #gnucash
03:24:33 <lmat> /win next
03:28:18 *** gjanssens has joined #gnucash
03:28:18 *** ChanServ sets mode: +o gjanssens
03:28:37 <gjanssens> .
03:44:39 *** fabior has joined #gnucash
04:11:08 *** bertbob has quit IRC
04:22:15 *** pilotauto has quit IRC
04:26:26 *** bertbob has joined #gnucash
04:33:26 *** User has joined #gnucash
04:41:41 *** Aussie_matt has joined #gnucash
05:53:52 *** Taxicletter has joined #gnucash
05:54:03 <Taxicletter> Hi people!
05:54:29 <Taxicletter> I guess you all use gnucash? I'm searching for a good, preferably free, accounting program.
05:54:59 <Taxicletter> I used Manager in the past and I like that, but the web-version is payed.
05:55:33 <Taxicletter> Is it easy to exchange my accounting with my accountant with GnuCash?
05:57:03 <gjanssens> Taxicletter: I'm not currently using gnucash in a context where an accountant is involved. I know several users do though.
05:57:38 <gjanssens> You can gerenate reports for most if not all of the data your accountant requires as far as I know
05:57:46 <Taxicletter> OK
05:58:53 <Taxicletter> Is it compatible with european accounting practises? I live in Belgium, and in Manager things are done a little different then most accountants seem to be used with.
06:00:30 <gjanssens> It follows general accouning best practices, but is slightly US oriented.
06:00:58 <gjanssens> This shows in details like there's no "Passiva" section on the balance sheet as that's not used in the US
06:01:20 <gjanssens> Instead it shows liabilities and equity as separate sections
06:01:34 <gjanssens> I'm in Belgium too by the way :)
06:02:01 <gjanssens> So "Goeiedag" or "Bonjour" depeding on where exactly you live :D
06:02:55 <Taxicletter> Hallo! :-)
06:03:18 <Taxicletter> It could be Gutentag as well, but it isn't :-)
06:03:38 <gjanssens> It did cross my mind :)
06:03:57 <Taxicletter> And the missing "passiva" is not a problem for my accounting?
06:04:17 <gjanssens> It depends on how picky your accountant is.
06:04:35 <gjanssens> passiva is just a group name for liabilities and equity
06:04:49 <gjanssens> So it's mostly a presentation issue
06:05:02 <gjanssens> All the data is there, it's just presented slightly differently
06:05:52 <Taxicletter> OK, I guess it will do then. Thanks gjanssens!
06:07:03 <gjanssens> Good luck!
06:07:38 <Taxicletter> Thanks. I'll have fun with it (pfff...)
06:16:44 <gjanssens> Yes, I can imagine :-/
06:36:19 *** Jimraehl1 has joined #gnucash
06:37:33 *** Jimraehl1 has quit IRC
07:00:23 *** fabior has quit IRC
07:37:26 *** Taxicletter has quit IRC
07:51:57 *** rickoehn has joined #gnucash
08:12:43 *** Aussie_matt has quit IRC
08:40:24 *** kael has joined #gnucash
08:40:50 *** fekepp has joined #gnucash
08:44:37 *** kael has quit IRC
08:57:02 <lmat> @tell Taxicletter I couldn't tell from your discussion with gjanssens, but gnucash has no web version. It may someday, but not soon.
08:57:02 <gncbot> lmat: The operation succeeded.
09:01:41 <gjanssens> Thanks lmat. I wanted to mention that as well but forgot...
09:08:36 <lmat> gjanssens: It's exciting to find a compatriot! Not so much for me, but perhaps for you ;-)
09:10:13 *** fabior has joined #gnucash
09:40:07 *** jotrago1 has joined #gnucash
09:40:30 *** jotrago has quit IRC
09:40:31 *** jotrago1 is now known as jotrago
09:43:41 *** jotrago has quit IRC
09:46:18 *** jotrago has joined #gnucash
09:46:35 <warlord> gjanssens: the docs build failed again last night.. The reason is that MASTER and MAINT have different docdir paths. Sigh.
09:49:55 <warlord> Fixed. We'll try again tonight ;)
09:52:17 *** fabior has quit IRC
10:02:36 <gjanssens> warlord: yes, moving things around in only one branch will cause some common assumptions to break :(
10:06:30 *** fabior has joined #gnucash
10:06:30 <warlord> Indeed.
10:12:20 *** bhardwajs has joined #gnucash
10:41:22 *** fekepp has quit IRC
10:47:16 *** LeeRead has joined #gnucash
11:03:14 *** karelk has joined #gnucash
11:28:24 *** kael has joined #gnucash
11:30:08 *** bertbob has quit IRC
11:44:38 *** bertbob has joined #gnucash
11:48:11 *** kael has quit IRC
12:06:09 *** bhardwajs has quit IRC
12:06:38 *** Mechtilde has joined #gnucash
12:12:20 <lmat> The qof_string_cache is aimed at improving performance when using malloc and won't be needed in c++?
12:23:25 *** ArtGravity has joined #gnucash
12:29:30 *** fabior has quit IRC
12:36:34 <gjanssens> I hope we won't need it any more. I have a customer using gnucash on a huge data set and I had to remove the use of qof_string_cache in the register code because it became unbearably slow
12:36:52 <gjanssens> I think it was mostly for memory efficiency, not for performance in terms of speed.
12:37:10 <gjanssens> lmat: ^
12:39:27 <lmat> Right, part of the eternal tradeoff :-)
12:40:26 <lmat> If I change the kvp_frame not to create trees anymore, but simply be a key-value pair store, off the top of your head, what will break?
12:41:07 <lmat> So, instead of having kvp_frames inside kvp_frames, flatten it down by removing all the parsing of slashes so that a key can be "one/two/three".
12:41:31 <lmat> Surely not much of the code is sensitive to the implementation detail of that creating a tree of kvp_frames?
12:44:18 *** fabior has joined #gnucash
12:53:10 <gjanssens> lmat: I have no idea unfortunately. I haven't had much to do with kvp yet.
12:53:27 <gjanssens> jralls_ is the expert :)
12:54:56 <lmat> gjanssens: aye. I'm making the change now to see what blows up.
12:59:01 *** LeeRead has quit IRC
13:02:15 <lmat> gjanssens: By the way, is there anything I can do to help tidy up the current release?
13:08:56 <lmat> You know, this flattening bit is looking familiar. I think I tried this back when I first worked on the c++ conversion. There are a lot of tests that expect this kind of functionality.
13:09:27 <lmat> For instance, once you set "a/b", you expect there to be a value at "a". If the key is "a/b", obviously there's nothing at "a". So this may wind up being a fairly invasive change. Nice to refresh my memory.
13:09:47 <warlord> lmat: the OFX Baysian code expects to be able to enumerate, IIRC
13:09:54 *** jralls_ is now known as jralls
13:10:18 <lmat> warlord: makes sense.
13:10:45 *** ChanServ sets mode: +o jralls
13:12:15 <jralls> lmat: You're basically removing KVP_Frame as an allowed KVPValue type. I know tests will blow up and I think other places will as well.
13:14:23 <jralls> The SQL backend's slots table is very much oriented towards operating on KVP_Frame KVPValues, and IIRC there's a lot of existing data that's stored that way in both SQL and XML. Anywhere you see <slot><slot>...</slot></slot> in XML is a nested frame.
13:15:20 <lmat> Yes, it's bigger than I hoped.
13:15:26 <gjanssens> jralls: (I'm about to leave, but quickly still this)
13:15:49 <gjanssens> I think we should consider name other than lib for the pulled in library bits
13:16:08 <gjanssens> The cmake build will use lib as build directory for shared libraries as well, so there's overlap
13:16:27 <jralls> So you'll need to start backwards. Find an instance of KVP_Frame as a KVP_Value and convert it. Find its storage, fix that so that it reads both ways but writes only the new one. Commit that, lather, rinse, repeat.
13:16:35 <lmat> gjanssens: Then "l<tab>" would complete to libgnucash... ;-)
13:16:37 <gjanssens> So far this isn't causing issues, but it comes with an increased risk of getting such conflicts
13:16:39 *** cyphase has joined #gnucash
13:17:03 <gjanssens> how about 'extlib' or something ?
13:17:07 *** gjanssens is now known as gjanssens_afk
13:18:15 <jralls> gjanssens: Hasn't been a problem so far, but you're right at least in principle. "extlib' seems a bit awkward. 'external' is a keyword so that's best avoided.
13:18:35 <lmat> jralls: Do you recommend this course of action? (removing KVP_Frame as a KVP_Value)
13:18:39 <jralls> gjanssens: How about "borrowed"?
13:19:50 <jralls> lmat: Yes, I think it's something we want to do for SQL performance, but I don't think we have time to do it for 2.8.
13:20:24 <lmat> jralls: Or perhaps I should aim in a different direction for that bayes bug. Or let me know if I can help with 2.8?
13:23:10 <lmat> or 2.7...
13:23:19 <jralls> lmat: We need to get the bayes bug fixed, so yes, look in a different direction. In the old KVP implementation it was possible to pass a tree to KVP and that wasn't parsed for separators because it was already broken up. I'm pretty sure that's what the imap_bayes code used and was why I had to handle it specially when I made KVP private.
13:24:41 <jralls> IIUC the new KVP code doesn't have that feature and I think the fix for the '/' bug is to add it.
13:25:24 <lmat> Add the ability to pass a tree?
13:25:39 <lmat> Of course, we'll need to add the ability to pass a tree to qofinstance, too.
13:31:36 <jralls> lmat: No, the need to pass a tree is the reason that imap (and IIRC a couple of other things) *doesn't* use qof-instance-set/get.
13:32:30 <lmat> There's more. I just made a comment on the bugzilla bug report. If I understand correctly, this has always been a problem with the sql backend since it's always stored as a string (rather than the different structured XML storage).
13:34:32 <lmat> Oh, but I think you said that some parts of the application might store that way in XML, too.
13:35:41 *** LeeRead has joined #gnucash
13:44:12 <jralls> lmat: Your use of "always stored as a string" is confusing. Both backends store frames recursively. In XML a frame represents a slot element containing one or more slot elements. In the SQL backend the data of a frame is a GUID and each KVPValue contained by the frame is stored with that GUID as the "obj_guid".
13:45:04 <lmat> jralls: Okay, it's likely that I'm not seeing the full picture then.
13:49:17 <jralls> Oh BTW I've found a new KVP problem associated with feature tracking. The error is that boost::variant::details::visitation_impl isn't specialized and the generic template aborts.
13:49:33 <jralls> I haven't figured out yet what type isn't implemented.
13:55:06 <lmat> jralls: what is "feature tracking"?
13:57:43 <jralls> It's a way of maximizing backwards file compatibility while still allowing new features. It works by storing feature tags in a KVP Frame on the QofBook when a "new" feature is used. If an older version encounters a feature it doesn't know about it will abort the load.
14:02:29 *** To7 has quit IRC
14:12:43 <lmat> jralls: I see.
14:14:49 <lmat> jralls: Which visitor would this be? We have visitors for delete, comparisons, and to_string.
14:18:21 <jralls> lmat: Not sure. The variant entry point is "frame->for_each_slot(&add_feature_to_hash, &features);" at qofbook.c:1138.
14:21:16 <lmat> jralls: Is reproduction as easy as calling set_feature with a few features, then call get_features?
14:22:21 <jralls> lmat: I don't know, I haven't tried writing a test for it. The problem arises while loading the features from the SQL backend.
14:24:12 *** Kaell has joined #gnucash
14:24:13 <jralls> Full stack trace at https://pastebin.com/T2YZR9ba.
14:24:44 *** fabior has quit IRC
14:25:07 <jralls> (The paths are the old ones. I'll generate another with the new paths, but it'll take 10 minutes or so.)
14:27:21 *** Kaell has quit IRC
14:28:36 <lmat> So the touching off point is in kvp-value.hpp:176 if (this->datastore.type() != typeid(T)) return {};
14:29:01 <lmat> It's in the ".type()" bit.
14:30:41 *** frakturfreak has joined #gnucash
14:33:01 <jralls> OK. It turns out that the SQL backend didn't get built right after the rearrangement, but that may be due to my temporarily hiding libgtk2 which broke libgncmod-aqbanking which in turn breaks libgnc-module which then breaks all of the loadable modules... That dependency needs to be cleaned up but I'll
14:34:11 <jralls> But I'll try a workaround first so that I can debug the KVP problem...
14:45:42 *** cyphase has quit IRC
14:49:42 <lmat> It may be impossible to get this information from the stack trace alone, but maybe you were retrieving an int64_t.
14:51:46 <jralls> Well the workaround didn't so I've got to figure out why it's not loading the SQL backend. That may take a while.
14:51:58 <lmat> jralls: No sweat.
15:19:32 *** Mechtilde has quit IRC
15:32:14 *** Mechtilde has joined #gnucash
15:35:21 *** Mechtilde has quit IRC
15:36:17 *** Mechtilde has joined #gnucash
15:39:29 *** Mechtilde has quit IRC
15:41:10 *** gjanssens_afk is now known as gjanssens
15:42:08 <gjanssens> jralls: I'm fine with "borrowed"
15:42:28 <jralls> OK.
15:48:51 <lmat> gjanssens: Is there a good reason to keep test-core separate from test in libgnucash?
16:18:55 <gjanssens> lmat: test-core was a separate directory in src and is used both by libgnucash and gnucash
16:19:26 <lmat> gjanssens: Ahh, I see
16:19:28 <gjanssens> There's also a test-core in libgnucash/engine, but I didn't research why they were separate
16:22:02 <gjanssens> jralls: fyi in the restructuring process I ran in to the file path restriction of tar. To solve it I change the tar variant used by autotools to ustar which in the autotools docs is described "to be sufficiently old to be considered portable"
16:22:08 <gjanssens> That seems to work
16:22:41 <gjanssens> And with that, I'm off to bed...
16:22:44 <gjanssens> Bye :)
16:22:55 *** gjanssens has quit IRC
16:29:09 <lmat> I see kvp_value has a member that is a GDate, but how can that be? It's talking about this GDate, right? https://developer.gnome.org/glib/stable/glib-Date-and-Time-Functions.html That should be GDate* ?
16:33:38 <jralls> @tell gjanssens Re: ustar. OK if that's good enough, though ISTM all of our users will be using recent enough gnutar or bsdtar that posix would work too.
16:33:38 <gncbot> jralls: The operation succeeded.
16:34:40 <jralls> @tell gjanssens That means you can un-shorten the import-export subdir names if you like. I shortened them a few years ago to fit in the v7 99-character limit.
16:34:40 <gncbot> jralls: The operation succeeded.
16:39:37 *** frakturfreak has quit IRC
16:45:18 <jralls> lmat: Yes, that kind of gdate. https://github.com/Gnucash/gnucash/blob/master/libgnucash/engine/kvp-frame.cpp#L353
16:47:40 <jralls> lmat: Here's the stack trace from the new layout: https://pastebin.com/Q59kJYZc
16:51:50 <lmat> jralls: How do you reproduce it?
16:54:13 <jralls> I load my (somewhat huge) primary database in which I happen to have used a couple of new features.
16:55:51 <lmat> I added a unit test which sets and gets one of each data type. Nothing surprising turned up.
16:57:01 *** rickoehn has quit IRC
16:57:04 *** rickoehn has joined #gnucash
16:58:38 <jralls> lmat: So I went to frame 11 and tried `p this->datastore.type()` and got an assertion from forced_return so I suppose that the variant has gotten set up wrong.
17:02:21 <lmat> If you can get there, what does p this->datastore return?
17:03:37 <lmat> Something like "{which_ = 0, storage_ = {<boost::detail::aligned_storage::aligned_storage_imp<16, 8>>...."
17:03:47 <lmat> That which_ says which type is in use.
17:03:57 <lmat> 0 = int64_t, 1 is double, 2 is gnc_numeric, etc.
17:04:46 <jralls> https://pastebin.com/3BVmk2Lq
17:04:52 <lmat> Oh, also get p this (see if the address of this is odd, perhaps it's a bad dereference?)
17:05:29 <lmat> Yeah, bad value for "which"... But the buffer is filled legitimately.
17:06:37 <jralls> I'm pretty sure "New York" isn't a valid feature...
17:07:09 *** fekepp has joined #gnucash
17:08:01 <jralls> Anyway, I guess I need to find where the KvpValue is created and set a breakpoint on that.
17:08:11 <jralls> Later. Bedtime now.
17:08:12 <lmat> jralls: Can you get the address of this?
17:08:19 <lmat> jralls: yeah, later is fine :-)
17:09:05 <jralls> Oh, sorry, it's 0x00000001156949a0. I was just looking to see how to get lldb to tell me where the free store is.
17:09:37 <lmat> okay, not too suspicious...
17:12:21 *** fekepp has quit IRC
17:20:19 *** jralls is now known as jralls_afk
17:31:08 *** LeeRead is now known as lread
17:31:39 *** lread has quit IRC
17:31:48 *** lread has joined #gnucash
17:35:17 *** kael has joined #gnucash
18:00:52 *** rickoehn has quit IRC
18:10:12 *** kael has quit IRC
18:41:53 *** pilotauto has joined #gnucash
20:02:48 *** User has quit IRC
20:39:39 *** tuxd00d_ has joined #gnucash
20:39:52 *** tuxd00d has quit IRC
20:39:52 *** tuxd00d_ is now known as tuxd00d
20:50:25 *** Kaell has joined #gnucash
20:50:42 *** Kaell has quit IRC
21:25:22 *** ArtGravity has quit IRC
21:57:15 *** kael has joined #gnucash
22:19:41 *** kael has quit IRC
23:02:55 *** jethrogb has quit IRC
23:04:14 *** jethrogb has joined #gnucash
23:34:35 *** CDB-Away has joined #gnucash