2016-06-10 GnuCash IRC logs

00:10:30 *** fell has quit IRC
00:13:17 <dkcarlson> I have added my experience with GnuCash to that kde bug
01:15:40 *** Mechtilde has joined #gnucash
01:46:06 *** Mechtilde has quit IRC
03:24:07 *** gjanssens has joined #gnucash
03:24:07 *** ChanServ sets mode: +o gjanssens
03:32:08 *** fabior has joined #gnucash
04:01:07 *** ThomasKeller has joined #gnucash
04:06:15 *** aqua___ has quit IRC
04:11:12 *** uXuss has quit IRC
04:14:36 *** uXuss has joined #gnucash
04:20:21 *** aqua___ has joined #gnucash
04:38:19 *** nomeata has joined #gnucash
06:06:09 *** fell has joined #gnucash
07:44:30 *** fabior has quit IRC
08:03:52 <warlord> dkcarlson: have you tried using kioexec around gnucash?
08:23:16 <dkcarlson> The dangerous one wonders how he could do that?
08:23:50 <dkcarlson> he is still not an expert
08:32:12 *** finster has joined #gnucash
08:38:54 <warlord> dkcarlson: the same way they ran kioexec around the other apps in the bugreport
08:46:15 *** andy has joined #gnucash
08:51:16 *** andy has quit IRC
08:53:35 *** fabior has joined #gnucash
09:02:49 *** aqua___ has quit IRC
09:24:10 <dkcarlson> I shall try that this weekend. Going out of town today. Thanks for your help! bye.
09:24:20 *** dkcarlson has quit IRC
09:36:45 *** andy has joined #gnucash
10:14:46 *** kael has joined #gnucash
10:23:48 *** nomeata has quit IRC
10:28:10 <lmat> jralls: I'm happy to see the merge. What's next?
10:38:16 *** mlncn has quit IRC
10:42:28 <lmat> jralls: I'm interested in the idea of proper separation between the view technology and business logic, but I'm not sure 1) if now is the right time to start looking at that, and 2) where is a good place to start.
11:23:43 *** Mechtilde has joined #gnucash
11:27:16 <gjanssens> lmat: I'm happy to see the merge as well. Good work!
11:33:12 <gjanssens> lmat: as for what to do next, it seems to me it would be useful to get the remaining qof and engine objects converted to c++ first
11:34:06 <gjanssens> They should form the basis of further business logic refactoring
11:34:21 <gjanssens> Of course you are free to take on anything you feel like
11:34:48 * gjanssens is still slowly progressing on the csv importer conversion
11:35:19 <gjanssens> Parts of that conversion will probably have to wait until the transaction and split code have a c++ interface
11:35:35 * gjanssens wishes he had more time to spend on this...
11:55:22 *** kael has quit IRC
12:15:01 <lmat> gjanssens: Perhaps qofbook next? I don't think I know enough about the framework to decide what would be "best" next.
12:15:38 *** mlncn has joined #gnucash
12:26:37 <gjanssens> lmat: frankly I don't know for sure either...
12:27:11 <gjanssens> A quick glance in qofbook.h suggests it depends on qofid and qofinstance
12:27:45 <gjanssens> It looks like we're getting close to the c code that attempts to add some object orientation in gnucash
12:28:04 <gjanssens> I suppose the c++ conversion should make that code more or less obsolete
12:28:41 <gjanssens> Though we need to keep some temporary c api on top for everything that's not converted to c++ yet
12:29:01 <gjanssens> Perhaps jralls already has some ideas on how to best proceed here ?
12:48:18 *** mlncn has quit IRC
12:48:31 *** erikv has joined #gnucash
12:49:02 * erikv hi
12:49:23 <erikv> can i ask a question about setting up a form of a/r here?
12:54:37 <erikv> anybody home?
12:59:06 *** fabior has quit IRC
13:19:17 *** GabrieleV has quit IRC
13:20:48 <finster> hey there! you're probably aware, but the SSL certificate for gnucash.org has expired on june 2nd
13:23:07 <finster> % openssl s_client -connect gnucash.org:443 2>&1 </dev/null| sed -n '/----BEGIN/,/----END/p' | openssl x509 -noout -text | grep -A 3 Validity (19:22 ~)
13:23:10 <finster> Validity
13:23:12 <finster> Not Before: Mar 4 19:43:00 2016 GMT
13:23:14 <finster> Not After : Jun 2 19:43:00 2016 GMT
13:23:17 <finster> Subject: CN=gnucash.org
13:23:22 <finster> sorry for the lengthy paste
13:25:51 *** GabrieleV has joined #gnucash
13:31:25 <gjanssens> finster: yes, we are aware, but thanks for the heads up
13:31:46 <gjanssens> IUC we can't currently contact the responsible for the webserver
13:32:30 <gjanssens> erikv: don't meta ask, just ask your question directly and then wait (possibly for quite some time given timezone differences)
13:33:32 *** aqua___ has joined #gnucash
13:35:22 *** erikv has quit IRC
13:37:47 *** Mechtilde has quit IRC
14:07:45 *** minot has quit IRC
14:15:11 *** mlncn has joined #gnucash
14:47:00 <jralls> gjanssens, lmat: My feeling is that QofBackend is in the way of C++-izing QofInstance blocks QofBook and the rest of the engine. QofId and QofClass need to go away entirely as does GObject. That's blocked by QoFQuery and QofBackend. An interlocking horror show.
14:52:16 <jralls> So my plan is to get the backends in condition that they can support being derived classes of a new C++ QofBackend abstract class. My long-term goal is to have QofQuery be a wrapper for SQL, but I don't think we can get there directly.
14:52:22 *** mlncn has quit IRC
14:54:59 <jralls> Engine objects should be constructed directly from the backends instead of the current default-construct-and-set-parameters and similarly should be directly serialized in a single access rather than calling parameter getters.
14:55:30 *** mlncn has joined #gnucash
15:21:02 <jralls> Went off for some reading...
15:22:17 <lmat> jralls: Do the backends know about engine objects? (Engine objects consist of slots, transactions, accounts, etc., right?)
15:24:08 <jralls> lmat: The backends are pretty tightly coupled to the engine objects, yes. So is the GUI -- quite apart from the leakage of engine functionality into the GUI.
15:24:41 *** finster has left #gnucash
15:25:33 <lmat> jralls: Okay. So you're saying that now, the engine creates (malloc) an engine object, then sets its fields directly, but rather should construct them in one go?
15:27:07 <jralls> I was just looking at some alternatives to try and decouple things a bit. I think the GoF approach would be Observer, but the GUI libraries I'm familiar with--Qt aside--lead one towards tight coupling with the underlying classes.
15:29:14 <jralls> lmat: Yes. To complicate things there are 3 ways to set the fields: direct getter/setter functions, GObject properties, and QofClass getter/setter lookup.
15:29:51 <lmat> jralls: And if the engine classes have full constructors...
15:30:32 <lmat> jralls: So it sounds like I'll need to wait until some backend work is ready to move forward. I am still willing to familiarize myself with the code; any recommendations?
15:35:18 <jralls> lmat: Depends on what you want to work on. I haven't yet touched the XML backend, you could start converting that into classes and templates. You could also start extracting data manipulation functions from register/gnome/gnome-utils/app-utils. There's also some grunt-work to do, for example converting Timespec to time64 throughout the codebase so that we can get rid of the Timespec API.
15:37:33 <lmat> jralls: The last two sound most interesting so that I can give you room. I'll take a look through the front-end stuff and see if I can find code that shouldn't be there. I assume that data manipulation should be refactored into engine functions, right?
15:38:52 <jralls> Another thought: There's a lot of duplicated API in engine, i.e. multiple functions that do effectively the same thing, as well as a mish-mash of naming styles. Cleaning that up would make the eventual rewrite into C++ go a lot faster.
15:39:12 <lmat> What is time64? http://en.cppreference.com/mwiki/index.php?title=Special%3ASearch&search=time64
15:40:50 *** fabior has joined #gnucash
15:40:58 <lmat> (it doesn't appear to be a c++ std struct)
15:43:30 <jralls> lmat: It's 64-bit time_t. Posix specifies time_t as an int32_t. glibc decided to declare it as an int64_t on 64-bit systems, but BSD's libc didn't, so Apple's doesn't either, and IIRC neither does M$. So we have time64 defined in qof/gnc-datetime.h so that the mortgage calculator doesn't break when the date goes past 2038.
15:44:32 <lmat> gotcha :-)
15:45:00 <jralls> Timespec is a struct of an int64_t for seconds and an int32_t for nanoseconds, but we don't care about nanoseconds and always set that field to 0. There's a lot of wasted code dealing with that second field that needs to be removed.
15:45:17 <lmat> jralls: okay.
15:50:30 <jralls> On that same topic there's all of the GDate code. Christian Stimming thought that GDates would be a nice way to deal with the timezone problem for entry_date where we're not supposed to care about time (a subject of much discussion on the list). Nothing wrong with that except that it's a GLib dependency that we'd rather not have, so changing that to a GncDate (qof/gnc-datetime.hpp) will be necessary at some point, along wi
15:50:30 <jralls> th figuring out in each instance which (time64 or GncDate) is the correct class to use.
15:50:54 <jralls> Oh, and I got it wrong about where time64 is declared, it's gnc-date.h.
15:55:29 <lmat> jralls: Yeah, found it. I remember the issue of time-of-day on the list.
15:55:54 <lmat> Does GDate store a time of day?
15:56:29 <jralls> No: https://developer.gnome.org/glib/unstable/glib-Date-and-Time-Functions.html
15:56:52 <lmat> But GncDate does?
15:59:45 <lmat> Ah, GncDate doesn't. It's stored in a file called gnc-datetime.hpp because there's another class, GncDateTime which does.
16:00:19 <jralls> lmat: No, GncDate is a wrapper around boost::gregorian::date, http://www.boost.org/doc/libs/1_59_0_b1/doc/html/date_time/gregorian.html
16:00:41 <jralls> Or rather, "Right, GncDate..."
16:01:16 <lmat> Okay, thanks for the leads!
16:02:34 <jralls> Have fun!
16:25:47 <lmat> Oh crap... kvp_value can either hold int64_t or time64. Unfortunately, they are the same type.
16:45:09 *** mlncn has quit IRC
17:02:46 <lmat> I should e-mail Dave Peticolas. He wrote a comment in Account.c: "Because I can't use C++ for this project, doesn't mean that I can't pretend to! ..."
17:04:40 *** Simon has quit IRC
17:06:50 *** Simon has joined #gnucash
17:09:49 *** mlncn has joined #gnucash
17:12:51 *** fabior has quit IRC
17:23:00 *** Unhammer has quit IRC
17:23:09 <jralls> lmat: Unfortunately, he couldn't even pretend. :-?
17:23:22 <jralls> Err, :-/
17:24:57 *** aqua___ has quit IRC
17:25:55 <warlord> gjanssens, jralls, lmat .... i almost feel like we're getting to a point where we need a c++ branch to do some more, major re-construction, because adding all the C interfaces to keep backwards compatibility is requiring significant effort, only to be "removed" when it's done.. or worse, not removed and left as cruft.
17:26:44 <jralls> lmat: re kvp_value, are you using argument inference to set the correct visitor in C++?
17:27:58 <jralls> warlord: That's too dangerous. Without the C interfaces we can't test our work, so we'd run the risk of rewriting more than we need to.
17:29:02 <jralls> Or more correctly, we can't test that the C++ work still interacts correctly with the rest of the application. We might as well rewrite from scratch.
17:29:36 <warlord> jralls: true.
17:29:43 <warlord> but perhaps not a bad idea ;)
17:30:31 <jralls> The good news is that we can remove C API as soon as all of the users of that API are converted to using the replacement C++ API.
17:32:57 <jralls> Maybe not a bad idea to start over from first principles, but there isn't really enough developer bandwidth to do that and maintain the existing GnuCash.
17:33:26 <jralls> warlord: Separate subject, I think it's time to phone Linas about the certificate.
17:34:35 <warlord> jralls: I always just grab his # from whois. (see pm)
17:35:20 <warlord> I'm out of the country right now, so hard for me to phone him. I'll be back state-side late Monday.
17:36:15 <lmat> jralls: yes. boost uses a visitor pattern to get something from a boost::variant (in this case, writing the variant as a string). This relies on template specialization.
17:36:27 <lmat> kvp-value.cpp:121
17:36:59 <lmat> a struct to_string_visitor that has overloads for operator() for each type. void operator()(int64_t val) { output << val; }, etc.
17:37:35 <lmat> Perhaps I can take a look at how often that int64_t is used?
17:37:40 *** mlncn has quit IRC
17:38:40 <jralls> lmat: Right, but you can either let the compiler figure out which specialization to use or specify in code: to_string_visitor<time64>().
17:41:34 <jralls> We could also turn time64 into a struct with a single int64_t element. It would be the same size but the compiler would know the difference.
17:43:32 <jralls> I like that idea better. Much cleaner and type-safe.
17:58:00 *** fell_ has joined #gnucash
18:00:29 *** fell has quit IRC
18:23:10 *** gjanssens has quit IRC
19:00:36 *** CDB-Man_ has quit IRC
19:16:09 *** minot has joined #gnucash
19:38:10 *** andy has quit IRC
19:39:58 *** CDB-Man has joined #gnucash
19:41:32 *** CDB-Man has quit IRC
19:41:44 *** CDB-Man has joined #gnucash
19:44:11 <lmat> jralls: Good. I like it, too.
19:45:39 <lmat> jralls: Of course...once it's a struct...may as well have member functions...
19:45:55 <jralls> lmat: ;-)
19:46:21 <jralls> Though in the short term that will complicate its use in C.
21:11:14 *** mlncn has joined #gnucash
21:23:48 *** andy has joined #gnucash
22:01:04 *** andy has quit IRC
22:13:37 *** minot has quit IRC
22:16:56 *** andy has joined #gnucash