2015-09-23 GnuCash IRC logs

01:16:28 *** MechtiIde has joined #gnucash
02:10:44 *** MechtiIde has quit IRC
02:46:53 *** uXus has quit IRC
02:51:50 *** uXus has joined #gnucash
03:15:39 *** adrellias has quit IRC
03:17:45 *** fabior has joined #gnucash
03:32:37 *** rubdos has joined #gnucash
03:43:32 *** nomeata has joined #gnucash
04:13:51 *** fell has joined #gnucash
04:31:23 *** nomeata has quit IRC
05:00:03 *** fabior has quit IRC
05:01:14 *** fabior has joined #gnucash
05:40:23 *** rubdos has quit IRC
06:09:44 *** Jimraehl1 has left #gnucash
06:31:06 *** Jimraehl1 has joined #gnucash
06:34:50 *** aqua___ has joined #gnucash
06:55:49 *** dkcarlson has joined #gnucash
06:56:44 <dkcarlson> Is F::Q broken? It is failing on both of my computers
07:03:45 *** fabior has quit IRC
07:04:27 *** aqua___ has quit IRC
07:06:37 *** aqua___ has joined #gnucash
07:20:03 *** aqua_ has joined #gnucash
07:21:32 *** fell has quit IRC
07:22:29 *** aqua___ has quit IRC
07:23:47 *** himaxx has joined #gnucash
07:24:19 *** fell has joined #gnucash
07:26:31 *** himaxx has quit IRC
07:33:19 *** Jimraehl1 has left #gnucash
07:33:42 *** nomeata has joined #gnucash
07:46:27 <dkcarlson> now it is working again
07:46:40 *** dkcarlson has quit IRC
07:51:24 *** Jimraehl1 has joined #gnucash
07:53:19 *** uXus has quit IRC
07:57:40 *** uXus has joined #gnucash
08:16:32 *** gjanssens has joined #gnucash
08:16:32 *** ChanServ sets mode: +o gjanssens
08:17:36 <gjanssens> .
08:17:36 <gncbot> gjanssens: Sent 15 hours and 33 minutes ago: <jralls> Sorry, I was out to lunch. I don't have much experience with cairo either. Goocanvas might be a better choice as it's a bit higher level.
08:17:37 <gncbot> gjanssens: Sent 15 hours and 26 minutes ago: <jralls> The Register code seems to have been lifted from Gnumeric. It looks like most of it predates Gtk2, but the basic architecture of list and tree controls is pretty similar to the current GtkTreeView code, including the separation of the model , which has the code for assembling the list/tree, and the view , which has the widgets that make up a line in the displayed list. The main problem is that there's a l
08:17:38 <gncbot> gjanssens: Sent 15 hours and 19 minutes ago: <jralls> The Reg2 code is mixed because Bob started out by copying the Reg1 code and then modifying only the stuff he needed. Unfortunately he's in the copy & paste camp instead of the extract function camp, so there's tons of duplicated code everywhere. I pushed back his latest patches in part for that reason.
08:17:39 <gncbot> gjanssens: Sent 15 hours and 16 minutes ago: <jralls> Reg2 was pretty close to ready when we released 2.6 and set it aside. Since it's based on much more modern controls it's probably a better use of time to fix it up rather than trying to modernize Reg1.
08:30:37 *** himaxx has joined #gnucash
08:30:58 *** himaxx has quit IRC
08:41:34 *** nomeata has quit IRC
08:52:08 *** fabior has joined #gnucash
09:02:15 *** aqua_ has quit IRC
09:07:55 *** rubdos has joined #gnucash
09:27:37 <gjanssens> Back to writing unit tests for the csv importer (I know I'm jumping up and down between projects...)
09:28:07 <gjanssens> I'm writing what should be my 10th version for my first test :)
09:28:33 <gjanssens> I have the basic test framework in place
09:29:12 <gjanssens> My first implementation was a single function that calls parse_date() inside a g_assert function.
09:30:05 <gjanssens> The advantage is that a failed test would print a message in the log which immediatly shows the date and format that were passed to parse_date
09:30:41 <gjanssens> example call: g_assert(parse_date_without_year ("0801", 0));
09:31:04 <gjanssens> Upon failure the test log would show 'parse_date_without_year ("0801", 0) failed'
09:31:09 <gjanssens> So far so good
09:31:39 <gjanssens> (Actually that should have been g_assert(parse_date_without_year ("0801", 0) == -1);
09:32:19 <gjanssens> The trouble is, parse_date (or it's private subroutine parse_date_without_year) return a time64
09:32:40 <gjanssens> while the csvimport function only cares about the day/month/year information in there
09:33:12 <gjanssens> So I slightly altered the code to convert the returned time64 into a tm struct and only assert
09:33:47 <gjanssens> on the expected values of its tm_year, tm_mon, tm_mday members
09:34:15 <gjanssens> The assert however now looks like this:
09:34:56 <gjanssens> g_assert (exp_year==got_year && exp_month==got_month && exp_day==got_day)
09:35:34 <gjanssens> Upon failure that is logged, but I the log message now no longer lists the date string and format I started with.
09:36:11 <gjanssens> As I'll be testing lots of date string/format combinations it now becomes very difficult to figure out which combination failed exactly.
09:36:36 <gjanssens> And so I'm looking for a way to get that information logged again
09:36:57 <gjanssens> g_test_message didn't do the trick. There's nothing added to the log when I add that one.
09:39:59 <gjanssens> Oh, g_error seems to do the trick...
10:30:09 *** MechtiIde has joined #gnucash
13:28:25 <gjanssens> Hm, this is puzzling me...
13:28:37 <gjanssens> I have added some tests for csv-import
13:29:08 <gjanssens> For one particular test I get a segfault in "test-driver", which appears to be the logger we have enabled
13:29:18 <gjanssens> If I comment out this one test, the others work fine.
13:29:23 <gjanssens> So I'm focussing on this test
13:30:40 <gjanssens> Here's the odd thing: if I alter the generated test script to add --verbose to the call of the test binary, the test runs fine as well ?
13:30:47 <gjanssens> How could that be ?
13:31:31 <warlord> uninitialized memory?
13:33:50 *** rubdos has quit IRC
13:34:35 <gjanssens> warlord: perhaps
13:34:58 <gjanssens> It's just puzzling it only happens if the test script is called without verbose
13:35:14 <gjanssens> And more importantly, how do I find out ?
13:36:49 <gjanssens> warlord: do you have experience with the glib test harness ?
13:37:44 <warlord> run the test script in gdb?
13:50:21 <gjanssens> within gdb the test script also runs successfully :(
13:50:31 <warlord> uggh
13:51:34 <gjanssens> hmm, it doesn't get run with the same command line parameters
13:51:43 <gjanssens> Have to dig a bit deeper still
13:53:51 <gjanssens> in fact, it's make check that results in the crash
13:54:11 <gjanssens> running the script manually does work fine
13:56:11 <gjanssens> So make check must be doing something different from plainly calling the script
13:56:37 *** gjanssens is now known as gjanssens_
15:03:19 *** gjanssens_ is now known as gjanssens
15:11:14 <gjanssens> So... it get's more weird
15:12:13 <gjanssens> the one test that failed so far was test_gnc_csv_parse
15:12:25 <gjanssens> all other tests work if I disable this one test
15:12:35 <gjanssens> conversely, this test works when I disable all others
15:13:00 <gjanssens> that is - "make check" works fine in both cases
15:13:20 <gjanssens> it fails as soon as all tests are enabled
15:16:22 <gjanssens> And even more narrowed down: there are two tests that won't be run together on "make check"
15:16:44 <gjanssens> test_gnc_csv_parse and test_gnc_csv_new_parse_data
15:17:42 <gjanssens> the latter is a very basic call to gnc_csv_new_parse_data followed by a release of that same data again
15:18:02 <gjanssens> It's not even using the same variable as the other function
15:18:25 <gjanssens> So I'm totally lost why these two functions interfere
15:18:39 <gjanssens> And also only when called via "make check"
15:35:55 *** MechtiIde has quit IRC
16:14:06 <warlord> gjanssens: my guess is "state" --- something is assuming to have a zeroed out data but the previous test doesn't zero it out. Does the order of the two tests matter?
16:16:54 <gjanssens> warlord: more testing still brings me to 3 functions that fail to be run one after another instead of 2
16:17:13 <gjanssens> disabling any one of the three will make the others work
16:18:01 <gjanssens> order does matter
16:18:18 <gjanssens> it's test_gnc_csv_new_parse_data that segfaults
16:18:38 <gjanssens> If I put it last in row the others finish fine
16:18:56 <gjanssens> if it's first the others won't be called
16:19:17 <gjanssens> that is they're never reached because of the segfault in test_gnc_csv_new_parse_data
16:19:30 <warlord> So it sounds like test_gnc_csv_new_parse_data() is the problematic function if it dies before it gets to the others.
16:19:51 <gjanssens> But only so if the two others are still following
16:19:58 <gjanssens> If only one follows, no problem
16:20:05 <gjanssens> I can choose either to disable
16:20:13 <gjanssens> It just doesn't make sense
16:20:29 <gjanssens> More so because it only happens when running "make check"
16:20:46 <gjanssens> calling the test executable directly is fine in all circumstances
16:21:39 <gjanssens> I'm beginning to suspect a bug in one of the dependent libraries like glib
16:22:41 <gjanssens> In fact I can also prevent the segfault by not calling gnc_csv_parse_data_free in test_gnc_csv_new_parse_data
16:23:26 <gjanssens> But it's on a local variable that's newly initialized/malloced one line above
16:23:33 <gjanssens> I can hardly imagine how that can interfere
16:23:53 <gjanssens> unless glibs memory handling is failing there somewhere
16:25:12 <warlord> What if you run it by hand with the same environment as make check?
16:25:26 <warlord> e.g., same env vars, etc.
16:34:30 <gjanssens> warlord: how do I find out the environment ?
16:44:06 <warlord> Umm.. Add a test that does a 'printenv' and 'echo "$@" ?
16:44:15 <warlord> and then call that test from 'make check'?
16:44:26 <warlord> make check TESTS=my-printenv-test
16:56:43 <gjanssens> warlord thanks for the tip. I'll do that later as I'm done for today
16:57:17 <warlord> Yeah, its late by you
16:59:29 <gjanssens> I have pushed my work so far to a working branch on my personal github clone:
16:59:31 <gjanssens> https://github.com/gjanssens/gnucash/tree/csvimptest
16:59:52 <gjanssens> if you're interested you can have a look there
16:59:52 <warlord> Hope you track this down... Last time I had an issue like this it was due to some global or static variable that was assumed by multiple tests to be initialized, but of course test1 messed that up for test2
17:00:05 *** fabior has quit IRC
17:00:28 <gjanssens> or if jralls still appears later
17:00:29 <warlord> I'll take a look if I have time; I'm leaving in 30 minutes and wont be back until late, so I suspect you'l get back to it before I do.
17:08:36 <gjanssens> Well, I'm leaving now...
17:08:39 <gjanssens> Good night
17:08:54 *** gjanssens has quit IRC
17:49:14 *** Nytram has joined #gnucash
19:15:35 *** himaxx has joined #gnucash
19:29:19 *** himaxx has quit IRC