2016-03-08 GnuCash IRC logs

00:36:34 *** Mechtilde has quit IRC
00:54:41 *** finster has joined #gnucash
00:54:43 *** minot has quit IRC
00:57:11 *** minot has joined #gnucash
01:11:21 *** rubdos has joined #gnucash
01:19:35 *** minot has quit IRC
01:20:16 *** minot has joined #gnucash
01:53:35 *** ErKa has joined #gnucash
02:06:53 *** ErKa has quit IRC
02:13:48 *** fabior has joined #gnucash
02:59:07 *** gncbot sets mode: +o fell
03:34:48 *** rubdos has quit IRC
06:28:35 *** ErKa has joined #gnucash
06:53:39 *** ErKa has quit IRC
07:03:50 *** Jimraehl1 has left #gnucash
07:09:59 *** Jimraehl1 has joined #gnucash
07:36:55 *** fabior has quit IRC
07:51:29 *** ErKa has joined #gnucash
08:08:54 *** ErKa has quit IRC
08:09:54 *** fell_ has joined #gnucash
08:11:59 *** fell has quit IRC
08:59:41 *** gjanssens has joined #gnucash
08:59:41 *** ChanServ sets mode: +o gjanssens
09:17:43 *** mlncn has joined #gnucash
09:27:46 *** ErKa has joined #gnucash
09:28:55 *** lwells has joined #gnucash
09:38:36 *** fabior has joined #gnucash
11:04:49 <gjanssens> jralls: I'm looking at your template code now
11:05:20 <gjanssens> What exactly is your worry about "going too far down the template path" ?
11:05:37 <gjanssens> I can follow what you're doing, like it even
11:06:29 <gjanssens> I can't comment though on whether it's good practise or not, given my beginner status in c++
11:07:17 * gjanssens is also looking at the rest of your branch as a learning example
11:09:31 <gjanssens> https://github.com/Gnucash/gnucash/commit/1f26dfdee3ad6 has an awful lot of whitespace fixes intermingled with the actual code changes.
11:09:53 <gjanssens> Do you plan to clean this up later on ?
11:10:16 <gjanssens> I'm just thinking we're telling other contributors to do so and something about dogfood... ;)
11:36:54 *** Mechtilde has joined #gnucash
11:41:47 <gjanssens> jralls: I'm adding comments/questions on github as I read through your code
11:42:18 <gjanssens> Some are more for my own education rather than feedback on your work so far. I hope you don't mind...
11:47:12 *** minot1 has joined #gnucash
11:48:09 *** minot has quit IRC
12:04:21 <jralls> gjanssens: I was worried about using type traits to control the template selection. If that makes sense to you then it's good.
12:04:49 <jralls> The code review is good, to. You've already got one catch.
12:05:04 <gjanssens> jralls: I'm fine with the type traits
12:05:14 <gjanssens> I understood after the second read already :)
12:06:22 <gjanssens> More in general on your code: I like your use of the other modern c++ concepts too (std::find, the alternative for loop, lambdas)
12:06:28 <gjanssens> They're good examples for me
12:07:06 <jralls> OK, good. Type traits is the first step down the metaprogramming rabbit hole. I'm new to that part of C++ too.
12:07:57 <jralls> I like lambdas. They're a huge improvement over function objects and boost::bind.
12:09:31 <gjanssens> They still require my brain to pause for a while, but that's ok
12:09:36 <jralls> The whitespace issue is from installing an emacs module that includes automatically fixing whitespace. It does make for dirty changesets, so I guess I should turn it off.
12:09:42 <gjanssens> The more I see them, the better I recognize them
12:10:41 <jralls> Really? I'd think they'd be second nature to someone fluent in Scheme. Is it because [](){} doesn't mean "lambda" to you?
12:11:02 <gjanssens> jralls: I'm not fluent in scheme :( Never was
12:11:28 <jralls> You're more fluent than I am!
12:11:44 <gjanssens> I did learn about lambdas for the first time in scheme though, and they still cause my brain to pause there as well...
12:12:04 <gjanssens> That may also be from counting parens though
12:12:56 <gjanssens> And yes, in C++ I'm not used to see [](){}, so I still have to remind myself they are lambda's
12:13:28 <gjanssens> That will probably become more natural when I start using them myself
12:13:40 <jralls> The bleeping parens make my head hurt. That and counting functions to figure out which one implements what in a class definition.
12:14:04 <gjanssens> :)
12:15:05 <gjanssens> jralls: brief pause at your commit message for de7752e3e8714cc5dde994fef75d44b56828715f: change variable names to m_ prefix
12:15:46 <gjanssens> I was wondering lately whether we did agree on some name scheme for variables, functions and so on
12:16:14 <gjanssens> I remember there was some discussion on it some time ago, but didn't immediately find a final summary of it
12:17:02 <jralls> I dunno if we agreed. I said something on the list last year and nobody complained. I think I put it in the wiki...
12:17:10 * jralls looks at wiki page...
12:18:09 <jralls> No, I didn't put it there.
12:18:39 <jralls> Is there another style you prefer to distinguish member variables? Or do you prefer not to?
12:18:48 <gjanssens> I did find http://wiki.gnucash.org/wiki/CodingStandard
12:19:15 <gjanssens> So we did more or less formalize it
12:19:44 *** mlncn has quit IRC
12:19:56 <jralls> Except that says camel-case everything and we did agree last year to camel-case class names and underscore-separate function names.
12:20:19 <gjanssens> I just had a hard time finding the right search parameter for the wiki
12:20:41 <gjanssens> Ok, then the wiki needs an update
12:20:58 <gjanssens> For the record, I am fine with the m_ rule
12:22:45 <jralls> I looked at http://wiki.gnucash.org/wiki/C++#Coding. I think I'll make that point at CodingStandard and fix the identifier casing in the latter.
12:23:46 <gjanssens> I also wondered whether we should we define a gnc:: namespace instead prefixing everything with Gnc ?
12:23:58 <gjanssens> I don't know the pros/cons of either though
12:24:24 <gjanssens> It just seems namespaces are more c++-y
12:27:43 <jralls> I feel strongly both ways. Namespaces are a nice way to prevent name collisions, but can be a pain and it's altogether too easy to stick a 'using namespace Gnc;' at the top of the file and forget what you'e doing. Do that with more than one namespace and you lose the benefit.
12:29:39 <gjanssens> Hmm true.
12:30:26 <gjanssens> I think we should only use "using namespace" on our own Gnc namespace anyway.
12:31:11 <gjanssens> I was mostly thinking for the long-term benefit of having the engine as a library that can be used in other projects (like an android or ios port)
12:31:41 <jralls> Agreed. The other wrinkle is that they have to be hidden from C, and I have no idea what Swig will do with them for talking to Scheme and Python.
12:32:26 <gjanssens> Interesting points. Perhaps it's too early to go that route.
12:32:30 *** mlncn has joined #gnucash
12:32:34 <gjanssens> Anyway, I have to leave for tonight (our guests have arrived)
12:32:35 <gjanssens> See you later
12:32:37 *** gjanssens is now known as gjanssens_afk
12:32:39 <jralls> G'night.
13:04:57 *** latentprion has joined #gnucash
14:01:02 *** mlncn has quit IRC
14:05:27 *** ErKa has quit IRC
14:10:41 *** bertbob has quit IRC
14:15:47 *** bertbob has joined #gnucash
14:38:11 *** mlncn has joined #gnucash
15:03:10 *** XAPO has joined #gnucash
15:20:36 *** XAPO has quit IRC
15:26:04 *** Mechtilde has quit IRC
15:37:29 *** fabior has quit IRC
15:54:22 *** fabior has joined #gnucash
16:52:33 *** ErKa has joined #gnucash
16:54:39 *** latentprion has quit IRC
17:31:02 *** fell_ has quit IRC
17:31:41 *** fabior has quit IRC
18:05:33 *** ErKa has quit IRC
18:15:11 *** mlncn has quit IRC
18:50:22 *** minot1 has quit IRC
19:25:37 *** gjanssens_afk has quit IRC
19:47:40 *** mlncn has joined #gnucash
19:51:19 *** mlncn has quit IRC
19:59:37 *** GnuGuest has joined #gnucash
20:05:24 <GnuGuest> Hi GnuCash devs... I have a question regarding the "gncOwner" concept in GnuCash. What is its purpose? How is it related to gncCustomer, gncVendor, gncEmployee, gncJob? Can it also be related to gncInvoice, gncBill, or any other gncInstances?
20:06:32 <warlord> GnuGuest: an Owner is a "base class" for objects that can "own" things (Jobs, Invoices). It's a generic container for a Customer, Vendor, or Employee.
20:07:04 <warlord> There is no "gncBill", a Bill is a GncInvoice with an Owner of Vendor.
20:07:15 <warlord> An Invoice is a GncInvoce with an owner of Customer
20:07:26 <warlord> and an expense voucher is a GncInvoice with an Owner of Employee
20:10:06 <GnuGuest> warlord, Thanks for the explanation.
20:12:58 <warlord> you're welcome.
20:16:10 <GnuGuest> Does this mean then, that gncCustomer (for instance) is a "Container" that can "own", say, a "gncInvoice"?
20:16:36 <warlord> No, a GncCustomer is not a container
20:16:46 <warlord> GncOwner is a meta-object container
20:16:58 <warlord> A GncInvoice is also a first-class object
20:17:19 <warlord> It DOES have an owner, via GncOwner, which can be one of the many types of owner
20:21:33 <GnuGuest> Hmmmm... okay. The reason I ask is because gncCustomer (C struct) has the QofInstance as a base class (ie: in the C-object system is the first starting field/structure), so I was wondering if the "ownerhsip" concept could be implemented by having an "owner" struct directly following the "QofInstance" to indicated multiple inheritance.
20:22:23 <GnuGuest> s/ownerhsip/ownership/gp
20:23:22 <warlord> No.
20:23:49 <warlord> GncOwner is a meta class
20:24:18 <warlord> Is this coming from a C++ translation concept? Or are you asking for some other reason?
20:26:59 *** latentprion has joined #gnucash
20:27:00 <GnuGuest> Yes, to the C++ translation concept... since it may be difficult to express/write multiple-inheritance in C, I was trying to understand the deeper concept of what gncOwner is trying to implement.
20:31:04 <GnuGuest> warlord, as you said it is a meta-class, but when I took a look at the code for gncCustomer and gncOwner, one has to wonder if in C++ the concept of "ownership" could be best expressed as an inheritance from a "Owner" class to a "Customer" class, for example.
20:31:14 *** latentprion has quit IRC
20:31:57 *** latentprion has joined #gnucash
20:34:09 <GnuGuest> In turn, "Employee", "Vendor", "Job"... would then just use "Owner" as a base class in C++ and the ownership relationship is thus preserved from the C-implementation to the C++ implementation.
20:36:30 <GnuGuest> This in turn implies that "Customer" (for example) in C++ could well be defined as inheriting from at least 2 base classes (qof/gnc)"Instance" and (gnc)"Owner" classes.
20:45:11 <warlord> Consider it an abstract base class (interface) from which Customer, Vendor, and Employee all inherit. And the Invoice is owned by a GncOwner
20:45:58 <warlord> but it's a meta class in that there is no "data" inherent in a GncOwner. All the data is stored in the subclass.
20:47:00 <GnuGuest> I understand, but that is exactly what a pure virtual base class in C++ is meant to serve.
20:49:53 <warlord> yes, i know.
20:50:10 <warlord> Anyways, gotta run.
20:50:40 <GnuGuest> Sorry, if I am stating the obvious, but I am really just trying to help.
20:51:18 <GnuGuest> Goodnight, warlord... it is nice chatting with you.
20:58:11 <latentprion> I'm here because I'm bad at money
21:05:50 *** GnuGuest has left #gnucash
21:21:19 *** DanC has joined #gnucash
21:22:08 <DanC> I'm working on a budget. The Income Expenses Transfers Total lines at the bottom look really handy, but they stay 0 no matter what I do. Clues?
23:15:46 *** latentprion has quit IRC