2021-11-02 GnuCash IRC logs
00:08:09 *** Mechtilde has joined #gnucash
00:11:09 *** Mechtilde has quit IRC
01:12:42 *** ericdm has quit IRC
01:48:01 *** Mechtilde has joined #gnucash
01:51:09 *** Mechtilde has quit IRC
02:05:17 *** fell has quit IRC
02:06:36 *** fell has joined #gnucash
02:06:36 *** ChanServ sets mode: +o fell
02:12:31 *** ericdm has joined #gnucash
02:20:19 *** sbluhm has joined #gnucash
02:35:05 *** Mechtilde has joined #gnucash
02:35:35 *** David has quit IRC
02:38:07 *** Mechtilde has quit IRC
02:44:23 *** Mechtilde has joined #gnucash
02:54:58 *** Mechtilde has quit IRC
03:11:29 *** kcin has quit IRC
03:14:20 *** kcin has joined #gnucash
03:19:38 <Simon> It's going to allocate in batches so reserving 1 extra element will never do anything useful
03:21:38 <Simon> Oh, it's not
03:22:00 <Simon> The data array is always contiguous
03:22:19 <Simon> I must be thinking of a different data structure
03:23:33 <Simon> So you could in fact memcpy the data as long as that has no side effects on the objects you're copying
03:37:22 *** CDB-Man_ has joined #gnucash
03:37:23 *** ChanServ sets mode: +v CDB-Man_
03:37:38 *** CDB-Man has quit IRC
03:49:38 *** tomk_dk has joined #gnucash
03:55:24 *** Hamaryns has joined #gnucash
03:55:24 *** ChanServ sets mode: +v Hamaryns
04:14:07 *** gjanssens has joined #gnucash
04:14:07 *** ChanServ sets mode: +o gjanssens
04:25:51 <chris> I managed to convert from GHashTable (120ms) to std::unordered_map (210ms)
04:54:49 *** alt_mikee has joined #gnucash
04:55:02 *** mikee has quit IRC
05:03:06 *** sbluhm has quit IRC
05:04:21 *** User_ has joined #gnucash
05:07:26 *** sbluhm has joined #gnucash
05:27:55 *** alt_mikee has quit IRC
05:28:07 *** mikee has joined #gnucash
05:33:39 *** kcin has quit IRC
05:45:22 *** kcin has joined #gnucash
05:47:36 *** Hamaryns has quit IRC
05:50:52 *** kcin has quit IRC
06:28:38 *** sbluhm has quit IRC
06:35:54 *** sbluhm has joined #gnucash
06:53:54 *** sbluhm has quit IRC
06:56:33 *** sbluhm has joined #gnucash
07:10:00 *** storyjesse has joined #gnucash
07:33:31 *** jonp` is now known as Guest62
07:51:23 *** kcin has joined #gnucash
07:56:53 *** kcin has quit IRC
08:13:45 <Simon> it's slower?
08:16:56 <chris> yups. see my benchmarks at https://github.com/Gnucash/gnucash/pull/1178
08:19:15 <chris> this is my first c++ project so I may not have done it right
08:43:23 <Simon> I think you want a https://en.cppreference.com/w/cpp/container/unordered_multimap
08:43:33 <Simon> that would avoid all that need to using GList
08:43:35 <Simon> use*
08:44:07 <Simon> (and if you find yourself doing an emplace loop with no changes to the value, there's functions for appending/inserting a range instead of doing it one at a time)
09:12:40 *** jervin has joined #gnucash
09:14:35 *** Jimraehl1 has joined #gnucash
09:40:33 *** jervin has quit IRC
10:31:01 *** jervin has joined #gnucash
10:33:32 * chris surprised cpp is so similar to scheme, with much more annoying punctuation <g>
10:35:39 *** warlord has quit IRC
10:35:39 *** TownsendHardware has quit IRC
10:35:39 *** lmat has quit IRC
10:35:39 *** neoweb has quit IRC
10:35:39 *** mapreri has quit IRC
10:35:41 *** neoweb has joined #gnucash
10:35:46 *** TownsendHardware has joined #gnucash
10:35:49 *** mapreri has joined #gnucash
10:35:49 *** ChanServ sets mode: +v mapreri
10:35:52 *** warlord has joined #gnucash
10:40:44 *** lmat has joined #gnucash
10:44:17 *** jervin has quit IRC
10:45:56 <chris> how does the destructors know when to destroy? do they refcount, or mark&sweep?
10:58:49 *** sbluhm has quit IRC
11:13:23 <chris> and, no g_free() and valgrind is still happy
11:41:59 *** guak has joined #gnucash
11:57:33 *** kcin has joined #gnucash
12:08:22 <jralls> chris, destructors don't know when to destroy, they're the function that does the destroying. So if the object is allocated on the stack the destructor runs when the variable goes out of scope. If the object is created on the free store (which may or may not be different from the heap depending on the implementation) with operator new then the object is destroyed when the memory is released with operator delete.
12:10:00 <jralls> To get a reference-counted pointer wrap the object pointer in std::shared_ptr; to get a single instance that can't be copied and will be deleted when its variable goes out of scope wrap it in std::unique_ptr.
12:11:18 <jralls> Note that unlike GObjects, std::shared_ptr takes care of the reffing and unreffing itself, you don't have to worry about it.
12:13:06 <jralls> Whenever possible use std::make_shared and std::make_unique to create the shared/unique_ptrs and allocate the object in one step.
12:15:04 *** kcin has quit IRC
12:16:20 <jralls> Also remember that to maintain the memory locality in std::vector it should contain the objects, not ptrs to the objects. Operate on the contents of the vector with references to avoid copying for any object bigger than 2 ptrs.
12:18:42 <jralls> As for std::unordered_map being slower than GHashtable, the first place I'd look is the hashing function. The GLib ones are extremely simple to favor speed over collision likelihood. std::unordered_map (and friends) use std::hash<>, which may or may not have different optimization goals.
12:35:22 <jralls> gjanssens If a class or struct declares no constructors, destructor, or operator= the compiler will create default ones for all 5, including a move constructor, so such a class is movable.
12:37:34 <jralls> chris, be careful using std::vector<foo>::emplace_back, that is for passing the arguments to one of foo's constructors so that the contained foo can be constructed in place in the vector. If you already have a foo use push_back(std::move(foo)) if you don't need the original foo later.
12:40:59 *** storyjesse has quit IRC
13:03:30 *** Mechtilde has joined #gnucash
13:15:14 <jralls> chris, re std::unordered_map, on checking Josuttis, *The C++ Standard Library*, I find that multiple values for a particular hash are stored in std::list instead of std::vector. That's another possible reason that GHashtable is faster.
13:20:15 *** jcarl43 has joined #gnucash
13:20:15 *** ChanServ sets mode: +v jcarl43
13:24:03 *** fell has quit IRC
13:24:40 *** fell has joined #gnucash
13:24:40 *** ChanServ sets mode: +o fell
13:33:24 <gjanssens> jralls: there's a subtle condition on whether move assignment operator is created automatically or not (copyting from Sean Parent's slides): a defaulted move assignment operator is defined as deleted if the class has
13:33:26 <gjanssens> a non-static data member or direct base class with a
13:33:27 <gjanssens> type that does not have a move assignment operator and is not trivially copyable
13:33:58 <gjanssens> I don't think it's the case here, but as I didn't know the details by heart, I chose to be prudent in my comment.
13:35:02 <gjanssens> If you add a unique pointer in the struct, it will have a member that's not trivially copyable and hence the move assignment operator wouldn't be created.
13:40:01 <jralls> Except that unique_ptr has a move constructor and a move assignment operator so the first condition is met and it won't block creation of a move constructor/assignment operator for the containing struct.
13:40:49 <jralls> And std::unigue_ptr is not only not trivially copyable, it's not copyable at all. That's what makes it unique.
13:41:50 *** sbluhm has joined #gnucash
13:42:22 <jralls> But that's a problem with the example only; any non-static data member that isn't moveable will indeed prevent the compiler from creating a default move constructor and operator=.
13:50:01 <jralls> Herb Sutter has a nice short guide to move at https://herbsutter.com/2020/02/17/move-simply/. For all of the gritty details Nico Josuttis started to write a similar blog post a few years ago and ended up with a 230 page book: https://www.cppmove.com
13:54:30 *** TownsendHardware has quit IRC
14:00:35 *** sbluhm has quit IRC
14:05:52 *** ericdm has quit IRC
14:12:04 *** sbluhm has joined #gnucash
14:14:17 *** ericdm has joined #gnucash
14:16:44 *** kcin has joined #gnucash
14:25:34 *** sbluhm has quit IRC
14:37:48 *** sbluhm has joined #gnucash
15:01:46 *** jervin has joined #gnucash
15:04:48 *** sbluhm has quit IRC
15:44:52 *** frakturfreak2 has joined #gnucash
15:46:51 *** sbluhm has joined #gnucash
16:21:05 *** kcin has quit IRC
16:22:08 *** kcin has joined #gnucash
16:31:52 *** warlord has quit IRC
16:34:25 *** bertbob has quit IRC
16:46:34 *** warlord has joined #gnucash
16:50:57 *** jervin has quit IRC
17:06:22 *** jcarl43 has quit IRC
17:07:05 *** sbluhm has quit IRC
17:13:07 *** sbluhm has joined #gnucash
17:17:01 *** tomk_dk has quit IRC
17:21:45 *** kcin has quit IRC
17:32:45 *** bertbob has joined #gnucash
17:32:45 *** ChanServ sets mode: +v bertbob
17:42:00 *** bertbob has quit IRC
17:50:37 *** sbluhm has quit IRC
17:51:04 *** gjanssens has quit IRC
18:02:12 *** Mechtilde has quit IRC
18:18:44 *** bertbob has joined #gnucash
18:18:44 *** ChanServ sets mode: +v bertbob
18:29:51 *** User_ has quit IRC
18:31:25 *** bertbob has quit IRC
18:45:54 *** jcarl43 has joined #gnucash
18:45:54 *** ChanServ sets mode: +v jcarl43
18:51:50 *** bertbob has joined #gnucash
18:51:50 *** ChanServ sets mode: +v bertbob
19:35:42 *** jcarl43 has quit IRC
20:01:13 <chris> jralls: thanks. 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.
20:28:38 *** guak has quit IRC
21:33:55 <chris> not sure how to make std::vector contain Split rather than Split*.
21:35:14 *** jervin has joined #gnucash
22:13:58 *** PowaBanga has quit IRC
22:38:02 *** manju has joined #gnucash
22:49:47 *** manju has left #gnucash
22:51:04 *** manju has joined #gnucash
22:51:04 *** ChanServ sets mode: +v manju
22:51:37 <manju> greetings everyone! I am having a problem with importing mutual fund data stored in .csv into the fund commodity │+chf
22:51:40 <manju> │ | account. Similar issue: │+chrko
22:51:42 <manju> │ | https://stackoverflow.com/questions/61669987/gnucash-can-not-import-stock-price-from-csv-to-gnucash-stock-account, │+flips
22:51:44 <manju> │ | solution that I tried: https://bugs.gnucash.org/show_bug.cgi?id=793306, Issue I am facing: Data is getting imported │+g5pw
22:51:46 <manju> │ | incorrectly as │+JayC
22:51:48 <manju> │22:45:38 manju | splits. Here is the data: https://pastebin.com/C8E0xEnE, issue: https://imgur.com/a/y4cCtDg
22:53:29 <manju> sorry for the paste. my first time in an irc...
22:53:45 <manju> here is a better version of what I pasted:
22:54:01 <manju> greetings everyone! I am having a problem with importing mutual fund data stored in .csv into the fund commodity
22:54:04 <manju> account. Similar issue: https://stackoverflow.com/questions/61669987/gnucash-can-not-import-stock-price-from-csv-to-gnucash-stock-account,
22:54:06 <manju> solution that I tried: https://bugs.gnucash.org/show_bug.cgi?id=793306, Issue I am facing: Data is getting imported
22:54:08 <manju> incorrectly as splits. Here is the data: https://pastebin.com/C8E0xEnE, issue: https://imgur.com/a/y4cCtDg
22:55:34 *** fell has quit IRC
22:58:54 *** fell has joined #gnucash
22:58:55 *** ChanServ sets mode: +o fell
23:17:06 *** manju has quit IRC