2014-12-17 GnuCash IRC logs
00:02:53 *** O01eg has quit IRC
00:06:48 *** cartsoftware has joined #gnucash
00:08:38 *** gour__ has joined #gnucash
00:12:17 *** jralls has quit IRC
00:12:54 *** cartsoftware has quit IRC
00:13:17 *** jralls has joined #gnucash
00:13:18 *** gncbot sets mode: +o jralls
00:13:48 *** cartsoftware has joined #gnucash
00:39:29 *** StuM has joined #gnucash
00:54:15 *** gjanssens has joined #gnucash
00:54:17 *** gncbot sets mode: +o gjanssens
01:02:23 *** cartsoftware has quit IRC
01:54:04 *** aqua___ has joined #gnucash
01:56:37 *** gour__ is now known as gour
02:17:06 *** cartsoftware has joined #gnucash
03:39:37 <gjanssens> @tell jralls I looked at config.log but it's not very useful: gcc segfaults already on getting its version information. I have moved the tag directory aside (for optional further analysis) and restarted a clean 2.6.5 tag build
03:39:37 <gncbot> gjanssens: The operation succeeded.
03:40:19 <gjanssens> @tell jralls we'll see if this one goes better
03:40:19 <gncbot> gjanssens: The operation succeeded.
03:45:36 *** aqua___ has quit IRC
04:20:13 *** Jimraehl1 has left #gnucash
04:21:26 *** Jimraehl1 has joined #gnucash
04:24:04 *** himaxx has joined #gnucash
04:26:33 *** StuM has quit IRC
04:57:02 *** mlncn has joined #gnucash
05:07:31 *** Guest58224 has joined #gnucash
05:08:11 *** mlncn has quit IRC
05:13:24 *** mlncn has joined #gnucash
05:24:53 *** uXus has quit IRC
05:27:09 *** gjanssens has quit IRC
05:27:09 *** cphuntington97 has quit IRC
05:27:09 *** Gbarr has quit IRC
05:27:09 *** aktrapper has quit IRC
05:27:09 *** mikee_afk has quit IRC
05:27:09 *** linas has quit IRC
05:27:09 *** mlncn has quit IRC
05:27:09 *** Jimraehl1 has quit IRC
05:27:09 *** cartsoftware has quit IRC
05:27:09 *** gour has quit IRC
05:27:09 *** andy_ has quit IRC
05:27:09 *** wizkid238 has quit IRC
05:29:33 *** Guest58224 has quit IRC
05:30:03 *** kimmo2_ has joined #gnucash
05:33:08 *** kimmo2 has quit IRC
05:33:19 *** gjanssens has joined #gnucash
05:33:19 *** mlncn has joined #gnucash
05:33:19 *** Jimraehl1 has joined #gnucash
05:33:19 *** cartsoftware has joined #gnucash
05:33:19 *** gour has joined #gnucash
05:33:20 *** cphuntington97 has joined #gnucash
05:33:20 *** Gbarr has joined #gnucash
05:33:20 *** aktrapper has joined #gnucash
05:33:20 *** mikee_afk has joined #gnucash
05:33:20 *** wizkid238 has joined #gnucash
05:33:20 *** linas has joined #gnucash
05:33:20 *** irc.eagle.y.se sets mode: +ooo gjanssens mikee_afk linas
05:33:20 *** gncbot sets mode: +o gjanssens
05:33:21 *** gncbot sets mode: +o mikee_afk
05:39:31 *** gour__ has joined #gnucash
05:40:52 *** uXus has joined #gnucash
05:44:55 *** andy has joined #gnucash
05:45:30 *** gour has quit IRC
05:51:39 *** himaxx has joined #gnucash
06:24:48 *** andy has quit IRC
06:29:59 *** cartsoftware has quit IRC
06:30:24 *** andy has joined #gnucash
06:39:06 *** cartsoftware has joined #gnucash
06:39:13 *** ErKa has joined #gnucash
06:47:26 *** wol has joined #gnucash
07:09:34 *** jralls has quit IRC
07:09:56 *** jralls has joined #gnucash
07:09:56 *** gncbot sets mode: +o jralls
07:14:32 <jralls> gjanssens: I see you restarted the build from scratch. It failed building goffice again because the .la files are getting munged incorrectly to point to c;/gcdev/gnucash-2.6.5/gnucash-2.6.5/foo/lib. I'd fixed that manually with find...sed... yesterday and had been running build_package.sh directly.
07:14:33 <gncbot> jralls: Sent 3 hours and 34 minutes ago: <gjanssens> I looked at config.log but it's not very useful: gcc segfaults already on getting its version information. I have moved the tag directory aside (for optional further analysis) and restarted a clean 2.6.5 tag build
07:14:34 <gncbot> jralls: Sent 3 hours and 34 minutes ago: <gjanssens> we'll see if this one goes better
07:15:19 <gjanssens> jralls: oops, didn't know that...
07:16:16 <gjanssens> Shouldn't we make that find...sed... step part of the build system ?
07:16:51 <jralls> No, we should figure out why the wrong paths are getting written into the .la files in the first place.
07:17:50 <jralls> It isn't libtool that's doing it, the bad paths are in the precompiled binaries.
07:18:54 *** wol has quit IRC
07:18:55 <jralls> But they spread. So if libglib.2.0.0.la has a bad path, everything that links libglib.2.0.0.la will, too.
07:18:56 <gjanssens> Oh, I see now - you're referring to the double gnucash-2.6.5 in there ?
07:19:03 <jralls> Yes.
07:19:59 <gjanssens> And those double entries are in the .la files of say libglib.2.0.0.la ?
07:20:54 <jralls> On the gcc problem, it's weird. If I source devrc.sh and run configure in gnucash/build it works fine, but running under the script it crashes.
07:21:28 <jralls> And of course the script built everything else without crashing.
07:22:00 <gjanssens> You can pick up yesterday's build if you want by moving gnucash-2.6.5-failed back into place
07:22:28 <gjanssens> That's what struck me as well: only the gnucash build causes gcc to segfault
07:23:16 <gjanssens> I think I'll start a local (release) build here to help me figure out what went wrong
07:26:11 <jralls> With the paths or with gcc?
07:26:34 *** gour has joined #gnucash
07:26:58 <jralls> I just swapped the gnucash-2.6.5 directories and started a build with install.sh to see if the issue is in build_package.sh or lower down.
07:26:59 *** gour__ has quit IRC
07:26:59 <gjanssens> Both
07:27:28 <gjanssens> Ok
07:28:11 <gjanssens> Re gcc, I noticed there were some include paths added with windows style c: notation instead of mingw's /c/
07:28:35 <gjanssens> But then again there were several segfaults even before gcc tried to compile a simple test program...
07:28:47 <gjanssens> I don't know, it's something I would check
07:41:49 <jralls> I'm pretty sure gcc is happy with either c: or /c/. All of that "foo.la has moved" noise comes from fact that libtool writes c: at the bottom of the .la and is passed /c/ by -L args to gcc.
07:44:05 <warlord> Sometimes I wish we could build wthout libtool..
07:45:51 <gjanssens> warlord: cutecash uses cmake. Does that use libtool ?
07:46:17 <gjanssens> (of course that's only for the gnucash sources, not for the dependencies)
07:47:14 <gjanssens> jralls: I agree it was a weak shot: gcc already crashes when running gcc -V
07:47:26 <jralls> Depends on how cstim set it up, but probably not.
07:47:40 <gjanssens> Which definitely doesn't have any c: based path names to process
07:47:57 <warlord> gjanssens: dunno
07:48:28 <gjanssens> When I looked at the VM this morning I also saw that the unlock tool was running, with two paths to git.exe in it
07:48:39 <gjanssens> jralls: was that something you were using ?
07:49:04 <gjanssens> I never used the unlock tool before so I don't know why it was there
07:49:24 *** O01eg has joined #gnucash
07:49:45 <jralls> Not that I remember. Did the show up in the status bar or did you see them in Task Manager?
07:49:56 <warlord> BIab
07:50:08 *** warlord has quit IRC
07:51:12 <gjanssens> jralls: the window was open behind the others. I noticed it while shuffling windows around
07:51:38 <gjanssens> "Blab" ?
07:51:46 <jralls> I installed the unlock tool because the sed scripts that I added to munge the .la paths, and which are probably the cause of the double gnucash-2.6.5, sometimes result in munged permissions to that neither the shell nor Windows Explorer can delete them.
07:51:48 <gjanssens> I know bbl or biaw
07:51:59 <jralls> No, BIab: Back In a bit.
07:52:25 <gjanssens> Oh that's a capital i instead of a small L :)
07:53:18 <gjanssens> Re the double gnucash-2.6.5 I think as well it comes from the path munging
07:54:00 <gjanssens> I was working towards a setup in which I could test the fix_lt_file function more closely
07:54:46 <jralls> It occurred to me to look at the "sh.exe.stackdump" that config.log says is getting written. It says that what's crashing is c:\gcdev\mingw\msys\1.0\sh.exe, not gcc.
07:55:11 <jralls> Oops, ..\bin\sh.exe.
07:56:06 <jralls> For a "STATUS_ACCESS_VIOLATION". Googling...
07:57:21 <jralls> Which is a funny way of saying segfault, or in Win-speak, general protection failure.
08:02:56 *** [LasaK] has joined #gnucash
08:20:28 *** himaxx has joined #gnucash
08:22:01 *** warlord has joined #gnucash
08:22:01 *** gncbot sets mode: +o warlord
08:23:53 *** wol has joined #gnucash
08:27:39 *** wol has quit IRC
08:30:22 *** himaxx has joined #gnucash
08:30:54 <gour> there is no more development going on cutecash?
08:36:56 <warlord> gour: cutecash has always just been one person's toy.
08:38:05 <jralls> gour: And that person has been mostly diverted by real life.
08:38:24 <gour> is there any use of it for the gnucash's future?
08:39:00 <gjanssens> gour: perhaps. It's too early to tell
08:39:32 <gjanssens> It depends on which gui toolkit the currently active developers decide on for the future of gnucash
08:39:40 <jralls> gour: It will be a long time. The C++ rewrite and MVC fixes take priority.
08:40:44 *** aqua___ has joined #gnucash
08:41:29 <gour> well, as far as i'm concerned, i recently switched from debian/xfce to suse/kde, but after giving fair-time to kde, i'm moving to gnome which looks much better. however, i'm aware that development-wise it does not matter much to decide between gtk & qt...maybe wx is nice option considering it has qt back-end now
08:46:06 <jralls> gour: I like wx because it wraps the native GUI on each platform. I think that gives a nicer user experience than pushing a foreign GUI on users. OTOH, they're a small team managing a huge project and it's hard for them to keep up with platform changes.
08:47:03 <jralls> QT had the advantage for a long time of being maintained by a large paid staff. It shows.
08:47:11 <gour> jralls: i agree
08:51:57 *** wol has joined #gnucash
08:57:36 <gjanssens> Isn't qt also trying to give a native experience ? I thought it used to at some point.
08:57:56 <gour> gjanssens: yes it tries
08:58:13 <gjanssens> Ok, and how good/bad does it succeed ?
08:58:46 <gjanssens> jralls: are you currently working on the VM ? I'd like to check some files there
08:59:30 <gour> well, i use only linux - can't say...mac users are to be asked :-)
09:00:54 * gour --> short logout
09:00:55 *** gour has quit IRC
09:01:21 <jralls> gjanssens: Yes, but feel free to open a new shell window and make your checks.
09:01:38 <jralls> I think I figured out the path problem, BTW, testing that now...
09:08:03 <gjanssens> jralls: I'll let you finish that. I was checking for that issue as well :)
09:08:52 <jralls> Mine failed, syntax error. What's your's?
09:09:43 <gjanssens> I wasn't there yet, I wanted to look at the generated .la files first
09:12:20 <jralls> Ah. The generated files aren't the issue. It's the fix_lt_file() function that munges the paths in the ones copied in that's doing the wrong thing.
09:12:54 <gjanssens> Generated by fix_lt_file I meant
09:14:13 <jralls> The shell window on the right would be already set to the path that you want to look at, but I removed the relevant dirs, changed fix_lt_file, and ran install.sh. fix_lt_file failed so it doesn't show what you want.
09:14:32 <jralls> The file you just looked at is one I fixed with sed yesterday.
09:14:48 <gjanssens> Yes, I just realized that :(
09:15:14 <gjanssens> What did you change in fix_lt_file ?
09:15:53 *** warlord has quit IRC
09:17:08 <jralls> I swapped the third and fourth lines in the perl script, but forgot to move the terminal semicolon, so it didn't compiler.
09:17:15 <jralls> err, compile.
09:18:13 <gjanssens> jralls: perhaps you shoud add a set -x
09:18:21 <gjanssens> *should*
09:18:31 <jralls> Where?
09:18:37 <gjanssens> in fix_libtool_files
09:18:53 <gjanssens> That will give some more details on how the parameters are parsed exactly
09:19:29 <gjanssens> And will reveal exactly which paths are passed to fix_lt_file as well
09:21:07 <jralls> OK. I'm going to try running it locally first. The darn VM is just too slow.
09:21:26 <gjanssens> You bet it is :(
09:21:32 <jralls> I'm still utterly baffled by the shell crash in inst_gnucash.
09:21:40 <gjanssens> Perhaps it's even worse if two people look at the same time
09:22:09 *** MechtiIde has joined #gnucash
09:26:06 <gjanssens> jralls: the switch of expressions indeed does the trick locally. Nice catch :)
09:27:30 <jralls> Ah, good. I can't seem to get a tag build to work locally. I'll restart the test with the semicolon in the right place.
09:28:43 <gjanssens> Well, I cheated and only put the minimal requirements in place to test the function directly - unit testing ;)
09:28:56 <gjanssens> But the issue that was there before is now gone
09:29:33 <gjanssens> I have closed my connection to the VM. That may give you a tad more performance.
09:30:43 <gjanssens> jralls: as for releasing 2.6.5: https://bugzilla.gnome.org/show_bug.cgi?id=741418 may be a blocker for business users
09:31:06 <gjanssens> Although the bug is reported on master, it's most likely a direct result of my work to eliminate lot links on maint.
09:31:27 <gjanssens> I'm still investigating to be sure though
09:32:47 <gjanssens> Since you're on top of the windows build, I'll refocus on that bug instead
09:33:05 <jralls> Really? It looks like it's a direct result of the reporter doing something stupid. He says that it only applies to a few of his bills.
09:33:26 <jralls> But yeah, it would be good to at least understand it.
09:33:46 <jralls> Are you able to reproduce it?
09:35:36 <gjanssens> Partly
09:36:53 <gjanssens> when I offset one payment with two invoices, I get a lot link that has 4 splits, where you'd expect only 3
09:37:39 <gjanssens> Erh that should has been "one invoice with two credit notes"
09:38:50 <gjanssens> The OP offsets 4 bills with 6 credit notes
09:39:31 <gjanssens> The way the offsetting logic is currently written can indeed lead into an exponential proliferation of splits
09:40:40 <jralls> But the OP has more than an exponential proliferation, he has an apparently infinite proliferation.
09:40:58 <gjanssens> As his transaction log shows this action results in a lot link transaction consisting of over 200 splits
09:41:08 <gjanssens> No it's not infinite
09:41:33 <gjanssens> But I don't know if gnucash has ever been tested with a transaction consting of that many splits
09:41:34 <jralls> Umm, shutting down after consuming 10G of log sure looks infinite to me.
09:43:00 <gjanssens> Well with 200 splits the transaction log needs to write 200 commit lines of the size you see in the bug report
09:43:21 *** wol1 has joined #gnucash
09:43:58 <gjanssens> The trouble is that when one of the related bills gets unposted the lot link transaction is kept with all the fragmented splits
09:44:37 <gjanssens> Adding the bill (after posting) again will try to offset the bill against all the unbalanced fragments left over from unposting
09:44:46 <gjanssens> So now you get even more fragmentation.
09:45:00 <gjanssens> It's this in-code generated fragmentation that is the culprit
09:45:53 <gjanssens> I should optimize the transaction generation such that it cumulates the fragments as much as possible
09:46:18 <gjanssens> That is all splits that go into one lot should be merged into one single split
09:48:18 <jralls> I see a great deal of refactoring in gnc-lots.c, capital-gains.c, Scrub2.c and Scrub3.c... and I was hoping to release 2.6.5 before next summer. ;-)
09:49:04 *** wol has quit IRC
09:49:14 <jralls> You might check in with Alex, he said he was going to attack the lots mechanism too.
09:51:48 *** warlord has joined #gnucash
09:51:48 *** gncbot sets mode: +o warlord
09:59:54 *** gour has joined #gnucash
10:01:54 *** wol1 has quit IRC
10:02:08 *** wol has joined #gnucash
10:13:14 *** [LasaK] has quit IRC
10:13:55 *** dkcarlson has joined #gnucash
10:25:49 *** gncbot has joined #gnucash
10:28:16 *** warlord sets mode: +o gncbot
10:31:26 *** wol has joined #gnucash
10:32:22 <wol> Hallo!
10:37:50 <dkcarlson> Hi I am testing the Windows release 2.6.4 built from git rev a6230fb+ on 2014-12-06 in Windows 7. I just searched in the accounts window for a transaction containing certain text in the Notes field, found several, then used one of them to create a scheduled transaction. The newly created transaction appeared in the search window with each line containing an account named "6792a2[plus many...
10:37:52 <dkcarlson> ...more characters]" and dated today
10:38:50 <dkcarlson> Is this a reportable bug?
10:43:53 *** wol has quit IRC
10:45:32 <jralls> dkcarlson: Did the search find the SX itself or txns created by the SX? Is the Account GUID in the Notes or Memo fields of the SX?
10:45:55 <jralls> Does the account in question have a name?
10:50:05 *** MechtiIde has quit IRC
10:50:34 <dkcarlson> The newly created scheduled transaction is scheduled to be entered monthly starting Nov 2, but the Since last Run has not created any transactions from it yet. So I think the search updated itself with the scheduled transaction. The notes and memo fields have the text that was searched for in the scheduled transaction
10:53:07 <dkcarlson> If I open the new transaction in the search window and tab to the account field the long account name disappears and the editor wants me to enter an existing account name
10:53:11 <jralls> dkcarlson: IMO search shouldn't be finding SXes, so if true that would be a bug, but maybe we should run it by the user list to see if others agree.
10:55:49 <jralls> Ah, I misunderstood. It's displaying the GUID in the transfer account field. That's interesting.
10:56:37 *** lmat has joined #gnucash
10:57:32 <dkcarlson> Oh, so that is a GUID
10:59:25 <dkcarlson> could the search be working differently if the scheduled transaction is created after the search is created as opposed to before the search is created?
11:03:46 <jralls> It does seem to, yes. I just repeated what you did and the txn with the GUID in the account field showed up in the original search window, but when I did a new search it didn't.
11:04:39 <dkcarlson> I think GUIDs are never displayed in a transaction register, so a search should not display them
11:04:41 <jralls> So the bug seems to be in the code that implements the Schedule... context menu item rather than in the search code.
11:07:09 <jralls> Interestingly, the GUID is the same in both splits in the Find window. The SX editor correctly shows the accounts in the template, so there's no apparent problem with the created SX.
11:08:14 <jralls> Yeah, that's a bug, though not a very high priority one. In fact, I'd be inclined to ignore it until after the SX code is refactored and rewritten into C++.
11:08:45 <jralls> Which probably means extracted from a GUI code directory.
11:09:22 <jralls> But go ahead and file it so it isn't completely forgotten about. Please attach a screen shot.
11:10:15 <jralls> Now I've got to go. Be back in a couple of hours.
11:10:24 *** jralls is now known as jralls_afk
11:10:32 <dkcarlson> If I create a bug report, what information should I include? I can copy the text of this conversation too. Would this be unique to Windows?
11:13:22 <warlord> I can't see how it would be specific to windows.
11:21:59 *** Laaknor has joined #gnucash
11:22:44 *** ErKa has quit IRC
11:25:26 *** wol has joined #gnucash
11:32:20 *** jralls_afk has quit IRC
11:33:13 *** jralls_afk has joined #gnucash
11:45:09 *** aqua___ has quit IRC
11:55:16 *** lmat has quit IRC
12:01:35 *** wol has quit IRC
12:09:14 *** wol has joined #gnucash
12:10:29 *** dkcarlson has left #gnucash
12:21:02 *** ErKa has joined #gnucash
12:35:47 *** gour has quit IRC
12:38:33 *** ubergoober has joined #gnucash
12:55:30 *** GabrieleV_ has joined #gnucash
12:56:07 *** GabrieleV has quit IRC
12:56:08 *** GabrieleV_ is now known as GabrieleV
12:56:16 *** gour has joined #gnucash
13:05:03 *** gjanssens has quit IRC
13:08:20 *** wol has quit IRC
13:09:34 *** pppp2 has joined #gnucash
13:10:39 *** wol has joined #gnucash
13:36:21 *** jralls_afk has quit IRC
13:36:52 *** jralls_afk has joined #gnucash
13:37:18 *** jralls_afk is now known as jralls
13:37:22 <jralls> @op
13:37:23 *** gncbot sets mode: +o jralls
13:38:18 <jralls> @tell dkcarlson Definitely not Windows-only, I reproduced it on my mac.
13:38:18 <gncbot> jralls: The operation succeeded.
13:47:08 *** ubergoober has quit IRC
14:11:28 *** O01eg has quit IRC
14:11:34 *** pppp2 has quit IRC
14:11:47 *** O01eg has joined #gnucash
14:14:19 *** harry1989 has joined #gnucash
14:53:58 *** wol has quit IRC
15:00:57 *** gour has quit IRC
15:05:48 *** wol has joined #gnucash
15:58:54 *** harry1989 has quit IRC
16:15:17 *** Coderjoe_ has quit IRC
16:15:20 *** Coderjoe has joined #gnucash
16:17:21 *** Coderjoe has quit IRC
16:22:32 *** Coderjoe has joined #gnucash
16:45:47 *** lwells has joined #gnucash
17:22:17 *** jralls has quit IRC
17:23:16 *** jralls has joined #gnucash
17:23:17 *** gncbot sets mode: +o jralls
17:51:06 *** lwells has quit IRC
18:04:58 *** ErKa has quit IRC
18:09:29 *** cartsoftware has quit IRC
18:10:16 *** cartsoftware has joined #gnucash
18:22:02 *** isaacd has joined #gnucash
18:40:33 *** GabrieleV has quit IRC
18:41:02 *** GabrieleV has joined #gnucash
19:10:32 *** GabrieleV_ has joined #gnucash
19:11:08 *** GabrieleV has quit IRC
19:11:08 *** GabrieleV_ is now known as GabrieleV
19:24:20 *** mlncn has quit IRC
19:42:35 *** kpreid has joined #gnucash
20:25:56 *** GabrieleV_ has joined #gnucash
20:25:59 *** GabrieleV has quit IRC
20:25:59 *** GabrieleV_ is now known as GabrieleV
20:50:23 *** mlncn has joined #gnucash
22:00:12 *** ErKa has joined #gnucash
22:11:29 *** jralls has quit IRC
22:12:01 *** jralls has joined #gnucash
22:12:01 *** gncbot sets mode: +o jralls
22:18:45 *** ErKa has quit IRC
22:25:19 *** MechtiIde has joined #gnucash
22:36:50 *** jralls has quit IRC
22:37:46 *** jralls has joined #gnucash
22:37:46 *** gncbot sets mode: +o jralls
22:39:50 *** uXus has quit IRC
23:03:35 *** edgy has joined #gnucash
23:04:24 <edgy> Hi, I am now using gnucash 2.6.3 and when I print invoice and select payment, the payment is not registered. is this a bug?
23:17:56 *** MechtiIde has quit IRC
23:30:35 *** uXus has joined #gnucash
23:41:27 *** O01eg has quit IRC
23:51:12 *** Krzysiek_K has joined #gnucash
23:56:53 *** uXus has quit IRC