2021-03-20 GnuCash IRC logs

01:32:04 *** Robert847 has joined #gnucash
01:33:48 <Robert847> Hi I am looking for information on how the new Bayesian matching process is supposed to work
01:34:34 *** David has quit IRC
01:34:48 *** David has joined #gnucash
01:36:30 <Robert847> I have been importing transactions under the new process for several months and it still is not assigning the correct accounts to many transactions which the old process used to match correctly
01:39:08 <Robert847> for one thing, it appears to only look at the characteers in the description field before the first space character. Is that correct?
01:58:48 <Robert847> OK, poking around the import map editor it does appear to look at text strings case sensitive, but one string has appeared 22 times yet Gnucash still fails to associate transactions containing it to any account, when it always goes to the same one.
02:01:45 <Robert847> Since that string appears weekly, we are looking at over 5 months of data.
02:24:06 *** fell has quit IRC
02:25:11 *** fell has joined #gnucash
02:25:11 *** ChanServ sets mode: +o fell
02:48:10 *** frakturfreak has quit IRC
02:58:18 *** Mechtilde has joined #gnucash
03:02:37 *** frakturfreak has joined #gnucash
03:07:32 *** gjanssens has joined #gnucash
03:07:32 *** ChanServ sets mode: +o gjanssens
03:07:45 <gjanssens> .
03:07:45 <gncbot> gjanssens: Sent 7 hours and 2 minutes ago: <jralls> I didn't get any errors like yours, but GnuCash master didn't build successfully either. I'm out of time for today, I'll look at it some more tomorrow. I misremembered about pkgconf, I do have it installed rather than pkg-config. It might take a little python debugging to figure out the problem with your build.
03:21:34 *** Mechtilde has quit IRC
03:21:53 *** Mechtilde has joined #gnucash
03:37:10 *** sbluhm has joined #gnucash
03:37:10 *** ChanServ sets mode: +v sbluhm
03:47:40 *** sbluhm has quit IRC
03:57:24 *** andrewbt has joined #gnucash
04:10:56 *** andrewbt has left #gnucash
04:13:14 *** jervin has quit IRC
04:18:10 *** andrewbt has joined #gnucash
04:18:10 *** ChanServ sets mode: +v andrewbt
04:24:06 <andrewbt> Hi - new to IRC so hope I get this right:
04:24:21 <andrewbt> I’ve a problem with the cash entry for a stock transaction not showing in the bank account
04:24:21 <andrewbt> Following the wiki example 9.5.2.3 buying shares with net pricing, my transaction mirrors the screenshot in the example in the stock account, with the correct cost against the bank account in the Sell column
04:24:21 <andrewbt> But when I open the bank account I see the transaction but no amount
04:24:23 <andrewbt> Any ideas? Thanks
04:43:14 *** tomk_dk has joined #gnucash
05:01:38 <fell> andrewbt: I assume in the guide. I can't remember seeing it in the wikki.
05:02:34 <fell> Without amout usually means there is a problem with the exchange rate.
05:05:12 <fell> If you entered in the purchase got 50 IBM for 5000$ total, it shoiuld calculate the rate $50/IBM
05:06:09 <fell> or 51 in net pricing
05:14:50 *** fabior has joined #gnucash
05:36:21 *** sbluhm has joined #gnucash
05:42:49 *** Mechtilde has quit IRC
05:50:15 *** tomk_dk has quit IRC
05:51:43 <andrewbt> Thanks fell, you're right it's the guide not wiki, and there is something on currency which I'd not noticed
05:52:16 <andrewbt> The bank account is GBP, whilst the summary at the bottom of the stock account shows a total in CHF (my default)
05:52:16 <andrewbt> I don't remember setting currency for the stock - do you know if there's a way to change it?
05:52:32 <andrewbt> It should be in GBP
05:53:28 *** giuseppef has joined #gnucash
05:58:07 *** sbluhm has quit IRC
06:08:17 *** frakturfreak has quit IRC
06:08:19 *** frakturfreak has joined #gnucash
06:09:59 *** David has quit IRC
06:10:33 *** David has joined #gnucash
06:12:06 <fell> andrewbt: I would create assets:stocks:GBP.your_stock
06:12:53 <fell> the stock account inherits the currency from it's parent account.
06:18:45 *** sbluhm has joined #gnucash
06:18:45 *** ChanServ sets mode: +v sbluhm
06:19:14 <andrewbt> Yes, that worked! Many thanks fell
06:19:41 <fell> Welcome
06:28:30 *** sbluhm has quit IRC
06:28:49 *** User_ has joined #gnucash
06:30:09 *** sbluhm has joined #gnucash
06:40:39 *** sbluhm has quit IRC
06:54:46 *** Aussie_matt has quit IRC
06:56:38 *** Aussie_matt has joined #gnucash
07:45:40 *** sbluhm has joined #gnucash
07:45:40 *** ChanServ sets mode: +v sbluhm
07:52:28 *** User_ has quit IRC
07:59:17 *** User has joined #gnucash
07:59:19 *** sbluhm has quit IRC
08:03:20 *** fabior has quit IRC
08:08:07 *** sbluhm has joined #gnucash
08:08:07 *** ChanServ sets mode: +v sbluhm
08:25:21 *** sbluhm has quit IRC
08:31:43 *** sbluhm has joined #gnucash
08:31:43 *** ChanServ sets mode: +v sbluhm
08:40:42 *** Jimraehl1 has joined #gnucash
08:41:23 *** Jimraehl1 has quit IRC
08:43:54 *** David has quit IRC
08:44:08 *** David has joined #gnucash
09:08:59 *** ChanServ sets mode: +qo warlord warlord
09:09:00 *** warlord sets mode: +o gncbot
09:22:19 *** tomk_dk has joined #gnucash
09:22:42 *** sbluhm has quit IRC
09:27:29 *** storyjesse has joined #gnucash
09:27:37 *** sbluhm has joined #gnucash
09:27:37 *** ChanServ sets mode: +v sbluhm
09:47:03 *** Aussie_matt has quit IRC
10:17:30 *** chris has joined #gnucash
10:17:30 *** ChanServ sets mode: +v chris
10:17:30 *** gncbot sets mode: +o chris
10:17:56 <chris> .
10:19:34 <chris> giuseppef: you'll have to tell the narrative -- why the invoice postdate is in the future, and what you'd expect the receivable aging report to show, and why.
10:19:48 <chris> other business users will have opinion too
10:20:15 <giuseppef> hi chris
10:21:25 <giuseppef> I think the receivable aging should show the time between "now" and due date
10:22:47 <giuseppef> The reason why I used to post those invoices in the future, is related just to my accounts, so I don't think it is important. However:
10:23:51 *** sbluhm has quit IRC
10:24:23 <giuseppef> I use gnucash for accounts of a noprofit organization; those invoices are amounts annualy due from associated (my "customers"). The date when they have the obligation to pay is on March 31th, and this is why I posted invoices in the future
10:25:47 <chris> well without being silly this is the purpose of the 'Due Date' field. 'Posted Date' is techically exactly when you formalize the invoice into your A/R.
10:25:48 <giuseppef> Those invoices are created by a python script, for every active "customer" (with a special prefix in their ID, identifying associated guys from real customers)
10:27:11 <chris> 'Posted Date' is almost always today. warlord and CDB-Man_ will be ready to support my view. Due Date is however generous you want your customer to be.
10:27:36 <giuseppef> Yes, I know I could have done something different, but I have just seen the report takes into accont posted date and not "today" and this is why I posted the bugreport
10:29:30 <giuseppef> no chris, I don't think so. Others software has a "registering date" that is the (system) date when something is recorded into journal, and a post date that is the date when the economic fact became relevant for account
10:30:09 <giuseppef> Normallu registering date is after posting date (if you periodically update your accounts)
10:30:18 <giuseppef> In my case, I did it in advance
10:33:05 <chris> Is there formal literature on this online?
10:34:52 <giuseppef> not sure, have a look here https://answers.sap.com/questions/3680061/posting-date-and-invoice-date.html
10:35:25 <chris> I'm not disputing your view - we want to limit num(options) in reports and ensure expert accountants are happy with reports.
10:36:52 <giuseppef> https://www.dab-europe.com/en-US/blog/2014/lets-have-a-date-date-fields-in-sapr-financials
10:37:16 <CDB-Man_> Invoice date = date the invoice takes effect
10:37:32 <CDB-Man_> Posted date = the date a transaction is registered with the GL
10:37:47 <CDB-Man_> Invoice date = transaction effective date
10:37:52 <CDB-Man_> This is a nomenclature thing
10:37:53 <giuseppef> Help me CDBm what is GL?
10:37:59 <CDB-Man_> General ledger
10:38:01 <chris> Invoice Date = the "Tax Point" date
10:38:02 <giuseppef> ok
10:38:41 <CDB-Man_> Posted date often has no relevance to the economic effective date
10:38:55 <CDB-Man_> Posted date is simply the date you bothered to key something in
10:39:19 <chris> (Ditto Payment Date is irrelevant in Accrual Accounting except when sending payment reminders lol - I know this fact)
10:39:20 <CDB-Man_> If I sold something on February 11, but I didn't bother to key it in until March 13
10:39:54 <CDB-Man_> My posted date is March 13, my invoice effective date is February 11, and my invoice issuance date is March 13
10:40:11 <chris> So: can Posted Date ever be in the future, with a later Due Date?
10:40:46 <chris> Oops:can Invoice Date ever be in the future, with a later Due Date?
10:40:58 <giuseppef> if february and march are in different fiscal years, at which fiscal year GC will attribute the revenue?
10:41:23 <CDB-Man_> The revenue ought to be attributed to February 11, the date the sale was made
10:41:55 <giuseppef> sure, but I think our reports use the post date to do this
10:42:14 <CDB-Man_> I think that's just poor hygiene in use of terminology
10:42:19 <giuseppef> this is why posting date is editable (I think)
10:42:58 <chris> CDB-Man_ if that's true then the GnuCash vocabulary is very wrong
10:43:46 <CDB-Man_> Transaction (effective) date is the date the economic activity occurs
10:44:03 <CDB-Man_> Posting date is simply the date you bother to key it into the system
10:44:37 <CDB-Man_> If I don't record my sale until a month later, my posting date is a month delayed
10:44:53 <CDB-Man_> But my transaction effective date is dated the actual day of sale
10:45:35 <giuseppef> CDB, I think SAP uses "entry date" as the date when you push the button (look here: https://www.dab-europe.com/en-US/blog/2014/lets-have-a-date-date-fields-in-sapr-financials)
10:46:15 <giuseppef> and "posting date" as the date relevant for accounts
10:46:57 <CDB-Man_> Page returns error when I try to load it
10:47:25 <giuseppef> https://www.dab-europe.com/en-US/blog/2014/lets-have-a-date-date-fields-in-sapr-financials
10:48:52 <chris> So; I'm a contractor: I perform consulting on 1-Jan, create invoice on 10-Jan, finalise and post invoice into book on 15-Jan, expect payment on 31-Jan ---
10:49:02 <chris> Posted-Date = 15-Jan
10:49:04 <CDB-Man_> Ah yes, SAP because they introduce entry date
10:49:15 <CDB-Man_> It shifts the definition
10:49:53 <CDB-Man_> In the SAP context, entry date is the date the entry is keyed into the system
10:50:05 <CDB-Man_> And posting date is the transaction effective date
10:51:21 <giuseppef> yes chris. Now think about you had spare time to write your accounts on 10-Jan, and record your invoice with a posting date of 15-Jan and due date of 31-Jan
10:52:02 <CDB-Man_> The date you recognize revenue Chris is January 1
10:52:38 <CDB-Man_> The document date of the invoice (using SAP terminology) is January 15 since that's the date you print it
10:53:04 <CDB-Man_> January 1 is probably the SAP posting date aka transaction effective date
10:53:30 <CDB-Man_> Gnucash does not separate document date from transaction effective date
10:53:39 <CDB-Man_> You would have to manually do it
10:54:00 <CDB-Man_> Dr revenue suspense, CR revenue
10:54:10 <CDB-Man_> To capture January 1
10:54:32 <CDB-Man_> Then when you create the invoice, Dr accounts receivable, Cr revenue suspense
10:54:44 <CDB-Man_> So that the invoice date reflects January 15
10:54:50 *** andrewbt has quit IRC
10:55:04 <chris> (Aside: Invoice Entry Date is how I'd record the Work-done Date -- so I'd send Invoice dated 15-Jan for work done on 1-Jan and 2-Jan etc)
10:55:23 <CDB-Man_> [10:55:04] <@chris> (Aside: Invoice Entry Date is how I'd record the Work-done Date -- so I'd send Invoice dated 15-Jan for work done on 1-Jan and 2-Jan etc)
10:55:36 <CDB-Man_> Work done date =/= invoice issuance date
10:55:55 *** andrewbt has joined #gnucash
10:55:55 *** ChanServ sets mode: +v andrewbt
10:55:59 <CDB-Man_> Your revenue GL account should be dated January 1
10:56:26 *** sbluhm has joined #gnucash
10:56:26 *** ChanServ sets mode: +v sbluhm
10:56:36 <CDB-Man_> If you performed the work in December but don't issue the invoice until January, you probably want to recognize work as completed in the prior fiscal year
10:57:25 <CDB-Man_> That or don't be lazy and issue the damn invoice
10:57:54 <CDB-Man_> This is what auditors call cutoff testing
10:58:56 *** bertbob has quit IRC
11:01:00 *** CDB-PHONE has joined #gnucash
11:01:00 *** ChanServ sets mode: +v CDB-PHONE
11:05:13 *** bertbob has joined #gnucash
11:05:14 *** ChanServ sets mode: +v bertbob
11:09:40 <giuseppef> well, I think that the main problem in GC is that to record in A/R you have to post an invoice or bill. In Italy the posting date is relevant just for sales tax (VAT), but not for direct tax (income tax).
11:12:40 <giuseppef> Let's suppose I make a provision of a service for a customer: I have to issue invoice (asking for VAT and becoming a VAT debtor) just on the date I receive the payment. But, if I am a company, I have to use "competence" (not sure about the translation) to record revenue; and I have to record the revenue when I completed my work, even if I have not been payed, yet
11:13:47 <giuseppef> On selling goods, it is a bit different, because I have (generally) to issue invoice with VAT when I ship or deliver the stuff
11:15:10 *** David has quit IRC
11:15:24 *** David has joined #gnucash
11:16:41 <giuseppef> So, not to post an invoice before you have been paid is not just bout lazyness. If you post the invoice you have to pay VAT even if your customer still didn't pay your job
11:16:46 *** CDB-PHONE_ has joined #gnucash
11:16:50 *** CDB-PHONE_ has joined #gnucash
11:16:59 *** tomk_dk has quit IRC
11:18:58 <chris> giuseppef: your statement date is 31-12-2021 -- obviosuly this is 91+ days after the "posted date" of 31-03-2021...
11:19:10 *** CDB-PHONE has quit IRC
11:19:25 <chris> ergo, no bug
11:20:34 <giuseppef> .... damn. You are right. There is a "report date" too, involved
11:20:39 <giuseppef> really thanks
11:20:45 <giuseppef> I apologize for all this
11:21:30 <chris> np
11:23:51 <giuseppef> The only thing is that if I ask for a report on today, I have no credit shown, because today invoices are not posted "yet". But I think this due to what CDB was saying about lack of difference between document date and transaction effective date
11:24:54 *** frakturfreak has quit IRC
11:25:38 <giuseppef> Ok, you closed bug. Thanks
11:26:04 <chris> In GnuCash terminology an unposted invoice effectively does not exist. It's off the books.
11:26:57 <chris> warlord made it so
11:37:29 *** JayC has quit IRC
11:39:48 *** frakturfreak has joined #gnucash
11:40:15 *** JayC has joined #gnucash
11:40:15 *** ChanServ sets mode: +v JayC
11:40:44 *** chris has quit IRC
11:46:20 *** CDB-PHONE_ has quit IRC
11:46:22 *** CDB-PHONE_ has joined #gnucash
11:46:43 *** CDB-PHONE_ has joined #gnucash
12:12:53 *** field^Mop has joined #gnucash
12:15:26 *** mydogsnameisrudy has joined #gnucash
12:15:41 *** mydogsnameisrudy has quit IRC
12:17:28 *** sbluhm has quit IRC
12:25:40 *** sbluhm has joined #gnucash
12:29:57 *** tomk_dk has joined #gnucash
12:31:05 *** tomk_dk has quit IRC
12:31:39 *** sbluhm has quit IRC
12:50:41 *** sbluhm has joined #gnucash
12:50:41 *** ChanServ sets mode: +v sbluhm
12:51:14 <jralls> gjanssens, any progress on Win32 build, or no time today?
12:52:22 *** jervin has joined #gnucash
12:53:58 <gjanssens> jralls: I tried with pgkconf instead of pkg-config, but the error remained the same. That's all I had time to try so far.
12:54:28 <gjanssens> I could try out a few things now if you have some time
12:55:24 <gjanssens> For starters I wasn't really sure if your plan was to make me switch to jhbuild 3.36, or rather you would amend your patch for master
12:55:42 <gjanssens> I didn't see any commits to gnucash-on-windows, so I decided to wait a bit
12:56:47 <jralls> My first thought was that maybe jhbuild 3.36 would be different, but I tested the build on master and had no trouble so now I don't think that's the problem.
12:56:58 *** David has quit IRC
12:57:12 *** David has joined #gnucash
12:57:33 <jralls> I did push the /usr/bin/env python -> /usr/bin/python in jhbuild.in, but you'd already done that manually.
13:00:31 <gjanssens> True. So where would I start debugging this ?
13:01:09 <jralls> Try editing jhbuild.git/jhbuild/utils/packagedb.py line 79 s/self.manifest/self._manifest/. I think that's a mistake: manifest is the function just above that sets _manifest.
13:04:25 <gjanssens> Ok, started another build after this change. Building xmlsec now.
13:04:54 <gjanssens> Is there a module which takes only very little time to build ? That would speed up test iterations...
13:06:30 <gjanssens> Still odd it does w ork for you though with the same mistake
13:07:04 <jralls> xmlsec is pretty small, as is libunistring, libatomic-ops, and bdw-gc.
13:07:27 *** sbluhm has quit IRC
13:08:07 <gjanssens> Thanks for fixing the date functions btw
13:08:11 <jralls> Yeah, and the code isn't new. It's puzzling.
13:08:11 *** sbluhm has joined #gnucash
13:08:11 *** ChanServ sets mode: +v sbluhm
13:10:01 <jralls> That's only a start. https://bugs.gnucash.org/show_bug.cgi?id=798150 reveals a couple of problems, and it's long past time to clean up and consolidate the date API. We have dozens of functions doing almost the same thing each their own way.
13:11:20 *** storyjesse has quit IRC
13:11:26 <jralls> Plus the design allocates a lot because it use 1990s-style pimpl. That's not great for code that we use heavily.
13:12:03 <jralls> On the other hand the more modern way is CRTP and I know you're not fond of it.
13:12:55 <gjanssens> Oh, if that's really so much better, I'll adapt :)
13:13:39 <gjanssens> So pimpl is old-fashioned these days ? Or just the way it's used in our date/time code ?
13:14:02 * gjanssens was just trying it out for GncQuotes...
13:16:08 <jralls> Anything involving virtual functions is considered old fashioned. Some of that's fashion brought about by the way object oriented design was taught in the 90s with way too much emphasis on inheritance and especially deep inheritance trees (Gtk is a glaring example).
13:17:51 <gjanssens> Ok, I'm not using virtual functions per se, but composition.
13:18:19 <gjanssens> Unless you consider reimplementing public functions in a private implementation virtual also ?
13:18:40 *** sbluhm has quit IRC
13:21:32 <jralls> Virtual means using the virtual keyword in a class member function declaration so that when you can pass a SubClass* to a function as SuperClass foo* but when that function calls foo->bar() it gets the subclass implementation.
13:22:53 *** jervin has quit IRC
13:23:20 <jralls> The 1990s pimpl idiom involves a pure virtual SuperClass (meaning that it only declares the interface, it doesn't implment anything) with a single member variable of its own type.
13:25:13 <gjanssens> Ok, so that's more or less what I'm doing, though to single member variable is of the private implementation type.
13:25:23 *** jervin has joined #gnucash
13:25:28 <jralls> Sorry, no, that's not right. The SuperClass isn't pure virtual and the member variable is a SuperClassImpl*. Instead of virtual calling there's two-step calling: SuperClass::foo() { m_impl->foo(); }
13:25:28 <gjanssens> Guess I'l have to go study the CTRP idiom some more then...
13:25:35 *** jervin has quit IRC
13:26:13 <gjanssens> Anyway, good news is your python suggestion does fix the jhbuild issue. It started the next module without error.
13:26:16 <jralls> The problem with that is that m_impl has to be allocated on the heap.
13:26:24 <jralls> Interesting.
13:26:32 <gjanssens> Let's see if it now builds to the end
13:27:11 <gjanssens> Yeah, from the podcasts I'm listening (cppcast) it sounds like heap allocation is to be avoided with container based code.
13:27:42 <gjanssens> I suppose for GncQuotes this is less of an issue as it would be for GncDate.
13:28:02 <gjanssens> Quotes code is just called occasionally, dates are used all the time.
13:28:13 <jralls> Exactly.
13:28:36 <gjanssens> So I won't fuss about it just yet for GncQuotes :)
13:28:55 <gjanssens> I'll need some time to grow into the new paradigms
13:29:40 <gjanssens> For GncQuotes I'm focussing on using as much of the stl as possible: containers and algorithms
13:29:41 <jralls> It's a little more nuanced for std::containers, but if you're looking for good cache performance it doesn't do you any good to have a cache-friendly std::vector<Foo*> when every element points to some random place in the heap.
13:30:09 <gjanssens> Yes, that's how I have come to understand it.
13:30:27 *** jervin has joined #gnucash
13:32:40 *** jervin has quit IRC
13:33:05 <jralls> On the other hand a std::vector<MegaFoo> where MegaFoo is too big to fit in a cache frame it might be more efficient to do std::vector<MegaFoo*> so that your iterator stays in the cache. Only the profiler can tell.
13:35:39 <gjanssens> True. And that means only after one way or the other was implemented.
13:36:05 <gjanssens> And I assume cache frame differs from machine to machine, or rather from cpu to cpu
13:36:17 <jralls> Actually only after both are implemented so that you can see which one is faster!
13:36:30 <gjanssens> Right :)
13:36:58 <gjanssens> And I gather to not waste too much developer time that's only done for areas that are either suspected of being slow or proven to be slow
13:37:21 <jralls> Indeed cpu makes a big difference. You can tune to Intel only to find that ARM goes to hell and vice versa.
13:38:47 <jralls> And then there's threads. We've built ourselves into an uncomfortable box by not designing with multithreading in mind.
13:40:28 <gjanssens> I am very interested in slowly breaking out of that box. But weary also of the huge number of potential pitfalls we can end up in.
13:41:12 <gjanssens> I think GncQuotes has a very lightweight first experiment in it: it uses futures (though that's taken from example code I found on the web for boost::asio)
13:42:07 <gjanssens> I also think the first step is to get rid of the GObject model. With std::containers we may leverage some parallellism built-in into the std::algoritms
13:42:20 <jralls> There aren't that many pitfalls. I haven't found anywhere where we depend on UB, just lots of places where we lazily use a file static variable instead of writing a class with an instance variable.
13:43:23 <gjanssens> UB?
13:43:32 <jralls> GObject is a very lame attempt to create 1980s C-with-classes in C by people who only half understood C-with-classes and didn't at all get the evolution to C++.
13:43:59 <gjanssens> Yeah, tell me something...
13:44:13 <jralls> I thought you'd know UB because of your reference to cppcast: Jason uses it all the time. Undefined Behavior.
13:44:36 <gjanssens> Heh, should have known that :)
13:45:12 <gjanssens> But I didn't make the link with threading. Probably as we're not using it, I don't pay too much attention in the podcasts on that topic...
13:45:40 <gjanssens> But otherwise yes, I agree on the statics
13:46:20 <jralls> I don't remember them talking about threading much. Everyone at their level just does it as a matter of course.
13:47:34 <jralls> And price quotes is beyond multithreaded, it's multiprocess because you have to shell out to perl.
13:47:43 <gjanssens> Shows how much I still have to learn...
13:47:51 <gjanssens> (re threads)
13:48:05 <gjanssens> Correct wrt price quotes
13:48:41 <gjanssens> For the record, my branch has dropped prices-quotes.scm and can now fetch quotes solely using one simplified perl wrapper and c++ code.
13:49:07 <jralls> Yay!
13:49:08 <gjanssens> I'm refactoring my proof of concept now to end up with smaller, testable functions
13:49:20 <jralls> Double Yay!
13:49:57 <gjanssens> And in the process I'll be able to add a "dump" function to gnucash-cli as well, so we can get rid of a third perl script
13:50:04 <jralls> Though current doctrine is that you should have written the tests first. But it seems that while lots of folks say that very few of them actually do it.
13:50:32 <gjanssens> Yes, I plead guilty as charged.
13:50:58 <gjanssens> Seem my brain still doesn't function that way.
13:52:24 <gjanssens> I guess my time schedule is in the way as well.
13:52:39 *** jralls_afk has joined #gnucash
13:52:39 *** ChanServ sets mode: +o jralls_afk
13:52:47 <jralls_afk> I've been listening to old episodes of the "other" C++ podcast, cpp.chat. One of the hosts, Phil Nash, wrote a test framework and bangs on about TDD when the other host, Jon Kalb, lets him get a word in.
13:52:55 *** jralls was kicked by jralls_afk (jralls_afk)
13:52:59 *** jralls_afk is now known as jralls_
13:53:06 <gjanssens> :)
13:54:18 *** sbluhm has joined #gnucash
13:54:18 *** ChanServ sets mode: +v sbluhm
13:56:11 <gjanssens> Gtg for a while
13:58:42 *** David has quit IRC
13:58:57 *** David has joined #gnucash
14:00:14 <jralls_> Bye!
14:01:02 *** sbluhm has quit IRC
14:04:10 *** andrewbt has quit IRC
14:04:17 *** andrewbt has joined #gnucash
14:04:17 *** ChanServ sets mode: +v andrewbt
14:04:48 *** andrewbt has left #gnucash
14:41:07 *** Mechtilde has joined #gnucash
14:41:41 *** flips has joined #gnucash
14:41:43 *** ChanServ sets mode: +v flips
14:47:01 *** Mechtilde has quit IRC
14:47:19 *** Mechtilde has joined #gnucash
15:00:32 *** sbluhm has joined #gnucash
15:00:32 *** ChanServ sets mode: +v sbluhm
15:26:39 *** jralls_ is now known as jralls
15:52:51 *** guak has joined #gnucash
16:57:10 *** Mechtilde has quit IRC
16:59:18 *** jw4 has quit IRC
16:59:58 *** jw4 has joined #gnucash
16:59:58 *** ChanServ sets mode: +v jw4
17:02:28 *** David has quit IRC
17:02:41 *** David has joined #gnucash
17:24:31 *** sbluhm has quit IRC
18:02:30 *** guak has quit IRC
18:21:39 *** User has quit IRC
18:43:47 *** chris has joined #gnucash
18:43:47 *** ChanServ sets mode: +v chris
18:43:47 *** gncbot sets mode: +o chris
18:44:56 <jralls> chris, have you tried the tiny patch at https://bugs.gnucash.org/show_bug.cgi?id=797621#c12 to see if it corrects the freeze you reported in https://bugs.gnucash.org/show_bug.cgi?id=797290?
19:11:33 *** Aussie_matt has joined #gnucash
21:01:30 <chris> jralls: yes it does work. I'd use (height || 1) <g>
21:01:57 <chris> it was never a hard freeze, just delays in UI
21:02:02 <jralls> Yeah, that's a little too obtuse.
21:02:50 <chris> guile-3.0.5 apparently does now compile on MingW... time to get my win10 skills up
21:03:00 <chris> 3.0.5 unreleased
21:03:23 <jralls> But does it work?
21:03:45 <chris> the patch?
21:03:50 <chris> yes
21:04:18 <chris> guile-3 I have no idea - they're going through test suite on MingW and fixing as they find
21:04:21 <jralls> guile 3.0.5 on MinGW. And is that MinGW classic or MinGW-w64 aka MSYS2.
21:04:24 <jralls> ?
21:05:12 <chris> no idea.....
21:06:20 <chris> https://git.savannah.gnu.org/cgit/guile.git/tree/NEWS search MINGW
21:07:00 <chris> AFAIU mingW will now use mini-gmp
21:08:02 <jralls> OK, I guess. Regular gmp isn't much of an obstacle on MinGW. GnuLib causes a lot more trouble.
21:09:49 <chris> guile-3.0.5 already out, it'll be 3.0.6
21:10:12 <chris> i'll retry compiling windows one of these days
21:10:19 <chris> i'll retry compiling /on/ windows one of these days
21:10:49 <jralls> compiling Windows would take a while. ;-)
21:13:07 <chris> and rather afk..
21:13:21 <chris> afk
21:27:04 <jralls> On https://bugs.gnucash.org/show_bug.cgi?id=798150 I've fixed it so that gnc_mktime does the right thing when it hits a DST transition time and Rafael's chart is still messed up in November.
21:30:02 <chris> Do attach the patch on the bug
21:30:32 <jralls> I'm called to dinner. I'll clean it up and push tomorrow morning. It's a general improvement so I won't tie it to the bug.
21:30:45 <chris> NP
21:37:53 *** field^Mop has quit IRC