2016-10-12 GnuCash IRC logs

01:05:04 *** fell_ has joined #gnucash
01:06:51 *** fell has quit IRC
01:43:09 *** iliv has joined #gnucash
02:02:48 *** dgtlmoon has quit IRC
02:38:03 *** gjanssens has joined #gnucash
02:38:03 *** ChanServ sets mode: +o gjanssens
02:52:57 *** jralls has joined #gnucash
02:54:00 *** jralls_ has quit IRC
03:26:53 *** fabior has joined #gnucash
03:31:15 *** fabior has quit IRC
03:32:35 *** fabior has joined #gnucash
03:56:06 *** fell_ has quit IRC
06:04:51 *** karelk has joined #gnucash
06:05:37 *** karelk has joined #gnucash
06:06:01 *** karelk has left #gnucash
06:07:06 *** thecat has joined #gnucash
06:07:51 *** thecat has joined #gnucash
06:58:58 *** fabior has quit IRC
07:03:34 *** mlncn has joined #gnucash
07:31:19 *** Jimraehl1 has joined #gnucash
07:31:43 *** Jimraehl1 has left #gnucash
07:37:15 *** Jimraehl1 has joined #gnucash
07:54:57 *** CDB-Man_ has quit IRC
08:21:51 *** iliv has quit IRC
08:27:54 *** iliv has joined #gnucash
08:35:28 *** fabior has joined #gnucash
08:36:24 *** Jimraehl1 has joined #gnucash
08:36:59 *** Jimraehl1 has joined #gnucash
08:37:38 *** Jimraehl1 has joined #gnucash
08:38:05 *** Jimraehl1 has joined #gnucash
08:56:32 *** thecat has quit IRC
08:59:48 *** ChanServ sets mode: +o jralls
09:06:13 *** fabior has quit IRC
09:38:50 *** kael has joined #gnucash
09:45:00 *** kael has quit IRC
10:24:15 <jralls> gjanssens: Is https://lists.gnucash.org/pipermail/gnucash-devel/2016-February/039403.html the discussion you meant in your comment about GncTransProperty in PR101?
10:26:42 <warlord> So every part is enroute... except my RAM
10:40:33 *** iliv has quit IRC
10:52:23 *** iliv has joined #gnucash
11:49:40 *** iliv has quit IRC
11:52:04 *** fell has joined #gnucash
11:55:34 *** tuxd00d has quit IRC
11:57:04 *** fabior has joined #gnucash
12:07:52 *** tuxd00d has joined #gnucash
12:15:05 *** mlncn has quit IRC
12:15:32 *** iliv has joined #gnucash
12:22:28 *** Mechtilde has joined #gnucash
13:04:28 <warlord> Ah, I take that back. newegg just didn't update the order online or inform me that it shipped; it's scheduled for tomorrow. Yay. So I should have everything by Saturday.
13:14:42 *** mlncn has joined #gnucash
13:19:48 *** iliv has quit IRC
13:21:05 *** tuxd00d has quit IRC
13:23:56 *** iliv has joined #gnucash
13:31:45 *** tuxd00d has joined #gnucash
13:36:33 *** tuxd00d has quit IRC
13:46:05 *** Mechtilde has quit IRC
13:49:47 *** Mechtilde has joined #gnucash
14:02:31 *** tuxd00d has joined #gnucash
14:11:17 *** iliv has quit IRC
14:12:33 *** iliv has joined #gnucash
14:17:14 *** fabior has quit IRC
14:28:25 <gjanssens> jralls: yes, that's the one
14:38:59 *** iliv has quit IRC
14:53:47 <warlord> ... Oops, except for my rack rails. According to FedEx those still haven't actually left the warehouse. But everything else is actually moving according to FedEx and USPS, so I should have everything (except the rails) by Saturday. I don't need the rails to build/install the system, so that delay is just fine. On the other hand I probably wont be able to build the system until next weekend.
14:57:21 <warlord> Most everything should be arrving tomorrow and friday, except the CPU heatsink/fans which are scheduled for saturday.. and the rails, which haven't left.
15:01:53 *** fabior has joined #gnucash
15:04:32 <warlord> gjanssens: it's too bad we can't leverage the QIF importer code date-checking code.
15:09:01 <warlord> Actually, we might -- it uses RegEx to match different formats. There are four types, d-m-y, m-d-y, y-m-d, and y-d-m. The separators aren't important, the regex will deal with anything.
15:09:20 <warlord> Perhaps we can leverage that regex -- or refactor the code into C and then wrap it for use in the QIF importer?
15:11:35 <gjanssens> warlord: similar code is already in the csv importer as well - in c++ using boost::regex
15:11:53 <gjanssens> It supports 5 formats, 3 of which are the same as the qif importer
15:12:05 <gjanssens> the other two are for dates without a year
15:12:55 <gjanssens> I agree with jralls though it would be better to move this code into GncDateTime and have one single spot to handle it all
15:18:01 <warlord> But I thought there was an issue with the separators? Or did I miss a part of that conversation?
15:21:39 <warlord> Also, does it deal with the ambiguity like the QIF importer?
15:22:01 <warlord> (it would be nice to have a single subsystem can could deal with *any* date input -- from all importers)
15:25:55 *** kael has joined #gnucash
15:26:59 <gjanssens> The format jralls proposes would indeed be too limited. But nothing stops us from writing the extra GncDateTime constructor to accept both specific and generic formats and act according to which type is passed in.
15:32:55 <warlord> So long as there is a way to specify the ambiguity --- and a way to request the abiguity in order to ask the user.
15:34:11 <warlord> e.g., if I pass in "12/6", what does that mean? But if I pass in 12/6 , 12/10, 12/20 -- then it's no longer ambiguous.. But if I pass in 12/20 and 13/6 --- then we have a problem/ (this is from the qif logic)
15:35:59 <warlord> So it would be nice to have an API something like vector<Format> GncDataTime::GuessFormat(std::string&, vector<Format>=GncDateTime::dateFormatList)
15:36:35 <warlord> where dateFormatList is the list of possible formats we support (where format is purely the token order, not separator)
15:37:27 <warlord> Then we could have the Format be an argument to the constructor.
16:01:01 <jralls> Depends on which one I proposed. The current GncDateTime(const std::string&) constructor is limited to ISO dates, but that's just because that's what the existing C functions needed.
16:01:46 <jralls> The underlying parser in http://www.boost.org/doc/libs/1_51_0/doc/html/date_time/date_time_io.html is pretty capable. We can leverage that to get a lot more flexibility.
16:03:04 * gjanssens was referring to the additional constructor with an extra format specifier taking formats of the form "%d-%m-%Y"
16:04:00 <jralls> The problem with which is?
16:04:59 <gjanssens> That it doesn't match the flexibility of the current csv and qif parser in that it will only accept one separator in the date per format passed in
16:05:03 <warlord> I believe the problem is that '-' is literal
16:05:09 <gjanssens> right
16:05:48 <warlord> What we want is to be able to say %d<SEP1>%m<SEP2>%Y
16:06:12 <warlord> where <SEP1> and <SEP2> are valid seperators (and may be distinct)
16:07:38 <jralls> There's more than that: We should also be able to handle e.g. 12OCT2016 and localized variants thereof. So we need a regex parser to pick the string apart and reformat it.
16:08:23 <jralls> If we have to do that anyway then we might as well just reformat to a dmy tuple and pass that to a constructor.
16:08:37 <warlord> wouldn't that be %d-%b-%Y?
16:09:26 <jralls> The main point being that we should have a single parser in GncDateTime, not have a zillion of them splattered all over the place.
16:10:31 <jralls> warlord: No, not a string. If we're doing all of the parsing work ourselves it makes sense to pass in a std::tuple<uint, uint, uint>.
16:11:01 *** thecat has joined #gnucash
16:11:50 <warlord> jralls: We still need a parser to convert from string to the tuple.
16:12:06 <gjanssens> So you'd add parsing support for 12OCT2016 in GncDateTime as well if we want it, or are you saying whichever code want the GncDateTime conversion functionality should pre-parse the input into a dmy tuple
16:12:11 <gjanssens> ?
16:13:07 <jralls> warlord: That's the point: If we're doing a bunch of regex parsing, we might as well just make a tuple of ints rather than a standard string that boost::date_time has to parse again.
16:15:23 <jralls> gjanssens: I'm saying that we should have a single parsing facility that can take whatever kind of date string we decide we need and convert it to a std::tuple to construct the GncDateTime.
16:17:43 <jralls> The parser will need to take an optional format for disambiguation and should throw if it decides the date is ambiguous either because it didn't get a format or the format wasn't good enough.
16:18:05 <gjanssens> Agreed. However, why stop at the std::tuple, instead of directly returning a GndDateTime ? Are there use cases where we'd want the tuple itself ?
16:18:45 <gjanssens> Oh, perhaps because of the time which could be day_start, neutral or day_end ?
16:19:58 <gjanssens> I'm mostly picking your brain here jralls, as you wrote the new gnc-date classes so you probably know best at this point where it best belongs and in which format.
16:22:11 *** fabior has quit IRC
16:29:15 <jralls> I'm thinking of a pre-constructor function, or maybe set of functions, that do(es) all of the parsing and then calls the constructor with the std::tuple or with d,m,y params. If it turns out we need more than one parse function then having constructors do the parsing gets ugly because we have to have an additional type parameter to differentiate them.
16:29:20 *** Mechtilde has quit IRC
16:31:24 <gjanssens> Ok
16:47:13 <warlord> jralls: I dont agree it should throw, necessarily --- we might be in a UI that wants to detect the possible amiguities and ask the user -- which is why I suggested the API I presented earlier.
16:48:32 <jralls> warlord: Throwing is the standard way of saying "I don't understand, please try again." We sure as heck don't want UI stuff leaking into the very bottom of the engine.
16:51:03 <warlord> jralls: I want an API where I can present a date string, e.g. "1/2/16" and it will return the list of potential formats. I'd like, also, to be able to pass that same API the list of formats I got from a previous entry to further refine.
16:52:08 <warlord> At the end I have a (potentially empty) list. If the list is empty, then the input was bogus -- contained multiple date formats. If the list is a singleton, I disambiguated mechancally. If the list >1 entries I need to ask the user.
16:52:15 <jralls> I'm not saying that your guessing function is bad; it looks quite reasonable, though it does require pulling in all of the date fields and looking through them. But as you said, if we find 12/20 and 13/6 we have a problem. When there's a problem we have to signal an error somehow, and throwing is a lot cleaner than error returns, especially with dates.
16:52:35 *** thecat has quit IRC
16:53:13 <warlord> Yes, but the process of disambiguating shouldn't throw... except, perhaps, in the case where it gets to the #entries=0 case.
16:53:27 <warlord> in MOST cases the returned list will have >= 1 entries
16:55:28 <jralls> That's another level of parsing that would have to happen before actually starting to construct GncDateTimes; I suppose it (potentially combined with user input) be used to select which parsing function is used to pre-process the strings to pass to the constructor.
16:56:13 <jralls> sigh. it (possibly combined with user input) could be used...
16:56:59 <gjanssens> I agree this guessing function should be a separate function
16:58:01 <gjanssens> But it's a very useful function to simplify the user's life
17:07:48 *** mlncn has quit IRC
17:11:44 <gjanssens> jralls: I'll ponder your last question on the PR a bit later. It's time for bed here.
17:11:49 <gjanssens> See you
17:12:38 * jralls too. Goodnight, all.
17:12:46 *** jralls is now known as jralls_afk
17:13:53 *** gjanssens has quit IRC
17:18:45 <warlord> And this should all be centralized.
17:42:33 *** mlncn has joined #gnucash
18:07:48 *** kael has quit IRC
18:49:38 *** CDB-Man has joined #gnucash
18:53:09 *** CDB-Man has quit IRC
18:53:20 *** CDB-Man has joined #gnucash
19:47:34 *** tuxd00d has quit IRC
20:13:59 *** tuxd00d has joined #gnucash
20:44:10 *** mlncn has quit IRC
21:31:14 *** tuxd00d has quit IRC
22:09:32 *** tuxd00d has joined #gnucash
22:27:47 *** mlncn has joined #gnucash