2015-08-03 GnuCash IRC logs

09:58:08 *** gncbot has joined #gnucash
10:05:57 *** jimvideo has joined #gnucash
10:06:57 *** kimmo has quit IRC
10:10:00 *** mlncn_ has joined #gnucash
10:19:12 *** kimmo has joined #gnucash
10:39:28 *** MagicFab has quit IRC
10:41:30 *** warlord sets mode: +o gncbot
10:41:41 *** kimmo has quit IRC
10:41:59 *** rubdos has joined #gnucash
11:03:52 *** trav135 has joined #gnucash
11:06:04 *** MagicFab has joined #gnucash
11:06:59 *** trav135 has quit IRC
11:21:02 *** MagicFab has quit IRC
11:22:40 *** MagicFab has joined #gnucash
11:25:24 *** kimmo has joined #gnucash
11:26:59 *** MagicFab has quit IRC
11:47:24 *** cfoch has quit IRC
11:49:39 *** andy has quit IRC
11:52:27 *** MagicFab has joined #gnucash
11:56:28 *** fabior has joined #gnucash
11:57:49 *** MagicFab has quit IRC
12:01:43 *** O01eg has joined #gnucash
12:48:37 <jralls> warlord: It actually went down last night but with traceroute it looked like a network problem so I didn't ping you about it.
12:54:30 <warlord> Well, it was a network problem; the OS fell off the network (and somehow wedged).
12:54:37 <warlord> But it wasn't a "network problem" per se.
13:04:06 *** MechtiIde has joined #gnucash
13:06:22 <gjanssens> jralls: I checked Mechtilde's PR and it passes make distcheck now
13:06:22 <gncbot> gjanssens: Sent 1 day, 22 hours, and 25 minutes ago: <jralls> Usually no: Static functions are supposed to be implementation details. However in our legacy code it sometimes makes more sense to test the static implementation as the first step of a refactoring. I took that approach in a few cases in utest-Transaction, utest-Split, and utest-Account.
13:06:23 <gncbot> gjanssens: Sent 1 day, 22 hours, and 20 minutes ago: <jralls> The way I did it was to create a struct of pointers to the static functions and a function that initializes the struct and returns a pointer to it. I include that struct* in Fixture and call the init function in setup (or SetUp if you're using Google Test), then free it in teardown (or TearDown).
13:07:10 <jralls> gjanssens: Very good. Since you've already got it, could you merge and push?
13:07:22 <gjanssens> That's what I meant to ask :)
13:07:36 <gjanssens> Got sidetracked by your message from a couple of days ago
13:07:48 <gjanssens> Just received it now from gncbot
13:08:36 <MechtiIde> Thanks, I hope it will be better next time
13:08:44 <jralls> Apropos that, I worked on the testing docs, both wiki and doxygen, on Saturday. Can you have a look and see if they're clearer?
13:09:15 <gjanssens> Mechtilde: no worries - we all learn something new every day
13:09:32 <gjanssens> Thanks for working on the german translation
13:10:01 <gjanssens> jralls: I have read them and I'm happy with the improvements
13:10:34 <gjanssens> I particularly like the mention of make-testfile
13:10:50 <gjanssens> Played with it and was pleased to have found it
13:11:48 <jralls> gjanssens: Thanks, but do you think they're clear enough that you can start a new unit test?
13:12:11 <gjanssens> I used it to set up the test directory for csv-imp and moved my first attempts into the newly created file
13:12:25 <gjanssens> What do you mean with "a new unit test" ?
13:13:09 <gjanssens> Oh, that *I* can start a new unit test ? They are certainly clear enough for me to set up the required file structure.
13:13:52 <jralls> Yes, that's what I meant.
13:14:31 <gjanssens> So yes I can work from this.
13:15:16 <jralls> OK, good.
13:15:25 <gjanssens> I'll need to build up some experience in what to use as test data (ie determine normal inputs, bad inputs and how to trigger each branch in the functions...
13:15:58 <gjanssens> And I discovered parts of the csv importer are essentially untestable as it is written now :(
13:16:18 <gjanssens> There's a function that returns a time64 based on a date string input
13:16:35 <gjanssens> That function returns a different value depending on the time of the day you run it...
13:16:52 <jralls> Yeah, figuring out what inputs to supply to exercise the various code paths is the hard part.
13:16:54 <gjanssens> Instead of normalizing on a fixed time of day
13:17:30 <gjanssens> What is the normalized time we use internally for our dates ?
13:17:53 <jralls> Hmm. There should be something already in gnc-date.cpp for that.
13:18:54 <gjanssens> I'm still on maint...
13:19:09 <jralls> In maint, midnight, which was a dumb choice. I changed that to 1100 in master a few weeks ago. That keeps the date the same in all TZs except standard time just east of the Date Line (-12).
13:19:43 <jralls> OK, gnc-date.c then.
13:20:50 <gjanssens> Ok, I'll probably alter csv-import then to return reproducable results
13:21:36 <gjanssens> Since it's never had this, I can probably just start using 1100 on maint already as well ?
13:25:02 <jralls> This is for Transaction::date_posted, right? Better to use the same function that entering the txn in the GUI uses so that there's only one place to maintain it.
13:28:38 <gjanssens> Good reasoning
13:28:50 <gjanssens> However this is actually earlier in the code.
13:29:12 <jralls> OK, what's it for then?
13:29:16 <gjanssens> This is the part of the code that attempts to parse the date as found in csv and converts it to time64
13:29:41 <gjanssens> Which will likely be used later on to set the posted date (can't check right now)
13:30:12 <gjanssens> I'll try to get back to this later this evening
13:30:21 <gjanssens> (are you in Europe already ?)
13:35:15 <jralls> No, we're leaving for the airport around 2200 your time. I'm visiting a friend on a boat in the south of England for a few days, so I probably won't be up on IRC and will have spotty email until next Monday when we get to Glasgow.
13:37:13 *** storyjesse has quit IRC
13:37:38 <gjanssens> Ok
13:47:30 <jralls> So the Transaction posted-date setting routines like xaccTransSetDatePostedSecsNormalized converts the time64 into a GDate then calls gdate_to_timespeec() to set the actual variable. That in turn calls gnc_dmy2timespec, which sets it to midnight.
14:09:58 <gjanssens> Right. I see gnc-csv-model.c uses xaccTransSetDatePostedSecsNormalized as well to set the date of a transaction
14:10:07 <gjanssens> Which means it will get normalized at that point
14:10:36 <gjanssens> And hence I can choose any convention for my date parsing, as long as it returns a reproducible value
14:10:52 <gjanssens> So I'll just go with 1100 when parsing the date string as default time
14:11:03 *** fabior has quit IRC
14:39:15 *** MechtiIde has quit IRC
14:39:38 *** himaxx has joined #gnucash
14:42:17 *** himaxx has quit IRC
14:48:04 *** fell_ has joined #gnucash
14:50:39 *** fell has quit IRC
15:07:03 <jralls> gjanssens: I can't actually find a change in my boost-date series where I changed the posted_date timestamp to 1100Z, but that probably doesn't matter until I get to rewriting Transaction.cpp anyway.
15:09:24 <warlord> jralls: I'll take a look at the Cite extension, but it might be a bit before I can get to it.
15:10:24 <jralls> warlord: OK. Please remember to clean up the win32 logs when you have a moment.
15:10:29 *** mlncn_ has quit IRC
15:11:50 <gjanssens> jralls Ok
15:12:37 <warlord> Will do.
15:34:31 *** jimvideo has quit IRC
15:34:39 <jralls> Time for me to shut down here. Bye, all!
15:34:47 *** jralls has quit IRC
15:38:35 *** jimvideo has joined #gnucash
15:51:17 *** jimvideo has quit IRC
15:54:33 *** jimvideo has joined #gnucash
16:15:46 *** rubdos has quit IRC
16:24:08 *** rpg has joined #gnucash
16:28:45 *** gjanssens has quit IRC
16:30:59 *** jimvideo has quit IRC
16:36:22 *** jimvideo has joined #gnucash
17:44:17 *** jimvideo has quit IRC
17:51:51 *** rpg has quit IRC
17:59:27 *** rpg has joined #gnucash
18:38:55 *** MagicFab has joined #gnucash
18:52:31 *** rpg has quit IRC
19:00:41 *** MagicFab has quit IRC
19:27:46 *** himaxx has joined #gnucash
19:31:18 *** himaxx has quit IRC
21:24:07 *** fell_ has quit IRC