[GNC-dev] Planning for 4.x - progress in scheme code
christopher.lck at gmail.com
Thu Oct 3 02:03:13 EDT 2019
Just a small tip about ctests.
ninja can build in parallel. ctest can also run tests in parallel. The
following does the trick for me:
On Mon, 30 Sep 2019 at 13:55, Christopher Lam <christopher.lck at gmail.com>
> Hi Users and Devs
> Those with an eye on maint & master will notice I've continued cleaning up
> reports and report infrastructure heavily. I hope these efforts are
> appreciated. In my subjective view, the cleaned up reports are neater and
> easier to follow, and less wordy.
> I have two major approaches in use:
> 1. minimise set! in reports -- using set! in scheme is prone to
> incomprehensible code; it allows modifications of vars out of scope. Also
> comment about using set! in scheme.
> 2. try eradicate gnc:commodity-collector modification in reports -- using
> them is mostly used to keep track of monetary amounts, and they are
> *always* converted to a target currency for display or other processing
> (otherwise why keep track of them?). Therefore commodity-collector logic
> should be hidden away. I've added gnc:collector+ and gnc:collector- to add
> a list of collectors, and can be used similar to + or - as in
> (gnc:collector+ assets liabilities) whereby assets & liabilities are
> collectors, and this will create a *new* collector with the added amounts.
> This is a neater approach, and avoids such hacks as
> which is a hack to ensure the correct collector is modified in scheme.
> Conclusion: best abstract commodity-collectors away, transforming report
> code from accumulator to functional approach, such as:
> While this is ongoing, there are PRs waiting in github, awaiting further
> consideration. I've refrained from merging too much work into master
> because I think many will require careful review or debate.
> 1. https://github.com/Gnucash/gnucash/pull/459 - to implement
> book-specific accounting-period. This work is complete but creates two
> confusing accounting periods. I am not sure how to create a transition from
> global to book property.
> 2. https://github.com/Gnucash/gnucash/pull/463 - to refactor
> advanced-portfolio.scm -- this will be a long-term project because this
> report is too complex. I'll keep this one for last.
> 3. https://github.com/Gnucash/gnucash/pull/477 - for book-saved-reports
> -- this branch works well but needs modification to options.scm. I think
> this will depend on c++ options work to be completed.
> 4. https://github.com/Gnucash/gnucash/pull/500 - GST/VAT Reports upgrade
> -- this work will augment income-gst-statement.scm to also present reports
> suitable for UK VAT and Australian BAS returns. The only remaining issue
> here is a decision on *how* to tag UK EC VAT and Sales accounts; currently
> they rely on *ECGOODS* and *ECVAT* present in account description. This is
> a fine hack, but a hack nonetheless. Is there a better approach?
> 5. https://github.com/Gnucash/gnucash/pull/520 - redirect jqplot to
> chartjs -- I think this is ready to be merged in. Any objections?
> 6. https://github.com/Gnucash/gnucash/pull/535 - unify job & owner - I
> think this is nearly ready. It augments these reports to allow linking
> invoices <-> payments. But I am still not sure how to present the
> aging-table especially with overpayments and credit-notes not paired
> 7. https://github.com/Gnucash/gnucash/pull/538 - refactor-aging ditto
> 8. https://github.com/Gnucash/gnucash/pull/544 - qif upgrade - instead of
> saving account full-name in qif-import-map, save the account guid instead.
> will need more testing especially the qif mapping needs to be useful with
> multiple books.
> 9. https://github.com/Gnucash/gnucash/pull/558 - remove "Report Title"
> option - I think could be merged in already.
> 10. https://github.com/Gnucash/gnucash/pull/576 - ensure budget estimator
> can ignore closing entries -- I think it could also be merged in.
> 11. https://github.com/Gnucash/gnucash/pull/585 - fix internal budget
> amounts to ignore global account-reversal property. I think this is
> complete, however, there is work pending to fix amount signs on existing
> budgets. This requires coding to guard future books from being modified by
> previous versions, and I have no idea how to code this.
> Any constructive comments welcome. That's all for now!
More information about the gnucash-devel