2019-11-08 GnuCash IRC logs
00:43:05 *** storyjesse has joined #gnucash
00:44:45 *** Mechtilde has joined #gnucash
01:17:17 *** storyjesse has quit IRC
01:19:42 *** Mechtilde has quit IRC
01:45:40 *** giuseppef has quit IRC
01:50:05 *** boldstripe has quit IRC
01:51:00 *** boldstripe has joined #gnucash
01:55:01 *** fell has quit IRC
03:38:14 *** bertbob has quit IRC
03:50:44 *** bertbob has joined #gnucash
03:50:45 *** ChanServ sets mode: +v bertbob
03:50:45 *** boldstripe has quit IRC
03:51:42 *** boldstripe has joined #gnucash
03:54:08 *** boldstripe has quit IRC
04:17:22 *** omnireq_ has joined #gnucash
04:18:35 *** omnireq has quit IRC
04:44:40 *** omnireq_ has quit IRC
04:45:38 *** omnireq_ has joined #gnucash
04:54:58 *** Gerd has joined #gnucash
05:02:50 <mauritslamers> blaztek: it is known that it is offline, the exact reason I don't know
05:04:04 <mauritslamers> Question: Why are separate dialog windows not in the "Window" menu list?
05:06:40 *** omnireq_ has quit IRC
05:07:14 *** omnireq_ has joined #gnucash
05:28:10 *** omnireq_ has quit IRC
05:28:20 *** omnireq_ has joined #gnucash
05:34:09 *** andreas^ has joined #gnucash
05:34:09 *** ChanServ sets mode: +v andreas^
05:34:14 <andreas^> hello.
05:34:35 <mauritslamers> morning
05:35:20 <andreas^> I would like to know how to see the field name on a budget after scrolling to the right.
05:35:30 <andreas^> currently for me they are all hidden because of the scroll.
05:46:19 <chris> mauritslamers: you can right-click on the tabs to get the list of them. I agree the Window menu should also populate itself with tabs.
05:46:28 <chris> patches would be welcome
05:47:28 <chris> andreas^: are you referring to the budget editor/viewer or the budget report?
05:47:28 <mauritslamers> chris: right-click on the tabs only gives me the available tabs, what I mean are the separate dialogs...
05:48:07 <chris> patches welcome! C is not my field
05:48:25 <mauritslamers> chris: mine neither ;-) JS is my field to be honest :)
05:49:16 <mauritslamers> If I would have all the time, I would rewrite the interface of gnucash as an Electron-like app
05:49:44 <mauritslamers> The framework I use mostly (SproutCore) is ideal for this kind of applications.
05:51:29 <chris> maybe one day you can. you'd call libgnucash for any data access calls.
05:52:30 *** boldstripe has joined #gnucash
06:01:41 *** andreas^ has quit IRC
06:12:27 <mauritslamers> yes, I would have to write a NodeJS FFI like interface I guess.
06:12:34 <mauritslamers> let's see :)
06:13:31 <mauritslamers> interesting: someone wrote a gnucash npm package (https://www.npmjs.com/package/gnucash/v/0.0.2) to read in gnucash files.
06:14:23 <mauritslamers> and even more: https://github.com/phjardas/gnucash-browser
06:17:23 <chris> unfortunately there are many unofficial data accessors; it's the official libgnucash that needs more attention
06:19:30 *** redarrow has quit IRC
06:20:07 *** xmaka has quit IRC
06:20:38 <mauritslamers> chris: it seems that there is a SWIG file
06:20:46 <mauritslamers> I found it in the Python bindings
06:21:17 <mauritslamers> I think (and hope) that means that making interfaces for other scripting languages is not too much of an issue
06:22:02 <chris> correct. you're very welcome to create swig for js
06:22:03 <mauritslamers> publishing a npm package with bindings to libgnucash so people can build things on top of it could help
06:23:29 <chris> even better, make the existing swig file usable to more languages, and you'll be a hero
06:23:48 <mauritslamers> in a way expose the public interface of libgnucash
06:24:02 <chris> because I would love to use the swig bindings from independent guile scripts but I don't know swig
06:27:15 <mauritslamers> me neither, but it seems that perhaps the quick and dirty technique is to simply include all headers of libgnucash
06:27:52 <chris> go for it ;)
06:28:35 <chris> I believe warlord, gjanssens and jralls could help
06:28:39 * chris can't
06:37:06 *** Jimraehl1 has joined #gnucash
06:38:21 *** Jimraehl1 has quit IRC
06:41:33 *** xmaka has joined #gnucash
06:42:34 *** Gerd has quit IRC
06:42:47 *** redarrow has joined #gnucash
06:54:31 *** boldstripe has quit IRC
06:55:06 <chris> jralls warlord: running the installer in maint gives the following warning: https://imgur.com/PbMOqof
06:55:30 <chris> it does install successfully though
06:55:40 <chris> (this may just be my Win10 permissions)
07:07:14 *** User_ has joined #gnucash
07:08:02 *** fell has joined #gnucash
07:08:02 *** ChanServ sets mode: +o fell
07:13:18 *** User_ has quit IRC
07:38:17 *** oozer has joined #gnucash
07:39:15 *** gjanssens has joined #gnucash
07:39:16 *** ChanServ sets mode: +o gjanssens
08:10:07 <mauritslamers> looking at swig for a sec, trying to see whether I can create a wrapper for libgnucash, I used the python swig file as a basis. Now running into weird compilation errors, such as "#include <datetime.h> file or folder doesn't exist
08:10:37 <mauritslamers> running under Linux 18.04
08:19:50 <mauritslamers> never mind, probably part of python
08:30:31 *** fell has quit IRC
08:56:09 *** fell has joined #gnucash
08:56:09 *** ChanServ sets mode: +o fell
09:01:41 *** Mechtilde has joined #gnucash
09:08:42 *** Gerd has joined #gnucash
09:12:27 *** waeking has quit IRC
09:13:04 *** sbluhm has joined #gnucash
09:13:04 *** ChanServ sets mode: +v sbluhm
09:22:56 *** User_ has joined #gnucash
09:25:22 *** waeking has joined #gnucash
09:25:23 *** ChanServ sets mode: +v waeking
09:27:30 *** User_ has quit IRC
09:33:49 *** storyjesse has joined #gnucash
09:39:50 *** Gerd has quit IRC
09:41:34 *** sbluhm has quit IRC
09:44:09 *** fell has quit IRC
09:47:23 *** jervin has joined #gnucash
09:48:36 *** jervin has quit IRC
09:48:42 *** jervin has joined #gnucash
09:49:43 <warlord> mauritslamers, a long long time ago, the gnucash app *was* a guile script.
09:50:11 <warlord> But it was still integrated; you couldn't really write a standalone script the same way you can now write a standalone python script.
09:52:15 *** jervin has quit IRC
10:02:40 *** Gerd has joined #gnucash
10:25:00 *** omnireq_ has quit IRC
10:28:54 <mauritslamers> warlord: interesting :) ok, status so far is that after manually compiliing and installing swig 4.0.1 I got something that compiles, but crashes on the init. In the Python swig file there is an init section, and loading the compiled library causes an error on the first command of the init "gnc_environmet_setup()"
10:30:24 <mauritslamers> error is "undefined symbol"
10:34:23 *** kriesel has joined #gnucash
10:37:32 <mauritslamers> which is not entirely strange as the binary doesn't seem to have a reference to libgnucash
10:39:28 *** kriesel has quit IRC
10:42:03 *** kael has joined #gnucash
10:42:03 *** ChanServ sets mode: +v kael
11:01:54 *** omnireq has joined #gnucash
11:01:54 *** ChanServ sets mode: +v omnireq
11:03:47 <warlord> mauritslamers, I've got swig 3.0.12.
11:05:48 *** mauritslamers has quit IRC
11:06:49 *** mauritslamers has joined #gnucash
11:06:50 *** ChanServ sets mode: +v mauritslamers
11:09:03 *** Mechtilde has quit IRC
11:17:56 *** isn0gud has joined #gnucash
11:21:46 *** jervin has joined #gnucash
11:29:08 *** kael has quit IRC
11:36:27 *** warlord has quit IRC
11:42:22 *** kael has joined #gnucash
11:42:22 *** ChanServ sets mode: +v kael
11:45:29 *** jervin has quit IRC
11:55:09 *** guak has joined #gnucash
12:03:57 *** Gerd has quit IRC
12:04:04 *** warlord has joined #gnucash
12:05:19 *** Mechtilde has joined #gnucash
12:07:47 *** storyjesse has quit IRC
12:12:52 *** storyjesse has joined #gnucash
12:33:24 *** calvinct has joined #gnucash
12:33:58 <mauritslamers> warlord: that is the official version installable under Ubuntu, problem is that the code it generates only works for NodeJS < 10.12
12:34:26 <mauritslamers> So, to be able to compile thinigs with a bit recent version of NodeJS requires swig 4
12:35:01 <mauritslamers> I tried a PPA, but that didn't work
12:35:13 <jralls> mauritslamers: The Window menu's behavior is ideally determined by the platform
12:35:54 <jralls> platform's HIG--really ideally it's something that the platform takes care of without the app having to do anything. That's the case on Mac.
12:36:40 <warlord> Oh, I missed that you were trying to build a set of JS bindings.
12:39:54 <jralls> All of the HIGs make a distinction between windows and dialog boxes. Dialog boxes are supposed to be for some limited user interaction subsidiary to a window and they're never included in the Windows menu. So which to use--dialog or window--for any particular use is a UI design decision and whether the UI designer wants the object on the Windows menu is one consideration.
12:40:42 <mauritslamers> jralls: that would be valid if the dialog closes nicely after the user leaves it
12:41:54 <mauritslamers> (I have an example, but have to find the english translation :) )
12:42:30 <jralls> I suppose that's another design decision, but it has nothing whatever to do with the validity. If you create a GtkWindow it shows up on the Windows menu. If you create a GtkDialog it doesn't. That's the way Gtk works. The M$Windows and MacOS analogs work exactly the same way.
12:44:09 <mauritslamers> jralls: perhaps we think along the same lines here :-)
12:44:17 <mauritslamers> If you for example open the reconclie window, then choose to open the account, the dialog is still there even though the focus went back to a (new) tab in the main window
12:44:43 <jralls> Note as well that there are two flavors of dialogs: Modal, which suspend the main run loop and use their own, and non-modal which don't. A non-modal dialog allows the user to interact with other parts of the program while the dialog is open; a modal one doesn't.
12:44:46 *** storyjesse has quit IRC
12:44:58 *** boldstripe has joined #gnucash
12:45:18 <mauritslamers> the only way to find it though is to search behind the main window, or to go through the menu.
12:45:49 <mauritslamers> I also noticed that certain dialogs are kept on top while other are not
12:45:58 <warlord> There have been issues in the past where a modal dialog pops up behind the main window, which makes it look like GnuCash freezes.
12:46:50 <mauritslamers> The reason I am mentioning this is that I am going through the manual and as a consequence encounter all these things :)
12:47:10 <jralls> There have indeed and there are probably plenty more lurking in the weeds. Bob Fewell did a search-and-fix early last year and got a lot of them, but GnuCash has *lots* of dialogs.
12:47:23 <warlord> Modal dialogs should IMHO be kept on top to prevent this kind of issue.
12:47:54 <mauritslamers> warlord: I agree
12:48:29 <jralls> Yes. The way to do that is to call gtk_window_set_transient_for(dialog, parent). It's API that was added after much of the GnuCash UI was written.
12:48:31 <mauritslamers> but also the non-modal ones might be good to be kept on top
12:49:14 <warlord> No, if its non-modal then you dont want to force it to stay on top because the user might want to work on other parts of the app.
12:49:25 <mauritslamers> The other option might be to not use dialogs for non-modal
12:49:47 <jralls> That causes a problem: If the dialog is non-modal then one is supposed to be able to interact with the parent window. If the dialog is always on top that becomes challenging unless one has enough screen space to move the dialog completely off the window.
12:49:57 <mauritslamers> In an interface with tabs, it feels more natural to me to have non-modal dialogs as tabs
12:50:27 <jralls> Eh, I can see that both ways.
12:50:35 <mauritslamers> jralls: I understand, but then they should be in the window menu
12:50:59 <mauritslamers> if there is a possibility they get to lurk behind the main screen, they are a separate window, and as such need to be in the window menu :)
12:52:03 <mauritslamers> On a completely different topic: I am trying to see how far I can get to create a wrapper around libgnucash for NodeJS.
12:52:24 <mauritslamers> I adapted the one for python, but now I am a bit stuck: it builds, but it doesn't link to any of the libgnucash libs
12:52:57 <mauritslamers> that might very well be because of my limited skills in this corner, and the inability to read the cmake files in the python folder
12:53:10 <mauritslamers> as in: I have no clue what they mean :)
12:54:51 <jralls> Well, you'll just have to learn CMake then. Are you already fluent with SWIG and sufficiently fluent with C++ to make sense of it?
13:02:44 <jralls> Note that there is no libgnucash.so, libgnucash is a major source subdirectory that builds several shared libraries. You'll need to link or load libgnc-core-utils.so, gnucash/libgncmod-engine.so, and gnucash/libgncmod-app-utils.so plus the backend libraries in both lib and lib/gnucash to get access to most of libgnucash's symbols.
13:04:28 <linas> arghhh 3 day delay in shipping
13:04:59 <mauritslamers> Not fluent with swig at all, but I think know enough to try to make sense of it. I know there is no libgnucash, I am just trying to figure out how to properly link the libs
13:05:02 <jralls> linas, Sigh. I guess you haven't had any luck with the failover server.
13:06:46 <jralls> mauritslamers: That might work if your goal was to understand how to use the python bindings. You're going to have to become fluent in SWIG and its JS generator's quirks if you're going to use it to write a new binding.
13:08:09 <jralls> mauritslamers, Also note that not all of the Python swig code is in bindings/python. There are pieces of it in the SWIG files (foo.i) in libgnucash too.
13:09:07 <mauritslamers> yes, I have seen those.
13:09:22 <jralls> Note also common/typemaps.i. You may need to specialize some of them for JS.
13:09:37 <warlord> linas, argh. Sorry.
13:11:45 *** MarkFirewhal has quit IRC
13:46:43 <gjanssens> jralls, mauritslamers: while there is no libgnucash.so yet, that was/is one of the main goals of my "gnc-module-begone" branch
13:46:54 <gjanssens> I hope to pick up on this soon
13:47:50 <gjanssens> The plan is to move all bindings found in libgnucash to bindings
13:48:16 <gjanssens> core-utils and engine are done.
13:48:25 <gjanssens> Currently processing app-utils
13:48:31 <warlord> :)
13:49:20 <gjanssens> (the branch name is gnc-module-load-begone actually suggesting the second goal of that branch)
13:49:33 <gjanssens> got to leave again...
14:00:16 *** fell has joined #gnucash
14:00:16 *** ChanServ sets mode: +o fell
14:00:58 *** sbluhm has joined #gnucash
14:00:58 *** ChanServ sets mode: +v sbluhm
14:11:54 *** boldstripe has quit IRC
14:17:57 *** boldstripe has joined #gnucash
14:20:34 *** frakturfreak has joined #gnucash
14:20:34 *** ChanServ sets mode: +v frakturfreak
14:34:40 *** mdf has quit IRC
14:37:42 *** nhbh^ has joined #gnucash
14:38:13 <linas> I just don't have a spare empty case. For a while I was thinking of plugging it into a raspberry pi(the website has a very low CPU demand) but I don't have the right binaries on the disk
14:39:07 <warlord> What binaries do you need?
14:53:54 *** gncbot has joined #gnucash
14:55:08 <warlord> gjanssens, jralls -- can you /op gncbot ?
14:55:18 *** jralls sets mode: +o gncbot
14:55:28 <warlord> thx
14:56:46 <jralls> warlord: All of them ;-). Raspberry Pi is ARM-based, not binary compatible with x86.
14:57:42 <warlord> jralls, right, but I dont know what binaries he needs that aren't part of the RPi distro being run?
15:17:28 *** sbluhm has quit IRC
15:19:40 *** TommyT has joined #gnucash
15:19:41 *** ChanServ sets mode: +v TommyT
15:27:24 *** sbluhm has joined #gnucash
15:27:24 *** ChanServ sets mode: +v sbluhm
15:33:34 *** kael has quit IRC
15:35:10 <mauritslamers> linas: what do you need exactly server-wise?
15:38:43 *** Mechtilde has quit IRC
15:39:52 <mauritslamers> linas: I have a server behind a 100mbit fiber connection, I don't mind running an lxd container if that will help out things
15:41:39 *** sbluhm has quit IRC
16:04:51 *** warlord has quit IRC
16:09:44 *** kael has joined #gnucash
16:09:44 *** ChanServ sets mode: +v kael
16:18:55 <jralls> warlord, I think he meant that he'd use the disk from the failed server and boot up a raspberry with it. That wouldn't work.
16:20:45 *** MarkFirewhal has joined #gnucash
16:25:09 *** warlord has joined #gnucash
16:33:07 * chris applauds any improvements to bindings
16:33:41 <chris> mauritslamers: note the python bindings have the nasty feature of omitting xaccAccount prefix
16:35:09 <mauritslamers> chris: I have loads of issues trying to get the python bindings to work at all... biggest issue is that I can create a nodeJS loadable binary, but it fails to load as I have loads of undefined symbols
16:35:11 <chris> which makes object accessors differently-named
16:35:46 <jralls> chris: That's because Python is ground-up OO so instead of saying xaccAccountFoo(acct) you say acct.Foo(). The python bindings correctly implement that.
16:36:32 <warlord> mauritslamers, if you're missing symbols, that just means you're not linking in all the appropriate .so files
16:36:34 <mauritslamers> The biggest issue I have at the moment is that gnc_environment_setup is not defined
16:36:36 <chris> ok. makes for confusing reading though
16:36:57 <warlord> chris, acct.xaccAccountFoo() would be even MORE confusing.
16:36:58 <mauritslamers> warlord: I am linking everything, they simply don't seem to be linked
16:37:18 <warlord> Are the .so files in your LD_LIBRARY_PATH?
16:37:22 <mauritslamers> I have a suspicion why that is
16:37:35 <mauritslamers> yes, I trace the inclusion by the linker
16:37:41 <chris> it shouldbe xaccAccountGetName(acct) to be comparable to C and guile
16:38:06 <chris> my knowledge of python has faded
16:38:18 <mauritslamers> and ld finds everything, it just doesn't get registered in the shared library gnucash.node
16:38:56 <chris> meanwhile I have found a discrepancy between owner-report and new-owner-report and will hack it some more
16:43:23 <warlord> chris, but that's not "the python way". Why force a non-OO C API on python users?
16:43:54 <warlord> mauritslamers, if ld is finding and including the library then I have no idea why gnucash.node isn't finding them.
16:44:10 <mauritslamers> warlord: it is more than not finding, it is not linking
16:44:33 <mauritslamers> I mean: I provide the library through -l and provide a proper library path, and ld is finding them
16:44:43 <mauritslamers> but when I run ldd on the resulting lib, it is not in the list
16:45:42 <mauritslamers> actually, it is even weirder
16:45:56 *** jervin has joined #gnucash
16:46:34 <warlord> is it not in the ldd list or in the list but not found?
16:46:51 <warlord> can you show me the ldd output of gnucash.node?
16:47:01 <mauritslamers> warlord: working on that
16:47:55 <mauritslamers> point is that libgnc-core-utils.so is linked in gnucash.node, and that library is exporting gnc_environment_setup
16:49:12 <mauritslamers> but when running the library with node, it complains "Z21gnc_environment_setupv" undefined symbol
16:50:44 <warlord> OH.. Wait... Are you linking with gcc or g++???
16:51:02 <warlord> You need to link with g++
16:52:15 <mauritslamers> hmm, I would assume that node-gyp would do that
16:53:32 <warlord> Don't assum.
16:53:36 <warlord> Check.
16:53:42 *** isn0gud has quit IRC
16:53:50 <warlord> My guess is that it is not -- it looks like a name mangle mismatch.
16:54:03 <warlord> Or something is missing an extern "C" {}
16:56:49 <mauritslamers> warlord: possibly, but if this doesn't work for NodeJS, how could it work for Python?
16:57:06 <jralls> The latter. gnc_environment_setup is defined in core-utils/gnc-environment.c
16:57:22 <mauritslamers> linking is done through g++
17:01:30 <jralls> mauritslamers: SWIG works by generating a new file in the build directory, e.g. builddir/bindings/python/gnucash_core.c. It would make gnucash_core.cpp if you tell it to, and in that case it will use c++ to compile and link it. If you do that you need to put all C #includes inside an extern "C" { } block inside the corresponding swig file, in this case gnucash_core.i.
17:01:54 <mauritslamers> jralls: ah :)
17:02:59 <mauritslamers> for nodejs it has to be a c++ file otherwise it cannot work.
17:07:21 <warlord> jralls, I wonder if we should add the appropriate extern "C" {} within our own .h files to properly protect our C interfaces?
17:11:34 <jralls> warlord: They'd have to be guarded with #ifdef __cplusplus, but we could do that instead of wrapping the includes in the C++ files.
17:12:16 <mauritslamers> adding it to the .i file seems to do something now
17:12:22 <warlord> Yes, of course. (I was being brief .. yeah, #ifdef ... extern "C" { ...
17:13:02 <gjanssens> chris: re xaccAccountFoo(acct) - it will become something like acct->Foo() in C++ as well.
17:13:53 <mauritslamers> bingo
17:14:03 <chris> \o/
17:14:32 <mauritslamers> simply adding the extern "C" {} in the %module section of the .i file is enough
17:15:54 <mauritslamers> so, now it compiles and can be interfaced... however doing a complete display of the resulting object creates an error "double free or corruption (!prev)
17:16:17 *** MarkFirewhal has quit IRC
17:17:24 <mauritslamers> ok, this is interesting. The current setup seems to now expose all functions in all header files
17:17:44 <mauritslamers> including things like guid_malloc
17:18:35 <warlord> mauritslamers, that's what the %include<> does in .i file
17:18:49 *** pohly1 has quit IRC
17:18:57 <warlord> If you don't want that then you need to define the APIs you want to wrap.
17:20:01 <mauritslamers> I am now trying to bring it down to what was done in the Python wrapper
17:23:05 * chris another bug squashed
17:25:33 * mauritslamers has done enough today ...
17:25:36 <mauritslamers> time for bed :)
17:26:37 <warlord> mauritslamers, good night. Only 2:30pm here.
17:28:48 *** frakturfreak has quit IRC
17:35:17 *** Gerd has joined #gnucash
17:37:25 <mauritslamers> warlord: 11.37pm here (Europe :) )
17:37:37 <mauritslamers> have a good day!
17:40:21 <warlord> mauritslamers, I'm in Seattle (for the next 8 hours). have a good night.
17:42:31 <jralls> gjanssens: Any ideas on setting the G_LOG_LEVEL to G_LOG_LEVEL_WARN when running ninja check? It seems to be on G_LOG_LEVEL_INFO and it makes Testing/Temporary/Last_Log.txt too long to display in Travis.
18:06:14 *** warlord has quit IRC
18:12:23 <gjanssens> jralls: isn't there a way to pass this via environment variables ?
18:15:24 <jralls> G_MESSAGES_DEBUG, but the default is to not print debug or info. Are we setting that in the travis setup somewhere?
18:15:43 <jralls> Scratch that, I got it locally too.
18:20:55 <jralls> It doesn't show up in our codebase. Hmm.
18:21:36 <gjanssens> There's qof_log_set_level, but that's only used in test-aqb.c
18:21:53 <gjanssens> Anyway, time to go to bed. TTYL
18:22:31 *** gjanssens has quit IRC
18:40:12 *** Gerd has quit IRC
18:40:21 *** Gerd has joined #gnucash
18:50:16 *** kael has quit IRC
18:50:51 *** Gerd has quit IRC
19:39:51 *** fabior has joined #gnucash
19:40:18 *** jervin has quit IRC
20:07:23 *** fabior has quit IRC
20:11:29 *** kael has joined #gnucash
20:11:29 *** ChanServ sets mode: +v kael
20:13:22 *** omnireq has quit IRC
20:21:43 *** kael has quit IRC
20:34:27 *** guak has quit IRC
20:35:44 *** o01eg has quit IRC
20:35:53 *** o01eg has joined #gnucash
20:44:22 *** Mechtilde has joined #gnucash
20:47:23 *** Mechtilde has quit IRC
21:19:17 *** omnireq has joined #gnucash
21:27:19 *** oozer has quit IRC
21:31:25 *** storyjesse has joined #gnucash
21:43:40 *** boldstripe has quit IRC
21:44:34 *** boldstripe has joined #gnucash
22:06:33 *** TommyT has quit IRC
23:37:22 *** jervin has joined #gnucash
23:44:20 *** boldstripe has quit IRC
23:45:13 *** boldstripe has joined #gnucash