2019-07-07 GnuCash IRC logs

00:02:06 <chris> ok if I understand that 1 job = 1 customer or vendor then I can work with that. I'll be aiming to merge job-report.scm into owner-report.scm
00:02:29 <warlord> A job has 1 owner. An owner can have many jobs.
00:04:41 <chris> ok I meant 1 job must belong to 1 customer/vendor (which means 1 job = 1 currency/addres etc) for the merged job-report.scm
00:04:51 <warlord> sure
00:05:28 <warlord> bedtime for me. after midnight here. TTFN
00:06:11 <chris> night!
00:07:12 *** fell has quit IRC
00:14:14 <chris> ... I think my merged owner-report.scm works well
00:14:58 <chris> ...... I think it *could/should* be upgraded to search all AP/AR accounts instead of the selected one for invoices/bills, and *could/should* support multiple currencies
00:20:03 <chris> therefore owner-report (encompasses customer/vendor/job report) will show all invoices/bills and their payments in multiple currencies, which is nice when owner's currency has changed
00:20:24 <chris> so, ... worthwhile ugprade?
00:25:44 *** fell has joined #gnucash
00:25:44 *** ChanServ sets mode: +o fell
00:38:20 *** Mechtilde has joined #gnucash
00:38:20 *** ChanServ sets mode: +v Mechtilde
00:57:45 *** fell has quit IRC
01:47:44 *** fell has joined #gnucash
01:47:44 *** ChanServ sets mode: +o fell
01:53:45 *** fell has quit IRC
01:58:24 *** fell has joined #gnucash
01:58:24 *** ChanServ sets mode: +o fell
02:02:39 *** fell has quit IRC
02:02:46 *** fell has joined #gnucash
02:02:46 *** ChanServ sets mode: +o fell
02:03:27 *** fell has quit IRC
02:03:35 *** fell has joined #gnucash
02:03:36 *** ChanServ sets mode: +o fell
02:22:35 *** fell has quit IRC
02:22:43 *** fell has joined #gnucash
02:22:43 *** ChanServ sets mode: +o fell
02:48:19 *** gour has joined #gnucash
03:41:16 *** Aussie_matt has quit IRC
04:15:40 *** bertbob has quit IRC
04:18:29 *** bertbob has joined #gnucash
04:18:29 *** ChanServ sets mode: +v bertbob
04:21:03 *** ArtGravity has quit IRC
04:21:12 *** ArtGravity has joined #gnucash
04:21:12 *** ChanServ sets mode: +v ArtGravity
04:22:43 *** seanh has quit IRC
04:22:46 *** seanh has joined #gnucash
04:23:17 *** seanh has quit IRC
04:23:24 *** bertbob has quit IRC
04:23:58 *** seanh has joined #gnucash
04:34:22 *** bertbob has joined #gnucash
04:34:22 *** ChanServ sets mode: +v bertbob
04:36:57 *** frakturfreak has joined #gnucash
04:37:28 *** bertbob has quit IRC
04:40:08 *** bertbob has joined #gnucash
04:40:09 *** ChanServ sets mode: +v bertbob
04:40:41 *** frakturfreak has quit IRC
04:42:00 *** boldstripe has joined #gnucash
05:32:16 *** storyjesse has joined #gnucash
06:36:21 *** jralls has quit IRC
06:36:54 *** jralls has joined #gnucash
06:36:54 *** ChanServ sets mode: +o jralls
06:40:51 *** jralls has quit IRC
06:41:14 *** jralls has joined #gnucash
06:41:15 *** ChanServ sets mode: +o jralls
07:05:44 *** boldstripe has quit IRC
07:53:51 *** oozer has joined #gnucash
08:23:01 *** Mechtilde has quit IRC
08:23:48 *** gour has quit IRC
08:27:39 *** Mechtilde has joined #gnucash
08:27:39 *** ChanServ sets mode: +v Mechtilde
08:54:20 <chris> https://imgur.com/a/WhUZDkk bug 711563
08:56:55 <chris> also see "Balance" column i.e. running balance amount owed
09:14:58 <chris> invoice links to payments splits. payment links to invoice splits. I think it's too brittle though.
09:18:56 *** Jimraehl1 has joined #gnucash
09:19:57 *** Jimraehl1 has left #gnucash
09:56:18 <chris> bug 771563
10:05:20 <warlord> chris, that image looks good! I like it. Although "credits" and "debits" might want to be reworded perhaps?
10:12:43 *** KevinDB has quit IRC
10:13:34 <chris> warlord very brittle though, bug 771563 although lots are usually stable, payments can be mangled. dr/cr renamed to what?
10:14:03 *** KevinDB has joined #gnucash
10:14:04 *** ChanServ sets mode: +v KevinDB
10:14:50 <chris> https://imgur.com/E3tcvyl better text for payment column
10:15:43 *** jervin has joined #gnucash
10:16:16 <chris> there's some invoice->lot->splitlist, payment->search splitlist->invoices srfi-1 magic behind it all
10:17:10 <chris> and I'm sure owner-report should be upgraded for multiple currencies...
10:19:16 *** jervin has quit IRC
10:27:58 *** jervin has joined #gnucash
10:28:32 *** jervin has quit IRC
10:38:43 *** O01eg has joined #gnucash
11:21:14 *** storyjesse has quit IRC
11:34:15 <chris> ok last iteration before bed :) https://imgur.com/5mYeRIR -- invoice line has payments + outstanding; payment line has multi-invoice details
11:41:59 *** jervin has joined #gnucash
11:47:21 *** jangid has joined #gnucash
11:53:49 *** jervin has quit IRC
11:57:04 *** bertbob has quit IRC
12:01:19 *** jangid has quit IRC
12:02:53 *** bertbob has joined #gnucash
12:02:55 *** ChanServ sets mode: +v bertbob
12:35:59 *** fell has quit IRC
12:36:07 *** fell has joined #gnucash
12:36:07 *** ChanServ sets mode: +o fell
12:47:24 *** jangid has joined #gnucash
12:49:11 *** ChanServ sets mode: +v jangid
12:52:16 <jangid> Is the postgresql setup faster than XML?
13:02:58 <jralls> jangid: No.
13:04:47 <jangid> I had used GnuCash earlier. About 12 years back. On macOS there was dependency on unofficial x-server so I didn't install. Now it is working. My question is ...
13:05:49 <jangid> will the load time be affected as the file grows?
13:06:21 <jangid> Earlier I used it on GNU/Linux. It was faster on Linux. At least I felt so.
13:10:58 *** jangid has quit IRC
13:11:09 *** jangid has joined #gnucash
13:12:28 *** ChanServ sets mode: +v jangid
13:35:45 *** mr_sm11th has joined #gnucash
13:35:45 *** ChanServ sets mode: +v mr_sm11th
13:43:18 *** gour has joined #gnucash
13:43:18 *** ChanServ sets mode: +v gour
13:49:26 *** gjanssens has joined #gnucash
13:49:26 *** ChanServ sets mode: +o gjanssens
13:49:35 <gjanssens> .
13:59:37 *** gour has quit IRC
14:00:03 *** gour has joined #gnucash
14:00:04 *** ChanServ sets mode: +v gour
14:00:16 *** gour has quit IRC
14:13:42 *** KevinDB has quit IRC
14:15:05 *** KevinDB has joined #gnucash
14:15:05 *** ChanServ sets mode: +v KevinDB
14:22:03 *** frakturfreak has joined #gnucash
14:22:03 *** ChanServ sets mode: +v frakturfreak
14:26:21 <jralls> jangid: Yes, loading will get slower as the file grows. Saving the XML file will also get slower, but saving is done at every transaction commit with the SQL backends so there's no "big save"; the tradeoff is that there's also no previous copies.
14:27:12 <jralls> jangid: 12 years ago the Postgres backend was different from today's SQL backend that supports SQLite3 and MySQL as well as Postgresql.
14:28:50 <jangid> jralls: okay. the same backend is working for three DBs. which library is that?
14:29:22 <jralls> http://libdbi.sourceforge.net/
14:29:40 <jralls> At least for now.
14:30:56 *** gjanssens has quit IRC
14:32:17 <jangid> was! six other DBs are in line there.
14:32:22 <jangid> wow!
14:33:00 <jangid> But the project looks like inactive. Last news in 2013.
14:34:22 <jralls> But GnuCash won't support the other three as they're not Free.
14:35:00 <jralls> That's not quite correct. The most recent commit to https://sourceforge.net/p/libdbi/libdbi/ci/master/tree/ was in 2017.
14:37:36 <jralls> But that burst of activity didn't last. The library is also a bit limited in what it can do and we plan in the future to make better use of SQL so it will eventually be replaced with something else.
14:40:18 *** jangid has quit IRC
14:45:57 *** gjanssens has joined #gnucash
14:45:58 *** ChanServ sets mode: +o gjanssens
15:06:25 *** fabior has joined #gnucash
15:07:15 *** Mechtilde has quit IRC
15:12:48 *** jervin has joined #gnucash
15:15:54 *** jervin has quit IRC
15:21:56 *** jangid has joined #gnucash
15:32:34 <Simon> I have compression disabled on the XML file to improve save time
15:33:04 <Simon> I find that there's actually a significant amount of load time just opening all of the account registers too (which normally happens behind the splash screen)
15:33:10 *** KevinDB has quit IRC
15:33:20 <jralls> Simon, OK speed vs. space is a perrenial tradeoff in programming.
15:34:20 <Simon> the biggest impact on load speed was when I changed from a 2 old Opteron CPUs to an i7
15:34:30 *** KevinDB has joined #gnucash
15:34:31 *** ChanServ sets mode: +v KevinDB
15:35:14 <Simon> I'm also doing this which gets a minor speedup but it less safe: https://git.uuid.uk/simon/ppa/gnucash/tree/patches/no-char-check-on-load.patch
15:35:49 <jralls> gjanssens, chris, what do you think of junking the whole options thing and just use KVP? BobIT's https://github.com/Gnucash/gnucash/pull/536 does that for what's now the book properties.
15:36:12 <Simon> it might make sense to verify that the entire file is valid UTF-8 instead of having to do it for every individual string
15:37:54 <jralls> Simon: Then it would have to iterate over every character in the file instead of just the text elements.
15:40:18 <Simon> yes but that may be faster than calling a function to do it for each string
15:40:34 <gjanssens> jralls: isn't that a case of just kicking the can further down the road ?
15:40:50 <Simon> (have they made a UTF-8 instruction in CPUs yet? :))
15:41:08 <jralls> Simon: LOL>
15:41:12 <gjanssens> Talking about the kvp thing
15:41:29 <jralls> gjanssens, but it's only one can instead of two?
15:41:52 <gjanssens> That's a reasonable argument indeed
15:42:31 <gjanssens> I'm just a bit worried the kvp concept is becoming rather overloaded
15:42:54 <gjanssens> For that matter where would you store the report options in xml ?
15:43:50 <gjanssens> There's no <gnc:report> tag in there and AIU the kvp slots are normally stored as sub nodes of the main object
15:44:12 <gjanssens> In sql that's less of an issue as the slots table is just a separate one
15:44:39 *** jervin has joined #gnucash
15:44:55 <gjanssens> And one could just search for a saved-report guid (cutting a few corners here)
15:45:25 <jralls> Right, so either we add the <gnc:report-options> tag and children to the schema or we do KVP and hang it off of some object, and the book is the least-illogical choice.
15:46:06 <gjanssens> Oh, and isn't this partially overlapping with chris' work to store saved-reports as json blobs in the book ?
15:47:59 <gjanssens> Would storing options in kvp make that work obsolete ?
15:48:01 <jralls> It's all part of the same design discussion. chris's json idea is because it's easy to get to from Scheme with the guile-json module.
15:48:17 <gjanssens> It's equally easy to get to json with boost
15:48:50 <gjanssens> And in a way I do like using a universal data format
15:48:56 <jralls> IIRC the json blob was to go into a KVP hanging off of the book.
15:49:04 <gjanssens> That's how I remember it as well
15:49:38 <gjanssens> I expect to get questions from users to import and export saved reports if we internalize them into the data file/db
15:50:14 <gjanssens> With all the caveats that some of the saved options may be highly book specific (like account guids)
15:50:25 <jralls> So from that standpoint it's a bit of an added complication: Parse the XML, then parse the json inside an XML element instead of just parsing XML.
15:50:38 <gjanssens> True
15:50:53 <gjanssens> Except it's universal in that it works for both our xml and db schemas
15:51:43 <gjanssens> I'm not extremely defending it either though.
15:52:08 <gjanssens> We could also just make the export/import format json or something else altogether
15:52:43 <gjanssens> Using a well known format once outside of gnucash is useful to allow user manipulation between export and import
15:52:53 <jralls> In SQL we
15:53:20 <jralls> we'd just have a bunch of entries in the slots table with the option paths and values.
15:56:33 <jralls> What does json export/import do for users that XML doesn't? XML already has a rich set of standards for schema and validation. That effort is just getting started for JSON: https://json-schema.org/
15:59:37 <jralls> Plus we already have an XML backend, a JSON one would have to be written.
15:59:50 *** KevinDB has quit IRC
16:00:48 <jralls> OTOH a JSON backend could be plugged into NoSQL databases like MongoDB... not that that's a great fit for an accounting app.
16:01:09 <gjanssens> Oh I don't have anything against xml. But our xml backend is not really something I want to push that much further.
16:01:12 *** KevinDB has joined #gnucash
16:01:12 *** ChanServ sets mode: +v KevinDB
16:01:29 <gjanssens> It's really up to some major modernization
16:02:59 <gjanssens> As for the potential NoSQL connections, we don't see a use for it currently, but opening up opportunities for others is always nice.
16:03:18 <jralls> The backend itself rather than the schema, right?
16:03:24 <gjanssens> Yes
16:03:51 <gjanssens> I think our schema is fairly decent
16:05:10 <gjanssens> However it would be nice if our backend actually *used* a formal schema and provided conversions from older to newer schema instead of us having to hand-code each schema change.
16:05:31 <gjanssens> Heh, look at me...
16:05:45 <gjanssens> Spewing tons of design ideas with no time to implement any of it :(
16:05:52 <jralls> NoSQL databases are useful for finding stand-alone chunks of data. They're expressly *not* for tabular data. A lot of non-tabular data was wedged into SQL databases in the 80s and 90s because that's what was available. In the early 2000s XML databases were briefly popular as an alternative for more document-oriented data, then JSON was invented and MongoDB came along shortly after.
16:06:52 <gjanssens> So back to the options-in-kvp idea, my only concern would be performance
16:07:45 <jralls> I completely agree about the XML backend, and I plan to rewrite it to properly use libxml2's validation on an actual schema to stuff the in-memory SQL DB. It took to long to get 3.x stable so that's set aside for next year.
16:08:10 <gjanssens> Ok
16:09:06 <gjanssens> Isn't boost capable of mapping xml directly onto a data structure (though if we want to stuff an in-memory sql-db that's not helpful) ?
16:09:30 <jralls> So back to options. It's a huge API, 35 C functions and ~150 scheme ones.
16:09:55 <jralls> Um, you mean boost::serialize? Does it do XML?
16:10:54 <gjanssens> No, https://www.boost.org/doc/libs/1_65_1/doc/html/property_tree.html
16:11:30 <gjanssens> Don't know if that's helpful or not
16:11:39 <gjanssens> Just something I came across at some point
16:12:03 <gjanssens> But back to the API story ?
16:12:43 <jralls> Our data isn't the right shape for boost::property_tree.
16:15:24 <jralls> So the option API does two jobs: It creates a data structure for arbitrary options with defaults and it builds GUI on-the-fly. BobIT's PR separates the options currently managed by File>Properties, creating a normal GtkDialog/GtkNotebook with a Glade file.
16:15:38 <gjanssens> Ok, so boost::property_tree was just a distraction
16:17:36 <jralls> He sets and gets the option values using gnc_book_get_option to read and write the book's option slots.
16:19:53 <jralls> The *other* use of options is in reports. As you know, those options aren't stored unless either the user leaves a report tab open when she closes GnuCash or decides to save the configuration, and they're currently saved as scheme code, which has its own set of problems. chris wants to convert that scheme code, not the keys and values of the options, to json.
16:20:14 *** fabior has quit IRC
16:21:38 <gjanssens> I'm following so far
16:22:20 <jralls> Somewhat separately warlord pointed out that saved report configurations don't necessarily travel well and should be tied to the book for which they were saved. chris took that to mean that they should be saved to the book's KVP so he proposed stuffing his scheme-json into a single slot on the book.
16:23:52 <gjanssens> Got that as well
16:24:08 <jralls> ISTM that's just laying more complexity on top of something that's already horribly complex.
16:24:27 <gjanssens> Which means to get the options for one specific saved report, one has to do only one kvp lookup
16:24:46 <gjanssens> Storing each option separately means doing as many lookups as there are options per report
16:25:38 <gjanssens> Bringing me back to my performance concern
16:25:59 <gjanssens> Though I understand your complexity concern as well
16:27:18 <jralls> Not necessarily: One need store and retrieve only the options that are changed from the defaults. But KVP access is pretty fast and it could be made faster by hashing paths and getting rid of frames.
16:27:58 <gjanssens> Agreed
16:28:42 <gjanssens> Won't hashing paths make human debugging harder ? Or would you key in the hash but store a human readable string as well ?
16:28:52 <gjanssens> key on the hash
16:30:25 <gjanssens> The more general issue with kvp is that it prevent db normalization. But perhaps that's something you prefer to fix in one big data format change in the future ?
16:31:01 <jralls> The hashes are to speed up retrieval. Hash compares are O(1), string compares are O(n) on the length of the shorter string.
16:33:10 <jralls> So if the in-memory KVP is a sorted std::vector<std::pair<hash, value>> a binary search on the hash will be much faster than the current traversal of KVP frames based on string compares.
16:35:11 <jralls> Using std::binary_search, of course. We don't have to write it, just use it.
16:35:33 <gjanssens> Ok
16:37:49 <gjanssens> That's for in-memory. How would you do it in-db ?
16:39:06 <jralls> Leave it the way it is, otherwise it's a breaking change.
16:41:02 <jralls> SQL is strings all the way down and SQL DBs have sophisticated ways of making queries go fast.
16:41:45 <gjanssens> Ok, how would that work if your in-memory kvp is keyed on a hash and you have to write a changed value back to db ?
16:42:06 <gjanssens> Where's the link between in-memory hash and in-db/xml kvp path
16:42:09 <gjanssens> ?
16:44:37 <jralls> For SQL, it's in the code: We passed in the path-string to the KVP lookup and it hashed it to find the value. It updates the value in memory and writes to the slots table with owner-guid, the string path, and the value.
16:47:21 <jralls> For XML I guess we'd need to keep a std;:vector<std:pair<hash, path>> or maybe std::vector<std::pair<hash, std::vector<path-element>>> to be able to fill out the slots elements.
16:48:30 <jralls> Alternatively we could keep it together in a single std::vector<std::tuple<hash, value, std::vector<path-element>>>.
16:49:03 <gjanssens> That last one was what I was thinking about indeed.
16:49:37 <gjanssens> So the kvp performance can be fixed (which eliminating frames as a separate target to reach that goal)
16:50:05 <gjanssens> What paths would you propose for saved-report options ?
16:50:40 <gjanssens> I'll assume we store saved-reports somewhere as book kvps for now
16:52:08 <gjanssens> saved-report/<guid>/option-name ?
16:52:32 <gjanssens> (As a full string, not a kvp hierarchy)
16:53:08 <jralls> Yes, that's what I was thinking, though <guid> could as easily be a name.
16:54:58 <gjanssens> It would be more human readable with a name, but more difficult to handle name changes
16:56:22 <gjanssens> Also in order to set a default report for printing invoices and allowing the user to also choose one of their saved reports for that, a guid would be required (or at least something that isn't user changeable directly)
16:56:29 <jralls> Oh, were you thinking of the report's guid? I think that would need to be one of the options; a user may have several saved configs on the same report.
16:56:55 <gjanssens> Not the report's guid, a unique guid for this particular saved report
16:57:28 <gjanssens> For the reason above, to have something immutable to refer to from other parts of the code
16:57:46 <jralls> Got it.
16:57:59 <gjanssens> Obviously that code would still have to cope with the case where the user deletes a saved-report so the guid becomes unavailable
16:58:11 *** ChanServ sets mode: +v jangid
16:58:17 <jangid> I am kind of novice in using abbreviations. what do you mean by KVP here. Read it so many times.
16:58:31 <gjanssens> Key Value Pair
16:58:53 <gjanssens> It's a technique we use to store some of our data in the backends
17:00:08 <jangid> Is it in a JSON format? I read KVP Hierarchy in the above discussion.
17:00:13 <jralls> That's where "referential integrity" comes in. A SQL feature we can't use until there's only SQL. It comes along free with declaring foreign keys on tables.
17:00:55 <jralls> jangid: It's internal, buried very deep in the implementation. It's currently done with nested hash tables.
17:01:54 <jangid> which area of source to explore, if I want to read the code on this?
17:02:07 *** frakturfreak has quit IRC
17:02:12 <jralls> libgnucash/engine/KVP*
17:02:33 <jangid> ok. thanks.
17:03:01 <jralls> for the implemntation and libgnucash/engine/qofinstance.* for the use.
17:07:26 <jralls> gjanssens: The option values is only one piece of the system. It also stores Scheme function pointers for each option to get, set, get defaults, convert to string, and convert between SCM and KVP.
17:07:54 <gjanssens> Indeed: so the value would not cut it
17:08:32 <gjanssens> I can't imagine you'd intend to store those getters/setters and friends in kvp as well ?
17:08:39 <jralls> Well, no, all of that other stuff is hard-coded. Only the value needs to be persisted.
17:09:05 <Simon> postgres has a JSON type
17:09:05 <gjanssens> Right, so moving to kvp is only the tip of the iceberg for the options code overhaul
17:09:59 <jralls> Simon: That's nice, but immaterial. As far as the DB is concerned the JSON is just a string.
17:11:28 *** jangid has quit IRC
17:12:23 <jralls> Well, no. We've now circled back around. Most options don't get turned into KVP and the system relies on SCM's loose typing to allow the C struct to avoid dealing with the type of the option value.
17:13:36 <gjanssens> I imagine the C++ conversion would template these ?
17:14:16 <jralls> The options need to live in a container regardless of value type. I tried to implement that as a class hierarchy with a non-templated superclass and templated subclasses but got tripped up by having to get and set from a superclass ptr.
17:15:12 <gjanssens> Hmm, tricky
17:15:14 <jralls> Can't do that, so I started looking at a boost::variant implementation today, driven by the same constraints as lmat was three years ago.
17:15:30 <gjanssens> Yeah that was my next suggestion
17:15:59 <jralls> And along came BobIT's PR where he just chucks all of that and goes straight to KVP.
17:16:54 <jralls> Erm BRB
17:16:56 <gjanssens> Well, as a sidenote my concern with Bob's approach is that the primary definition for book options is now in a gui file instead of somewhere in the engine
17:18:59 <gjanssens> We can of course use the book options in the engine, but looking for them if not gui oriented is pretty hard (like for example someone writing python bindings)
17:23:12 <jralls> Which nicely segues to the other piece of the current options. Some of them also contain GUI callbacks, additional data, and even layouts for radio buttons.
17:24:09 <gjanssens> Yep, not a good mix
17:24:46 <jralls> That's mostly for the use of gnucash/gnome-utils/dialog-options.c to create the various report option dialogs on the fly.
17:25:29 <gjanssens> I would suggest to separate that in the new options system
17:25:48 <gjanssens> Gui parts should really be in gnucash, not libgnucash
17:26:31 <gjanssens> Each option can have a unique identifier that can be used in gui code to set up custom gui bits
17:26:49 <jralls> Technically they are: The option object just has function pointers; the actual functions pointed to are elsewhere.
17:27:13 <gjanssens> Oh right I forgot
17:27:50 <jralls> But it still violates the single-responsibility doctrine pretty badly.
17:31:12 <gjanssens> Yeah, I envision a purely non-gui option object that can be a base class for a gui-option object
17:31:32 <gjanssens> I'm about to leave for the night.
17:32:11 <jralls> Hmm, the issue there is that the GUI is still pretty C++-resistant, but I guess that's surmountable.
17:32:17 <gjanssens> And fyi, the coming three weeks I'll be on holidays, with probably only limited online presence
17:32:39 <jralls> I'm more concerned about the ability to create report options on the fly and have the GUI magically created.
17:33:42 <gjanssens> The gnc:make-option bits and how to accomodate for that in C++ ?
17:34:52 <jralls> Well, not exactly. The way that gnc:make-foo-option connects with dialog-option.c.
17:37:00 <gjanssens> And concerned in the sense of how to translate that to C++ code ?
17:37:26 <jralls> How to decompose it.
17:38:57 <gjanssens> I'd have to study that part of the code a bit more before I can comment on that I'm afraid.
17:39:10 <jralls> But my original question was about using KVP directly instead of another class with embedded boost:variants.
17:39:45 <gjanssens> Ok
17:41:03 <jralls> Do you want to mull on that for a bit (especially since it's your bedtime)?
17:42:00 <gjanssens> It is a tough question :)
17:42:47 <gjanssens> It depends a bit on how big of a change you intend to make for 4.x
17:42:49 <jralls> OK. Here's another one, completely unrelated: Let's get rid of Account SCU and just use the commodity's SCU everywhere.
17:43:22 <gjanssens> I think the class with embedded boost::variants is better long-term as it can be specialized for options.
17:43:34 <jralls> OK.
17:43:38 <gjanssens> I presume it will use KVP for the time being to store the actual data
17:44:45 <gjanssens> We're seeing several bugs about changeable SCU's lately, aren't we ?
17:45:01 <jralls> Maybe. There are some value types that will require new KVP types, like plot size.
17:45:48 <gjanssens> Good point. Several options are composed of more than one primary value
17:46:50 <gjanssens> Anyway, I'll see what good ideas the night brings for SCU :)
17:46:51 <jralls> Well, plot size is a std::pair<uint, uint>.
17:47:04 <jralls> Right. Good night!
17:47:08 <gjanssens> You did see my comment about holidays ?
17:49:19 *** gjanssens has quit IRC
17:56:50 *** tienne has joined #gnucash
18:39:51 *** Aussie_matt has joined #gnucash
19:03:55 *** DonationDrive has joined #gnucash
19:05:18 *** DonationDrive has quit IRC
19:05:32 *** DonationDrive has joined #gnucash
19:06:41 *** ChanServ sets mode: +v DonationDrive
19:06:54 <DonationDrive> I would like to extend heartfelt thanks to the incredible collaborators on Freenode who make FOSS projects and the fight to keep software free a reality. However, great challenges have befallen Freenode due to lawsuits filed by Microsoft and Apple accusing us of facilitating intellectual property theft. Now is a critical moment for you and other Freenode warriors who ensure the world will always have FOSS. Your donation of $25
19:06:55 <DonationDrive> USD or more will help ensure that the software oligarchy does not succeed in killing Freenode and the open source movement.
19:06:55 <DonationDrive> Payment information
19:06:55 <DonationDrive> URI: bitcoin:bc1qrwaduld085xuyfh70dnj65yk38n5k76dpfzusz?amount=0.00001000&label=Summer%20Drive&message=Thank%20you%20for%20supporting%20FOSS%20projects%21
19:06:56 <DonationDrive> Address: bc1qrwaduld085xuyfh70dnj65yk38n5k76dpfzusz
19:19:23 *** DonationDrive has quit IRC
19:20:54 *** DonationDrive has joined #gnucash
19:21:53 *** DonationDrive has quit IRC
19:22:24 *** DonationDrive has joined #gnucash
19:23:23 *** DonationDrive has quit IRC
19:57:11 *** tienne has quit IRC
21:21:26 *** Yotson has quit IRC
21:26:29 *** oozer has quit IRC
21:26:52 *** Yotson has joined #gnucash
21:40:20 *** fell has quit IRC
21:42:45 *** fell has joined #gnucash
21:42:46 *** ChanServ sets mode: +o fell
22:02:11 *** jangid has joined #gnucash
22:08:21 *** jangid has quit IRC
22:45:43 *** eramirez has joined #gnucash
23:00:32 *** ArtGravity has quit IRC
23:08:04 *** Robert8471 has joined #gnucash