2014-03-10 GnuCash IRC logs

01:51:49 *** MechtiIde has joined #gnucash
02:43:07 *** aqua__ has joined #gnucash
02:52:16 *** aqua_ has quit IRC
02:54:24 *** ErKa has quit IRC
03:00:41 *** MechtiIde has quit IRC
03:38:46 *** wol has joined #gnucash
04:05:17 *** SteveG has joined #gnucash
05:11:10 *** SteveG has quit IRC
05:59:46 *** SteveG has joined #gnucash
06:00:31 *** wol has joined #gnucash
06:21:28 *** fell has joined #gnucash
06:21:29 *** gncbot sets mode: +o fell
06:23:47 *** aqua__ has quit IRC
06:37:04 *** SteveG has quit IRC
07:33:05 *** Jimraehl1 has joined #gnucash
07:38:07 *** Jimraehl1 has quit IRC
07:48:34 *** O01eg has quit IRC
07:49:34 *** SteveG has joined #gnucash
08:10:03 *** warlord has joined #gnucash
08:10:04 *** gncbot sets mode: +o warlord
08:30:19 *** fell_ has joined #gnucash
08:30:19 *** gncbot sets mode: +o fell_
08:39:07 *** fell has quit IRC
08:51:46 *** SteveG has quit IRC
09:00:46 *** kraftb has joined #gnucash
09:00:49 <kraftb> hello !
09:01:02 <kraftb> I have a question regarding the use of mysql as storage backend.
09:01:26 <kraftb> Somewhere I read that it is not possible to open two connections at the same time. Or at least there is unexpected behaviour
09:01:48 <kraftb> So I would like to ask if you think the following is possible. Or if you can suggest a better solution.
09:02:42 <kraftb> We have a webapplication (Member/Seminar registration, www.voek.at) where the visitor can register for seminars and has to pay an attendance fee.
09:03:13 <kraftb> As I don't want to reinvent the wheel (and I do not need just a wheel but a whole car) I would like to use an existing tool for handling the finance stuff.
09:03:52 <kraftb> So I tought whenever someone performs an step for which a payment has to be made I let the webapplication create a transaction in the mysql backend of GNUcash.
09:03:57 <warlord> kraftb: gnucash is just an accounting program, it is not a point-of-sale or payment-processing program
09:04:07 <warlord> So you'll still need to implement the payment processing.
09:04:29 <warlord> From there I would recommend your payment app just generate some QIF that you can batch-import into GnuCash
09:04:33 <kraftb> the problem is that our customer wants to be able to make custom entries
09:04:45 <kraftb> ok ... that is what I feared :(
09:05:08 <kraftb> then we are again at the import/export stuff which is annoying.
09:05:22 <kraftb> What is the problem with my approach?
09:05:28 <warlord> you cannot have multiple writers into the gnucash database
09:05:36 <kraftb> I mean I could think of the webapplication as just another interface to gnucash
09:05:45 <kraftb> ok. so this is the main problem.
09:05:48 <warlord> Yes
09:05:52 <kraftb> Because I think this could get solved with kind of locking
09:06:05 <warlord> (and the fact that you cannot 'write' directly to the database.. you are only allowed to write using the GnuCash API)
09:06:21 <kraftb> the webapplication just has to keep back every transaction as long as the maintainers are manually working
09:06:33 <kraftb> is there an API
09:06:40 <kraftb> I mean a programmatic API ?
09:06:48 <warlord> Is there any other?
09:07:02 <kraftb> There is the "whole" GUI API :=
09:07:05 <kraftb> :)
09:07:13 <warlord> (Gnucash has an API in C, Scheme,and Python -- but it's not a "stable API")
09:07:32 <kraftb> well ... supporting the entry of transactions would be enough for me.
09:07:45 <warlord> I.e., the API is used internally, and is "available", but GnuCash makes no guarantees on the stability of said API and can change any interface at any time.
09:08:07 <kraftb> hmm ... I have to think about it
09:08:11 <warlord> But we're still back to the "no multiple writers" option.
09:08:23 <kraftb> this is something I can live with.
09:08:49 <warlord> IMHO you're still best off batch-processing via import. You can generate a QIF file that requires ZERO user attention -- you just load it and keep clicking 'Next" through the UI-helper until it's done.
09:09:10 <kraftb> usually they are doing payment entry (when they got their bank statement) and entering their expenses for speakers on seminars
09:09:53 <kraftb> Are you a gnucash dev or an user? Just wondering.
09:10:49 <kraftb> I do a lot of web projects ... and I know the one or other webshop. At least from having a simple look at them.
09:11:16 <kraftb> And I wonder why no one ever had the idea of pluging a powerful accounting software into it for finance handling
09:11:36 <kraftb> they are all reimplementing "some kind" of accounting themselves.
09:15:20 <warlord> previous dev.. now just a "very important user" ;)
09:15:31 <kraftb> ok :) thanks for the information anyways.
09:15:39 <warlord> you're welcome. good luck
09:16:17 <kraftb> It is sad to see that there are so few financial software for linux/opensource
09:16:29 <kraftb> maybe open source people don't want to bother with money :(
09:17:17 <kraftb> but thanks anyways. And to be complete: I am usually also just a personal user of gnucash. But for the recent project I suggested it to my boss.
09:17:35 <kraftb> I think he is against it because of having to learn/read gnucash documentation
09:22:24 *** wol has quit IRC
09:58:27 *** wizkid238 has quit IRC
10:00:03 *** wol has joined #gnucash
10:04:34 *** aqua___ has joined #gnucash
10:13:01 *** lmat has joined #gnucash
10:14:00 *** wizkid238 has joined #gnucash
10:22:27 <warlord> kraftb: LOL. He'd rather pay for something than read free documentation?
10:22:40 <warlord> If he wants to he can buy the "GnuCash Book" from Packt Publishing.
10:38:00 *** ErKa has joined #gnucash
10:42:03 <kraftb> Well. I think he is just a little bit anxious about using a software he doesn't know.
10:42:07 <kraftb> I know it - and I love it :)
10:42:14 <kraftb> just read in the archives:
10:42:42 <kraftb> <quote>We can't afford to loose these people, whether or not the core developers like their pet project.</quote> ... find it funny that my project indeed is a "pet" project (www.voek.at)
10:43:07 <kraftb> I guess here the right person got the right project ...
10:44:41 <warlord> :)
10:47:03 <kraftb> How can I donate to the gnucash project ?
10:47:52 <kraftb> ah... got it.
11:00:07 <warlord> :)
11:02:50 <kraftb> I guess I will donate something next month ...
11:02:58 <kraftb> Altough I am just using it privately currently.
11:03:23 <kraftb> What I always wondered is why it gets quite slow when you have a large account.
11:04:05 <kraftb> The "cash" asset account currently has about 2000 entries and it can take quite a while to scroll around and save the whole file (using xml format)
11:04:07 <warlord> Because the whole dataset is loaded into RAM and processed.. Processing is, at best, O(n), so as you add more transactions your processing time takes longer.
11:04:27 <kraftb> hmm. does this improve with sql?
11:04:57 <kraftb> And why does every transaction have to get processed again and again?
11:05:47 <kraftb> I mean I understand, that the current value in the asset (rightmost column) is the sum of all previous transactions.
11:06:18 <kraftb> But I guess if there are 10s of thousands of transactions it isn't feasible to reprocess them every time the file is opened
11:06:30 <kraftb> how are other financing applications solving this?
11:07:10 <kraftb> I assume some kind of intermediate values. You could for example store the current value of an account every 250 transactions.
11:07:30 <kraftb> when loading a file and displaying the last line you just have to replay the last <250 transactions
11:08:03 <kraftb> only if a transaction gets entered "above" the following stuff has to get recalculated and intermediate values dropped and recreated
11:08:20 <kraftb> some kind of blocking ...
11:09:02 <kraftb> I mean ... no problem if I now enter a transaction for 2003 ... I would understand the system takes some time to recalculate all values in between.
11:09:34 <kraftb> anyways. If I now enter a transaction for 2003 I am eventually already doing something mostly illegal :)
11:09:57 <kraftb> ... I think it is affordable if the system then displays "please wait. processing" :)
11:10:53 <kraftb> But my solutionwould be only true for xml format.
11:11:15 <kraftb> I guess for SQL it would be sufficient to submit a query which sums up all rows except the last 250
11:11:30 <kraftb> and then replay the last 250 rows in detail so it is possible to show them
11:12:29 <kraftb> In fact I would drop the XML format at all and use sqlite instead. Sqlite3 for example is used on android phones as the native local database
11:12:41 <warlord> No, it does not improve with SQL.. SQL improves the 'save' time because every transaction is saved when it is processed, but it still loads the full dataset into RAM. This is due to historical design reasons and will require significant rewrites to "fix"
11:12:44 <kraftb> altough XML is nice for interchange
11:13:22 <kraftb> I already assumed this would be the problem.
11:13:37 <kraftb> I did some investigation in android and how they are handling scrolling lists there.
11:13:51 <kraftb> what they do is to have some kind of "adapter" which reads in additional data when required
11:14:32 <kraftb> so the list-view just say: I need this and those rows and some api retrieves them from whatever adapter is hooked in (static content, xml, sqlite, ...)
11:14:52 <warlord> Sure, but a) that requires SQL (which GnuCash cannot assume), and b) it requires an architecture that doesn't assume all data is in core.
11:14:57 <warlord> both of these would need to be fixed.
11:15:10 <kraftb> sqlite is just a lib you compile in
11:15:12 <warlord> (a) can be fixed by loading XML into an in-core SQLite database
11:15:20 <kraftb> you do not need a server or anything like that
11:15:24 <warlord> (b) however requires some majore rearchitectural changes
11:15:34 <warlord> GnuCash supports SQLite
11:15:50 <warlord> But it's just a data storage backend.
11:15:53 <warlord> GnuCash is not a "DB App"
11:16:18 <warlord> To do what you're suggesting requires changing GnuCash to be a DB App, which requires major rearchitecting of 15-year-old subsystems.
11:16:26 *** aqua___ has quit IRC
11:16:28 <kraftb> hmm ...
11:16:55 <warlord> Sorry. You're not saying anything new.
11:16:59 <kraftb> I always find older software being better, more stable
11:17:21 <warlord> Indeed. GnuCash is pretty darn stable.. Especially the XML side. The SQL side, not so much (because it's newer)
11:18:01 <kraftb> I am using XML and until now had only one crash ... but I don't remember correctly. Maybe I just forgot to save before shutting down.
11:18:25 <kraftb> At least I had to recover the account file when starting gc the next time
11:19:06 <kraftb> and in fact it's called "book keeping" ... not "throwing books away" :)
11:19:06 *** wol has quit IRC
11:21:33 <warlord> :)
11:29:18 <kraftb> Does gnucash currently have any unit tests?
11:29:49 <warlord> Some
11:36:51 <kraftb> ok ... maybe when I have some time I start looking into gnucash source and start by adding some tests in the beginning
11:37:17 <kraftb> usually I just do web programming using "TYPO3" - a CMS which appeared in the last decade
11:37:35 <kraftb> But I am a quite good C programmer. At least better than C++
11:37:38 <warlord> GnuCash is mostly in C
11:37:42 <warlord> ~80%
11:37:57 <warlord> Scheme is the #2 language, probably around 17-18%
11:38:20 *** aqua___ has joined #gnucash
11:38:51 <kraftb> This is quite ok. Making objects out of everything isn't something necessary. At least in my eyes.
11:39:48 <warlord> Well...
11:39:59 <warlord> GnuCash does... using glib's "gobject" framework.
11:44:30 <kraftb> you mean gtk ?
11:45:42 <warlord> No, glib
11:45:47 <warlord> (gtk is also built on gtk)
11:45:52 <warlord> er, gtk is also built on glib
11:45:58 <kraftb> glibc ?
11:49:19 <kraftb> ok ... Now I got it.
11:50:35 *** benoitg has joined #gnucash
11:50:44 <kraftb> glib in fact developed from gtk
11:51:15 <kraftb> When I wrote being a good C programmer I do not mean being involved in any OS projects.
11:51:37 <kraftb> So this was just self estimation ...
11:51:50 <kraftb> :/
11:54:00 <warlord> Well, sure, glib/gtk all come from the Gnome Project.
11:54:08 <warlord> But it *is* a separate "project" per se.
11:54:12 <warlord> You can use glib without using gtk
11:54:20 <warlord> (although you cannot really use gtk without using glib)
11:55:55 <kraftb> I would love to support gnucash by doing some development but three years ago I moved. Back to my childhood home.
11:56:21 <kraftb> And now I have to do quite a lot of work here to get the house in an acceptable state. So I am not in the position to do any more voluntary work.
11:56:56 <kraftb> But who knows ...
11:57:13 <kraftb> As its on github it maybe you see some patches (most probably simple unit tests) from me :)
12:02:08 <warlord> Sounds great
12:18:32 *** wol has joined #gnucash
12:21:13 *** jralls has joined #gnucash
12:21:14 *** gncbot sets mode: +o jralls
12:28:23 *** MechtiIde has joined #gnucash
12:29:25 *** aqua___ has quit IRC
13:07:01 *** aqua___ has joined #gnucash
13:13:04 *** SteveG has joined #gnucash
13:46:35 *** Krzysiek_K has joined #gnucash
13:59:16 *** SteveG has quit IRC
14:04:58 *** Krzysiek_K has quit IRC
14:06:01 *** Krzysiek_K has joined #gnucash
14:32:50 *** ridler77 has joined #gnucash
14:50:12 *** ridler77 has left #gnucash
14:59:55 *** wol has quit IRC
15:02:08 *** aqua___ has quit IRC
15:03:49 *** kraftb has quit IRC
15:11:43 <warlord> I wonder why code has an apache process taking 60% CPU?
15:12:27 <warlord> Other than google and bing are pulling the wiki..
15:17:50 *** SteveG has joined #gnucash
15:22:38 *** [^DraCuLin^] has joined #gnucash
15:29:32 *** [^DraCuLin^] has quit IRC
15:31:37 <gjanssens> warlord I saw your clarification to the Sourceforge tip jar
15:31:41 <gjanssens> That's a good thing to add
15:32:22 <gjanssens> I would just somehow get your name into it as well as that is more familiar to list followers than your company's name
15:32:33 <gjanssens> How would you phrase this ?
15:32:51 <gjanssens> IHTFP Consulting (owned by Derek Atkins)
15:33:23 <gjanssens> or (run by...) or (Derek Atkin's consulting firm), or ...
15:35:54 <warlord> um, "{owned/operated/run} by Derek Atkins" is fine with me.
15:38:05 <gjanssens> ok
15:49:06 *** aqua___ has joined #gnucash
16:07:41 <gjanssens> Done. Made some graphical additions as well (with the help or Robert Brush)
16:13:49 <gjanssens> john have you done profiling on Windows related to the UI slowness bugs in 2.6 ?
16:14:05 <gjanssens> (make that jralls ^)
16:14:17 <gjanssens> Or did you do it all on OS X?
16:33:58 *** jralls has quit IRC
16:52:39 *** MechtiIde has quit IRC
16:53:28 *** jralls has joined #gnucash
16:53:28 *** gncbot sets mode: +o jralls
16:53:37 *** [^DraCuLin^] has joined #gnucash
16:58:50 <gjanssens> jralls have you done profiling on Windows related to the UI slowness bugs in 2.6 ?
16:58:53 <gjanssens> Or did you do it all on OS X?
17:12:55 *** lmat has quit IRC
17:16:05 <jralls> gjanssens: All in OSX. I don't know how to profile in MinGW.
17:17:08 <jralls> But there's so little Windows-specific code in GC that I doubt that there's much difference.
17:18:46 *** TradeBorG1110 has joined #gnucash
17:18:55 <jralls> After fixing the timezone problem, the next big hit is g_list_find. I can see a way to make an index with GHash, but I haven't yet convinced myself that I want to.
17:19:40 <jralls> Most of the calls are inserting and removing splits from accounts.
17:21:41 <gjanssens> Ok
17:21:50 *** TradeBorG1111 has joined #gnucash
17:21:55 <gjanssens> I was in fact asking this for another bug: https://bugzilla.gnome.org/show_bug.cgi?id=703427
17:22:28 <gjanssens> The last steps to reproduce by Tess were indeed easy to reproduce - on Windows
17:22:55 <gjanssens> There seems to be a huge memory leak somewhere in the register code that only manifests on Windows
17:23:17 <gjanssens> I can't reproduce that leaky behaviour at all on linux
17:24:06 *** TradeBorG1110 has quit IRC
17:24:06 <gjanssens> A similar memory leak happens on the account hierarchy while scrolling up and down
17:24:12 <gjanssens> The leak is really huge
17:24:34 <gjanssens> It jumps with megabites at the time, never recovering, not even when the register is closed
17:25:33 <gjanssens> My worry is that this comes from deeper in the support libraries but that's hard to determine without profiling
17:25:51 <gjanssens> But like you, I don't know how the profile in MingW
17:27:00 <jralls> I'd guess it's leaking in gdk-win32. But it's pretty weird that with all of the Windows users we've got nobody's noticed it before.
17:29:03 <gjanssens> Indeed. But as I said it's easy to reproduce. And on 2.6.x as well.
17:29:15 <jralls> Anyway, profiling won't tell you about leaks. You need a memory tool like Valgrind for that. OSX sensibly builds it in to libmalloc so you just set a couple of environment variables. Does Valgrind work with MinGW?
17:29:53 * jralls googles and finds https://sourceforge.net/p/valgrind4win/wiki/DevelopmentEnvironment/
17:31:45 <gjanssens> Good one. It does require gcc > 4.6 though. We're still at 4.5
17:32:07 <jralls> And of course one would have to build gtk+ with symbols.
17:32:20 <gjanssens> I might try in my new-mingw-experiment branch
17:32:40 <gjanssens> Although building gtk+ as well from scratch ? Bleh
17:32:55 <gjanssens> We don't have jhbuild on windows you know
17:33:22 <jralls> Yeah, I know. I've tried a couple of times to get it working without success.
17:33:31 <gjanssens> It looks like a job that will take more time than I currently have
17:33:55 <gjanssens> I may get back to it later when our windows toolchain is more up to date
17:34:05 <gjanssens> But that will certainly not happen before we branch
17:34:12 <jralls> Right.
17:34:35 <jralls> But if it's really a Gdk problem then what we're doing isn't important.
17:34:45 <gjanssens> Indeed
17:34:54 <jralls> The accounts page is a normal GtkTreeView, right?
17:34:59 <gjanssens> Yep
17:35:25 <jralls> So that lets our register code off the hook. Makes it more likely it's Gdk.
17:35:46 <gjanssens> Unless we're looking at two independent memory leaks
17:36:29 <gjanssens> For the register the only potential piece of code that is different on windows is the date-time handling code
17:36:36 <jralls> Possible, I suppose, but given that the cause and symptoms seem identical, not likely.
17:36:47 <gjanssens> Agreed
17:37:14 <jralls> That's libqof, not register. And it doesn't have anything to do with scrolling.
17:37:58 *** JeremyK has joined #gnucash
17:38:02 <gjanssens> I'm not sure. If the register recalculates the date strings that come from off-screen it might
17:38:10 <gjanssens> I agree it's a long shot though
17:38:13 <gjanssens> Just theory
17:38:38 * gjanssens hasn't actually looked at the code to see if this makes sense
17:39:25 <JeremyK> gjansses thanks for helping with the setting an image in the report the other day.
17:39:41 <gjanssens> You're welcome
17:41:04 <JeremyK> The trace says I am missing an expression
17:41:06 <JeremyK> (let ((table (gnc:make-html-table))
17:41:06 <JeremyK> (gnc:html-table-append-row! table (list e1 e2 e3))
17:41:06 <JeremyK> table))
17:42:10 <JeremyK> what expression am I missing?
17:44:32 <gjanssens> At least a closing parenthesis on the first line
17:45:30 <JeremyK> There is a double one on the last line for the let
17:48:06 <gjanssens> You're not closing the variable assignment block properly
17:48:29 <gjanssens> (let ( (var1 value) ) (other commands) )
17:48:50 <gjanssens> your value is another expression (gnc:make-html-table)
17:49:08 <gjanssens> Count the parenthesis, you need three closing ones on your first line
17:49:17 <gjanssens> And to match one less on your last line
17:58:17 <JeremyK> Bad binding table in expression (let (table (gnc:make-html-table)) (gnc:html-table-append-row! table (list e1 e2 e3)))
17:59:44 <gjanssens> Why did you remove the opening parenthesis after let ?
17:59:59 <gjanssens> It should be (let ((table ...
18:00:19 <gjanssens> (let ((table (gnc:make-html-table)))
18:00:49 <gjanssens> The whole variable assignment block should be in on pair of parenthesis
18:01:11 <gjanssens> And each individual assignment in on pair on its own
18:02:50 <gjanssens> Got to go...
18:03:10 *** gjanssens has quit IRC
18:04:45 <JeremyK> Thanks again
18:27:48 *** JeremyK has quit IRC
18:44:45 *** TradeBorG1111 has quit IRC
18:50:08 *** JeremyK has joined #gnucash
19:17:49 *** JeremyK has quit IRC
19:37:38 *** fell_ has quit IRC
20:06:53 *** SteveG has quit IRC
20:25:34 *** [^DraCuLin^] has quit IRC
20:27:12 *** benoitg has quit IRC
21:07:02 *** jralls has quit IRC
22:38:04 *** yargy has joined #gnucash
23:21:25 *** kpreid has quit IRC