Re: [GNC-dev] Make of 3.3-181

2018-12-24 Thread Geert Janssens
Op maandag 24 december 2018 02:33:39 CET schreef Frank H. Ellenberger: > I would suspect > > either the change of locale-specific-tax from an option to the default > behaviour in configure was not completely ported to cmake > > or it was not applied if the locale was C. > > Frank As far as I re

Re: [GNC-dev] Unwritten Wiki Conventions

2018-12-24 Thread D via gnucash-devel
Frank, On December 24, 2018, at 12:19 AM, "Frank H. Ellenberger" wrote: >David, >thanks for your question. Because it affects unwritten historical >conventions, I cc the list. >https://code.gnucash.org/wiki/Wiki_Conventions >Am 23.12.18 um 08:04 schrieb David T.: >> Frank, >> I just decided to

Re: [GNC-dev] Unwritten Wiki Conventions

2018-12-24 Thread Derek Atkins
No, the forward slash means it's a wiki subpage. E.g. one could have Taxes/US, Taxes/UK, etc. The wiki handles it just fine, and we already have examples of subpages. -derek Sent using my mobile device. Please excuse any typos. On December 24, 2018 7:26:18 AM D via gnucash-devel wrote: F

[GNC-dev] Introduction, a story, and 50% improvement in XML loading speed

2018-12-24 Thread Chris Carson
TL;DR: hi! I'm a programmer! The attached patch to one line of code gives a 50% reduction in XML load CPU use! Skeptical? I was. *Introduction* (of me) My name is Chris Carson. I wrote code for a living from 1976-1986, and then entered management but continued dabbling in code as a hobbyist

Re: [GNC-dev] Introduction, a story, and 50% improvement in XML loading speed

2018-12-24 Thread Geert Janssens
Op maandag 24 december 2018 13:38:27 CET schreef Chris Carson: > *The Patch* > > I tried a couple of different fixes to this. The patch below copies off > and validates only the bytes being consumed. It brings the user CPU to > startup and load my XML file from ~38 seconds to ~20.5 seconds, and

Re: [GNC-dev] Introduction, a story, and 50% improvement in XML loading speed

2018-12-24 Thread Geert Janssens
Op maandag 24 december 2018 14:29:15 CET schreef Geert Janssens: > Op maandag 24 december 2018 13:38:27 CET schreef Chris Carson: > > *The Patch* > > > > I tried a couple of different fixes to this. The patch below copies off > > and validates only the bytes being consumed. It brings the user CP

Re: [GNC-dev] Make of 3.3-181

2018-12-24 Thread John Ralls
> On Dec 24, 2018, at 1:35 AM, Geert Janssens > wrote: > > Op maandag 24 december 2018 02:33:39 CET schreef Frank H. Ellenberger: >> I would suspect >> >> either the change of locale-specific-tax from an option to the default >> behaviour in configure was not completely ported to cmake >> >>

Re: [GNC-dev] Make of 3.3-181

2018-12-24 Thread Frank H. Ellenberger
Am 24.12.18 um 18:30 schrieb John Ralls: > Agreed in principle, but in this case ISTM it would make more sense to just > remove them. Then all books based on SKR04 will crash. That was the reason, it became default. > de_DE.scm hasn’t been substantively maintained since it was first committed

[GNC-dev] GB PAS 76

2018-12-24 Thread Frank H. Ellenberger
David, Am 24.12.18 um 07:03 schrieb D: > Rather than add another code to an obscure code, I think you should have gone > the opposite direction, and named this page something like "Compliance with > UK Tax Authorities". This is especially relevant, since the page appears to > approach the topic

Re: [GNC-dev] Make of 3.3-181

2018-12-24 Thread Stephen M. Butler
On 12/24/18 1:35 AM, Geert Janssens wrote: Op maandag 24 december 2018 02:33:39 CET schreef Frank H. Ellenberger: I would suspect either the change of locale-specific-tax from an option to the default behaviour in configure was not completely ported to cmake or it was not applied if the locale

Re: [GNC-dev] Make of 3.3-181

2018-12-24 Thread John Ralls
> On Dec 24, 2018, at 9:44 AM, Frank H. Ellenberger > wrote: > > > > Am 24.12.18 um 18:30 schrieb John Ralls: >> Agreed in principle, but in this case ISTM it would make more sense to just >> remove them. > > Then all books based on SKR04 will crash. That was the reason, it became > defaul

[GNC-dev] clang-format - thoughts ?

2018-12-24 Thread c . holtermann
Hello folks, have there been thoughts about using a code formatter like clang-format ? My brother is taking part in cmake development and he says that he has included clang-format in his git deployment chain. regards and merry christmas, Christoph Holtermann __

Re: [GNC-dev] Make of 3.3-181

2018-12-24 Thread Frank H. Ellenberger
Am 24.12.18 um 22:10 schrieb John Ralls: > > >> On Dec 24, 2018, at 9:44 AM, Frank H. Ellenberger >> wrote: >> >> >> >> Am 24.12.18 um 18:30 schrieb John Ralls: >>> Agreed in principle, but in this case ISTM it would make more sense to just >>> remove them. >> >> Then all books based on SKR0

Re: [GNC-dev] clang-format - thoughts ?

2018-12-24 Thread John Ralls
Christoph, We've occasionally run artistic style (https://astyle.sourceforge.net ) when one of us gets really irritated with a lot of poor formatting, but it has been several years since anyone thought it necessary. Is there something in particular that’s rubbi

Re: [GNC-dev] clang-format - thoughts ?

2018-12-24 Thread c . holtermann
John, it's more of a general question. I don't have something specific. I tend to develop more sympathy towards formatting rules lately and clang-format sounded interesting. https://github.com/barisione/clang-format-hooks is an example of clang-format as github hook. As my main interest is py

Re: [GNC-dev] clang-format - thoughts ?

2018-12-24 Thread Christopher Lam
From a lisp viewpoint I was thinking of putting forward a coding style too! I use emacs which does the following automatically: https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html#Coding-Conventions C On 25/12/18 10:23 am, c.holterm...@gmx.de wrote: John, it's m

Re: [GNC-dev] Make of 3.3-181

2018-12-24 Thread Christopher Lam
There is still a strong argument to clean up these reports... They are generally messy, lots of duplicate code, impose new translatable strings; they use localised C API such as xaccAccountGetTaxUSCode (even taxtxf-de_DE.scm calls it), are poorly tested. I have not touched any of them signifi