2017-09-04 GnuCash IRC logs

00:31:48 *** Cuare has quit IRC
00:47:46 *** jralls_afk has joined #gnucash
00:49:04 *** Mechtilde has joined #gnucash
00:51:50 *** jralls_afk has quit IRC
02:00:28 *** Mechtilde has quit IRC
02:41:03 *** fabior has joined #gnucash
02:48:20 *** fekepp has joined #gnucash
02:49:56 *** jralls_afk has joined #gnucash
02:53:58 *** jralls_afk has quit IRC
03:11:30 *** mrklintscher19 has joined #gnucash
03:13:34 *** mrklintscher18 has quit IRC
03:16:13 *** mrklintscher19 has quit IRC
03:26:32 *** gjanssens has joined #gnucash
03:26:33 *** ChanServ sets mode: +o gjanssens
03:26:46 <gjanssens> .
03:32:12 *** fekepp has quit IRC
03:32:32 *** fekepp has joined #gnucash
03:32:41 *** mrklintscher19 has joined #gnucash
04:33:52 *** jotrago has quit IRC
04:52:16 *** jralls_afk has joined #gnucash
04:55:21 *** jralls_afk has quit IRC
05:08:00 *** fekepp has quit IRC
05:16:43 *** bertbob has quit IRC
05:20:29 *** fekepp has joined #gnucash
05:31:29 *** bertbob has joined #gnucash
05:53:33 *** jralls_afk has joined #gnucash
05:56:41 *** jralls_afk has quit IRC
06:08:14 *** pilotauto has quit IRC
06:25:51 *** fekepp has quit IRC
06:29:30 *** entreprnr has joined #gnucash
06:31:30 <entreprnr> hello. Is there any way to do the following: Upon importing credit card activity, automatically assign the charges to specific accounts (e.g. "Expenses:Auto:Gas"? I know some of the charges automatically get assigned, although they aren't always they way I would prefer, so I'm guessing I'm just missing something. Thanks!
06:47:31 *** jotrago has joined #gnucash
06:54:47 *** jralls_afk has joined #gnucash
06:57:00 *** jotrago has quit IRC
06:57:51 *** jralls_afk has quit IRC
07:08:14 *** fabior has quit IRC
07:21:12 *** User has joined #gnucash
07:56:01 *** jralls_afk has joined #gnucash
07:59:14 *** jralls_afk has quit IRC
07:59:26 *** rickoehn has joined #gnucash
08:11:52 *** storyjesse has joined #gnucash
08:15:13 <warlord> entreprnr: it depends which importer you're using. and also what you mean by "automatically"
08:40:53 *** jotrago has joined #gnucash
08:57:17 *** jralls_afk has joined #gnucash
09:00:27 *** jralls_afk has quit IRC
09:15:08 *** jotrago has quit IRC
09:43:47 *** fabior has joined #gnucash
09:45:10 *** fekepp has joined #gnucash
09:50:57 *** fekepp has quit IRC
09:51:09 *** fekepp has joined #gnucash
09:52:11 <entreprnr> thanks warlord. I'm using QFX files; and by "automatically", I mean having it recognize a charge such as "Exxon" and show up in the importer (or at least in the register) as "Expenses:Auto:Gas".
09:53:04 <entreprnr> so that i don't have to re-enter it every time I have a charge at Exxon
09:58:32 *** jralls_afk has joined #gnucash
10:01:33 *** jralls_afk has quit IRC
10:26:16 *** Mechtilde has joined #gnucash
10:28:15 *** cleahcim has quit IRC
10:36:01 *** Mechtilde has quit IRC
10:36:27 *** jralls_afk has joined #gnucash
10:37:30 *** jotrago has joined #gnucash
10:45:24 *** Mechtilde has joined #gnucash
11:01:16 *** Mechtilde has quit IRC
11:02:15 *** mrklintscher19 has quit IRC
11:09:41 *** storyjesse has quit IRC
11:36:11 *** frakturfreak has joined #gnucash
11:36:29 *** jralls_afk has quit IRC
11:38:11 *** frakturfreak has quit IRC
11:41:28 *** jralls_afk has joined #gnucash
11:44:35 *** jralls_afk has quit IRC
12:31:30 *** Mechtilde has joined #gnucash
12:42:24 *** jralls_afk has joined #gnucash
12:44:48 *** jralls_afk is now known as jralls
12:45:10 *** jralls has quit IRC
12:45:16 *** jralls_ has joined #gnucash
12:45:39 *** jralls_ is now known as jralls
12:46:58 *** ChanServ sets mode: +o jralls
13:11:34 *** Cuare has joined #gnucash
13:13:15 <jralls> gjanssens: It turns out that I misrepresented my Win7 environment: I'm not using either the MSYS2 or MinGW32 "shells" from the start menu. Instead I've been passing `c:\gcdev64\msys2\usr\bin\bash --login -1` to conemu.
13:16:45 <jralls> gjanssens: The "shells" from the start menu run a rather lengthy cmd file that I haven't yet studied, but one of the side effects seems to be munging of paths. This complicates things a bit, because some programs (cmake in particular) work with DOS-style paths (i.e. c:\gcdev64) while others (make and ninja) want Msys-style paths (i.e. /c/foo).
13:29:05 <jralls> gjanssens: So I've introduced another variable by not using either on Win7.
13:29:49 <gjanssens> jralls: interesting...
13:29:55 <gjanssens> What's conemu ?
13:31:48 <jralls> https://conemu.github.io/ It's a much nicer terminal emulator for Windows than conhost.
13:33:06 <gjanssens> jralls: do you think path munging is the culprit ? All other jhbuild modules (except googletest of course) build just fine, so they seem to find their dependencies regardless of the shell being used
13:36:19 *** Mechtilde has quit IRC
13:36:28 <jralls> The others all use autotools which is an enormous bash script, so they uniformly use msys-style paths. GnuCash uses CMake which is a standalone windows executable and expects DOS style paths.
13:39:58 <jralls> Make isn't Win32 aware; guile and ninja are partially Win32 aware. I was able to fiddle the paths in GncAddSchemeTarget.cmake to get the right combination for guile to behave. I haven't yet gotten ninja to, which is why I had to turn off ninja in gnucash.modules.
13:43:59 <jralls> So cmake's FindSwig (source at https://github.com/Kitware/CMake/blob/master/Modules/FindSWIG.cmake) uses find_program so it probably needs to have c:\gcdev64\msys2\usr\bin on the path (I'm looking for the find_program source now). We use pkg-config to find glib, and of course *that* uses msys-style paths.
13:43:59 *** Mechtilde has joined #gnucash
13:45:05 <jralls> So IIRC the MSYS2 shell sets up msys-style paths and can't find swig and the mingw32 shell sets DOS-style paths and can't find glib.
13:46:40 <gjanssens> It's the other way around on my system
13:47:03 <gjanssens> Msys2 can't find glib and mingw32 can't find swig (but finds glib)
13:51:21 <jralls> OK. On Win10 where I am using the msys2-distributed shells mingw32 does find swig. GncFindPkgConfig.cmake fails on Msys2, just as it does on your win7.
13:54:28 <gjanssens> jralls: I can see why Glib not being found in the msys shell. PKG_CONFIG_PATH in that environment is different from the one on mingw32
13:55:13 <gjanssens> In mingw32 it points at /mingw32/lib/pkgconfig:/mingw32/share/pgkconfig
13:55:33 <gjanssens> And glib is installed in mingw32 so that makes sense
13:56:15 <gjanssens> in the Msys2 shell it is /usr/share/pkgconfig:/usr/lib/pkgconfig:/lib/pkgconfig
14:00:56 <jralls> Right. So jhbuild tacking /c/gcdev64/msys2/mingw32/lib/pkgconfig onto the end of PKG_CONFIG_PATH must not make it through to CMake.
14:01:46 <gjanssens> Oh, I don't know for sure. I was looking in a plain mingw32/msys2 shell
14:02:09 <gjanssens> How do I start a jhbuild shell ? jhbuild -f <path to config> shell ?
14:02:15 <jralls> But why can't the ming32 shell find swig on win7 when it does find it on win10?
14:02:18 <jralls> Yes.
14:03:05 *** frakturfreak has joined #gnucash
14:03:22 *** fabior has quit IRC
14:03:39 <jralls> The msys2 shell does fail to find glib on win10.
14:06:25 <gjanssens> The extra path is properly added to PKG_CONFIG_PATH at least
14:08:41 <gjanssens> But yes, lets rather try to figure out why swig isn't found
14:13:12 <gjanssens> jralls: Is there a way to trace cmake's find_package command ? Or to extract which paths it searches swig for ?
14:18:46 *** Mechtilde has quit IRC
14:21:59 <jralls> It's find_program. I don't see any way to get it to spit out debug information, and it just passes control to Modules/FindSWIG.cmake. The first thing *that* does is call find_program(SWIG_EXECUTABLE NAMES swig3.0 swig2.0 swig) with no path argument.
14:22:33 <gjanssens> Yes I found that as well meanwhile
14:23:12 <gjanssens> The error I get Is "missing SWIG_DIR"
14:23:46 <gjanssens> so it looks the find_path command a bit further down is not working as expected on my system
14:23:53 <jralls> You could try setting the full path to SWIG_EXECUTABLE in CMakeLists.txt line 147.
14:24:32 <gjanssens> jralls: what's the output of swig -swiglib on your win10 system ?
14:25:19 <jralls> "/usr/share/swig/3.0.12"
14:25:29 <gjanssens> No empty lines ?
14:25:36 <gjanssens> I mean after that line
14:26:01 <jralls> Yes, an empty line before the prompt comes back.
14:26:16 <gjanssens> Ok, that's the same as on my system then.
14:29:11 <jralls> I can replicate the swig failure on a mingw32 shell on my Win7 VM.
14:30:12 <gjanssens> That's both good and bad...
14:33:44 <jralls> Ah, and the reason that it works for me on Win10 is that I'd hacked FindSWIG.cmake to get rid of that extra line.
14:34:37 <gjanssens> How so ?
14:36:42 <jralls> https://pastebin.com/vL9KP5Z4
14:38:26 <jralls> Some of that is debugging, of course. The important change is replacing ";" with "" at line 43.
14:38:36 <gjanssens> Got that
14:41:25 <jralls> Oh, and then adding the root path to it in new line 44 because CMake is running outside the shell and doesn't know about /usr and /mingw32.
14:44:53 <jralls> That doesn't explain why cmake's find_program is able to find swig without help on Win10 but not on Win7. There must be some other hack I made and then forgot about.
14:45:29 *** fekepp has quit IRC
14:53:42 *** quazgar has joined #gnucash
14:55:09 <gjanssens> jralls: here's how I fixed it: remove "NO_CMAKE_FIND_ROOT_PATH from the find_path line in FindSWIG.pkg and set -DCMAKE_FIND_ROOT_PATH on the cmake command line to d:/gcdev64/msys2
14:55:25 <gjanssens> Replacing the ";" with "" isn't even necessary
14:56:49 <gjanssens> If we can use CMAKE_SYSROOT instead of CMAKE_FIND_ROOT_PATH we'd even not have to fix FindSWIG.cmake
14:57:45 <gjanssens> However that variable has side-effects of which I can't estimate whether they would cause trouble later on
14:58:00 <gjanssens> I don't know what setting --sysroot to the compiler would do
14:59:14 <jralls> That's FindSWIG.cmake, right?
14:59:31 <gjanssens> Eh yes
15:00:18 <quazgar> Hi, I am looking for a way to specify a stylesheet (for reports) for printing/saving as PDF. So far I only managed to edit the look in the live view, or in the html export (which I could also use to print to PDF later). Any hint?
15:00:22 <gjanssens> Anyway, cmake ran successfully. I can finally start to debug my boost::filesystem stuff
15:00:38 <jralls> Setting --sysroot prepends the value to the default include and library search paths. I use it on MacOS for telling the compiler what SDK I want to use.
15:01:23 <gjanssens> Ok could that be useful in this context as well, or would it break other searches ?
15:01:41 <jralls> Looking at cmake's find_path we might be able to use a different variable.
15:03:46 <jralls> I'd think that d:/gcdev64/msys2 would be the default anyway, so it shouldn't break anything. Only compiling will tell for sure.
15:05:06 <jralls> quazgar: Not an expert on that, warlord knows more, but if you set the stylesheet from the report options I'd expect it to apply to both.
15:10:28 <jralls> gjanssens: As for boost::filesystem I suspect that the problem is that the SHGet functions in win32_get_userdata_home require a library that's in Windows/WinSxS. I was just about to test that on Friday when I ran out of time.
15:10:56 <quazgar> jralls: Ok, after trying it again, I find it does change something, but I have the impression that the font sizes are still a lot larger than what I set
15:13:05 <quazgar> For example, a font size of 6 is still very well readable, I doubt that that would be the case it it were really 6pt large only
15:13:09 <jralls> quazgar: That doesn't surprise me too much. Depending on the typeface you chose AdobeReader might have a different understanding of its metrics than does Webkit.
15:14:57 <jralls> quazgar: And that of course depends on your monitor. A HiDPI monitor with software that can understand it (which GnuCash 2.6 isn't but 2.8 will be) can make perfectly legible 6pt characters.
15:15:27 <quazgar> yes, looking forward to that :-)
15:15:46 <quazgar> I read about that when fixing some translation strings :-)
15:16:30 <jralls> But if you in fact have a HiDPI setup then AdobeReader is doing the right thing and WebKit isn't.
15:23:03 <gjanssens> jralls: fyi the msys2 shell uses a differen pgk_config.exe. That's probably why the build isn't working there
15:25:13 <jralls> Hmm, that's interesting.
16:10:44 *** fabior has joined #gnucash
16:18:33 *** fekepp has joined #gnucash
16:26:12 <gjanssens> jralls: how can I run cmake/make and have it print the commands it actually runs ?
16:26:30 <jralls> make VERBOSE=1
16:26:44 <gjanssens> I've made some changes and core-utils builds but now it complains boost::filesystem isn't found :(
16:26:48 <gjanssens> Ok tx
16:32:43 <jralls> That's because CMakeLists needs to include libbboost-filesystem-mt (but without the mt except on mingw64). Looks like I didn't push that yet.
16:33:55 <jralls> Ah, no, it's there but just the non-mingw64 version.
16:34:27 <gjanssens> Got it fixed by removing my hardcoded addition of -lboost_filesystem
16:35:03 <gjanssens> The build is getting past core-utils now. Where did it fail for you ?
16:35:37 <gjanssens> s/The build/My local build/
16:40:20 <gjanssens> Oh, I see. It breaks at compilation of report-collectors.scm
16:40:46 <gjanssens> That's because the compilcation of that file actually runs the filepath utils code
16:43:26 <jralls> Looks like I'd missed pushing a commit, it's pushed now.
16:45:16 *** frakturfreak has quit IRC
16:46:28 <jralls> It fails for me building app-utils/gettext.go with "The specified module could not be found." in libgncmod-app-utils.so.
16:46:58 <jralls> I need to go run an errand. BIAB.
16:59:40 *** fabior has quit IRC
17:01:00 *** fabior has joined #gnucash
17:03:32 *** fekepp has quit IRC
17:17:06 *** fabior has quit IRC
17:21:23 <quazgar> I have yet another question regarding AR/AP accounts: Is there a way to transfer an amount between several such accounts? Say I have a bill that needs to be paid, and I pay it by creating another liability (which should be in another AP account), how would I do that in GnuCash?
17:21:46 <quazgar> Do I need a "normal" account to transfer the money to and fro?
17:24:35 *** lread has quit IRC
17:34:01 <jralls> gazgar: If you're using the business features (bills, invoices, customers, etc.) you need to leave the A/R and A/P accounts alone. If you're doing everything by hand then GnuCash accounts are just like T accounts in Accounting 101. Find out from an accountant in your jurisdiction how to do it by hand and the procedure will transfer directly to GnuCash.
17:34:22 <jralls> Oops, quazgar.
17:39:26 <quazgar> yes, I understand that these account should only be touched by the business feature interfaces. It just bugs me that the GUI does not allow me to pay one bill directly into another such account
17:41:42 <gjanssens> quazgar: Are you trying to map from AR to AP (your client is also your vendor) ? That's indeed an unsupported construct which I hope to resolve one day
17:42:29 <quazgar> that would be another use case, but no, I want to have a transaction from one AP to another AP.
17:42:51 <gjanssens> Why ?
17:44:57 <quazgar> In this specific case the first item is a bill from a vendor, which leads to an AP entry. In a 2nd step, it is paid, but not by the company but privately by an employee first, which now of course needs to be paid the same amount by the company.
17:47:47 <jralls> gjanssens: Well, a new problem: It seems that the gcc-4.8.4 provided by Ubuntu 14.04 lacks the C++11 conversion facets; they're added in gcc-5.0.
17:47:59 <gjanssens> So where is the second AP account in that story ?
17:48:09 <gjanssens> jralls: I saw, but I have worked around it already
17:48:18 <quazgar> The only way I see to solve this is via a third, transfer account.
17:48:59 <gjanssens> The conversion facets are only needed on windows, so I slightly rewrote your code (which I had found today on SO as well btw) to be only visible when building on that platform
17:48:59 <quazgar> the second AP would be where the company owes money to the employee who first paid the bill out of their own pocket
17:50:11 <gjanssens> AP in gnucash context I meant to say. AN AP account is necessary to track bills, but in this case you want to track the payment
17:50:30 <gjanssens> That can be done in a liability account.
17:50:41 <gjanssens> But yes, you do need a third account to track this.
17:51:00 *** rickoehn has quit IRC
17:51:30 <gjanssens> If you set up a liability account ("Payed by employee" just to invent a name), you can pay the bill to that account
17:52:04 <gjanssens> From there you will have to track it manually. Bills due won't trigger on it anymore.
17:52:31 <quazgar> and then that account's type should stick to "normal" liability, I can't just switch between "liability" and "AP" (in GnuCash), right?
17:52:48 <gjanssens> No. The business logic is picky on that.
17:53:17 <gjanssens> But if you want to track your debt to the employee via the business features, you could create an internal bill for that
17:53:43 <quazgar> with the use of a third account
17:53:52 <gjanssens> The entry on the bill would be your liability account with its amount
17:54:01 <quazgar> exactly
17:54:03 <gjanssens> That way it will appear in your bills due
17:55:43 <quazgar> ok, thanks!
18:11:59 <jralls> gjanssens: Where are you with mingw64?
18:12:49 <gjanssens> I was about to shout the build runs to 100% completion \o/
18:12:56 <gjanssens> Now running make check for gigs
18:15:15 <gjanssens> jralls: I have just pushed the changes I needed to get it to build
18:15:31 <gjanssens> It turns out I was assuming wrong file permissions on Windows
18:17:43 *** bertbob has quit IRC
18:17:56 <gjanssens> Oh well, make check won't be for tonight. Building tests fails because strptime.h is not found in gnc-date.cpp. I guess we have to add that file in the test's sources.
18:18:00 <jralls> So you got no link errors building gettext.go?
18:18:06 <gjanssens> No
18:18:42 <jralls> So that would seem to be a win10 problem. Interesting. mingw32 shell, right?
18:18:58 <gjanssens> Yes
18:19:08 <gjanssens> Or a build sequence error once more
18:20:06 <gjanssens> An interesting windows oddity: when running make -j4 I sometimes get permission denied errors in build steps
18:20:34 <jralls> No, the library is built. The problem seems to be that dlopen can't find one of its linked libs.
18:20:59 <jralls> I've been using -j 1 (mingw64 make seems to need the space or it ignores the option).
18:21:07 <gjanssens> I believe they happen because of the parallellism and windows doesn't allow to read an open file
18:21:33 <gjanssens> That was just a sidenote. I don't think it was your issue.
18:22:23 *** mrklintscher19 has joined #gnucash
18:22:33 <gjanssens> Anyway, while building guile files anything is possible
18:24:35 <gjanssens> As you say the error doesn't necessarily mean libgncmod-app-utils.so is missing. The init code in that module is run so any other module that loads in turns could not have been built yet
18:24:48 <gjanssens> Resulting in the same error message
18:25:04 <gjanssens> Guile is not very transparent in that respect
18:25:47 <gjanssens> And even with make -j 1 you can get this issue if cmake isn't aware of these internal dependencies (which it isn't yet)
18:26:07 <gjanssens> s/iinternal/implicit/ ?
18:26:28 <jralls> Yeah, I think implicit is better.
18:32:22 *** bertbob has joined #gnucash
18:32:27 <gjanssens> jralls: it looks like app-utils only depends on the engine module. Is that one built already ?
18:32:33 <jralls> Anyway, the problem is introduced with the boost::filesystem changes. My "dodge-boost-filesystem" branch builds; if I cherry pick the three boost::filesystem commits on top of it it fails.
18:32:44 <gjanssens> Ok
18:33:00 <gjanssens> Have you pulled my last commit ?
18:33:03 <jralls> Yes. DependencyWalker shows all of the internal dependencies built and correctly linked.
18:33:09 <jralls> Not yet. I'll do that now.
18:35:31 *** bertbob has quit IRC
18:41:04 *** pilotauto has joined #gnucash
18:42:10 <jralls> No joy.
18:42:19 <gjanssens> :(
18:42:31 <gjanssens> On both Win7 and Win10?
18:43:13 <gjanssens> Meanwhile I have started a clean build to check if something was cached, and again it passed building gettext.go without issues
18:51:34 *** bertbob has joined #gnucash
18:52:20 <jralls> Haven't tried on Win7. Do you have any version of Visual C++ installed on your system?
18:55:43 <gjanssens> Not that I know of.
18:57:22 <gjanssens> I didn't install one in any case.
18:59:19 *** quazgar has quit IRC
18:59:36 <jralls> OK. I'm trying to figure out what DependencyWalker is telling me, and there are a bunch of can't find DLLs starting with API-MS. One search result said that they were from a VC++ distributable.
19:02:34 <gjanssens> jralls: on which dll have are you running depencency walker? libgncmod-apputils ?
19:03:51 <gjanssens> FYI I see several of those DLLs as well
19:06:49 <gjanssens> jralls: another approach, since it appears to start by including my filepat changes
19:06:57 *** mrklintscher19 has quit IRC
19:07:08 <gjanssens> Your build proceeds far enough to run the core-utils tests, but they aren't built yet
19:07:56 <gjanssens> I propose you run make test-user-data-dir
19:08:01 <gjanssens> and then run that test
19:08:41 <gjanssens> If it fails that means win10 is invalidating one of my assumptions
19:09:38 <gjanssens> That's how I debugged the filepath utils issues earlier this night
19:10:04 <gjanssens> The advantage of this method is you can run the test under gdb to follow what happens
19:11:44 <gjanssens> And... it's way past bedtime here so I'll have to leave you now.
19:11:53 <gjanssens> Good luck in your bug hunt !
19:12:19 <jralls> G'night and thanks!
19:13:12 *** gjanssens has quit IRC
19:27:49 <jralls> @tell gjanssens test-userdata-dir fails every test with a variant of "C:\Users\John Ralls\AppData\Roaming\Gnucash\foo vs. c:\gcdev64\msys2\tmp\Gnucash\foo". It does, however, link.
19:27:49 <gncbot> jralls: The operation succeeded.
19:28:57 <jralls> @tell gjanssens The Win7 build dies at compiling unittest-support.go with a link error in libtest-core-guile.
19:28:57 <gncbot> jralls: The operation succeeded.
20:22:44 <warlord> entreprnr: If you turn on baysian matching you can train the OFX importer. But you still have to manually teach it those mappings during the import process.
21:01:20 *** mpiechotka has joined #gnucash
21:14:41 *** mpiechotka has quit IRC
22:59:49 *** User has quit IRC