2019-06-13 GnuCash IRC logs

00:14:29 *** fell has quit IRC
00:14:53 *** fell has joined #gnucash
00:14:53 *** ChanServ sets mode: +o fell
00:15:27 *** boldstripe has quit IRC
00:16:29 *** boldstripe has joined #gnucash
00:26:42 *** marusich has joined #gnucash
00:26:42 *** ChanServ sets mode: +v marusich
00:57:30 *** puck has quit IRC
01:02:59 *** warlord has quit IRC
01:04:41 *** warlord has joined #gnucash
01:04:44 *** puck has joined #gnucash
01:04:59 *** gncbot sets mode: +o warlord
01:05:53 *** warlord has quit IRC
01:05:54 *** warlord has joined #gnucash
01:05:54 *** gncbot sets mode: +o warlord
01:06:25 *** warlord has quit IRC
01:06:34 *** warlord has joined #gnucash
01:06:34 *** gncbot sets mode: +o warlord
01:09:47 <fell> chris should we update the link https://www.scheme.com/tspl2d/ to https://www.scheme.com/tspl4/ ?
01:13:50 *** fell has quit IRC
01:15:09 *** fell has joined #gnucash
01:15:09 *** ChanServ sets mode: +o fell
01:18:23 *** Mechtilde has quit IRC
01:18:30 *** storyjesse has joined #gnucash
02:16:07 *** boldstripe has quit IRC
02:17:02 *** boldstripe has joined #gnucash
02:42:07 *** gjanssens has joined #gnucash
02:42:07 *** ChanServ sets mode: +o gjanssens
02:46:08 <gjanssens> .
02:51:13 *** boldstripe_ has joined #gnucash
02:51:27 *** boldstripe has quit IRC
02:51:27 *** boldstripe_ is now known as boldstripe
02:58:34 *** fabior has joined #gnucash
03:00:35 *** Aussie_matt has quit IRC
03:02:23 *** Aussie_matt has joined #gnucash
03:07:48 *** AdrianoKF has joined #gnucash
03:07:49 *** ChanServ sets mode: +v AdrianoKF
03:08:09 *** marusich has quit IRC
03:15:39 *** AdrianoKF has quit IRC
03:20:24 *** AdrianoKF has joined #gnucash
03:22:16 *** AdrianoKF has quit IRC
03:22:25 *** AdrianoKF has joined #gnucash
03:24:51 *** ChanServ sets mode: +v AdrianoKF
03:45:37 *** Aussie_matt has quit IRC
04:16:48 *** boldstripe has quit IRC
04:17:44 *** boldstripe has joined #gnucash
04:39:26 *** warlord has quit IRC
04:39:37 *** warlord has joined #gnucash
04:39:38 *** gncbot sets mode: +o warlord
04:45:38 *** Aussie_matt has joined #gnucash
05:02:14 *** fabior has quit IRC
05:03:07 *** fabior has joined #gnucash
05:23:14 *** fabior has quit IRC
05:34:42 *** fabior has joined #gnucash
05:52:11 *** storyjesse has quit IRC
05:59:06 <chris> fell: if you like, tspl is rather dense and difficult to follow; i learned from SICP, HtDP, racket tutorials, TLS
06:00:04 <chris> also change hello-world.scm if you like... beware strings changes
06:00:40 *** fabior has quit IRC
06:01:10 <chris> gjanssens: I think I'll unexport some exported functions from report(-core).scm -- there's a couple scheme-generators I'd like to remove but haven't been able to yet... when I finally manage it'll be easier to delete these ugly functions
06:02:04 <chris> ^ in master
06:07:08 <chris> moreover macros tutorial in racket guide is miles ahead of guile's
06:11:38 *** dantob has joined #gnucash
06:17:28 *** boldstripe has quit IRC
06:18:25 *** boldstripe has joined #gnucash
06:22:01 *** oozer has joined #gnucash
06:29:58 *** fabior has joined #gnucash
06:33:32 *** fabior has quit IRC
06:39:00 *** Jimraehl1 has joined #gnucash
06:39:39 *** Jimraehl1 has left #gnucash
06:40:46 <chris> report.scm was not exporting the ugly functions, so, ignore above msg
06:46:48 *** shoonya has joined #gnucash
06:56:09 <gjanssens> chris: no, np
07:15:09 *** warlord has quit IRC
07:15:09 *** warlord has joined #gnucash
07:15:09 *** gncbot sets mode: +o warlord
07:22:52 *** jervin has joined #gnucash
07:28:30 *** jervin has quit IRC
07:44:47 *** jervin has joined #gnucash
07:44:51 *** Mechtilde has joined #gnucash
07:53:56 * chris giving up on macro
08:08:56 <chris> test-graphing.scm upgraded but still not in CMakeLists; so, no more jqplot report in master
08:25:55 *** jervin has quit IRC
08:44:46 *** fell has quit IRC
08:44:54 *** fell has joined #gnucash
08:44:54 *** ChanServ sets mode: +o fell
09:03:30 *** shoonya has quit IRC
09:12:03 *** AdrianoKF has quit IRC
09:12:40 <fell> chris, can you send me an email (via gnucash-devel) with the full URLs and your estimation (pro/cons) of the books? Then I can try to incorporate them in the different components of our documentations.
09:13:43 <chris> you want my review of each book?
09:13:58 <fell> If possible
09:14:53 <fell> and what did you mean with "beware strings changes"?
09:15:52 <chris> changing translated strings in hello-world causes translator burden
09:18:14 <fell> Yes, but the outdatet link should be replaced. We should separate it from the rest of the sentence by changing it to a parameter.
09:19:02 <chris> what does the string currently say
09:19:15 <fell> BTW, I came there because I saw a few untranslated strings.
09:19:20 <chris> ah tspl
09:20:22 <fell> "You can learn more about writing scheme at &lt;https://www.scheme.com/tspl4/"
09:20:24 <fell> "&gt;."
09:21:01 <fell> would be the simple update of the book
09:24:39 *** boldstripe has quit IRC
09:25:27 *** boldstripe has joined #gnucash
09:36:39 *** Aussie_matt has quit IRC
09:43:06 *** jervin has joined #gnucash
09:49:45 *** kael has joined #gnucash
09:49:45 *** ChanServ sets mode: +v kael
09:59:27 *** kael1 has joined #gnucash
09:59:27 *** kael has quit IRC
09:59:27 *** kael1 is now known as kael
09:59:27 *** ChanServ sets mode: +v kael
10:00:48 *** kael has quit IRC
10:00:50 *** kael has joined #gnucash
10:00:51 *** ChanServ sets mode: +v kael
10:04:35 *** kael has quit IRC
10:04:38 *** kael has joined #gnucash
10:04:39 *** ChanServ sets mode: +v kael
10:07:05 *** jervin has quit IRC
10:07:40 *** jervin has joined #gnucash
10:15:09 *** boldstripe_ has joined #gnucash
10:15:23 *** boldstripe has quit IRC
10:15:23 *** boldstripe_ is now known as boldstripe
10:16:35 *** jervin has quit IRC
10:22:11 *** storyjesse has joined #gnucash
10:44:20 *** dantob has quit IRC
11:13:06 *** fabior has joined #gnucash
11:21:22 *** ArtGravity has joined #gnucash
11:21:23 *** ChanServ sets mode: +v ArtGravity
11:21:35 *** Mechtilde has quit IRC
11:25:42 *** shoonya has joined #gnucash
11:47:05 *** Grav has joined #gnucash
11:48:14 *** ArtGravity has quit IRC
11:54:27 *** O01eg has joined #gnucash
11:58:07 *** warlord has quit IRC
11:58:54 *** warlord has joined #gnucash
11:58:56 *** gncbot sets mode: +o warlord
11:59:27 *** warlord has quit IRC
11:59:49 *** warlord has joined #gnucash
11:59:50 *** gncbot sets mode: +o warlord
12:03:18 *** guak has joined #gnucash
12:15:44 *** shibu has joined #gnucash
12:24:57 *** calvinct has joined #gnucash
12:44:01 *** Cuare has joined #gnucash
12:44:03 *** ChanServ sets mode: +v Cuare
12:50:34 *** jervin has joined #gnucash
12:51:00 *** calvinct has quit IRC
12:53:21 *** calvinct has joined #gnucash
12:54:15 *** fabior has quit IRC
12:54:53 *** jervin has quit IRC
12:58:07 *** Mechtilde has joined #gnucash
13:04:52 *** calvinct has quit IRC
13:06:25 *** calvinct has joined #gnucash
13:09:35 *** calvinct has quit IRC
13:17:51 *** calvinct has joined #gnucash
13:23:00 *** Cuare has quit IRC
13:23:25 *** calvinct has quit IRC
13:23:44 *** Grav has quit IRC
13:26:53 *** Grav has joined #gnucash
13:32:17 *** calvinct has joined #gnucash
13:49:54 *** Grav has quit IRC
13:50:16 <jralls> warlord, gjanssens, it just occurred to me that we should remove all of the yahoo price sources from the drop-down lists. We could also filter them out before passing the list to gnc-fq-helper and put up a dialog box saying which securities we're not going to retrieve and why.
13:54:40 <warlord> jralls, I dont understand why F::Q doesn't just remove the broken sources.
13:54:53 <warlord> But yes, we could filter out known bad sources.
13:54:57 <gjanssens> Are all json sources broken these days ?
13:55:05 <jralls> erik hasn't had time to do a release in over a year.
13:55:06 <gjanssens> Eh Yahoo
13:55:19 <gjanssens> So also yahoo-json ?
13:55:45 <jralls> All except yahoo-json. They're technically not broken: Verizon discontinued the service.
13:55:52 <warlord> Yahoo-JSON works and should be kept
13:57:42 <jralls> The service being providing the quotes as CSV; the F::Q yahoo modules rely on that instead of screen-scraping, so it would be possible to restore yahoo sources by converting them to screen-scraping.
13:59:27 *** storyjesse has quit IRC
14:00:03 <gjanssens> Right, but unless that's fixed in F::Q I agree it would be best to remove them from gnucash dropdown lists
14:02:43 <jralls> Eh, looks like they're already removed from the hardcoded lists, but since gnc-fq-check reports them they get added in as "unknown".
14:02:45 *** shoonya has quit IRC
14:09:08 <gjanssens> jralls: other topic, should we continue the report changes discussion here for a bit more direct interaction ?
14:09:18 <jralls> Sure.
14:09:50 <gjanssens> So what part about the auto report detection and loading do you dislike ?
14:09:57 <warlord> So maybe gnc-fq-check should stop reporting them?
14:12:11 <jralls> gjanssens: That it seems to operate as a side effect of use-modules.
14:12:35 *** calvinct has quit IRC
14:13:04 <jralls> warlord: gnc-fq-check just gets the list from F::Q. We can filter the list at gnc-fq-check or in gnc_quote_source_add_new.
14:14:12 <warlord> jralls, w.r.t. report loading, searching the directory and loading all the reports there was specifically added. Whether it's done via use-modules or load-from-file is, IMHO, irrelevant. But being able to place a report in the correct directory have have it auto-load is, IMHO, a feature.
14:14:18 <jralls> And FWIW the Yahoo sources have been remove from F::Q git, so the problem is that Erik hasn't done a release in a long time. The Alphavantage throttling is in the same bucket.
14:14:22 <gjanssens> Ok. It appears most of the guile modules operate that way at least partly.
14:14:27 <warlord> jralls, w.r.t. quotes, I think it might be easier to change gnc-fq-check ;)
14:15:18 <warlord> (but I dont care where it happens)
14:16:59 *** Mechtilde has quit IRC
14:17:07 <jralls> gjanssens: Maybe because most of the guile modules are reports. ;-) But the modules that expose API and are loaded explicitly with use-modules and add their exported API to the namespace as functions that can be called. That's my understanding of the intended use of modules.
14:18:42 <jralls> warlord: In some ways it's a feature, but loading and automatically executing code from arbitrary files in an uncontrolled directory is an excellent way to get a CVE.
14:18:47 <gjanssens> Well, you typed faster than I could do my research...
14:19:24 <gjanssens> I wanted to add I don't generally think it should be that way, I just didn't invent it. It was there.
14:19:56 <gjanssens> Another example is app-utils.scm, which loads business-prefs.scm and that file ends with a function call.
14:20:14 <warlord> jralls, it's not an uncontrolled directory -- it's a system directory that is "owned" by gnucash. Someone could just as easily overwrite one of gnucash's existing .scm files.
14:20:33 <gjanssens> You could see these things as what a class constructor does in C++, though less formally defined as such
14:21:28 <gjanssens> Wrt to the CVE risk, we have worse offenders like config-user.scm which allows a user to run any arbitrary code.
14:21:57 <jralls> warlord: The user's gnucash config directory isn't controlled.
14:22:10 <jralls> gjanssens: Indeed we do.
14:23:03 <gjanssens> It occurred to me recently that if we want to continue support that we should implement a security level mechanism like libreoffice does.
14:23:22 <gjanssens> By default no uncontrolled or unsigned sources would be allowed
14:23:31 <jralls> gjanssens: And worse, both allow anyone who can gain write access to the user's home directory to run arbitrary code.
14:23:44 <gjanssens> I know very well.
14:24:09 <gjanssens> Though I'm not sure what you mean with "both"
14:24:12 <warlord> I think that is a bigger issue indeed. But again, someone with write access to a user's directory could just overwrite their .bashrc
14:25:09 *** Mechtilde has joined #gnucash
14:25:48 <jralls> If a module contains code outside of a function and use-modules runs that code, then *anything* loaded by use-modules will run arbitrary code. Just because gnucash thinks it's a report doesn't force it to behave like one.
14:26:23 <gjanssens> And given my real life time constraints I do like to box the amount of changes I should implement before the report fixups can be merged.
14:26:32 <jralls> And IIRC the report loading code also looks in the user's gnucash directory for reports.
14:26:40 <gjanssens> No it doesn't
14:26:56 <gjanssens> I have thought of implementing this, but so far didn't do so
14:27:02 <jralls> Oh? Then how does a user load a custom report?
14:27:28 <gjanssens> The user has to explicitly add a (load "path-to-report") in config-user.scm
14:27:51 <gjanssens> So we're back at the "worse offender" I pointed out.
14:27:56 <jralls> Ah, so it's only one hole, not two.
14:28:01 <gjanssens> Yes
14:28:33 <gjanssens> Anyway we can't possible solve this unless we involve the user while running gnucash or add a trust system using signed code
14:30:19 <gjanssens> The poor man's approximation is to disable it by default and only allow it after setting a system level preference (that is one only an admin can set)
14:30:57 <gjanssens> That would mitigate the risk for most users and still allow those that really choose to live with that risk to load their own custom reports.
14:31:37 <gjanssens> Still more than I have time for right now.
14:31:56 *** jervin has joined #gnucash
14:32:11 <gjanssens> OTOH if you prefer to do the report loading only by explicitly calling a function, that's an easy fix.
14:32:55 <gjanssens> And with that I refer to the code that's currently auto-run on use-modules to scan for gnucash provided reports
14:33:11 <jralls> I prefer that everything be done by explicitly calling a function, so if that's easy, yes please.
14:33:32 <jralls> And BTW I've started on converting the app-utils part of options to C++.
14:33:48 *** shibu has quit IRC
14:33:51 <gjanssens> I'll give it a go. It may have unexpected consequences in a few tests that assume reports are loaded.
14:34:02 <gjanssens> Nice to hear that!
14:34:53 <jralls> Yeah, the report tests look like a problem to me. They seem to work a bit differently from the way the actual reports do so I wonder if they're really testing what they purport to.
14:35:07 <gjanssens> I have always envisioned the end result to be a universal options system in gnucash that does both report options and system/book/user level preferences
14:35:21 <gjanssens> Don't know if that's feasible though
14:36:16 <gjanssens> As for the tests, I don't think they are *that* different in how they do reports. They do load one report at the time individually.
14:36:36 <gjanssens> (And I now have to amend them to load the default stylesheet explicitly in the same way)
14:36:56 <jralls> Hmm, book prefs and report options can work together, but I don't think that anything involving gsettings can store into the book.
14:37:32 <gjanssens> Right, that's why I imagined different options backends, but one public interface
14:38:06 <gjanssens> May be the wrong approach. It's just a high-level idea
14:38:49 *** nikolai has joined #gnucash
14:38:49 *** ChanServ sets mode: +v nikolai
14:39:15 <gjanssens> So now we've cleared out the bit on report loading and what was wrong with it, where should the code go now ?
14:39:25 <gjanssens> One common loader at the report-system level
14:39:37 <gjanssens> With stylesheets and reports in subdirectories of that one ?
14:40:08 <jralls> Conceptually no problem, but the current options system creates the GUI too. Mixing that with the Prefs UI might be hard. Dunno, haven't studied it. I don't think that there's time to do that by December so I'll focus on just straightening out the options part.
14:40:22 <gjanssens> That's fair
14:41:29 <gjanssens> eguile next to report-system at the top-level ?
14:41:45 <jralls> As for stylesheets, reports, and their loader, can't the function go in report-system and be called by html-style-sheets.scm for stylesheets and reports.scm for reports with the files to be loaded in their own directories?
14:41:59 <jralls> eguile, yes.
14:42:19 <jralls> s/loaded in/loaded from/
14:42:46 *** nikolai has quit IRC
14:43:38 <gjanssens> That doesn't make much sense. Loading stylesheets or reports happens only once. Neither htms-style-sheet.scm nor reports.scm are written with that in mind.
14:43:46 <gjanssens> They don't have a run-once bit of code
14:44:22 <gjanssens> The call would have to go somewhere that runs it only once, like in libgncmod-report's init function
14:44:53 <gjanssens> As long as we have gnc-modules we have to follow it's principles.
14:45:16 *** nikolai has joined #gnucash
14:45:16 *** ChanServ sets mode: +v nikolai
14:45:22 *** nikolai has quit IRC
14:45:27 *** nikolai has joined #gnucash
14:46:02 *** ChanServ sets mode: +v nikolai
14:46:34 <jralls> But you have it in mind to axe gncmod-report, right? And there's no libgncmod-report-system, so that wouldn't be the logical place to load the stylesheets.
14:47:09 *** boldstripe has quit IRC
14:47:23 *** nikolai has quit IRC
14:47:26 *** nikolai has joined #gnucash
14:47:42 <gjanssens> It won't be possible yet to axe gncmod-report. At this point I can kill gncmod-stylesheets and possible gncmod-locale-specific
14:47:48 *** ChanServ sets mode: +v nikolai
14:48:03 <jralls> Ah, the intent of outside-of-a-function code in a module file is analogous to python's __init__.py.
14:48:34 <gjanssens> Yes, I meant to write that earlier, but the discussion went another way
14:49:10 <gjanssens> BTW when we are ready to axe gncmod-report, its c code should move to gnome and the initialization should be explicitly done somewhere as well.
14:50:08 <gjanssens> For now there's a bit of report initialization in gnucash-bin.c, but I think it the long run that should move to some init code in the gnome lib (which is not a gnc-module hence no implicit initialization)
14:50:53 *** calvinct has joined #gnucash
14:50:55 <jralls> We need to separate the GUI code and put that in gnome and find another place for not-GUI code. If we don't start unscrambling that we'll never be able to change GUI backends.
14:52:17 *** calvinct has quit IRC
14:52:28 <gjanssens> True. The first step was to eliminate gncmod-report-gnome
14:52:49 <gjanssens> That bit had most of the gui code related to reports and it now lives in gnome
14:53:21 *** JayC has quit IRC
14:53:31 <gjanssens> gncmod-stylesheets has another bit of gui code (adding the stylesheet menu item)
14:53:50 <gjanssens> I moved that bit as well to gnome in my local repo
14:54:38 <gjanssens> In both cases some other part of the code explicitly has to call these features. For now that's gnucash-bin.c simply because that was the only place that had initialization code.
14:55:03 <gjanssens> Reworking gnucash-bin.c is a separate project
14:55:07 <jralls> OK, that sounds reasonable. As long as we're keeping gncmodule, is gncmod-stylesheets a reasonable place to load the stylesheets? What about TXF, those reports need to load the txf bits, right?
14:56:21 <gjanssens> Lastly, gncmod-report depends on gtk to find a default font family. It may be possible to move that bit somewhere else as well.
14:56:48 *** boldstripe has joined #gnucash
14:57:09 <jralls> Another digression: Yes, having all of those modules and dlopening them in gnucash-bin instead of just having shared libs has always bugged me. It's one of the main reasons it takes so long for GnuCash to start. But it's necessary for Guile to be able to see the code, right?
14:57:12 <gjanssens> gncmod-stylesheeds no longer exists in my local repo. I think it's an aweful overhead just to load 5 scm files.
14:57:40 <gjanssens> I don't think it's really necessary for guile to see the code.
14:59:26 <gjanssens> We could just as well directly call load-extension with the shared library as we do here: https://github.com/Gnucash/gnucash/blob/master/gnucash/gnome/report-menus.scm#L35
14:59:47 <gjanssens> The difficulty is mostly in untangling the initialization sequences
15:00:10 * jralls nods.
15:00:11 <gjanssens> The modules have been conceived such that each module always initializes whatever it requires
15:00:34 <gjanssens> If we remove the module glue, we have to move this initialization somewhere else
15:00:44 <gjanssens> And we could even go one step furhter:
15:01:24 <gjanssens> At present each module/shared library links in the swig generated interface specific for that module/libarary
15:02:47 <gjanssens> I now think it's even possible to move this swig interfaces into one separate shared library instead that is simply using the normal shared libary semantics to dynamically link with or normal shared libaries
15:03:38 <gjanssens> That would allow us to seperate these two: one shared lib that acts as guile extension to allow guile scripts to use our C interface
15:03:50 <gjanssens> And another shared lib to be our libgnucash
15:04:27 <gjanssens> And in the end no more sublibs like gncmod-engine, gnccore-utils or gncmod-app-utils and so on
15:05:12 <gjanssens> That's one more project I'm really interested in doing some experiments with, though I fear it won't make our December release
15:05:51 <jralls> Indeed, it sounds like a solid year's work.
15:06:08 * gjanssens nods
15:06:59 <gjanssens> So for now I'll narrow my scope again to the report stuff.
15:07:03 *** ArtGravity has joined #gnucash
15:07:03 *** ChanServ sets mode: +v ArtGravity
15:07:49 <gjanssens> If I find another way to get the default font, report-system is actually gtk free and could theoretically even live in libgnucash
15:07:50 <jralls> Right. So how to init stylesheets and TXF with no corresponding gncmods? Does report-system really need no init?
15:08:09 <gjanssens> The big issue there is of course it's all guile and we don't want that in libgnucash :)
15:09:21 <jralls> That's half of the big issue. The other half is what is libgnucash's target audience outside of GnuCash itself?
15:10:51 <jralls> Do things like options, preferences, and reports belong in libgnucash or should they be on the application side?
15:12:55 <gjanssens> The other potential consumers of libgnucash I imagine are the bindings (python atm, but possible also guile with the addition of a binding initializing routine), the android app and an ios app
15:13:40 <gjanssens> Or even external applications like KMyMoney that would like to implement import/export from/to gnucash
15:14:56 <gjanssens> As for the bindings and mobile apps, I like to believe they would also benefit from the possibility to generate reports. Be it in html or another format such as the csv bits chris is adding.
15:15:41 <gjanssens> And all options or preferences that affect the interpretation of the data would also belong in libgnucash
15:16:02 <gjanssens> Things like that account separator to use for example
15:16:35 <gjanssens> Others could be gui only like the date format used for presentation.
15:17:19 <jralls> At one end of that sepctrum, an import/export facility for KMyMoney would use only the backends. The account separator isn't important since Bob changed the bayes map to use GUIDs.
15:18:40 <gjanssens> That's not the only use of that option. It also defines what character is reserved when creating new accounts. That would be relevant for all consumers
15:18:58 <gjanssens> As for report-system, it does require initialization (I must be careful in choosing my names as on my local branch it's currently the report module)
15:19:14 <gjanssens> You will find it in gncmod-report-system's init function
15:19:54 <gjanssens> And to me it makes most sense to move the initializing bits for stylesheets and reports there.
15:20:43 <nikolai> hello
15:21:10 <nikolai> is it possible to set a currency for a single stock?
15:21:50 <jralls> The stylesheets, certainly. I like separating out the reports.
15:22:21 <jralls> nikolai, the currency for a stock account is the parent asset account's currency.
15:22:28 <nikolai> hmm ok
15:23:33 <jralls> nikolai, so suppose you have most of your stocks in EUR but you have one stock on the LSE in GBP. You need to create a GBP asset account and put the LSE stock account under it.
15:25:16 <gjanssens> jralls: we could of course, though I'm trying to understand what's different between reports and stylesheets for you ?
15:25:24 <gjanssens> Oh
15:25:38 <jralls> ?
15:25:43 <gjanssens> In your model the reports are still outside of the report-system module ?
15:26:32 <gjanssens> In my mental model I brought them back as being part of the report system
15:26:49 <gjanssens> That's option 3 in my last comment on the PR
15:27:10 *** jervin has quit IRC
15:27:20 <jralls> Yes, of course. Reports *use* report-system just like they use engine.
15:27:59 <gjanssens> It's more entangled than that.
15:28:28 <gjanssens> The report-system keeps track of loaded reports as well, so we could just as well say the report system uses reports
15:28:35 *** bertbob has quit IRC
15:28:38 <jralls> But stylesheets are part of report-system, they're used by html-style-sheets.scm. After all, they make sense only after the report is rendered to html.
15:29:11 <jralls> Maybe we need to split out that part of report-system.
15:29:22 <gjanssens> Ouch
15:29:25 <jralls> But maybe that's too much for now.
15:29:29 <gjanssens> Right
15:30:20 <jralls> Sigh, more design debt. It's hard to avoid spaghetti code when you have a spaghetti design. :-(
15:30:21 <gjanssens> Anyway if we want to see it that way, the generic function that can load reports or stylesheets can't be part of the report-system
15:30:59 *** ArtGravity has quit IRC
15:31:17 <gjanssens> It should be higher level as well, and I don't think we have a good spot currently to add such higher level code
15:31:28 <gjanssens> That again would be a candidate to split out the report-system
15:31:36 *** bertbob has joined #gnucash
15:31:37 *** ChanServ sets mode: +v bertbob
15:31:47 <gjanssens> out of*
15:32:27 <jralls> Why not? It just spools through a directory and loads everything it sees in that directory into the current module. How is that different from e.g. gnc:get-exchange-totals?
15:33:21 <gjanssens> So you mean to make it even report-agnostic ?
15:33:41 <gjanssens> And put it in app-utils or something similar ?
15:34:15 <jralls> Noooo! Anywhere but app-utils! ;-)
15:34:57 <gjanssens> Thought so :)
15:35:27 <jralls> More seriously, it should stay in report-system unless there's a use case for using it somewhere else.
15:36:02 <gjanssens> So the only sensible place I see at this point is report-system.scm, which on my local branch is (gnucash report), next to (gnucash reports)
15:37:12 <gjanssens> That way I can invoke it from both gncmod-report-system to load the stylesheets and from (gnucash-reports) to load the reports
15:37:49 <jralls> Right. That's what I had in mind.
15:38:15 <gjanssens> Ok good enough for this round.
15:40:04 <jralls> Very good then.
15:42:29 <jralls> On the matter of app-utils, there's a file simple-obj.scm that's used only in qif-import. Mind if I move it there?
15:45:06 <gjanssens> Not at all
15:50:48 <jralls> Have you ever looked at https://github.com/Gnucash/gnucash/blob/maint/libgnucash/app-utils/guile-util.c? It seems to be wrapping scheme functions for splits in C. But splits are C objects, why would one want to use C to operate on a split that's been converted to Scheme?
15:51:04 <jralls> warlord, do you know anything about that?
15:53:02 <gjanssens> jralls: I have seen that before and was puzzled by it back then.
15:53:33 <gjanssens> I vaguely remember even naively trying to skip those parts but the end result didn't work properly any more.
15:53:40 <jralls> It's only used in ledger-core/split-register.c.
15:53:47 <gjanssens> It's been a while so I don't remember the details
15:54:19 <gjanssens> And perhaps I'd be able to make more sense of it now than I did in the days
15:56:18 <warlord> jralls, sorry, I don't know for sure.
15:57:42 <gjanssens> Bleh, regarding reports and stylesheets, the report loading code is currently hardwired to work from the gnucash/reports directory :(
15:57:53 <gjanssens> Have to modify that bit too then...
15:58:08 <jralls> Eww.
15:58:38 <jralls> Shouldn't be too hard to fix.
16:00:22 <jralls> The (clearly misnamed) guile-utils code is used for the registers' cut/copy/paste functions. Splits are converted to a Scheme representation by cut and copy, then converted back for paste.
16:12:00 *** JayC has joined #gnucash
16:12:01 *** ChanServ sets mode: +v JayC
16:39:11 *** Mechtilde has quit IRC
17:00:37 *** nikolai has quit IRC
17:07:48 <warlord> jralls, I wonder if that was done because of (a belief that?) the cut-buffer can really only contain a single (text?) object?
17:08:15 <jralls> warlod: But an SCM isn't a text object.
17:09:16 <warlord> Is it being stored as a SCM and not a SCM->text?
17:09:53 <warlord> Also remember that the original developers were Schemers, so to them everything was supposed to be written in scheme if possible.
17:26:37 *** gjanssens has quit IRC
17:30:13 <jralls> warlord, as SCM, not text. It's never even sent to the clipboard, it lives in a static SCM in split-register.c.
17:31:31 <warlord> Huh. Interesting.
17:46:59 *** calvinct has joined #gnucash
18:20:51 *** fell has quit IRC
18:23:32 *** fell has joined #gnucash
18:23:32 *** ChanServ sets mode: +o fell
18:29:31 *** Aussie_matt has joined #gnucash
18:30:47 *** calvinct has quit IRC
18:46:33 *** kael has quit IRC
18:48:09 *** ArtGravity has joined #gnucash
18:48:09 *** ChanServ sets mode: +v ArtGravity
19:08:01 *** Unhammer has quit IRC
19:23:31 *** ArtGravity has quit IRC
19:30:40 *** ArtGravity has joined #gnucash
19:30:40 *** ChanServ sets mode: +v ArtGravity
19:42:30 *** jervin has joined #gnucash
19:58:01 *** Unhammer has joined #gnucash
20:38:29 *** oozer has quit IRC
21:29:23 *** Cuare has joined #gnucash
21:29:23 *** ChanServ sets mode: +v Cuare
21:31:44 *** puck has quit IRC
21:37:16 *** guak has quit IRC
21:41:36 *** boldstripe has quit IRC
21:49:35 *** jervin has quit IRC
21:49:51 *** puck has joined #gnucash
22:06:59 *** warlord has quit IRC
22:51:22 *** Grav has joined #gnucash
22:52:32 *** ArtGravity has quit IRC
23:12:10 *** thecat400 has joined #gnucash
23:15:12 *** thecat400 has quit IRC
23:16:05 *** fourhundredthecat has joined #gnucash
23:17:24 *** fourhundredthecat has quit IRC
23:18:08 *** karelk has joined #gnucash
23:21:32 *** karelk has quit IRC
23:22:04 *** karelk has joined #gnucash