2018-10-11 GnuCash IRC logs

00:10:50 *** nate has joined #gnucash
00:12:38 <nate> Hey guys, trying to solve a slow saving bug I saw in bugzilla. But trying to build gnucash with debug symbols on via script (so I dont have to mess with cmake files causing a diff) any thoughts on cmd line switchs for cmake to force it to build with debug symbols turned on (for gdb). Im on ubuntu.
00:14:12 <nate> I've tried "cmake -DCMAKE_BUILD_TYPE=Debug $SRCROOT" (where SRCROOT is an env var pointer to my src path). But this (after a make) didnt produce any symbols for gdb to use
00:19:25 *** Mechtilde has joined #gnucash
00:57:11 *** Mechtilde has quit IRC
01:19:21 *** fell has quit IRC
01:20:14 *** fell has joined #gnucash
01:20:43 *** gncbot sets mode: +o fell
02:23:45 *** gjanssens has joined #gnucash
02:23:46 *** ChanServ sets mode: +o gjanssens
02:24:01 <gjanssens> .
02:27:18 <fell> Hooi!
02:30:24 *** ldir has quit IRC
02:30:52 *** KevinDB has joined #gnucash
02:43:10 *** KevinDB has quit IRC
02:43:35 *** KevinDB has joined #gnucash
02:45:00 *** gour has joined #gnucash
02:52:10 *** fabior has joined #gnucash
03:14:40 <gjanssens> Hey fell
03:14:55 <gjanssens> You were a tad faster than I was in handling Pedro's PR
03:15:08 <fell> Pedro is really quick
03:15:22 <gjanssens> You are clearly getting more comfortable with git :)
03:15:54 <gjanssens> Although I was a bit confused by your remark on git merge vs git rebase.
03:17:01 <gjanssens> While true, the user doesn't always have the choice
03:17:12 <fell> I believe the branching section in the wiki needs a clear explaiation about when to use rebase, merge and cherrypick.
03:17:41 <gjanssens> And the merge commit Pedro got, came from github's pull mechanism
03:18:52 <gjanssens> We really should discourage using it to get a fork in sync with our upstream repos
03:19:17 <gjanssens> I did an experiment earlier this morning, there is just no way to make it do the equivalent of a git pull
03:19:48 <gjanssens> Github's pull mechanism by the way it their Pull Request interface.
03:20:19 <gjanssens> It's ok contributors generate pull requests against our repo, but not the other way around.
03:20:35 <gjanssens> Unfortunately github doesn't have a way of blocking this.
03:20:54 <fell> But when I opened the page, it was referencing "Fix spell error in Russian translation #1"
03:21:14 <fell> That was confusing for me.
03:21:19 <gjanssens> Right I saw that one as well.
03:22:05 <gjanssens> I believe that's a bug in github's webinterface
03:22:20 <KevinDB> I can tell you that on openwrt we pull in github PRs to a local staging git tree and then push to our repo...so that everything is a linear fast-forward rather than merge, merge, mege
03:22:57 <gjanssens> The PR #1 should have referenced the first PR against Pedro's repo, but the webinterface messed up and instead referenced the very first PR against our upstream repo
03:23:17 <gjanssens> KevinDB: indeed that's how we handle PR's as well
03:23:53 <KevinDB> I shall stop teaching to suck eggs then :-)
03:24:12 <gjanssens> Although for big feature changes we do use a merge commit to make it easier to track the feature's origin
03:24:28 <gjanssens> KevinDB: all input is welcome :)
03:25:33 <gjanssens> fell: I wanted to get to the point of explaining that git pull sometimes forces a merge. It would have for Pedro because of the combination of factors I explained in my comment on the PR
03:25:59 <fell> which I am just reading
03:26:39 <gjanssens> Eh, no. I'm mistaken. git pull would have worked for him as you didn't change his PR's history
03:26:58 <fell> BTW, didn't you start a wiki page about using githubs web interface with sunfish?
03:27:34 <gjanssens> Yes, and I should revoke it. I'm wrong about it being a safe way to deal with this.
03:28:11 <gjanssens> The only thing we can do is fork-add commits-generate PR-destroy repo when PR is merged
03:28:17 <fell> It might not be a nice result, but it is an important result.
03:28:49 <gjanssens> Back to my git pull explanation
03:30:11 <gjanssens> If I would have told Pedro to go run git pull in the current state, then his local repo would create a merge commit, because our history diverged from his (we dropped the merge commit and you changed a comment on his commit)
03:32:28 <gjanssens> There are three ways to get out of this depending on the state of the local repo:
03:33:13 <gjanssens> 1. if there's no relevant history left in the local repo, you can just reset it to the upstream history. This is what I proposed in the PR
03:34:54 <gjanssens> 2. if there is local history you want to keep, you have to readd it on top of the upstream history. How to do it depends on the state of the local history.
03:35:44 <gjanssens> 2a. if the local history is clean (only commits that are either already in the upstream history or commits you want to keep) a git rebase is the way to go
03:36:13 <gjanssens> 2b. if local history also has commits you no longer want or conflict with upstream history, git cherry-pick is the last resort
03:37:20 <gjanssens> Now I remember we spoke in the past about trying "git pull --rebase" and that it didn't do as we hoped: it rebased remote history on top of the local branch
03:37:47 <gjanssens> While we almost always want it to be the other way around, we want our local changes to be rebased on top of upstream history.
03:38:17 <gjanssens> Meanwhile I did find a way to do that which I want to share with you: git fetch; git rebase
03:39:37 <gjanssens> git pull is really "git fetch; git merge"
03:43:55 <gjanssens> fell: I am searching for the wiki page where a pure github workflow would be described, but I don't find it.
03:44:02 <gjanssens> Do you know where it is ?
03:45:41 <fell> gjanssens, I am unshure, if you put it in the wiki or wrote it only in the PR.
03:49:23 <fell> At least I see nothing in the 37 pages containing "Github"
03:55:31 *** ncv has joined #gnucash
03:56:22 <fell> It seems, your experiment started in https://github.com/Gnucash/gnucash-docs/pull/110
04:05:41 *** chris has joined #gnucash
04:17:31 *** Aussie_matt has quit IRC
04:32:27 * chris can't wait for jralls' latest benchmarks
04:33:20 <gjanssens> :)
04:41:22 <fell> gjanssens, by intuition I am usually using git fetch; git rebase. :-)
04:42:04 <fell> Are there currently still questions? Else I will be a few hours off.
04:46:20 <gjanssens> fell: good intuition :)
04:46:25 <gjanssens> No more questions your honor
04:47:20 <gjanssens> Fyi this PR https://github.com/Gnucash/gnucash/pull/423 documents my experiment as to why github's "Rebase and merge" is not working
04:50:25 <fell> Rebase is fine only before you publish something to code or github.
04:51:02 <fell> After something is published, it would mean a rewrite of history.
04:53:11 <gjanssens> Exactly
04:57:10 <gjanssens> Except I had hoped that a rebase of commits that don't change parent would be a no-op. Unfortunately that's not the case when crossing repo borders
05:04:21 <fell> So, "fix a typo" can be done on github, but more complex things better not.
05:05:33 <fell> But if nobody of us has time to apply it the users fork is blocked.
05:08:32 <gjanssens> Indeed
05:09:16 <gjanssens> It's the best we can do though as github doesn't offer a clean way to bring an upstream branch up to date in your private fork
05:10:58 <fell> So their "normal" workflow should be pull github/gnucash; push github/$USER
05:11:26 <fell> in their local repo
05:12:47 <gjanssens> The point is this "normal" workflow is too complicated for casual contributors
05:13:16 <gjanssens> We see it over and over again these people get lost in the git concepts
05:13:31 *** fabior has quit IRC
05:13:59 <gjanssens> That's why a lightweight github based workflow would be a good alternative
05:14:15 <gjanssens> But it does use sledgehammer style refresh cycles...
05:15:16 <gjanssens> And githhub won't allow to fork a repo more than once, otherwise that would have been an alternative if users are waiting for a PR to get merged in
05:15:57 <gjanssens> Of course nothing prevents a user to create multiple branches in the same repo to work on multiple PR's at once.
05:16:09 <gjanssens> They would all be based on the same maint commit though.
05:17:35 <gjanssens> And they would all block an update to a more recent base branch
05:17:41 <fell> That's why I think, attach it to bugzilla has might still be easier in some cases.
05:18:04 <gjanssens> So the only use case that really can't be served this way is if the most recent commits on maint are required for the user to continue on an existing PR
05:18:11 *** luwum[m] has quit IRC
05:18:29 <gjanssens> Or in other words where a branch in the fork needs to be rebased on a more recent maint.
05:18:57 <gjanssens> As for the bugzilla patch: how would you create one purely in github ?
05:19:34 <gjanssens> Remember the goal here is to shield users from using any git commands directly
05:19:53 <fell> Good question!
05:21:02 <fell> https://wiki.gnucash.org/wiki/Simple_Patch
05:21:05 <gjanssens> I am curious what gitlab has to offer in this context.
05:21:25 <chris> (on another note there's no more jsc/jsc.h libwebkit compile failure on updated bionic)
05:21:41 <gjanssens> chris: yay
05:21:46 <gjanssens> That's good news
05:22:04 <gjanssens> I want to experiment with gitlab.
05:22:41 <gjanssens> When gnome first announced their migration to that platform we were only looking at what to do with our bugzilla history.
05:24:18 <gjanssens> But I am slowly grasping more of the benefits that drove the gnome folks to this decision.
05:25:03 <gjanssens> It would need some experimentation (which I hope to do at some point)
05:25:41 <gjanssens> I know it also supports forks and online edits. I don't know if it has a way to synch with "upstream" built in though.
05:26:44 <gjanssens> That was just an example of things I'd like to figure out.
05:28:16 <gjanssens> Anyway, got to leave to do some errands
05:28:24 *** gjanssens is now known as gjanssens_afk
05:29:26 <fell> GitLab Denies Service to Crimea, Cuba, Iran, North Korea, Sudan, and Syria. (from https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities)
05:40:27 *** KevinDB has quit IRC
05:43:49 *** KevinDB has joined #gnucash
06:05:41 *** storyjesse has joined #gnucash
06:07:31 *** luwum[m] has joined #gnucash
06:10:41 *** User has joined #gnucash
06:17:48 *** User has quit IRC
06:27:36 *** fabior has joined #gnucash
06:34:42 *** storyjesse has quit IRC
06:35:15 *** storyjesse has joined #gnucash
06:37:28 *** fabior has quit IRC
06:43:29 *** Jimraehl1 has joined #gnucash
06:43:50 *** Jimraehl1 has left #gnucash
06:47:16 *** oozer has joined #gnucash
07:10:14 *** fell has quit IRC
07:10:21 *** gjanssens_afk is now known as gjanssens
07:11:52 *** Aussie_matt has joined #gnucash
07:19:31 <gjanssens> @tell fell I was not thinking of gitlab.com, but of selfhost the opensource community edition, just as gnome does
07:19:31 <gncbot> gjanssens: The operation succeeded.
07:32:48 *** sjamaan has joined #gnucash
07:32:55 <sjamaan> Hi, is the Scheme API documented somewhere?
07:33:18 <sjamaan> I'm having some trouble with the options object I'm generating in my custom report, but I am missing what is going wrong here
07:36:19 <sjamaan> Gnucash tells me "There are no options for this report", but the options generator procedure _is_ invoked (I added a call to DISPLAY in it)
07:36:48 <chris> The scheme API is documented in the C source code :)
07:36:52 <sjamaan> haha
07:36:59 <sjamaan> Also in the Scheme source code
07:37:16 <sjamaan> Is there a way to get a readable representation of an options object? Like an alist or something
07:37:24 <chris> do you have your report published somewhere?
07:37:32 <sjamaan> Not yet, I can paste it if you want
07:37:36 <chris> let me whip out something I've prepared earlier...
07:38:13 <chris> call (gnc:html-render-options-changed options plaintext?)
07:38:35 <chris> plaintext? #t will output as string, #f will output html-text
07:38:40 <chris> paste to pastebin or somewhere
07:39:36 <sjamaan> Is there a way to reload a report? Now I'm quitting and restarting Gnucash all the time
07:39:56 <chris> yups we all had to do this
07:40:43 <chris> until you can generate a report via unit testing... see test-transaction.scm for example which will dump into /tmp/test-trep-*.html and you can view your output using webbrowser
07:41:32 <sjamaan> gnc:html-render-options-changed is undefined
07:41:54 <sjamaan> I'm on Gnucash 2.6.15 (Debian)
07:42:26 <chris> hmm it's time to upgrade, much has improved since then
07:42:32 <sjamaan> https://paste.call-cc.org/paste?id=7bbde1865bf7ab3548e79f9b29a38b53b882a01b
07:42:56 <sjamaan> ^ that's the report. It's just a stripped-down version of the shipped income&expenses report
07:44:55 <sjamaan> Crap, looks like some formatting issues
07:45:08 <chris> lots wil have changed between 2.6.15 and 3.3
07:45:33 <sjamaan> Upgrading isn't really an option for me right now
07:46:41 <chris> then copy&paste the functions somewhere and experiment https://github.com/Gnucash/gnucash/blob/maint/gnucash/report/report-system/html-utilities.scm#L819
07:49:11 <sjamaan> The options object seems to be empty
07:49:23 <sjamaan> What the hell
07:50:23 <chris> note this gnc:html-render-options-changed will only dump 'changed' options
07:50:30 <sjamaan> Oh right
07:50:48 <sjamaan> *duh*
07:51:01 <chris> you'll need to change L853 to (if #t (addto! ...))
07:51:22 <sjamaan> yup
07:51:33 <sjamaan> I just lifted the addto! expression
07:51:52 <sjamaan> What is addto!
07:51:58 <sjamaan> It is undefined
07:52:05 <chris> macro...
07:52:12 <sjamaan> Is it (set! foo (cons bar foo))?
07:52:19 <chris> yea
07:53:05 <sjamaan> ok, it shows output
07:53:14 <sjamaan> But still it claims there are no options defined
07:53:32 <chris> well then bug somewhere
08:14:07 <sjamaan> Interestingly, the options seem to exist; the renderer will fail if I comment out some options in the options-generator
08:15:03 *** User has joined #gnucash
08:32:48 *** oozer has quit IRC
08:46:00 <warlord> sjamaan: are you returning the options object?
08:46:14 <sjamaan> yes
08:50:29 *** boldstripe has joined #gnucash
08:51:55 <sjamaan> warlord: The strange thing is, the report renderer can read the options just fine from the options object
08:51:57 *** Aussie_matt has quit IRC
08:52:12 <sjamaan> For some reason the UI thinks these options are not configurable or something like that
08:58:11 <boldstripe> I cannot resize Gnucash 3.3 to half screen width in Debian 10 (buster). I am pretty sure I could do this with 3.2. Also, consequently, 'Super+LR arrow' does nothing, although it should resize window to half screen width.
08:59:43 <boldstripe> (manual adjust cannot make window less than about 60% wide)
09:01:46 <warlord> sjamaan: a quick glance at the code and it LOOKS okay, so I'm not sure why you're getting errors about no options.
09:02:00 <sjamaan> Looks like the C code just calls gnc:report-options
09:02:45 <sjamaan> This is too weird
09:04:04 <sjamaan> Is there any type of caching involved anywhere regarding reports or options?
09:04:34 <warlord> Oh... Why did you define the 'options-generator parameter the way you did?
09:05:06 <sjamaan> It's a copy of the shipped standard barchart report
09:05:40 <sjamaan> I didn't want to completely overhaul it
09:05:54 <warlord> Which barchart?
09:06:15 <sjamaan> scm/gnucash/report/standard-reports/category-barchart.scm
09:06:55 <sjamaan> I already simplified it a bit, maybe I messed up there
09:07:26 <warlord> Yeah, take a look instead at, say, the cashflow-barchart report
09:07:39 <warlord> It ends like this:
09:07:42 <warlord> (gnc:define-report
09:07:42 <warlord> 'version 1
09:07:42 <warlord> 'name reportname
09:07:42 <warlord> 'report-guid cashflow-barchart-uuid
09:07:42 <warlord> 'menu-tip (N_ "Shows a barchart with cash flow over time")
09:07:43 <warlord> 'menu-path (list gnc:menuname-income-expense)
09:07:45 <warlord> 'options-generator cashflow-barchart-options-generator
09:07:47 <warlord> 'renderer cashflow-barchart-renderer)
09:08:21 <warlord> The issue is that you're passing the wrong API into the report engine.
09:08:31 <sjamaan> It's a thunk, isn't it?
09:08:34 <sjamaan> So is mine
09:08:42 <warlord> Yes, but it's a thunk with the wrong API
09:08:51 <sjamaan> What do you mean?
09:09:21 <sjamaan> Mine's wrapped in (lambda () ...), so it's the same interface
09:10:01 <warlord> the report code takes your options-generator thunk and calls it with 3 paramters.
09:10:11 <warlord> No, it's not, because your lambda doesn't take any parameters.
09:10:28 <warlord> well, it is.. but it means the report system can't tell the options generator what to do.
09:10:36 <warlord> Because you're always ignoring it
09:11:01 <sjamaan> That's the intention
09:11:20 <warlord> So you never want the user to be able to modify the options?
09:11:37 *** kael has joined #gnucash
09:11:55 <sjamaan> ?
09:12:00 <warlord> How about removing the lambda first ...
09:12:04 <warlord> Simplify
09:12:59 <sjamaan> I can lift the account-types definition up, if that's what you mean
09:13:22 <warlord> The category barchart is a generic report; so yes, there are lots of thunks that get defined because there are lots of different reports that are built from that one script.
09:14:41 <warlord> Nevermind -- too early in the day here and my tea hasn't kicked in..
09:15:19 <warlord> I looked more closely at the cashflow report; the options generator doesn't take parameters, and the renderer only takes one. So... nevermind.
09:15:35 <sjamaan> OK, thank god I'm not losing it :)
09:15:45 <warlord> No, it's not you, it's me.
09:16:18 <sjamaan> I did remove the options to the options generator so it's now a thunk, but that didn't help (as expected)
09:17:24 <warlord> You do need the lambda there, based on how your options-generator method is defined. BUT you could always just simplify the options-generator itself (again, look at the cashflow barchart)
09:17:37 <warlord> Those parameters don't need to be parameterized.
09:17:48 <warlord> ... because you're only defining one report.
09:17:57 <warlord> (unless your intention is to define multiple reports eventually??)
09:18:29 <sjamaan> No, I just want the one report for now
09:18:44 <chris> just out of interest, why is upgrading not an option?
09:18:49 <warlord> Then you can (and probably should) de-parameterize both the options-generator and renderer
09:19:01 <sjamaan> chris: I don't want to mess with the packages on my stable system
09:19:14 <chris> ok
09:19:52 <chris> some ppl had success with flatpak like docker
09:20:08 <sjamaan> Current version: https://more-magic.net/temp/fixed-costs.scm
09:20:25 <sjamaan> (the pastebin had some issues with HTML escapes... Reported it to its author)
09:20:49 <chris> i can't help with your report ... i'd slowly shave down options until something works then build up slowly
09:21:57 <chris> could anything be due to guile vs chicken syntax?
09:22:53 <sjamaan> Not very likely, I've just copied the existing report and tweaked it a bit
09:24:01 <sjamaan> I narrowed it down!
09:24:02 <sjamaan> (gnc:options-add-account-levels!
09:24:02 <sjamaan> options gnc:pagename-accounts optname-levels "c"
09:24:02 <sjamaan> (N_ "Show accounts to this depth and not further.")
09:24:02 <sjamaan> 10)
09:24:08 <sjamaan> ^ that causes the options to die
09:25:08 <warlord> I think 10 is too high
09:25:10 <sjamaan> aha, the max level shown in the dialog is 6
09:25:14 <warlord> Try making it '2'
09:25:17 <sjamaan> But I wouldn't expect it to fail like _that_
09:25:39 <chris> haha
09:25:42 <warlord> LOL
09:25:44 <sjamaan> Jesus, that was it
09:26:12 <sjamaan> The failure mode of some of these things should really be improved XD
09:26:14 <chris> lots of dumb code hiding
09:26:20 * chris is trying
09:27:45 <warlord> Glad you figured it out.
09:28:18 <chris> sjamaan should have read the documentation... aka options.scm lol
09:28:30 <sjamaan> :)
09:29:32 <chris> good luck... and if you update to 3.3 one day there are many api changes
09:30:27 <sjamaan> *glp*
09:30:44 <sjamaan> Oh well
09:30:54 <sjamaan> This is only my second custom report
09:31:01 <sjamaan> So it should not be much work to port the two
09:31:25 *** fabior has joined #gnucash
09:51:48 *** ncv_ has joined #gnucash
09:53:00 *** ncv has quit IRC
10:10:51 *** fabior has quit IRC
10:24:30 <sjamaan> Looks like my report is doing what it should
10:24:35 <sjamaan> Thanks for the help, folks!
10:29:51 <warlord> sjamaan: yay.
10:29:53 <warlord> glad it's working
10:29:57 <sjamaan> Me too
10:30:14 <sjamaan> It's probably completely iffy from an accounting perspective but it seems to do what I need
10:30:35 <sjamaan> Perhaps some day I'll clean it up a bit and publish it
10:33:12 <sjamaan> Anyone ever considered adding a REPL window to GNUCash? That would help quite a bit with defining reports and reloading them
10:34:05 *** mohave has joined #gnucash
10:34:29 <warlord> There was at one point a hook that would allow re-loading a report. The problem is that due to the way guile works it's possible to retain old environments.
10:35:13 <chris> https://wiki.gnucash.org/wiki/Custom_Reports#Command_line_access_to_the_API
10:36:35 *** fabior has joined #gnucash
10:38:02 <sjamaan> chris: That's not quite the same as just having a repl available in a standard build :)
10:40:01 <chris> well it was the best i could find :)
10:49:27 *** chris has quit IRC
10:59:54 *** chris has joined #gnucash
11:02:42 *** zipppy has quit IRC
11:12:42 *** boldstripe has quit IRC
11:13:43 *** boldstripe has joined #gnucash
11:15:31 *** zipppy has joined #gnucash
11:24:13 *** mohave has quit IRC
11:26:30 *** oozer has joined #gnucash
11:31:53 *** jerryq has quit IRC
11:36:03 *** storyjesse has quit IRC
11:36:29 *** storyjesse has joined #gnucash
11:41:57 *** storyjesse has quit IRC
11:42:26 *** storyjesse has joined #gnucash
11:45:19 *** storyjesse has quit IRC
11:45:20 *** ncv__ has joined #gnucash
11:46:30 *** ncv_ has quit IRC
12:04:20 *** User has quit IRC
12:04:31 *** ArtGravity has joined #gnucash
12:04:59 *** fabior has quit IRC
12:08:50 *** User has joined #gnucash
12:14:26 *** calvinct has joined #gnucash
12:18:31 *** jerryq has joined #gnucash
12:46:37 *** fabior has joined #gnucash
12:55:13 *** ncv__ has quit IRC
12:55:14 *** mohave has joined #gnucash
13:05:06 *** fabior has quit IRC
13:09:57 *** Mechtilde has joined #gnucash
13:14:08 *** mohave has quit IRC
13:17:20 <jralls> warlord: Is there a way programmatically to make bugzilla set GnuCash as the default project? I tried from the admin console and couldn't find a way.
13:19:30 <jralls> gjanssens: I use `git pull --rebase` frequently. It always rebases my local commits on top of the upstream ones. Was your local branch set up to track the remote you rebased from?
13:27:16 *** fabior has joined #gnucash
13:28:23 *** mohave has joined #gnucash
13:30:28 *** Mechtilde has quit IRC
13:30:41 *** Mechtilde has joined #gnucash
13:35:12 <gjanssens> jralls: it's been a while but I think it was
13:35:39 <jralls> That's strange then.
13:35:53 *** kael has quit IRC
13:36:13 <gjanssens> Yeah, I'll recheck next time I am in a situation that needs a rebase
13:36:31 <gjanssens> It has been a while since I tried due to the earlier bad experience.
13:36:39 <jralls> Though if you've merged in a feature branch and not pushed it, rebasing will erase the merge commit.
13:36:42 <gjanssens> Might have been me not understanding what was going on back then.
13:37:04 <jralls> So this wasn't something you did this morning...
13:37:29 <gjanssens> I noticed that too in an experiment this morning (that a local rebase will erase the merge commit)
13:37:42 <gjanssens> That one was new for me.
13:39:23 <jralls> It makes sense if you think about it. That's rebase's basic function, to flatten out merges into a linear history.
13:39:42 <gjanssens> True. It just never occurred to me
13:40:30 *** kael has joined #gnucash
13:42:46 *** calvinct has quit IRC
13:47:08 <jralls> chris: 46 seconds for weighted average, 6 for average cost. A 10x improvement!
13:49:20 <warlord> jralls: I dont know if there's a way....
13:49:54 <warlord> jralls: i think it's a user preference
13:51:44 <jralls> warlord: I don't see it there.
13:52:35 *** fabior has quit IRC
13:52:36 <warlord> jralls: actually, there may not be a way to do it.
13:55:01 <jralls> Hmm, I'd leapt to a conclusion. There is no default, the first page of creating a new bug asks you to select a product and they're in alphabetical order.
13:57:08 <jralls> There doesn't seem to be a way to change that order besides renaming the products. :(
13:59:47 <warlord> :(
14:10:44 *** calvinct has joined #gnucash
14:10:54 *** fell has joined #gnucash
14:10:58 *** Mechtilde has quit IRC
14:15:39 <warlord> jralls: are people adding bugs in the wrong project?
14:17:30 <jralls> Someone did this morning, https://bugs.gnucash.org/show_bug.cgi?id=796907 was submitted to "Bugzilla".
14:18:38 <warlord> *sigh*
14:31:05 *** boldstripe has quit IRC
14:32:04 *** boldstripe has joined #gnucash
14:36:10 *** sjamaan has left #gnucash
14:37:05 <gjanssens> warlord: jralls' question on bugzilla reminds me I haven't received bugzilla mail since August.
14:37:39 <gjanssens> I did have to reroute to a different mail server around that time, but other mail seems to come in normally
14:38:04 <gjanssens> Can you check on your side if I got one some kind of blacklist or so ?
14:40:32 *** oozer has quit IRC
14:40:46 <gjanssens> Oh, it looks like SAV is failing. I see noqueue messages in my logs with reason: <bugs-admin@bugs.gnucash.org>: Recipient address rejected: We do not accept bugmail
14:41:02 *** oozer has joined #gnucash
14:41:40 <gjanssens> My mailserver won't accept mails from a sender that doesn't verify
14:41:58 <warlord> gjanssens: that is probably it..
14:42:05 <warlord> the bz email isnt valid
14:42:11 <warlord> i should go fix it
14:42:16 * gjanssens already found it awfully quiet in bug land...
14:42:43 <gjanssens> Heh, more work for warlord...
14:42:49 <warlord> lol
14:51:05 *** mohave has quit IRC
15:00:38 *** frakturfreak has joined #gnucash
15:10:18 *** KevinDB has quit IRC
15:11:05 *** mohave has joined #gnucash
15:13:38 *** KevinDB has joined #gnucash
15:25:38 *** mohave has quit IRC
15:31:34 *** oozer has quit IRC
15:35:30 <gjanssens> Ok, first roadblock for switching to itstool...
15:36:08 <gjanssens> When extracting translatable messages it expands all ENTITYs
15:36:43 <gjanssens> So the message id's become "GnuCash Documentation Team" instead of "&app; Documentation Team"
15:38:00 <gjanssens> It has an option to not expand entities (-k), but then it won't extract messages from all included chapters (the <!ENTITY bla SYSTEM> entities)
15:39:41 <gjanssens> One can of course add multiple xml files as parameters to the itstool command invocation
15:40:12 <gjanssens> However for all but gnucash-guide.xml it will error out due to undefined entities like &app;
15:40:28 <gjanssens> Not a great start :(
15:40:59 <gjanssens> itstool doesn't seem to have a forum, so I have contacted the author by e-mail asking for advice
15:41:08 <gjanssens> (forum or mailing list)
15:48:58 <jralls> They may use github issues as their forum.
15:49:24 <jralls> If so the principal will probably tell you so in his reply.
15:50:08 *** jerryq has quit IRC
15:52:10 *** jerryq has joined #gnucash
16:03:18 *** mohave has joined #gnucash
16:28:05 *** calvinct has quit IRC
16:31:31 *** mohave has quit IRC
16:32:12 <fell> One approach could be a conversion from <!ENTITY ,,, System ---> to XInclude
16:32:12 <gncbot> fell: Sent 9 hours and 12 minutes ago: <gjanssens> I was not thinking of gitlab.com, but of selfhost the opensource community edition, just as gnome does
16:32:43 *** gncbot sets mode: +o fell
16:33:16 *** boldstripe has quit IRC
16:33:35 *** boldstripe has joined #gnucash
16:33:51 *** kael has quit IRC
16:34:48 <fell> ... but I am no fan of po based translation for longer strings than ~3 lines.
16:37:50 <jralls> fell: That's probably more restrictive than you mean. After all we have plenty of msgids in GnuCash that are longer than 3 lines.
16:39:45 <gjanssens> fell: XInclude may indeed fix this particular issue
16:39:50 <jralls> That aside, ISTM that there are only two choices: Some sort of chunk-based translation facility like gettext (and the only other one in wide circulation that I know about is ICU) or treating each language's documentation as a stand-along document.
16:40:00 <fell> After "Insert/remove a space in the english text" you are searching and searching.
16:40:02 <jralls> s/stand-along/stand-alone/
16:40:49 <gjanssens> fell: I think a decent diff tool will be able to show you exactly which characters have changed
16:41:05 <gjanssens> kdiff3 does for example
16:41:21 <jralls> fell: Not really. Unless the change substantially changes the meaning of the msgid the msgstr need not change. Just remove the "fuzzy" and move on.
16:41:40 <gjanssens> And I agree with jralls on the two options we have
16:42:02 <gjanssens> I thought we had discussed this at length last week (or was it the week before) ?
16:42:15 <fell> That's what I do with docs: 1 diff window with english changes and one with en vs. de.
16:42:26 <jralls> Last month, I think. We've all been busy on other stuff.
16:43:10 <gjanssens> The stand-alone version means we won't be able to track changes between english and other languages, effectively ruling out decent translations in the long run
16:43:29 <gjanssens> So the choice boils down to po based translations or no translations
16:43:52 <fell> I think Mechtilde is still testing one tool
16:49:07 <jralls> Well, in the sense that stand alone documents aren't entirely translations.
16:49:57 <fell> LANG edition
16:50:22 <jralls> Chunk-based translations aren't a magic bullet either: The Italian translation is chunk-based and it's stuck at 2.6.something because that's when Cristian stopped updating it.
16:52:21 *** frakturfreak has quit IRC
16:52:31 <fell> On htdocs I recently removed a "and sent mail to gnucash-devel". I was able to patch indogermanic languages, but not CJK.
16:52:39 <jralls> fell: Do you mean e.g. "GnuCash Tutorial and Concept Guide, German Edition"?
16:52:48 <fell> yes
16:54:26 <jralls> I think that's basically what David T. is advocating. It gives him the freedom to heavily rewrite the English editions without having to worry about the others. I'd sure like to hear what Pedro and Dmitry think of this.
16:54:45 *** oozer has joined #gnucash
16:55:56 *** linas has quit IRC
16:57:13 *** KaiForce has quit IRC
16:57:19 <fell> cc them on PR 115 or ask via gnucash-devel
17:01:14 <gjanssens> We may be able to work around the chunk based translation issue by not automating too much.
17:02:18 <gjanssens> That is we could commit a work as far as it's translated in xml format and never run po file merges automatically.
17:02:51 <gjanssens> It may require some xslt hacking to publish only really translated chunks, but that should be doable.
17:03:39 <gjanssens> And as I understood Mechtilde she is mostly trying to translate the English version, with only changes where German regulation diverts from US regulation
17:03:56 <gjanssens> So she does want to be able to track English document changes.
17:04:20 <gjanssens> She's actually working in some kind of hybrid mode.
17:04:32 <jralls> But she emphatically doesn't want to do a major rewrite.
17:04:59 <gjanssens> What does "emphatically" mean in this sentence ?
17:06:01 <gjanssens> And what do you mean as a whole ?
17:06:05 <fell> PR115 in the current form would invalidate all translations in mayor parts.
17:06:07 <jralls> She was quite emphatic here last month that she wasn't willing to redo large parts of her previous work.
17:06:59 <gjanssens> Well I think in the stand-alone mode the rework that would fall on her shoulders would be much bigger than in a po based mode
17:07:25 <gjanssens> But of course that depends on how the rewrite is handled
17:08:00 <gjanssens> If it's just moving blocks of text to other locations in the document(s), po would recognize this and require no changes
17:08:15 <gjanssens> If the text gets completely rewritten, this becomes another matter.
17:08:20 <fell> A po based wark would require much more discipline from writers: put often used strings like bug url in separate entities, ...
17:08:21 <jralls> And how heavily David T. wants to revise it. He sometimes comes across as wanting to write The GnuCash Reference Guide by David T.
17:08:40 <gjanssens> :)
17:09:45 <gjanssens> But I'm not convinced yet that PR 115 would invalidate translations. We'll have to do the experiment.
17:10:10 <gjanssens> But apparently that needs some other steps first
17:10:21 <gjanssens> Like getting itstool to work with our docs
17:10:37 <gjanssens> Which probably means converting to XInclude
17:10:51 <fell> I am not against the content of his changes, only it's form: one big patch.
17:11:14 <jralls> Can Yelp cope with XInclude?
17:11:16 <gjanssens> I will work on an experiment as time permits
17:11:24 <gjanssens> Ah, good question!
17:12:02 <gjanssens> But I think so as it's used in geany sources and the meson command to install the docs is called gnome.yelp
17:12:25 <gjanssens> That's of course only an abstract conclusion
17:12:38 <gjanssens> Or theoretical, not from practical experience
17:13:44 <fell> http://write.flossmanuals.net/introduction-to-mallard/xinclude/
17:13:46 <gjanssens> fell: whether the size of the patch matters will also show from further experimentation
17:15:24 <gjanssens> I also found the reference to other tools you proposed: https://github.com/Gnucash/gnucash-docs/pull/115#issuecomment-425277135
17:16:09 <gjanssens> Mechtilde points out that Openlanguagetools is dead. I wouldn't want to build our documentation workflow on a dead project
17:16:22 <gjanssens> She didn't comment yet on OmegaT
17:16:44 <fell> She wanted time for testing
17:17:56 <fell> (and probably Openlanguagetools has become Librelanguagetools?)
17:18:43 <fell> https://extensions.libreoffice.org/extensions/languagetool
17:19:57 <jralls> The description of that sounds more like a grammar checker than a translation aid.
17:21:18 <gjanssens> From OmegaT's wikipedia page I infer this tool is also chunk-based, so essentially what po does. Although it uses regular expressions to define the chunks
17:21:33 <jralls> https://en.wikipedia.org/wiki/Open_Language_Tools is/was to XLIFF (the ICU translation file format) what po-edit is to gettext.
17:22:19 <gjanssens> So that is another chunk based solution
17:22:51 <gjanssens> Anyway, it's been interesting but my time is up for tonight...
17:24:43 <gjanssens> TTYL!
17:25:00 <jralls> Good night!
17:25:43 <gjanssens> Oh, one final note: OmegaT has support for computer translations, which is an interesting thing to check out...
17:25:45 <gjanssens> Bye!
17:26:06 *** gjanssens has quit IRC
17:26:56 *** bertbob has quit IRC
17:30:07 *** calvinct has joined #gnucash
17:38:05 <fell> I think, https://en.wikipedia.org/wiki/OmegaT sounds promising.
17:39:43 *** calvinct has quit IRC
17:40:58 *** bertbob has joined #gnucash
17:46:49 <chris> jralls good... but not good enough, please let me know statprof output too :)
17:46:55 *** puck has quit IRC
17:48:51 *** jerryq has quit IRC
17:49:59 <jralls> chris: On the PR.
17:50:39 *** Cuare has joined #gnucash
17:50:46 *** Aussie_matt has joined #gnucash
17:54:02 *** puck has joined #gnucash
17:54:57 <chris> cool. lots of time in gnc-commodity-print-info. you've enabled table display. now off to work.
17:55:40 <jralls> chris: Have fun!
18:02:16 *** Grav has joined #gnucash
18:02:27 *** ArtGravity has quit IRC
18:04:09 *** Cuare has quit IRC
18:04:24 *** fell has quit IRC
18:06:20 *** Agfarmer18 has joined #gnucash
18:07:41 *** fell has joined #gnucash
18:07:41 *** gncbot sets mode: +o fell
18:33:18 *** boldstripe has quit IRC
18:34:18 *** boldstripe has joined #gnucash
18:38:39 *** zipppy has quit IRC
19:07:04 *** gour has quit IRC
19:20:00 <fell> In en-US "web site" or "website" is more common?
19:22:11 *** bertbob has quit IRC
19:23:33 <fell> OK, wikipedia says no space
19:36:44 *** bertbob has joined #gnucash
19:38:03 <jralls> I agree with Wikipedia. I almost never see "web site".
19:39:19 <fell> but we have several occurrences in the docs
19:57:45 *** WebManOfFesto has joined #gnucash
20:32:41 *** Grav has quit IRC
20:38:59 *** jerryq has joined #gnucash
20:58:16 *** badger92 has quit IRC
20:59:04 *** badger92 has joined #gnucash
21:14:30 *** boldstripe has quit IRC
21:14:49 *** boldstripe has joined #gnucash
21:30:19 *** mmkodali[m] has quit IRC
21:30:36 *** User has quit IRC
21:44:03 *** mmkodali[m] has joined #gnucash
21:49:20 *** redlizard has joined #gnucash
21:50:05 <redlizard> Greetings.
21:50:14 <redlizard> Is there a repository somewhere of custom gnucash reports?
21:50:27 <redlizard> The basic set seems a bit limited.
22:05:40 <fell> redlizard: which version are you using?
22:07:00 <redlizard> fell: I was on the 2.6 branch, looking at 3.3 now.
22:08:13 <fell> Because there is some progress driven by chris.
22:08:50 <fell> You saw already https://wiki.gnucash.org/wiki/Custom_Reports?
22:09:01 <redlizard> Yes. That's my fallback.
22:09:20 <redlizard> But I was sort of hoping that others have gone this route and have conveniently published their results for me :)
22:10:55 <fell> Sometimes users pubished their reports i.e. on the mailing lists....
22:11:50 <redlizard> But there is nothing like a CPAN-style repository?
22:11:58 <fell> or referenced by https://wiki.gnucash.org/wiki/Published_tools
22:13:09 <fell> I don't know anybody maintaining one.
22:13:23 <redlizard> Pity.
22:13:48 <redlizard> The things I want are pretty simple, and it's entirely possible that gnucash can actually do them and I just don't know how.
22:17:02 <fell> With the right chooice of options many things can be done from the existing reports.
22:18:03 <redlizard> Yeah. It's finding out what CAN and what CANNOT be done with them that's the tricky question.
22:20:50 <fell> you could describe you problem on gnucash-user or your locale list gnucash-nl and ask if someone has an approach.
22:22:11 *** PyroPeter_ has joined #gnucash
22:23:47 *** oozer has quit IRC
22:23:58 *** PyroPeter has quit IRC
22:24:45 <redlizard> For now, the main challenge seems to be that a lot of the reports don't want to collage placeholder accounts for me.
22:25:03 <redlizard> *collate
22:27:22 <redlizard> For instance, I'm trying to create a transaction report that summarizes all transactions against subaccounts of a placeholder account, without distinguishing between those subaccounts (just add it all up to one summary number).
22:34:51 <fell> Display:Detail level?
22:35:16 <redlizard> That's something else, I think.
22:40:49 <redlizard> Say, are there any reports that just report "value difference of $account between dates X and Y"?
22:41:16 <redlizard> Just that one number.
22:47:52 <fell> I am pretty shure, but do not know off hand.
22:48:10 <fell> http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd:101: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.4/dbnotnx.mod"
22:48:57 <fell> jralls, did you see ^ before?
22:49:19 <redlizard> I certainly would expect it to be possible, for it seems rather fundamental as reports go :)
22:49:59 <redlizard> (The next step would be to tabulate it against periods like months or weeks, with multiple columns for multiple accounts. But that's for later.)
22:55:25 <redlizard> (Whoops, have to run. I'll be back later.)
23:08:34 *** storyjesse has joined #gnucash
23:33:33 *** nate has quit IRC
23:45:06 *** jerryq has quit IRC