2014-05-23 GnuCash IRC logs

00:42:59 *** SteveG has joined #gnucash
00:59:56 *** MechtiIde has joined #gnucash
01:36:40 *** SteveG has quit IRC
01:42:28 *** SteveG has joined #gnucash
01:44:45 *** uXus has quit IRC
01:58:06 *** O01eg has quit IRC
01:59:59 *** uXus has joined #gnucash
02:05:51 *** floh1111 has joined #gnucash
02:11:26 *** jmd has joined #gnucash
02:41:19 *** ErKa has quit IRC
02:56:12 *** floh1111_ has joined #gnucash
03:01:18 *** floh1111 has quit IRC
03:09:34 *** gjanssens has joined #gnucash
03:09:34 *** gncbot sets mode: +o gjanssens
03:13:46 *** SteveG has quit IRC
03:25:49 *** uXus has quit IRC
03:28:48 *** uXus has joined #gnucash
03:34:38 *** aqua___ has joined #gnucash
03:45:48 *** aqua___ has quit IRC
04:02:01 *** StuM has joined #gnucash
04:26:37 *** fell has joined #gnucash
04:26:38 *** gncbot sets mode: +o fell
06:11:42 *** Jimraehl1 has joined #gnucash
06:21:02 *** Jimraehl1 has left #gnucash
06:25:24 *** Jimraehl1 has joined #gnucash
06:58:09 *** aqua___ has joined #gnucash
07:06:06 *** himaxx has joined #gnucash
07:07:34 *** himaxx has quit IRC
07:48:57 *** aqua___ has quit IRC
07:56:05 *** StuM has quit IRC
08:26:28 *** SteveG has joined #gnucash
08:26:53 *** pppp has joined #gnucash
08:43:51 *** StuM has joined #gnucash
08:48:12 *** ErKa has joined #gnucash
08:49:50 <fell> warlord, simon: IIRC open-subaccounts was always a read-only view because when creating a new transaction the from account would be undefined.
08:51:43 <Simon> the SubAccounts view isn't read-only if the account isn't a Placeholder account
08:52:51 <Simon> and it forces Transaction Journal view, so I have to specify all accounts manually if I create a new transaction
09:07:06 *** jmd has left #gnucash
09:16:11 *** pppp has quit IRC
09:19:05 <warlord> fell: Open Subaccounts should not be read-only, exactly because, as Simon says, it's a journal view and therefore you need to specify all splits for new transactions.
09:19:46 *** SteveG has quit IRC
09:22:57 <fell> Then file a bug report, simon.
09:23:25 *** wol has joined #gnucash
09:28:19 *** himaxx has joined #gnucash
09:28:36 *** jralls has quit IRC
09:29:10 *** himaxx has quit IRC
09:29:17 *** aqua___ has joined #gnucash
09:31:38 *** himaxx has joined #gnucash
09:32:59 *** aqua___ has quit IRC
09:34:15 *** himaxx has quit IRC
09:53:59 *** ErKa has quit IRC
09:59:37 *** susin has joined #gnucash
10:55:10 *** ErKa has joined #gnucash
11:18:35 *** wol has quit IRC
11:19:16 *** aqua___ has joined #gnucash
11:24:58 *** jralls has joined #gnucash
11:24:58 *** gncbot sets mode: +o jralls
11:27:27 *** wol has joined #gnucash
11:52:33 *** aqua___ has quit IRC
11:54:04 *** jmd has joined #gnucash
12:03:03 *** lmat has joined #gnucash
12:15:33 *** wol has quit IRC
12:16:15 *** AndroUser has joined #gnucash
12:21:12 *** rpg has joined #gnucash
12:23:06 <jralls> lmat: I've been thinking some more about the implementation of GncGUID.
12:24:33 <lmat> jralls: I'm all ... eyes ^_^
12:24:47 <jralls> ISTM we want it to be a typedef of POD of some sort rather than a normal PImpl because we want it to be stored in the object that it indexes.
12:25:11 <lmat> jralls: Ah yes, makes sense
12:26:00 <jralls> There's really only three things we want to do with it: serialize, deserialize, and check equality.
12:26:43 <jralls> Oh, and create, of course, that's what consumes almost all of the code in the current implementation.
12:26:52 <lmat> sure
12:26:54 <jralls> Am I missing anything?
12:26:58 <lmat> do we sort on it ?
12:27:02 <lmat> (so, compare)
12:27:08 <lmat> for binary search, etc.
12:28:27 <jralls> Right now we search linked lists of objects on the object's GUID. It's the #1 time consumer in profiling.
12:28:41 <lmat> Ah, that's necessarily not a binary search,then :)
12:34:02 <jralls> So the last thing we need to be doing is chasing more pointers around the free store to do that search. When we get to QOFId (which is what implements QofCollection) we can consider a faster implementation, but even then we won't want to be chasing *GncGUID around.
12:39:08 <jralls> boost::uuids::uuid is a POD, which is good, but ISTM that wrapping it in C while preserving its POD-ness might be a bit challenging. C needs to be able to call size_of(GncGUID) and get the right answer without understanding boost::uuids::uuid
12:41:40 <lmat> jralls: Yup, I'm not sure how that works...
12:42:07 *** AndroUser has quit IRC
12:51:26 *** lmat has quit IRC
12:53:05 *** aqua___ has joined #gnucash
12:53:07 <jralls> @tell lmat Maybe we can typdef char[16] GncUUID and then reinterpret_cast<> it inside the implementation code.
12:53:07 <gncbot> jralls: Error: "16" is not a valid command.
12:53:36 <jralls> @tell lmat Maybe we can typdef char\[16\] GncUUID and then reinterpret_cast<> it inside the implementation code.
12:53:36 <gncbot> jralls: Error: "16\" is not a valid command.
12:54:17 <jralls> @tell lmat Maybe we can 'typedef char[16] GncUUID' and then reinterpret_cast<> it inside the implementation code.
12:54:17 <gncbot> jralls: Error: "16" is not a valid command.
12:57:08 *** cigarshark has joined #gnucash
12:58:02 *** fell_ has joined #gnucash
12:58:04 *** gncbot sets mode: +o fell_
12:58:31 <jralls> @tell lmat Maybe we can \"typedef char[16] GncUUID\" and then reinterpret_cast<> it inside the implementation code.
12:58:31 <gncbot> jralls: Error: "16" is not a valid command.
12:59:57 *** StuM has quit IRC
13:00:52 <jralls> @tell lmat "Maybe we can typedef char\[16\] GncUUID and then reinterpret_cast<> it inside the implementation code."
13:00:52 <gncbot> jralls: The operation succeeded.
13:07:06 *** fell has quit IRC
13:12:38 *** rpg has quit IRC
13:25:02 <warlord> jralls: that was a very weird gncbot error!
13:25:13 <warlord> w.r..t GNCGuid, we also need the ability to assign it..
13:25:22 <warlord> (although I suppose that's just another c'tor)
13:25:33 <warlord> Why do we necessarily need it to be POD for C?
13:25:44 <warlord> Why would we need to use sizeof()?
13:31:30 *** rpg has joined #gnucash
13:31:38 *** rpg has joined #gnucash
13:53:58 *** jmd has quit IRC
13:53:59 *** jmd has joined #gnucash
14:02:35 <jralls> warlord: The supybot error is because it thinks that just about any special character introduces a command, so it took me a few tries to get the escaping right.
14:06:28 <warlord> *sigh*
14:06:41 <jralls> As for GncGUID, it needs to be a POD because C only recognizes POD and POD*. struct qualifies, but it doesn't know what to do with class.
14:08:02 <jralls> Why use sizeof()? How about foo = malloc(sizeof(Split));?
14:08:32 <warlord> jralls: that malloc should only happen within Split.c(pp) in xaccMallocSplit(). It shouldn't happen anywhere else.
14:09:10 <jralls> But even if you just declare a Split foo, the compiler has to use sizeof(Split) to allocate the right amount of memory on the stack.
14:09:19 <warlord> As for the class/struct thing.. wouldn't C accept a struct {} that has "member functions" defined #ifdef __cplusplus"?
14:09:33 <warlord> But we don't do that anywhere.
14:09:55 <warlord> Theoretically Split_t could be a "void*" ...
14:11:02 <warlord> Theoretically nothing outside of Split.c(pp) should need to know the structure definition.
14:11:18 <jralls> It will be a long time before we get to Split.cpp. It will be several months at least before we even get to qofinstance.cpp.
14:12:03 <warlord> fair enough. But in the interim, I think that GncGuid can be defined publically as: typedef struct _GncGuid GncGuid;
14:12:24 <warlord> and then struct _GncGuid can be defined "internally".. Unless we necessarily need to expose the implementation details?
14:12:28 <warlord> (for guid maybe we do?)
14:14:00 <jralls> So the choice is to have structs (qofinstance in particular) that contain a GncGUID to have a pointer or for the actual struct GncGUID to be public so that the compiler knows how much memory to allocate.
14:14:23 <jralls> Otherwise it raises "Incomplete type" errors.
14:14:43 <warlord> Oh, because qofinstance uses GncGUID in-place and not a pointer to it..
14:14:55 <warlord> Well, couldn't we do something like:
14:14:57 <warlord> struct GncGuid {
14:15:05 <warlord> char[16] guid;
14:15:13 <warlord> #ifdef __cplusplus
14:15:20 <warlord> <methods here>
14:15:22 <warlord> #endif
14:15:24 <warlord> };
14:16:15 <jralls> Except that for C++ we want "class GncGUID : private boost::uuids::uuid {"
14:16:37 <jralls> So for the C wrapper we need to lie.
14:16:54 <warlord> Hmm...
14:17:19 <warlord> would this work:
14:17:24 <warlord> struct GncGuid
14:17:28 <warlord> #ifdef __cplusplus
14:17:38 <warlord> : private boost::uuids::uuid
14:17:40 <warlord> #endif
14:17:41 <warlord> {
14:17:43 <warlord> ......
14:18:20 <warlord> (I dont know if you can "subclass" a "struct" in C++)
14:18:53 *** SteveG has joined #gnucash
14:19:08 <jralls> You can. struct and class are equivalent, except that the default privacy in a struct is public and of a class, private.
14:20:16 <warlord> okay...
14:20:23 <warlord> :)
14:20:47 <jralls> Rather than clutter up the declaration with a bunch of ifdefs, it might be better to have
14:21:00 <jralls> #ifdef __cplusplus
14:21:22 <jralls> class GncGUID : private boost::uuids::uuid {
14:21:25 <jralls> ...
14:21:29 <jralls> }
14:21:34 <jralls> #else
14:21:45 <jralls> struct GncGUID {
14:22:11 <jralls> char element[16];
14:22:13 <jralls> }
14:22:18 <jralls> #endif
14:22:37 <warlord> my main issue with that is you need to keep them in sync and make sure they are the same size
14:23:09 <jralls> You do any way you can think of except having pointers.
14:23:56 <warlord> Sure... but if the body of the definition is shared you're less likely to make a mistake..
14:24:39 <warlord> (although I suppose in this case we inherit the "size" from boost::uuids::uuid and need to make sure that's handled in the C side..)
14:24:52 <jralls> Exactly.
14:25:20 <jralls> In fact, we don't even want to use structs here. We want
14:25:28 <jralls> #ifdef __cplusplus
14:25:44 <jralls> typdef boost::uuids::uuid GncGUID;
14:25:47 <jralls> #else
14:26:00 <jralls> typedef char[16] GncGUID;
14:26:05 <jralls> #endif
14:26:28 <warlord> but if we do that we lose the ability to define our own c++ methods on the class.
14:26:57 <jralls> We don't need any in this particular case.
14:27:53 <jralls> In fact, not only do we not need any, we don't want any, because that ruins the POD-ness of boost::uuids::uuid and makes it much less efficient.
14:28:39 <jralls> That won't be true of GncNumeric, which is another class that we want to be as POD-like as possible.
14:32:05 <warlord> True
14:32:16 <warlord> The SWIG bindings are going to be ... interesting...
14:32:18 <warlord> especially with GUID!
14:34:29 <jralls> SWIG is primarily a C++ tool, but for the short term I think we'll have to hide the C++ from it.
14:37:16 <jralls> Once we get to the GObject-based classes it should actually be easier for SWIG to handle their C++ replacements.
14:38:21 <jralls> Especially with Python; the object models line up pretty well. I'm less sure about Scheme because I'm not really familiar with its object model.
14:40:13 <warlord> jralls: unrelated mac question: is tehre an easy way for me to get a mac to tell me the BSSID of the AP that Wifi is using?
14:41:31 <jralls> Can netstat do that?
14:41:33 *** SteveG has quit IRC
14:44:32 <warlord> I dont think so...
14:44:42 <warlord> on linux I'd use iwconfig
14:44:56 <jralls> Found this: http://rednectar.net/2011/07/19/finding-the-bssid-of-the-access-point-your-macintosh-is-connected-to/
14:45:21 <jralls> The path to 'airport' is /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport
14:45:50 <jralls> And saying that without arguments dumps a help screen.
14:48:00 <warlord> Awesome. Thanks
14:50:38 *** MechtiIde has quit IRC
14:54:44 *** aqua___ has quit IRC
15:08:28 *** jralls has quit IRC
15:11:16 *** jralls has joined #gnucash
15:11:17 *** gncbot sets mode: +o jralls
15:16:32 *** jralls has quit IRC
15:17:04 *** jralls has joined #gnucash
15:17:04 *** gncbot sets mode: +o jralls
15:48:21 *** SteveG has joined #gnucash
15:49:11 *** jmd has quit IRC
15:49:58 *** aqua___ has joined #gnucash
15:52:09 *** wafflejock has quit IRC
16:01:03 *** ErKa has quit IRC
16:02:36 *** ErKa has joined #gnucash
16:16:39 *** aqua___ has quit IRC
16:24:23 *** floh1111_ has quit IRC
16:24:25 *** rpg_ has joined #gnucash
16:33:36 *** rpg has quit IRC
16:47:29 *** wol has joined #gnucash
16:51:50 *** wol has quit IRC
16:59:35 *** susin has quit IRC
17:13:05 *** gjanssens has quit IRC
17:25:50 *** wafflejock has joined #gnucash
17:50:44 *** rpg_ has quit IRC
18:41:07 *** wafflejock has quit IRC
18:42:51 *** SteveG has quit IRC
18:45:20 *** wafflejock has joined #gnucash
19:08:13 *** StuM has joined #gnucash
20:33:12 *** cigarshark has quit IRC
21:00:19 *** jralls has quit IRC
21:35:10 *** jralls has joined #gnucash
21:35:10 *** gncbot sets mode: +o jralls
21:45:23 *** jralls has quit IRC
21:59:56 *** ErKa has quit IRC
22:58:52 *** wafflejock has quit IRC
23:18:50 *** jmd has joined #gnucash
23:21:36 *** ErKa has joined #gnucash
23:37:06 *** jralls has joined #gnucash
23:37:07 *** gncbot sets mode: +o jralls
23:47:20 *** jralls has quit IRC