2015-05-04 GnuCash IRC logs

00:34:06 *** GabrieleV_ has joined #gnucash
00:34:23 *** GabrieleV has quit IRC
00:34:23 *** GabrieleV_ is now known as GabrieleV
00:54:02 *** MechtiIde has joined #gnucash
01:13:36 *** ErKa has quit IRC
01:14:00 *** jimvideo_again has quit IRC
01:40:56 *** MechtiIde has quit IRC
02:11:58 *** StuM has joined #gnucash
02:19:55 *** cartsoftware has joined #gnucash
03:08:54 *** fabior has joined #gnucash
03:49:04 *** kraftb has joined #gnucash
04:14:24 *** josePHPagoda has quit IRC
04:18:25 *** mlncn has quit IRC
04:40:37 *** GabrieleV_ has joined #gnucash
04:41:19 *** GabrieleV has quit IRC
04:41:20 *** GabrieleV_ is now known as GabrieleV
05:25:07 *** GabrieleV_ has joined #gnucash
05:25:39 *** GabrieleV has quit IRC
05:25:40 *** GabrieleV_ is now known as GabrieleV
05:50:45 *** josePHPagoda has joined #gnucash
06:11:50 <Remo> In case the link I posted looks like spam, it's not!
06:12:47 <Remo> It's about a little Perl script allowing to have Thunderbird compose a mail to all active customers...
06:43:11 *** himaxx has joined #gnucash
07:14:28 *** Jimraehl1 has left #gnucash
07:15:02 *** himaxx has quit IRC
07:15:03 *** Jimraehl1 has joined #gnucash
07:26:20 *** fabior has quit IRC
07:43:37 <warlord> Remo: posted where?
07:54:00 *** rickoehn has joined #gnucash
07:57:35 *** theframer has left #gnucash
08:01:06 *** himaxx has joined #gnucash
08:06:09 *** himaxx has quit IRC
08:22:43 *** andy has quit IRC
08:34:18 *** fabior has joined #gnucash
08:36:26 *** andy has joined #gnucash
08:51:39 *** lmat has joined #gnucash
08:53:19 *** rubdos has joined #gnucash
09:09:30 *** ErKa has joined #gnucash
09:16:30 *** aqua_ has quit IRC
09:28:34 *** himaxx has joined #gnucash
09:29:09 *** himaxx has quit IRC
09:31:52 *** mlncn has joined #gnucash
09:34:44 *** cartsoftware has quit IRC
09:35:30 *** cartsoftware has joined #gnucash
09:44:21 *** jralls has quit IRC
09:45:57 *** ErKa has quit IRC
10:03:58 *** himaxx has joined #gnucash
10:06:54 *** rubdos has quit IRC
10:09:11 *** himaxx has quit IRC
10:20:16 *** MechtiIde has joined #gnucash
10:24:06 *** ErKa has joined #gnucash
10:42:42 *** aqua_ has joined #gnucash
10:45:03 *** jralls has joined #gnucash
10:45:03 *** gncbot sets mode: +o jralls
10:50:14 *** aqua_ has quit IRC
10:58:20 *** jralls has quit IRC
11:01:17 *** aqua_ has joined #gnucash
11:02:18 *** codesmythe has joined #gnucash
11:19:40 *** aqua_ has quit IRC
11:40:14 *** GabrieleV_ has joined #gnucash
11:40:17 *** GabrieleV has quit IRC
11:40:18 *** GabrieleV_ is now known as GabrieleV
11:40:44 *** aqua_ has joined #gnucash
11:47:19 *** gjanssens has joined #gnucash
11:47:20 *** gncbot sets mode: +o gjanssens
11:54:55 *** jralls has joined #gnucash
11:54:55 *** gncbot sets mode: +o jralls
11:55:28 *** aqua_ has quit IRC
11:57:39 <jralls> lmat: In your kvp-value implementation, what's the benefit of boost::variant as opposed to just a templated class? ISTM that any particular kvp-value instance can hold only one type, so template specialization should be sufficient. The unspecialized template can just throw to prevent creating random KvpValue types.
12:19:59 <warlord> Indeed, I would've expected to just have a GncKvpValue<int64>, GncKvpValue<String>, ....
12:30:19 *** codesmythe has quit IRC
12:35:33 *** gjanssens has quit IRC
12:38:24 *** gjanssens has joined #gnucash
12:38:24 *** gncbot sets mode: +o gjanssens
12:40:08 *** Gbarr has quit IRC
13:01:16 *** GabrieleV_ has joined #gnucash
13:01:38 *** GabrieleV has quit IRC
13:01:39 *** GabrieleV_ is now known as GabrieleV
13:09:23 *** Gbarr has joined #gnucash
13:22:16 *** StuM has quit IRC
13:30:40 *** codesmythe has joined #gnucash
14:14:43 *** MechtiIde has quit IRC
14:35:36 *** kraftb has quit IRC
14:50:24 *** codesmythe has quit IRC
15:03:06 <warlord> jralls: FYI, gmail might be having DMARC issues going through the list
15:04:04 <jralls> warlord: Yeah, I thought of that. I didn't want to overwhelm the poor guy with technobabble.
15:04:43 <warlord> I looked at the email he sent and I got a DKIM failure.
15:04:45 <jralls> warlord: I do hope that Google hasn't followed Yahoo! down that particular rabbit hole.
15:05:58 <jralls> warlord: Sigh. Well, with two major providers bouncing on DMARC I guess you have to turn on the workaround.
15:06:24 <warlord> Well, gmail doesn't use reject... they use something else.
15:07:00 <jralls> warlord: Does that mean it needs a different workaround?
15:07:02 <warlord> i.e., I dont think there are bounces from gmail-user-sent-messages.
15:07:26 <warlord> Well, I think I do need to enable the mailman dmarc workaround.
15:16:42 *** himaxx has joined #gnucash
15:34:27 *** himaxx has quit IRC
16:10:15 *** josePHPagoda1 has joined #gnucash
16:10:22 *** GabrieleV has quit IRC
16:10:22 *** josePHPagoda has quit IRC
16:10:22 *** Remo has quit IRC
16:10:22 *** calp has quit IRC
16:10:22 *** uXus has quit IRC
16:12:47 <lmat> jralls: I think I remember investigating that option
16:13:13 <lmat> jralls: hmmm...trying to remember
16:13:51 *** GabrieleV has joined #gnucash
16:17:06 <lmat> jralls: Obviously, it means that a KvpValueImpl* can never change its internal type (I don't know if this is a problem or now).
16:17:10 <lmat> doh s/now/not
16:18:46 *** Remo has joined #gnucash
16:18:46 *** calp has joined #gnucash
16:18:46 *** uXus has joined #gnucash
16:24:06 <lmat> I think there can't be a constructor like <template typename A> KvpValueImpl (A const &); we would need to go to factory generation instead.
16:24:14 <lmat> Oh wait, maybe not...
16:24:57 <lmat> In short, I'm not sure; maybe it could be done :-) But what is boost::variant for?
16:25:54 <jralls> lmat: Boost::variant is for cases where you'd use a union in C: Where the type of what's in the object can change at run time.
16:27:28 <lmat> jralls: And that's what we're dealing with here?
16:27:30 <jralls> lmat: A template class's constructor will get created by the compiler when it encounters a requirement for one. You limit the types that can be constructed by making the default throw, then specialize it for the types that you want to support.
16:28:05 <jralls> lmat: I don't think that's what we're dealing with here. I think that KvpValue types are known at compile time.
16:31:42 <lmat> jralls: I'm looking at void set(T); (which could change types), but if that was removed (and I think it's not used), it seems likely that a template implementation would be viable.
16:32:00 <lmat> jralls: I saw the union in C (the old implementation) and tried not to make any assumptions (about kvp_frames not changing type, etc.).
16:32:19 <lmat> oops s/frame/value/
16:47:27 <jralls> lmat: Except for KvpValues containing KvpFrames or GLists, they have only new() and get(). Those two can replace the contained KvpFrame or GList, but can't change type.
16:57:28 <gjanssens> hey I'm finally dipping my toes into the c++ conversion work :)
16:58:26 <gjanssens> I decided to start in csv import as that's a relatively isolated code area that allows me to experiment without interrupting the core work on qof and engine
16:59:09 <gjanssens> And if I succeed in using boost as a csv parser it has the potential to drop the goffice dependency
16:59:12 <jralls> gjanssens: Great!
16:59:23 <gjanssens> Anyway, still a looong way to go :)
17:00:05 <gjanssens> A basic question: when a create a class with a vector member variable, can I assume it to be initialized as an empty vector
17:00:26 <gjanssens> or should I explicitly call vector::clear() in the class' constructor ?
17:01:47 <gjanssens> I'm assuming it starts with a proper empty vector...
17:02:05 *** fabior has quit IRC
17:28:52 *** StuM has joined #gnucash
17:32:54 <jralls> gjanssens: Unless you tell it otherwise it will call the vector's default constructor. which will be empty. If you have some idea of how much you're going to be inserting into the vector you'll get a big speedup by initializing it with that size, because it will allocate the whole thing at once.
17:34:35 <jralls> e.g. myclass(size_t len) : m_vector(len * sizeof(object)) {} where std::vector<object> m_vector.
17:35:14 <jralls> Hmm, //where std::vector<object> m_vector.
17:43:47 <gjanssens> jralls: tx for the info.
17:44:09 <gjanssens> I don't think I can know the size in advance in this case
17:44:34 <gjanssens> The vector will hold column types for columns found in a csv file
17:44:50 <gjanssens> Each csv file can have a different number of columns
17:44:57 <jralls> That's probably OK, speed isn't going to be a concern there.
17:45:06 <gjanssens> What I thought as well
17:46:02 <gjanssens> So far I have converted the GncCsvParseData struct into a class and have added the functions related to it into member functions
17:46:20 <gjanssens> And replaced my first GArray with a vector
17:46:39 <jralls> Did you remember to write unit tests? ;-)
17:46:42 <gjanssens> It's still compiling (after fixing my typo's)
17:47:11 <gjanssens> I haven't (yet)
17:47:25 <gjanssens> I will have to study it to see how that can be done
17:47:40 <gjanssens> The csv importer is heavily UI dependent
17:48:15 <gjanssens> Lot's of functional code is in the assistant (gui) code
17:48:21 <jralls> I got a "conversion" (in the religious sense) experience last week when I spent 2 days chasing a guiled crash because I'd written too much without unit tests.
17:48:22 <gjanssens> I may have to clean that part up as well
17:49:25 <gjanssens> Ouch
17:49:26 <jralls> Yes, do separate the GUI and non-GUI parts, at least into separate files (one per class!) if not separate directories.
17:50:07 <gjanssens> Ok, I'll take that up as well
17:50:08 <jralls> Make that *two* per class, header and implementation.
17:50:19 <gjanssens> :)
17:50:29 <gjanssens> Going to bed now though
17:50:35 <gjanssens> See you later
17:51:11 <jralls> The easy way to start is to do your C++ classes in new files and then replace the calls in the Wizard code.
17:51:16 <jralls> G'night.
17:52:36 *** gjanssens has quit IRC
17:58:13 *** rickoehn has quit IRC
19:27:03 *** himaxx has joined #gnucash
19:47:09 *** himaxx has quit IRC
19:48:15 *** mlncn has quit IRC
19:49:44 *** ErKa has quit IRC
20:17:02 *** ErKa has joined #gnucash
20:24:02 *** lmat has quit IRC
20:59:41 *** mlncn_ has joined #gnucash
21:46:10 *** ErKa has quit IRC
22:12:29 *** GabrieleV_ has joined #gnucash
22:12:30 *** GabrieleV has quit IRC
22:12:30 *** GabrieleV_ is now known as GabrieleV
22:37:31 *** GabrieleV_ has joined #gnucash
22:37:40 *** GabrieleV has quit IRC
22:37:40 *** GabrieleV_ is now known as GabrieleV
23:07:30 *** GabrieleV_ has joined #gnucash
23:07:36 *** GabrieleV has quit IRC
23:07:36 *** GabrieleV_ is now known as GabrieleV