2021-11-03 GnuCash IRC logs
00:39:01 *** mikee has quit IRC
00:40:41 *** mikee has joined #gnucash
00:40:51 *** CDB-Man_ has quit IRC
00:49:03 *** neoweb has quit IRC
00:49:16 *** neoweb has joined #gnucash
01:34:02 *** Mechtilde has joined #gnucash
01:36:18 *** jervin has quit IRC
02:04:00 *** fell has quit IRC
02:05:19 *** fell has joined #gnucash
02:05:20 *** ChanServ sets mode: +o fell
02:07:14 *** Mechtilde has quit IRC
02:13:52 *** frakturfreak2 has quit IRC
02:15:19 *** PowaBanga has joined #gnucash
02:28:39 *** frakturfreak2 has joined #gnucash
02:32:39 *** sbluhm has joined #gnucash
03:01:21 *** fell has quit IRC
03:02:40 *** fell has joined #gnucash
03:02:41 *** ChanServ sets mode: +o fell
03:16:08 *** jervin has joined #gnucash
03:51:45 *** jervin has quit IRC
03:55:25 *** Mechtilde has joined #gnucash
04:08:35 <Simon> chris: pass it as a reference if you don't want a copy
04:10:39 *** Mechtilde has quit IRC
04:14:49 *** gjanssens has joined #gnucash
04:14:49 *** ChanServ sets mode: +o gjanssens
04:27:00 *** Pegasus_RPG has joined #gnucash
04:37:31 *** Pegasus_RPG has quit IRC
04:41:59 *** storyjesse has joined #gnucash
04:42:47 <gjanssens> @tell jralls re move semantics, you're correct. I misinterpreted Sean's example. I have rewatched his talk and now understand the issue and context sligthly better. (Only slightly though... ;)
04:42:47 <gncbot> gjanssens: The operation succeeded.
04:44:37 <gjanssens> @jralls If you're interested in where I found this: https://www.youtube.com/watch?v=QGcVXgEVMJg around the 30 minute mark. Associated slides are at https://sean-parent.stlab.cc/presentations/2017-01-18-runtime-polymorphism/2017-01-18-runtime-polymorphism.pdf the relevant slide being page 54
04:44:37 <gncbot> gjanssens: Error: "jralls" is not a valid command.
04:44:46 <gjanssens> @tell jralls If you're interested in where I found this: https://www.youtube.com/watch?v=QGcVXgEVMJg around the 30 minute mark. Associated slides are at https://sean-parent.stlab.cc/presentations/2017-01-18-runtime-polymorphism/2017-01-18-runtime-polymorphism.pdf the relevant slide being page 54
04:44:46 <gncbot> gjanssens: The operation succeeded.
04:57:34 *** PowaBanga has quit IRC
04:57:52 *** PowaBanga has joined #gnucash
05:01:20 *** User_ has joined #gnucash
05:50:40 *** storyjesse has quit IRC
06:52:01 *** field^Zzz3 has joined #gnucash
08:27:03 *** field^Zzz3 has quit IRC
09:03:03 *** Jimraehl1 has joined #gnucash
09:49:58 <chris> shared_ptr: seems fine but fails, maybe because split_t needs sizeof? #1178
10:01:08 <chris> gjanssens this is slightly improved by #include "SplitP.h": https://pastebin.com/raw/RZTaXb5V
10:03:15 <chris> maybe libgnucash is not ready for shared_ptr
11:17:31 <chris> Simon if you know cpp your views welcome too :)
11:17:33 *** ArtGravity has joined #gnucash
11:17:33 *** ChanServ sets mode: +v ArtGravity
11:17:59 <chris> latest commit compiles but calls free() with the shared_ptr with I want to remove
11:18:29 <chris> I don't want to clone the splits because they will need to be modified via xaccSplitSetReconcile afterwards
11:26:08 *** ArtGravity has quit IRC
12:18:22 *** warlord has quit IRC
12:39:28 *** sbluhm has quit IRC
12:41:22 *** sbluhm has joined #gnucash
13:04:57 <gjanssens> chris: I think the core of the issue is you're mixing two memory models. The GLib model based on g_new/g_free and variants and the C++ memory model based on new and delete.
13:07:16 <gjanssens> Or actually the main issue is that Split is a typedef to the type split_s which isn't publicly defined (on purpose).
13:08:10 <gjanssens> I don't think we're supposed to do memory management of splits outside of the transaction and split functionality. So shared_ptr is probably not a good option here.
13:08:35 <gjanssens> But perhaps jralls has more experience with this already and can offer more insights.
13:13:36 *** sbluhm has quit IRC
13:26:11 *** TownsendHardware has joined #gnucash
13:36:56 *** jervin has joined #gnucash
13:47:02 *** jervin1 has joined #gnucash
13:47:28 *** jervin has quit IRC
13:47:29 *** jervin1 is now known as jervin
13:50:54 *** jervin has quit IRC
13:55:07 *** jervin has joined #gnucash
14:03:30 <Simon> You can't use Split unless the list will be the primary storage of that object
14:03:49 <Simon> If it's just a list of Splits that are elsewhere you must use Split*
14:06:24 <Simon> If you want to mix Split and Split* then you have a problem. Somewhere else will need to hold the Splits that you create if they're not held elsewhere.
14:06:45 <Simon> That could be a shared_ptr or a unique_ptr
14:07:45 <Simon> Calling free() on the contents of either ptr type will likely be wrong; those types can free() for you when they're no longer referenced.
14:43:29 <jralls> chris: > I noticed that passing sack (std::unordered_map<numeric, GList*>) as parameter to a function simply leads to cloning sack every time, causing enormous slowdowns.
14:43:30 <gncbot> jralls: Sent 10 hours ago: <gjanssens> re move semantics, you're correct. I misinterpreted Sean's example. I have rewatched his talk and now understand the issue and context sligthly better. (Only slightly though... ;)
14:43:31 <gncbot> jralls: Sent 9 hours and 58 minutes ago: <gjanssens> If you're interested in where I found this: https://www.youtube.com/watch?v=QGcVXgEVMJg around the 30 minute mark. Associated slides are at https://sean-parent.stlab.cc/presentations/2017-01-18-runtime-polymorphism/2017-01-18-runtime-polymorphism.pdf the relevant slide being page 54
14:45:30 <jralls> chris, That's because you're passing the sack by value. Pass it by reference, i.e. std::unordered_map<numeric, GList*>&; if the function doesn't mutate it then stick `const` in front.
14:50:38 <jralls> chris, Primary objects live in the books collections and are expected to live for the duration of the session. I imagine that's why we don't use GObject reference counting on them. There are some special cases, like the backup txns and splits made by begin_edit, but that wouldn't apply here.
14:57:24 <jralls> You can't put those ptrs in a unique/shared_ptr because that would cause them to be freed before the end of the session causing no end of trouble.
15:01:35 <Simon> I still think you should look at using an unordered_multimap if the GLists aren't essential
15:09:44 <jralls> Simon, maybe a bit cleaner code but the net result will be the same as the duplicates are placed in a std::list.
15:10:28 *** Mechtilde has joined #gnucash
15:10:30 <Simon> It will avoid needing to do a whole lot of manual iteration to make copies
15:12:18 *** jervin has quit IRC
15:12:41 <jralls> Shouldn't be doing manual iteration for copies anyway: https://developer-old.gnome.org/glib/stable/glib-Doubly-Linked-Lists.html#g-list-copy
15:21:03 *** jervin has joined #gnucash
15:23:27 <jralls> gjanssens, that's a complex example, no wonder you didn't get it the first time.
15:25:43 *** jervin has quit IRC
15:27:36 *** jervin has joined #gnucash
15:40:57 *** sbluhm has joined #gnucash
15:57:39 <gjanssens> jralls: at some point Sean introduces a concept_t struct in his example. He's still using C++14 in there, but is that a glimpse of what concepts in C++20 will be used for ?
15:57:59 <gjanssens> (Or is concepts for C++23 only ?)
15:59:40 <jralls> That last is a difficult question. So-called concepts light did land in C++20 but compiler support hadn't materialized when I last checked a couple of months ago. Meanwhile there are a lot of rough edges that are supposed to be smoothed out in 23.
16:00:53 <gjanssens> Ok. I never looked into concepts so far. That's why I wondered whether Sean's example code was a precursor to what it's supposed to bring.
16:01:37 <jralls> My browser doesn't find concept_t in the slides you linked. About where is it?
16:01:48 <gjanssens> Regardless, I'm really impressed by his example and have been thinking of ways to use those ideas in gnucash somewhere.
16:02:15 <gjanssens> Oh, perhaps that was in a reduced version of his talk. Let me look that up.
16:07:08 <gjanssens> It's in his 2016 edition of the same talk. Here's the pdf: https://sean-parent.stlab.cc/presentations/2016-10-10-runtime-polymorphism/2016-10-10-runtime-polymorphism.pdf
16:07:56 <gjanssens> He introduces a concept_t on page 80 to replace two separate implementations of with a single templated one.
16:15:20 <jralls> It's in the 2017 slides too but the browser can't seem to see it. Weird. Anyway, no, that's not really what concepts are about. It's not templated, at least not on slide 80. He's just demonstrating run time polymporphism by creating a superclass for string_model_t and int_model_t so that he can use concept_t as the typename to pass to unique_ptr.
16:18:10 <gjanssens> Well he templates it on page 150. The explanations are in the accompanying video recording.
16:18:21 <gjanssens> But regarding concepts - oh well.
16:18:54 <gjanssens> It still remains a pretty good explanation of runtime polymorphism.
16:20:01 <gjanssens> It's actually still using the pimpl idiom though and if I remember it correctly you said recently the CRTP is preferred these days. Don't know if it applies here.
16:20:10 <gjanssens> Switching topic
16:20:43 *** sbluhm has quit IRC
16:21:00 <gjanssens> I was looking into writing tests for our GSettings wrapper. But it occurred to me we don't want to test the g_settings_xyz calls themselves, only our wrapper code.
16:21:09 <jralls> CRTP depends on what you're doing. CRTP creates duck typing like in Python.
16:21:31 <gjanssens> So my first thought was to mock these functions out using gmock.
16:21:40 <jralls> Good thought.
16:21:52 <gjanssens> That seems however suboptimal (from several SO articles)
16:22:01 <gjanssens> gmock is written for C++, not C
16:22:27 <gjanssens> Though I see someone started writing mock code for some of our engine objects as well
16:22:58 <gjanssens> Do you think gmock is worthwile in this context or should I just handwrite replacement functions ?
16:23:29 <jralls> Christian Gruber, https://github.com/Gnucash/gnucash/pull/738 and others.
16:23:38 <gjanssens> Yeah, that's what I saw
16:25:17 <jralls> GMock is maybe overkill for this because it's a one-off. Either way the hard part will be getting the wrapper functions to use the mocks instead of the real thing.
16:26:03 <gjanssens> True. I don't know yet how to do this.
16:26:20 <gjanssens> I started from this SO question: https://stackoverflow.com/questions/31989040/can-gmock-be-used-for-stubbing-c-functions
16:26:44 <gjanssens> Several illustrations of how to mock C functions and several pointers to other frameworks more suited for C code...
16:27:04 <gjanssens> I'm hesitant to add other frameworks though. We already have plenty.
16:27:50 <jralls> Isn't that true! I'd really prefer to get all of the testing under one framework.
16:29:36 <jralls> But maybe the first question is do the wrapper functions really need to be tested? If they're of the form gnc_settings_foo(char* bar) {return g_settings_foo (bar); } then there's no point in testing them.
16:30:16 <gjanssens> Heh, it was a precursor to TDD. I want to refactor the whole thing to be much more C++ like.
16:30:28 <gjanssens> But at the same time prevent regressions.
16:32:04 <gjanssens> All the getter and setter functions repeat the same boilerplate. Each minor change currently has to be applied to each of those.
16:32:07 *** sbluhm has joined #gnucash
16:32:14 <jralls> That's good. So introduce indirection. Create an pure virtual class that provides the functions you need and two subclasses, one that trivially wraps the corresponding g_settings functions and one that does the mock stuff.
16:33:32 <jralls> Eh, we crossed. "That's good" was about the TDD approach.
16:33:39 <gjanssens> I figured :)
16:35:11 <gjanssens> That does use inheritance though rather than runtime polymorphism, but I suppose in this case that's reasonable.
16:37:04 *** User_ has quit IRC
16:40:14 <jralls> Actually inheritance *is* runtime polymorphism. Templates provide compile-time polymorphism. To do it that way you'd create a bunch of wrapper functions templated on the called function, e.g. template <typename Func> void gnc_settings_foo(char* bar, Func f){ return f(foo)}.
16:40:22 *** sbluhm has quit IRC
16:40:33 <jralls> oops, return f(bar);.
16:42:32 <gjanssens> Right. I'll experiment a bit to see what suits me best.
16:45:35 <jralls> For this case I think the inheritance version is probably better, it has fewer moving parts.
16:46:20 <jralls> And any performance saved by avoiding the vtable will be eaten by longer compile time.
16:48:25 <gjanssens> Ok
16:48:28 <jralls> BTW have you read https://www.goodreads.com/book/show/44919.Working_Effectively_with_Legacy_Code? I happened to have been re-reading bits of it last week.
16:50:04 <gjanssens> No I haven't yet. Useful for gnucash' legacy code base ?
16:50:42 <jralls> Very much so. He defines "Legacy code" as "code that doesn't have unit tests".
16:51:11 <jralls> And more particularly code that's written in a way that makes writing unit tests hard.
16:51:27 *** Mechtilde has quit IRC
16:51:41 <gjanssens> :D GnuCash is the role model for that...
16:51:50 <jralls> In spades.
16:52:28 <gjanssens> I'm ordering it now...
16:53:53 <gjanssens> And that concludes my evening. See you later!
16:54:18 <jralls> Good night!
16:54:26 *** gjanssens has quit IRC
17:13:40 *** jervin has quit IRC
17:49:08 *** field^Zzz3 has joined #gnucash
18:03:01 *** jervin has joined #gnucash
18:46:09 *** Pegasus_RPG has joined #gnucash
18:48:09 *** field^Zzz3 has quit IRC
18:53:47 *** Pegasus_RPG1 has joined #gnucash
18:53:48 *** Pegasus_RPG has quit IRC
18:53:50 *** Pegasus_RPG1 is now known as Pegasus_RPG
19:02:53 *** KipITOne-GTBS has quit IRC
19:05:11 *** Pegasus_RPG has quit IRC
19:05:30 *** Pegasus_RPG has joined #gnucash
19:18:38 *** Pegasus_RPG has quit IRC
19:27:52 *** frakturfreak2 has quit IRC
19:42:28 *** frakturfreak2 has joined #gnucash
20:11:05 *** bertbob has quit IRC
20:16:48 *** bertbob has joined #gnucash
20:16:48 *** ChanServ sets mode: +v bertbob
20:32:11 *** jervin has quit IRC
20:39:39 *** jervin has joined #gnucash
20:41:59 *** jervin has quit IRC
20:43:07 *** jervin has joined #gnucash
20:49:46 *** jervin has quit IRC
20:49:58 *** jervin has joined #gnucash
21:24:46 *** jervin has quit IRC
22:11:54 *** JZ has joined #gnucash
22:40:43 *** KipITOne has joined #gnucash
22:40:44 *** ChanServ sets mode: +v KipITOne
22:49:50 *** TheDcoder[m] has joined #gnucash
22:51:32 *** TheDcoder[m] has left #gnucash
22:57:02 *** bertbob has quit IRC
22:59:13 *** bertbob has joined #gnucash
22:59:13 *** ChanServ sets mode: +v bertbob
23:11:12 *** storyjesse has joined #gnucash
23:38:53 *** frakturfreak2 has quit IRC
23:53:12 *** frakturfreak2 has joined #gnucash