2019-09-21 GnuCash IRC logs
00:18:34 *** Mechtilde has joined #gnucash
00:44:58 *** Mechtilde has quit IRC
00:46:50 *** Mechtilde has joined #gnucash
01:33:57 *** JayC has joined #gnucash
01:33:57 *** ChanServ sets mode: +v JayC
01:46:12 *** Mechtilde has quit IRC
01:51:49 *** sbluhm has joined #gnucash
01:51:49 *** ChanServ sets mode: +v sbluhm
01:51:57 *** sbluhm has quit IRC
01:55:32 *** sbluhm has joined #gnucash
01:55:32 *** ChanServ sets mode: +v sbluhm
01:56:11 *** sbluhm has quit IRC
01:56:12 *** gour has joined #gnucash
01:56:13 *** ChanServ sets mode: +v gour
01:59:58 * chris thinks overloading + is a bad idea(TM); + is likely coded in C for speed and will break things
02:35:24 *** Aussie_matt has quit IRC
02:40:22 *** storyjesse has joined #gnucash
03:04:08 *** storyjesse has quit IRC
03:22:43 *** Mechtilde has joined #gnucash
03:53:58 *** fell has joined #gnucash
03:53:58 *** ChanServ sets mode: +o fell
04:16:51 <fell> Hooray! Back again!
04:16:51 <gncbot> fell: Sent 20 hours and 29 minutes ago: <gjanssens> I have already moved us and de tax reports in separate directories on master
04:16:52 <gncbot> fell: Sent 20 hours and 29 minutes ago: <gjanssens> factoring out common code was not part of that
04:19:09 *** gjanssens has joined #gnucash
04:19:09 *** ChanServ sets mode: +o gjanssens
04:20:13 <gjanssens> .
04:20:30 <gjanssens> Morning fell, DSL appears to work again?
04:21:36 <fell> Yes, the technician told me, another technician had removed his contruction.
04:38:59 *** Mechtilde has quit IRC
04:43:52 <fell> ganssens: an Ubuntu 18.04 user:
04:43:53 <fell> Fehler: The application
04:43:55 <fell> org.gnucash.GnuCash/x86_64/master-C3.7-176-g9214f2ed5-D3.7-15-gc52384e
04:43:56 <fell> requires the runtime org.gnome.Platform/x86_64/3.32 which was not
04:43:58 <fell> found
04:44:28 <fell> gjanssens ^
04:48:39 <fell> the last win maint build is still 2019-09-19
04:48:46 *** Mechtilde has joined #gnucash
04:49:39 *** bertbob has quit IRC
04:49:45 <fell> and master is still from august.
04:50:39 <fell> jhbuild build: failed to parse /C/gcdev64/src/gnucash-on-windows.git/gnucash.modules: not well-formed (invalid token): line 138, column 46
04:50:55 *** bertbob has joined #gnucash
04:50:56 *** ChanServ sets mode: +v bertbob
04:54:49 <fell> OK, I go for win. the flatpak log is longer.
04:55:10 <gjanssens> fell: Our own repo doesn't ship runtimes (like org.gnome.Platform) indeed. I don't know if we should
04:55:49 <gjanssens> On my system they seem to come from flathub. So the your may have to enable the flathub repo in addition to our own
04:56:10 <fell> I could suggest, they should at first install the release from flathub
04:56:21 *** bertbob has quit IRC
04:57:38 <gjanssens> The windows bug is a stray " in the libchipcard line
04:57:45 <gjanssens> I'll push a fix.
04:58:36 <fell> grr
04:59:10 *** Mechtilde has quit IRC
04:59:58 <gjanssens> When I opened that file in the kate text editor it was immediately obvious: the syntax highlighting already marked the string as invalid syntax with a red underline
05:00:45 <gjanssens> as for the flatpak, I don't know if they really should install the release. It may be sufficient to just enable the flatpak repo
05:00:52 <gjanssens> I haven't tested this.
05:01:02 <fell> I worked directly in githubs web interface.
05:04:54 <fell> the last flatpak on code is from 2019-09-19, too but there is a very long log for 2019-09-20
05:09:02 *** pohly1 has joined #gnucash
05:17:55 *** pohly1 has quit IRC
05:18:00 *** bertbob has joined #gnucash
05:18:01 *** ChanServ sets mode: +v bertbob
05:19:57 <gjanssens> windows master needs some more investigation. I think the reworked gtest detection code is messing things up.
05:21:40 <gjanssens> flatpak build fails due to the addition of the pcsc socket
05:21:56 <gjanssens> Apparently the flatpak version on code doesn't know this one yet :(
05:22:16 <gjanssens> So we can't build it into our flatpak ourselves
05:24:23 *** pohly1 has joined #gnucash
05:24:59 <fell> RuntimeRepo=https://sdk.gnome.org/gnome.flatpakrepo links gnome.flatpakrepo which does not exist
05:26:33 *** Mechtilde has joined #gnucash
05:27:23 <gjanssens> Users on recent systems can still enable this socket themselves using the command 'flatpak override --user --socket=pcsc org.gnucash.GnuCash'
05:29:24 <gjanssens> Hmm, the missing runtime seems to be a recent change at gnome.
05:29:43 <gjanssens> We'll have to figure out where to get the runtimes from going further.
05:30:02 <gjanssens> But I have to leave for a couple of hours. To be continued later.
05:31:29 <fell> @flatpack org.gnome.Platform
05:31:29 <gncbot> fell: Error: "flatpack" is not a valid command.
05:31:37 <fell> '@flatpack org.gnome.Platform
05:34:11 <fell> at gnome, I see only nightlies
05:34:56 <gjanssens> I suppose you mean flathub
05:35:02 <fell> yep
05:35:20 <fell> http://docs.flatpak.org/en/latest/available-runtimes.html
05:36:23 <fell> preferrable also org.freedesktop.Platform.Locale?
05:36:42 <fell> ahem org.gnome.Platform.Locale
05:39:57 <gjanssens> I'm not sure we can install extensions directly from a flatpakref... I never came across an example
05:40:46 *** Mechtilde has quit IRC
05:42:36 *** Mechtilde has joined #gnucash
06:11:23 *** phoenix has joined #gnucash
06:14:40 *** Mechtilde has quit IRC
06:14:42 *** phoenix has quit IRC
06:17:39 *** oozer has joined #gnucash
06:18:16 *** Mechtilde has joined #gnucash
06:22:17 <chris> jralls: returning #f is not lispy :) case in point: (+) returns 0, (every positive? '()) returns #t -- the latter because every tests list members looking for any #f, and if it doesn't find any then it returns #t etc
06:25:14 *** phoenix has joined #gnucash
06:29:05 *** phoenix has quit IRC
06:54:12 *** fabior has joined #gnucash
06:57:13 <chris> lol: https://github.com/Gnucash/gnucash/blob/maint/libgnucash/app-utils/gnc-sx-instance-model.c#L11 good to know ...
06:59:27 <chris> the SX mechanism is not visible to scheme so I cannot test it
07:05:53 *** oozer has quit IRC
07:12:58 *** fabior has quit IRC
07:14:25 *** FoxT has quit IRC
07:20:39 *** FoxT has joined #gnucash
07:20:52 *** Mechtilde has quit IRC
07:30:01 *** PeterAxup has joined #gnucash
07:30:01 *** ChanServ sets mode: +v PeterAxup
07:36:12 *** Mechtilde has joined #gnucash
07:37:48 *** storyjesse has joined #gnucash
07:37:56 *** jervin has joined #gnucash
07:45:01 *** jervin has quit IRC
08:07:16 *** Jimraehl1 has joined #gnucash
08:12:46 <chris> sx-summary.scm will be gone soon
08:22:44 <warlord> .
08:36:22 <chris> ...and gone
08:38:06 <warlord> sx-summary.scm is dead. long live txn-summary.scm
09:06:42 *** jervin has joined #gnucash
09:07:08 *** jervin has quit IRC
10:14:12 *** fell has quit IRC
10:23:05 *** fell has joined #gnucash
10:23:05 *** ChanServ sets mode: +o fell
10:24:46 *** mohave has joined #gnucash
10:24:48 *** mohave_ has joined #gnucash
10:35:55 <fell> chris: about tax-number: German users were the first, which asked for one. So cstim implmented it in teh german tax module.
10:37:04 <fell> In theory we need 2: EU-VAT-Nr. and DE-Incometax-Nr.
10:38:00 <fell> The VAT is also required for Suppliers and clients.
10:39:02 <fell> I think both numbers should become book-properties, not user-prefs.
10:39:14 *** CarwynNelson has joined #gnucash
10:39:14 *** ChanServ sets mode: +v CarwynNelson
10:39:51 <CarwynNelson> .
10:39:52 <gncbot> CarwynNelson: Sent 1 day, 15 hours, and 14 minutes ago: <jralls> No one has taken the time to triage bugs that way. When I started out I approached it by picking one of the components (it was the then-new SQL/DBI backend because Phil Longstaff had stopped working on it and it was holding up the 2.4.0 release) and dove in.
10:39:53 <gncbot> CarwynNelson: Sent 1 day, 15 hours, and 12 minutes ago: <jralls> that the libgnucash side is a better place to start because Gtk has its own rather steep learning curve and it's hard to work on the UI bits until one has climbed it.
10:39:54 <gncbot> CarwynNelson: Sent 1 day, 15 hours, and 4 minutes ago: <jralls> Meanwhile after more study I think I went off the rails a bit on GncOptionWrapper, too much redesign for this round. I'm just going to put a void* for the widget on GncOption and provide a getter and setter. I'll reset to 7a87905 and force-push.
10:40:13 <fell> If I have my business in town A and am a residential of town B, I will also have 2 different income tax nubers.
10:40:53 <fell> That can be solved by having a private and a business book.
10:41:34 <chris> fell: I really cannot comment on the worldwide needs... my recent change is merely to harmonise the discrepancy whereby a locale defines a unique global property... it *could* have been a book property; shame it was not done as such
10:42:06 <chris> jralls thanks to gnc:collector arithmetic we can condense as follows for great clarity https://github.com/christopherlam/gnucash/commit/99fe5b1053e5fb1e8092f0e3f11a28c17e50ec3c
10:43:16 <fell> chris: a first step on a long way. ;-)
10:43:37 <CarwynNelson> jralls: Thanks for the reply / advice.
10:44:20 <chris> CarwynNelson: good luck with endeavours... you notice I cannot comment on writing C/C++ -- I can barely read it. Any scheme questions do ask!
10:44:22 <CarwynNelson> I was looking through the bug tracker and noticed a lot of bugs that haven't been responded to in a long time, or have had fixes applied in releases many months or years ago. I imagine these bug reports can be closed now.
10:44:30 <CarwynNelson> chris: will do!
10:45:00 <CarwynNelson> Would it help if someone were to go through parts of the bug tracker and close these off if they fall into these "buckets"
10:46:28 <fell> As a first step you could close "Need Info" bugs whithout answers.
10:46:52 <fell> We have stock message in the wiki.
10:47:24 <fell> If they are at least amonth old.
10:48:01 <fell> They get status ".incomplete"
10:49:51 *** oozer has joined #gnucash
10:51:47 <CarwynNelson> Thanks. I've found the page. I'll give it a read over now.
10:56:02 *** CarwynNelson has quit IRC
10:56:34 *** CarwynNelson has joined #gnucash
10:56:34 *** ChanServ sets mode: +v CarwynNelson
11:09:35 <CarwynNelson> fell: just to confirm that I would be doing the right thing.Bug 657402 is marked as NEEDINFO, but it looks like John published a fix for 3.3 and there hasn't been a response in a year.
11:10:02 <CarwynNelson> So would I be ok to close this as obsolete with the obsolete stock message?
11:10:35 <fell> let me see ...
11:11:55 *** Mechtilde has quit IRC
11:12:18 <fell> create a test file with 8 decimal and see the result.
11:12:58 <fell> If the file contains 8 real decimals, it is fixed.
11:13:57 <chris> 797421
11:14:38 <fell> I believe I read about the problem this week somewhere else. One of the mailing lists perhaps?
11:15:31 <fell> Then answer it is not fixed and reset the bug to new.
11:18:13 <CarwynNelson> Yeah, I'm getting interesting behaviour too
11:18:24 *** Mechtilde has joined #gnucash
11:23:53 *** Mechtilde has quit IRC
11:24:22 *** Mechtilde has joined #gnucash
11:27:53 <fell> CarwynNelson, yiiu should link somehow both bug. Question: Duplicate, dependency (in which direction?) or only similar?
11:31:39 <CarwynNelson> I was going to move the original bitcoin one to New and post that the issue still seems to exist in 3.7, and then mark the new one as duplicate
11:31:58 <CarwynNelson> And also ask the person who raised the new bug to attach an example gnucash file
11:32:02 <CarwynNelson> Is that okay?
11:34:48 <fell> but then on the original bug
11:35:21 <CarwynNelson> Will do
11:35:38 <fell> Thren you can leave need info
11:38:36 <CarwynNelson> Does Bugzilla give you a way of @ mentioning someone?
11:40:33 *** geetar has joined #gnucash
11:42:13 <CarwynNelson> Looks like John beat me to it with a reply that might indicate the bug not being duplicate
11:47:15 *** Mechtilde has quit IRC
11:56:47 *** jervin has joined #gnucash
11:56:56 *** geetar has left #gnucash
12:03:25 <jralls> fell: WRT the new BTC bug, we've long maintained that we'll recognize crypto-currencies when the ISO4217 committee does and that users of them should create commodities for them. But that leads to complications when trying to book income and expense as only STOCK and FUND account types allow non-currency commodities.
12:03:39 *** jervin has quit IRC
12:05:03 <jralls> fell: We can accommodate either by creating one or more X-currencies or by relaxing the commodity type restriction. Or we can not accommodate. What do you think?
12:11:51 *** mohave has quit IRC
12:11:51 *** mohave_ has quit IRC
12:12:10 *** CarwynNelson has quit IRC
12:18:19 <chris> will it break things to allow custom currencies? the core iso4217 remains read-only and custom-currencies get saved into book schema somewhere
12:18:23 *** Mechtilde has joined #gnucash
12:18:30 <chris> (guessing not kvp)
12:24:16 <jralls> Not KVP. The commodities used in the file are stored near the top. Custom currencies is another option indeed.
12:28:19 *** CarwynNelson has joined #gnucash
12:28:19 *** ChanServ sets mode: +v CarwynNelson
12:30:09 *** fell has quit IRC
12:42:27 *** Mechtilde has quit IRC
12:59:45 <warlord> Looks like the yahoo blockage has cleared up.
13:00:06 *** fell has joined #gnucash
13:00:06 *** ChanServ sets mode: +o fell
13:04:56 <fell> jralls, I have currency {ISO|user} in mind for a long time.
13:06:39 <fell> Some numismatics may have pre-ISO currencies, the youngsters crypto-currencies.
13:07:38 <gjanssens> jralls, fell: an additional non-iso currency domain is also what I have had in mind for a while
13:35:15 *** storyjesse has quit IRC
14:07:58 <jralls> fell: Money in a coin collection isn't really currency any more, even if (like U.S. gold coins from 100 years ago) it's still legal tender. Its market value is much greater than its face value and unless the collector obtained it himself as legal tender (like my collection of US silver coins from the 1960s) the book value is as well.
14:10:10 *** frakturfreak has joined #gnucash
14:10:10 *** ChanServ sets mode: +v frakturfreak
14:49:54 <gjanssens> jralls: we have an interesting issue for the Windows builds
14:50:45 <gjanssens> With the reworked gtest detection on master we now have to specify -DGTEST_ROOT=$SRCROOT/googletest
14:51:24 <gjanssens> On maint that should still be -DGTEST_ROOT=$SRCROOT/googletest/googletest -DGMOCK_ROOT=$SRCROOT/googletest/googlemock
14:51:54 <gjanssens> How can we model this difference in config parameters if we only have one gnucash-on-windows branch (master)
14:52:17 <gjanssens> Is there a way to set up alternative module sets based on the branch ?
14:53:11 <gjanssens> I mean can we define a gnucash-maint and gnucash-master module and have jhbuild pick the right one via a meta module based on the branch it detected ?
14:54:00 <gjanssens> And what to do with releases ? For now they are all from maint still, but at some point we"'ll also get beta releases based on master...
14:57:52 <gjanssens> And after updating the command line to get past this error another interesting error popped up in the cmake generation step:
14:57:55 <gjanssens> https://pastebin.com/NBjCNKYq
14:58:57 <gjanssens> CMake complains about a missing interface path, but that path does exist. The issue is most likely CMake expects Windows native paths, not msys unix style ones.
15:11:51 <gjanssens> If I manually change the include path in guile-2.2.pc to start with c:/ instead of /c/ the error goes away (well it still bails on the presence of /usr/include for the same reasons)
15:11:57 <jralls> gjanssens: I'm just starting a test build with a workaround for the first problem.
15:12:08 <gjanssens> Nice
15:14:32 <gjanssens> Bleh, it looks like we may have to patch all *.pc files for the dependencies we query via pkg_check_modules to use cmake compatible paths :(
15:15:06 <gjanssens> Removing /usr/include from the guile pc file, cmake will now error out on gwenhywfar for the exact same reason
15:16:06 <jralls> No real surprise there, I guess. It would be weird otherwise.
15:16:52 <gjanssens> True. It would have been nice only...
15:17:40 <gjanssens> I wonder if we can get by with specifying Windows or cmake style installation paths to the configure commands of each
15:17:49 <jralls> Rather than change the pc files it would make more sense to patch FindPkgConfig.cmake.
15:18:06 *** Mechtilde has joined #gnucash
15:18:33 <gjanssens> MSYS bash understands c:/gcdev64 to be /c/gcdev64
15:18:39 <gjanssens> Perhaps that's sufficient ?
15:18:51 <gjanssens> I'll run a test with guile
15:21:05 *** jervin has joined #gnucash
15:23:29 *** PeterAxup has quit IRC
15:23:33 *** PeterAxup has joined #gnucash
15:23:33 *** ChanServ sets mode: +v PeterAxup
15:28:54 <gjanssens> Ok, it's a mess no matter how we turn it. While bash may handle it properly gcc does not. So configure fails already while testing gcc.
15:31:59 <jralls> So we need to teach cmake to recognize the MSYS-style paths.
15:41:54 <gjanssens> That looks like the best path forward indeed.
15:42:34 <gjanssens> I have tried several variations using c:/... c:\\... and c:\\\\... as basedir in jhbuildrc
15:43:30 <gjanssens> The first breaks gcc, the second causes configure not to be found and the last works to find configure but it aborts with an error about unsafe srcdir
15:43:51 <gjanssens> What an incredibly fragile build system that is, autotools...
15:44:59 *** RandomGuyOnIrc has joined #gnucash
15:44:59 *** ChanServ sets mode: +v RandomGuyOnIrc
15:45:33 <jralls> Well, this time around it's CMake that's being fragile.
15:45:43 <RandomGuyOnIrc> When I create a new account, an opposite charge goes to my Imbalance account. How can I change that to Opening Balances?
15:45:48 <gjanssens> In a way indeed
15:46:54 *** pohly1 has quit IRC
15:47:08 <gjanssens> RandomGuyOnIrc: what do you mean exactly ? Do you set an opening balance in the new account window and that is charged to your Imbalance Account ?
15:47:41 <gjanssens> Or do you create an opening balance in the register afterwards and that gets posted to an Imbalance account ?
15:49:01 <RandomGuyOnIrc> I create a new account
15:49:08 <RandomGuyOnIrc> I do an initial entry
15:49:29 <RandomGuyOnIrc> In the transfer columnt, if I don't change anything, it goes to the imblance account
15:49:42 <RandomGuyOnIrc> I have to manually specify, Equity:Opening Balances
15:49:46 <gjanssens> RandomGuyOnIrc: you have to set the transfer column
15:50:06 <RandomGuyOnIrc> Yes, I have to reset it
15:50:14 <gjanssens> If you want to skip that for opening balances, you can set the opening balance while creating the account, on the second tab
15:50:19 <RandomGuyOnIrc> If I don't set it, it goes to Imbalance
15:50:26 <RandomGuyOnIrc> thanks
15:50:29 <RandomGuyOnIrc> I will do that
15:50:41 <gjanssens> For gnucash an opening balance transaction is just a transaction as any other.
15:51:04 <gjanssens> It won't automagically treat your first transaction as an opening balance.
15:51:21 <gjanssens> The tab on the new account window serves as a convenience shortcut.
15:52:31 <gjanssens> jralls: it depends of course which bit we define as 'fragile'
15:53:03 <gjanssens> Requiring include paths in IMPORTED dependencies to exist is a bit overcautious indeed
15:53:49 <gjanssens> However on Windows it doesn't really need a unix like environment that autotools does
15:54:06 <gjanssens> I like that actually
15:55:12 <gjanssens> Unfortunately not all of our dependencies we build ourselves can do without an all encompassing bash environment
15:55:44 <jralls> That would be fine as long as it could tell when it was in a MinGW/Cygwin environment and when not and behave appropriately. As it is it insists on native windows behavior and requires a bunch of hoop-jumping to work with MinGW.
15:56:03 <gjanssens> True
15:56:36 <gjanssens> Eh, to work within msys
15:56:43 <gjanssens> not mingw
15:56:58 <gjanssens> Whatever
15:57:23 <jralls> Cygwin, really. MSYS and MSYS2 are just limited versions of Cygwin.
15:57:34 <gjanssens> Ok
15:57:45 *** Mechtilde has quit IRC
15:58:02 *** Mechtilde has joined #gnucash
16:01:04 <jralls> This sheds a little light: https://gitlab.kitware.com/cmake/cmake/issues/18980
16:02:24 *** Mechtilde has quit IRC
16:08:37 *** gour has quit IRC
16:11:53 <gjanssens> That suggests we should switch to msys2-cmake rather than mingw-cmake given we build several dependencies strictly for msys2
16:16:18 <jralls> It does, so I'm trying that now. It didn't like "MSYS Makefiles" so I removed that. Now it doesn't recognize WIN32 so it went looking for the wrong webkit.
16:23:27 <gjanssens> Sigh...
16:25:58 <CarwynNelson> is the trouble you guys are having now mostly around getting dependencies in order? Or is it more complicated than that?
16:26:48 <jralls> gjanssens, that was fixed by changing WIN32 to MINGW.
16:27:17 <gjanssens> CarwynNelson: it's more complicated than that
16:27:59 <gjanssens> We know our dependencies. The issue is that pathnames use different conventions on Windows and linux
16:28:17 <jralls> CarwynNelson: It's because I changed a bunch of pkg config packages from using the variables ${FOO_INCLUDE} and ${FOO_LIBS} to PkgConfig::Foo by telling pkg_check_modules IMPORTED_TARGET.
16:28:20 <gjanssens> And some of our dependencies can't be built directly on Windows becasue of that
16:28:34 <jralls> Works great on Unix, not so much on MinGW-w64.
16:29:00 <gjanssens> So they're built in a unix like environment on Windows, called MSys2
16:29:09 <gjanssens> That uses unix like pathnames
16:29:17 <CarwynNelson> Ah, right. The only reason I asked is because I did a small bit of research into vcpkg and found that the majority of packages were available in vcpkg.
16:29:36 <gjanssens> Turns out it's tricky to mix tools from both environments
16:31:10 <gjanssens> CarwynNelson: a quick glance at their ports directory suggests they have about the same set of dependencies we also get from the Mingw64 project.
16:31:55 <gjanssens> Missing from there are for example gwenhywfar, aqbanking, guile2
16:32:11 <gjanssens> All 3 need the msys2 environment to be built on Windows currently
16:32:33 <CarwynNelson> Is there a general theme that makes them require msys2?
16:32:50 <gjanssens> Yes, they require a unix like environment
16:33:11 <gjanssens> In particular they can only handle unix like path names during build.
16:33:42 <gjanssens> So they choke on paths like c:/gcdev64 or -heaven forbid- c:\gcdev64
16:34:18 <gjanssens> They also typically need a bash shell to run their configure and build scripts
16:35:30 <gjanssens> jralls: small shift of gears: I'm about to make swig wrapper generation a mandadory build step on master
16:35:45 <gjanssens> Any objections since we last discussed this a while back ?
16:36:51 <jralls> Ok. No objections, just make sure that the release tarballs still build!
16:37:32 <gjanssens> Right :)
16:37:57 <gjanssens> I'll do the distcheck thing before committing
16:39:03 <gjanssens> BTW the dependency tracking on the swig wrappers is probably cause by us not explicitly setting the wrapped header files as dependencies.
16:39:28 <gjanssens> For C(++) cmake tracks these automatically, for swig we have to do it ourselves I guess
16:47:40 <jralls> Maybe. I'll experiment with that later, after I get cmake beaten into submission--or punt and revert the IMPORTED_TARGET commits.
16:53:21 <gjanssens> Ok. Though it would even be better if we could leverage the built-in c tracking. Otherwise we'd need to recursively go through all include files and keep on doing so with every new header include.
16:53:29 <gjanssens> BTW distcheck still works fine.
16:57:18 <jralls> It's not built-in tracking, every C target gets a list of headers and sources. Those plus the linked library targets are its dependencies.
16:58:54 <jralls> We just need to do the same for Swig targets, and modify our macro a bit to deal with that.
17:07:51 <gjanssens> I'm not sure of this. If one header file includes another one we don't explicitly add this to our dependency lists yet cmake knows about changes in the included include.
17:08:02 <gjanssens> Anyway, food for thought for another day.
17:08:08 <gjanssens> I'm off for the night.
17:08:13 <gjanssens> Bye!
17:08:33 <jralls> G'night!
17:09:00 *** gjanssens has quit IRC
17:11:13 *** CarwynNelson has quit IRC
17:20:10 *** PeterAxup has quit IRC
18:19:45 *** mohave has joined #gnucash
18:19:57 *** mohave_ has joined #gnucash
18:31:09 *** mohave has quit IRC
18:31:09 *** mohave_ has quit IRC
18:33:13 <RandomGuyOnIrc> I want to write a program that will loop through all of my accounts, determine whether it is an asset, liability, income or expense, and print it in a particular order. What is the best language to do this?
18:33:37 <RandomGuyOnIrc> Should I use the C API or is there a Python wrapper?
18:33:45 <RandomGuyOnIrc> or Guile or something?
18:36:46 <RandomGuyOnIrc> I am stepping away
18:36:49 <RandomGuyOnIrc> back later
19:06:54 <jralls> RandomGuyOnIrc: There are python bindings.
19:09:20 <jralls> RandomGuyOnIrc: And Guile bindings if you're so inclined, but IIRC the session code isn't exported to Guile so you'd have to do that from C, at which point you might as well do it all from C.
19:30:32 *** frakturfreak has quit IRC
19:46:36 *** mohave has joined #gnucash
19:46:48 *** mohave_ has joined #gnucash
20:19:51 *** oozer has quit IRC
20:30:53 <RandomGuyOnIrc> jralls: thanks
20:31:48 <RandomGuyOnIrc> Perchance do you know where there is a good tutorial for C and or Python? Somthing that reads the data from the compressed xml file, loops through all accounts and prints the balance on a certain day?
20:33:03 <jralls> There is no tutorial. There's example code in the tests in bindings/python and there's API documentation for C at https://code.gnucash.org/docs/MAINT.
20:33:27 <RandomGuyOnIrc> Thanks
20:34:19 <jralls> np
20:40:40 <RandomGuyOnIrc> jralls I found this : /usr/share/doc/python-gnucash/examples/
20:40:51 <RandomGuyOnIrc> there are a lot of gziped python examples there
20:48:02 <RandomGuyOnIrc> It feels so good to see software work
21:18:05 *** mohave has quit IRC
21:18:05 *** mohave_ has quit IRC
21:26:37 *** JayC has quit IRC
23:12:57 *** Aussie_matt has joined #gnucash
23:21:29 *** jervin has joined #gnucash
23:24:47 *** jervin has quit IRC