[GNC-dev] Planning for 4.x - progress in scheme code

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[GNC-dev] Planning for 4.x - progress in scheme code

Christopher Lam
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
see
https://www.gnu.org/software/guile/manual/html_node/Variables-and-the-VM.html#Variables-and-the-VM
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
https://github.com/Gnucash/gnucash/blob/3.7/gnucash/report/report-system/html-acct-table.scm#L732
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:
https://github.com/Gnucash/gnucash/commit/80296a3c

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
correctly.

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!
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Planning for 4.x - progress in scheme code

Amish
On 30/09/19 7:25 pm, Christopher Lam wrote:
> 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.

You are doing amazing work. I really appreciate.

Scheme is so tough to learn and code (atleast for me). And yet you do it
so well.

Reports are backbone of any finance related software. And GnuCash
reports have helped me a lot for Indian Government GST related filing.

Thank you very much and best regards

Amish

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Planning for 4.x - progress in scheme code

Christopher Lam
Thank you for kind words!

On Tue, 1 Oct 2019 at 11:56, Amish <[hidden email]> wrote:

> On 30/09/19 7:25 pm, Christopher Lam wrote:
> > 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.
>
> You are doing amazing work. I really appreciate.
>
> Scheme is so tough to learn and code (atleast for me). And yet you do it
> so well.
>
> Reports are backbone of any finance related software. And GnuCash
> reports have helped me a lot for Indian Government GST related filing.
>
> Thank you very much and best regards
>
> Amish
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] Planning for 4.x - progress in scheme code

Christopher Lam
In reply to this post by Christopher Lam
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:

export CTEST_PARALLEL_LEVEL=4

On Mon, 30 Sep 2019 at 13:55, Christopher Lam <[hidden email]>
wrote:

> 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
> see
> https://www.gnu.org/software/guile/manual/html_node/Variables-and-the-VM.html#Variables-and-the-VM
> 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
> https://github.com/Gnucash/gnucash/blob/3.7/gnucash/report/report-system/html-acct-table.scm#L732
> 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:
> https://github.com/Gnucash/gnucash/commit/80296a3c
>
> 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
> correctly.
>
> 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!
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel