2017-01-12 GnuCash IRC logs

00:41:16 *** O01eg has quit IRC
00:52:41 *** fell has quit IRC
01:59:14 *** cartsoftware has quit IRC
02:14:29 *** rubdos has quit IRC
02:16:27 *** mlncn has quit IRC
02:27:55 *** cartsoftware has joined #gnucash
02:49:24 *** iliv has joined #gnucash
02:50:15 *** rubdos has joined #gnucash
02:56:17 *** rubdos has quit IRC
02:57:07 *** rubdos has joined #gnucash
02:59:45 *** Mechtilde has joined #gnucash
03:03:06 *** iliv has quit IRC
03:16:01 *** iliv has joined #gnucash
03:22:04 *** gjanssens has joined #gnucash
03:22:04 *** ChanServ sets mode: +o gjanssens
03:22:32 *** rubdos has quit IRC
03:42:11 *** iliv has quit IRC
03:48:33 *** iliv has joined #gnucash
03:53:21 *** fekepp has joined #gnucash
03:53:53 *** mrklintscher has joined #gnucash
04:12:53 *** fekepp1 has joined #gnucash
04:13:28 *** fekepp has quit IRC
04:15:49 *** fekepp1 has quit IRC
04:15:56 *** fekepp has joined #gnucash
04:22:45 *** hoijui has joined #gnucash
04:34:34 *** fabior has joined #gnucash
05:05:21 *** fabior has quit IRC
05:18:31 *** fabior has joined #gnucash
05:36:02 *** rubdos has joined #gnucash
05:40:13 *** cartsoftware has quit IRC
05:48:32 *** hoijui has quit IRC
05:55:43 *** cartsoftware has joined #gnucash
06:54:11 *** fabior has quit IRC
07:00:59 *** iliv has quit IRC
07:14:04 *** fell has joined #gnucash
07:16:57 *** Jimraehl1 has joined #gnucash
07:49:36 *** rickoehn has joined #gnucash
08:00:51 *** mlncn has joined #gnucash
08:15:50 *** hoijui has joined #gnucash
08:37:55 *** iliv has joined #gnucash
08:47:59 *** fabior has joined #gnucash
08:51:45 *** fabior has quit IRC
08:53:57 *** KaiForce has joined #gnucash
08:55:48 *** gncbot sets mode: +o fell
09:06:46 *** fabior has joined #gnucash
09:14:01 *** mlncn has quit IRC
09:57:06 *** ThomasKeller has quit IRC
09:57:18 *** ThomasKeller has joined #gnucash
10:20:09 *** fabior has quit IRC
10:27:52 *** iliv has quit IRC
10:37:09 *** O01eg has joined #gnucash
10:42:35 *** Mechtilde has quit IRC
10:44:45 *** iliv has joined #gnucash
10:48:51 *** Mechtilde has joined #gnucash
11:19:06 *** mlncn has joined #gnucash
11:57:01 *** Mechtilde has quit IRC
11:59:02 *** hoijui has quit IRC
12:28:25 <gjanssens> I'm experimenting to get our tests based on gtest running on travis
12:28:44 <warlord> Cool
12:28:54 <gjanssens> First step is to get gtest installed locally (not system wide) on my own machine and see if I can build tests there
12:29:22 <gjanssens> I'm getting a test failure in qof that surprised me
12:30:58 <gjanssens> This is the relevant part of the error message /home/janssege/Development/googletest/googletest/include/gtest/gtest.h: In instantiation of ‘testing::AssertionResult testing::internal::CmpHelperEQ(const char*, const char*, const T1&, const T2&) [with T1 = long unsigned int; T2 = int]’
12:31:20 <gjanssens> And this is the line causing it EXPECT_EQ (keys.size (), 1);
12:31:54 <gjanssens> I understand keys.size() is unsigned and probably the literal 1 is assumed to be signed
12:32:04 <gjanssens> What surprises me is this hasn't come up before
12:32:30 <gjanssens> The source line exists since june 2015
12:32:55 <gjanssens> I'm using gtest and gmock from their source repository default clone
12:33:20 <gjanssens> So perhaps this is something that only happens in their working branch ?
12:33:54 <gjanssens> I can of course easily fix this by making this (uint) 1, but wonder if that's the proper solution here...
12:34:42 <warlord> gjanssens: what about 1UL?
12:35:37 <gjanssens> Even better I think
12:35:46 <gjanssens> I wasn't sure of the notation...
12:47:34 *** fekepp has quit IRC
13:00:22 *** fabior has joined #gnucash
13:08:50 *** iliv has quit IRC
13:09:10 *** iliv has joined #gnucash
13:18:19 *** Mechtilde has joined #gnucash
13:21:33 *** iliv has quit IRC
13:34:34 *** fekepp has joined #gnucash
13:42:33 *** fabior has quit IRC
13:53:27 *** mrklintscher has quit IRC
13:56:30 <jralls> gjanssens: I suspect that it's because compilers have gotten pickier.
13:57:32 *** fabior has joined #gnucash
13:57:44 <jralls> cira: The metadata issue is probably because you didn't copy ~/Library/Application Support/gnucash to your PPC box.
13:58:19 <cira> Mmm, I'll check.
13:59:24 <jralls> cira: And you're running 10.5 on it, not 10.6. 10.6 supported only Intel Macs. Unfortunately 10.9 will be required for Gnucash 2.8 because that's the earliest version whose C++ runtime supports C++-11.
14:00:05 <cira> figures
14:01:46 <cira> I have ~/Library/Application Support/Gnucash/ with a variety of configuration data, but this won't change sqlite access will it?
14:01:59 <jralls> That aside, it's not a good idea to expose such an old OS to the internet. Current Debian will install on a PPC mac quite nicely and will have up-to-date security patches.
14:02:27 <cira> The metadata I'm talking about is part of account's data...
14:02:45 <jralls> No, it won't have any effect on SQLite3.
14:04:22 *** karelk has joined #gnucash
14:04:58 <cira> Eh, it isn't, there's a freebsd system it's going through. And the web browser, etc, is new.
14:05:44 <cira> Recapping, when I convent an XML gnucash file to a SQLite file on this system, and then open the new SQLite file, gnucash 2.6.15 complains and not all of the data is present.
14:06:12 *** cartsoftware has quit IRC
14:07:32 <jralls> So you copy the XML file to the PPC, it opens without errors, then you save as SQLite, close and reopen the SQLite DB and it complains about it being from an older version of GnuCash?
14:07:53 <cira> My reports, accelerators, and so forth from 'Application Support' don't seem to be an issue.
14:07:53 <cira> Yes.
14:08:10 <cira> Also, the PPC is one of the systems which created the XML file.
14:08:38 <cira> I have a heterogenous environment.
14:08:59 <cira> The XML file works fine on the PPC build.
14:09:45 <cira> I'm using it now.
14:10:56 <cira> (works great)
14:11:15 <karelk> when I open the "Scheduled Transaction Editor" (in menu "Actions" -> Scheduled Transactions")
14:11:21 <karelk> it opens in new tab, with insane colors
14:11:29 <karelk> its light text on light background
14:11:31 <karelk> which makes it pretty much unreadable
14:11:45 <jralls> cira: That's really strange. Will the sqlite command (in Terminal) open the Gnucash database?
14:11:52 <karelk> here is a screenshot: http://imgur.com/a/zs1MK
14:12:27 *** mrklintscher has joined #gnucash
14:12:51 <karelk> and second, it opens in a new tab, even though I have "open in new window" checked in Preferences
14:14:36 <jralls> keralk: The colors thing would be a theme problem. The preference item applies to new registers, not the SX editor. You can convert it to a window with Windows>New Window Wit Page.
14:15:27 *** fabior has quit IRC
14:16:25 <cira> karelk: I saw some problems with the themes under Win10 of 2.6.15 -- the theme selector crashes on certain themes....
14:16:46 <karelk> jralls: the "Windows" -> "New Windows with page" , I have to do it each time ?
14:16:52 <karelk> it does not remember my setting
14:17:09 <jralls> karelk: Yes, every time.
14:17:55 <cira> jralls: sqlite3 opens the file -- and .tables gives me a list of 24 entries.
14:18:04 <karelk> cira: I am on Debian, so I guess my theme comes from gtk
14:18:29 <karelk> but i don't have any problems in other applications
14:18:39 <jralls> karelk: Your theme comes from whatever you chose it to be. That's not the default Debian theme.
14:19:42 <jralls> karelk: There are some color choices in GnuCash that haven't been maintained since before themes. The calendar control in the SX editor is one of them.
14:22:15 <karelk> jralls: it seems to me, gnucash is only taking the text color from my theme
14:22:24 <karelk> and ignoring my dark background color
14:24:24 <jralls> karelk: I think that's correct. You can override the style in ~/.config/gtkrc-2.0.
14:25:21 <jralls> There might be a GUI style editor on Debian that can make it a bit less painful than text editing. I don't know, I don't mess much with themes.
14:26:37 <jralls> http://wiki.gnucash.org/wiki/FAQ#Q:_How_get_I_rid_of_strange_unreadable_characters_or_adjust_the_font_size has a brief instructions to get you started.
14:27:50 <karelk> jralls: thanks
14:32:26 <jralls> cira: When you open the SQLite db on GnuCash, I imagine that you select "OK" to do an upgrade. If you close and reopen afterwards do you get the same error?
14:33:57 <karelk> jralls: do you happen to know where in the source code the SX editor colors are defined ?
14:34:13 <karelk> is there an easy way to hardcode a color ?
14:34:25 <karelk> actually just changing the text color would solve my problem
14:34:41 <karelk> but only for the editor, not for the rest of gnucash
14:35:18 <cira> jralls: Yes. It just keeps griping every time. And if I build the SQLite file on another platform, the PPC build complains about that too.
14:35:33 <jralls> karelk: Should be src/gnome/dialog-sx-editor.c, but it's much easier to override the setting in gtkrc-2.0.
14:36:12 <karelk> overriding in gtkrc-2.0 will change colors everywhere
14:36:38 <jralls> karelk: No, you can specify it right down to the widget.
14:37:17 <karelk> what does it mean "right down to the widget" ?
14:37:26 <karelk> you mean per-application theme ?
14:37:49 <cira> widgets are UI elements on screen, like a button, menu, or a text field.
14:38:13 <karelk> if I change widchet for gnucash, it will affect whole gnucash, right ?
14:39:08 <cira> no, you should be able to be more fine grained than that. Or you could change it for all of gnucash.
14:39:30 <karelk> ok, I'll have a look at that
14:39:31 <karelk> thanks
14:40:30 <jralls> karelk: That would be an alternative. But in the line from the example in the FAQ says "widget_class "*" style "font", the "*" means every widget in every application. You can specify a particular widget calss. I think the one you want is "GncDenseCal".
14:44:20 <jralls> cira: OK, that sounds reasonable. What does 'select * from versions where table_name = "Gnucash";' return?
14:45:35 <cira> copy/paste ==> Gnucash|2061500
14:48:32 <jralls> Hmm. It should be 19920. Firing up my venerable if not too healthy PPC...
14:51:26 *** gjanssens has quit IRC
14:51:42 <cira> interesting . . . I get 2061500 from that command on the db created by the WinOS build too.
14:52:46 <cira> It looks the same under freebsd too. Still 2061500.
14:55:11 <warlord> cira: what if you create the SQL on Windows or BSD?
14:55:25 <cira> Yes, still the same.
14:55:33 <cira> Am I doing something wrong?
14:57:04 *** cartsoftware has joined #gnucash
14:57:44 <jralls> Hmm, and it's 2060800 in my primary DB. Aha, it sets "Gnucash-Resave" to 19920. So the DB_TOO_OLD check is comparing an apple and an orange.
14:58:08 *** iliv has joined #gnucash
14:59:00 <cira> OSX/PPC: `sqlite3 -version` == 3.4.0
14:59:29 <cira> FreeBSD: `sqlite3 -version' == 3.14.1 2016-08-11 18:53:32 a12d8059770df4bca59e321c266410344242bf7b
15:02:55 <jralls> cira: Gnucash is bundled with its own libsqlite, v 3.7.14. That's why I asked if the installed sqlite3 tool would work on it, I didn't know what version you have installed.
15:03:19 <cira> well, now you do :D
15:04:14 <jralls> Indeed.
15:08:45 *** iliv has quit IRC
15:09:11 <jralls> Ah, now I see what's going on. The "too old" error comes if GNUCASH_RESAVE_VERSION (19920) > the GnuCash version. That was originally an SVN revision number and when we switched to git it changed to a version number, which corresponds to 2.06.15, the release that created the database.
15:10:23 * cira does a happy dance
15:10:39 <jralls> So the problem must be in the comparison between what the query returns and the constant created by configure. Since it manifests on PPC and not Intel that points at an endianness problem.
15:12:51 <jralls> Let's see what the debugger tells us about that.
15:15:32 *** Brent has quit IRC
15:21:28 <jralls> Nothing, no symbols. I'll have to recompile, which will take a wee while.
15:31:28 <warlord> Oops
15:32:55 <jralls> Not really. It's a release build.
15:48:11 <karelk> jralls: where did you find the name of the widget: "GncDenseCal" ?
15:48:18 <karelk> that does not seem to work
15:48:30 <karelk> when I use this: widget_class "*" style "font"
15:48:40 <karelk> it works (for all applications)
15:48:47 *** Mechtilde has quit IRC
15:48:49 <karelk> but widget_class "GncDenseCal" style "font"
15:48:52 <karelk> has no effect
15:49:15 <jralls> karelk: src/gnome/gnc-dense-cal.h.
15:50:02 *** bertbob has quit IRC
15:50:19 <jralls> sorry, src/gnome-utils/gnc-dense-cal.h
15:54:08 <karelk> jralls: any idea why widget_class "GncDenseCal" style "font" has no effect ?
15:54:15 <jralls> Hmm, it's derived from GtkVBox. That probably doesn't take font styles.
15:58:13 *** bertbob has joined #gnucash
16:00:54 *** bertbob has quit IRC
16:02:51 *** bertbob has joined #gnucash
16:03:37 <jralls> No, it's calling gtk_widget_get_style() and passing the result to pango, so it *should* accept the style. Must need some more specification in gtkrc...
16:04:51 <jralls> Try "*.GncDenseCal".
16:06:00 *** bertbob has quit IRC
16:10:20 <karelk> jralls: "*.GncDenseCal" does not have any effect either
16:17:36 <jralls> karelk: OK.
16:18:41 <jralls> cira: No, not endian. It seems to be not loading the version information at all, so the version always comes out as "0".
16:22:11 *** bertbob has joined #gnucash
16:25:22 *** bertbob has quit IRC
16:41:27 *** bertbob has joined #gnucash
16:53:58 *** Brent has joined #gnucash
16:57:06 <jralls> cira: I recant. What's broken, and what probably explains most of the issues you're seeing--and maybe others as well--is that the GLib method for storing ints in a hash table is to cast them to pointers, and that seems not to work on PPC.
17:00:54 <jralls> IMO it's evil and shouldn't work anywhere, but that's a separate subject entirely. I think the fix would be to use a GValue containing the int instead, but I'm not sure I want to put in that amount of effort. Fixing the version table is simple enough but tracking down everywhere else G_INT_TO_POINTER is used would be a pretty substantial effort.
17:15:48 <jralls> karelk: You could try naming the rc file ~/.gtkrc-2.0.gnucash and see if that limits the effects to just GnuCash. Otherwise there's got to be a path that will work to set the style since widget "*" works. The basic doc is at https://developer.gnome.org/gtk2/2.24/gtk2-Resource-Files.html, but I'm not sure how to derive the correct path.
17:16:08 <jralls> You might also consider this way to set a different theme for GnuCash: https://ubuntu-mate.community/t/how-to-use-a-different-theme-for-individual-gtk2-applications/2514
17:33:04 <cira> yeah, many things in life sound easy, then you start digging and learn how difficult it would actually be. I think I will at least look at the source though.
17:33:18 *** KaiForce has quit IRC
17:37:28 *** xmaka has quit IRC
17:48:27 *** xmaka has joined #gnucash
18:02:37 *** mlncn has quit IRC
18:32:42 <jralls> @tell gjanssens I tried passing bogus dates to all of the relevant tests in test-gnc-date.c and got no exceptions. I checked out your cpp branch and got no test failures at all, never mind exceptions.
18:32:42 <gncbot> jralls: The operation succeeded.
18:43:05 *** mlncn has joined #gnucash
18:52:46 *** User_ has joined #gnucash
19:07:59 *** rickoehn has quit IRC
19:17:28 *** User_ has quit IRC
19:34:15 <jralls> @tell gjanssens Never mind, I messed up a build parameter so I tested the wrong source dir. Now I'm getting exceptions.
19:34:15 <gncbot> jralls: The operation succeeded.
19:58:22 <jralls> @tell gjanssens I've fixed and pushed the gnc_dmy2timespec_neutral exception leaks. It now PWARNS and returns INT64_MAX. I'll go through the rest of gnc-date.cpp and test/catch any other constructor calls tomorrow.
19:58:22 <gncbot> jralls: The operation succeeded.
21:00:08 *** mikee has quit IRC
21:02:04 *** mikee has joined #gnucash
21:02:05 *** ChanServ sets mode: +o mikee
21:53:41 *** wget has joined #gnucash
22:26:43 *** queso has joined #gnucash
22:27:51 <queso> So I had the cursor sitting in a transaction when I began reconciling an account. I marked that transaction as reconciled via the reconciliation window, but when I finished reconciliation and moved the cursor out of the transaction it un-reconciled it. Now the reconciliation is out of balance for next time. What can I do to fix it?
22:35:41 <queso> Well, I just re-reconciled the same date range and included that one missing transaction and I think it's good now. :)