User:Christopherlam

Build Scripts

rebuild.sh:
-----------
rm -rf /home/chris/sources/gnucash/{build,install}
cd /home/chris/sources/gnucash
mkdir build
cd build
cmake -GNinja  -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/chris/sources/gnucash/install ../maint


run.sh:
-------
cd build
ninja && ninja install
cd ../install
./bin/gnucash --logto stdout $1

Project 5 Upgrading reports based on html-acct-table.scm

This is a moderate-sized project. HTML-ACCT-TABLE.SCM is a utility object, designed to create a spreadsheet of numbers, with horizontal axis columns, and vertical axis accounts. It is usually constructed piecemeal from various reports as follows:

(define table (gnc:make-html-acct-table/env/accts table-env accounts))
(gnc:html-table-add-account-balances table table1 params)
(gnc:html-table-add-labeled-amount-line! table indent style ...)

In other words, html-acct-table is constructed from a basic table, and the data is added piecemeal to create a full spreadsheet.

My proposal is to eliminate html-acct-table completely, and create a single *add-multicolumn-acct-table* which accepts a minimum of parameters:

• table, an html-table object
• title, a string
• accountlist, list of accounts
• maxindent, a positive integer indicating maximum account depth
• get-cell-monetary-fn, a function taking (account col-data) as parameter to produce a gnc-monetary or #f
• cols-data, a list specifying parameters to be sent as parameter to get-cell-monetary-fn

and optional parameters, some of which are:

• get-cell-header-fn a function taking (col-data) to specify header
• get-cell-anchor-fn a function taking (account col-data) to specify cell url

I think this makes the function much simpler to create the following table from a single add-multicolumn-acct-table:

title........header1...header2...header3...header4...header5
account1.....cell1.....cell2.....cell3.....cell4.....cell5
account2.....cell6.....cell7.....cell8.....cell9.....cell10
total........total1....total2....total3....total4....total5

The accountlist is cycled on the vertical column, and each cell is rendered according to get-cell-monetary-fn which takes 2 argument - the row account, and the column col-data. Nested totals are generated and rendered according to 2 different strategies. Each cell may also be rendered as an HTML link to another report, or a register. Each cell may also include another monetary by specifying get-cell-orig-monetary-fn, thereby rendering 'original currency' amounts.

I believe this function will be versatile enough to replace many other reports, and a lot of incomprehensible code can be eliminated.

Project 4 Upgrading Invoices

TBA

Project 3 Upgrading Charts

Majority of charts upgrade from jqplot (on life support) to chartJS (actively maintained) is complete in https://github.com/Gnucash/gnucash/pull/316 (without tests).

The following files

• html-barchart.scm
• html-linechart.scm
• html-scatter.scm
• html-piechart.scm

have been merged into a common html-chart.scm.

This combined file will create an html-chart object and accept options, and will generate the required javascript code to call ChartJS and create a chart. As a bonus, URL jumps from charts to reports and registers have been resurrected.

The chart-based reports

• net-charts.scm
• average-balance.scm
• account-piechart.scm
• cashflow-barchart.scm
• daily-report.scm
• price-scatter.scm
• category-barchart.scm
• budget-barchrat.scm

have also been upgraded to call the combined charts API, selecting the appropriate bar/line/pie/scatter chart via html-chart-set-type! API call. No saved-reports compatibility issues are anticipated.

Project 2 Creating test-transaction.scm

I will document some thoughts about development of implementation/mock testing for transaction.scm. Without a framework, creating test-transaction.scm is an awkward hierarchy of function calls as follows:

(and (test-1) (test-2) (test-3))

I have tried yawaramin's ggspec and guile-2.0's SRFI-64 and I think the latter is a much simpler tool. I've created test-transaction.scm based on it, and is still in progress.

Generating Coverage Reports

Scheme has an inbuilt coverage report generator. Here's relevant excerpt from test-transaction.scm to illustrate coverage report generator.

(use-modules (system vm coverage)
             (system vm vm))

(define (run-test)
  (coverage-test run-tests-proper))

(define (run-tests-proper)
  (test-runner-factory my-runner)
  (test-begin "transaction.scm")
  (trep-tests)
  (test-end "transaction.scm"))

(define (coverage-test test-function)
  ;; we need to add location of transaction.scm otherwise it's not included in report
  (add-to-load-path "/home/chris/sources/gnucash/gnucash/report/standard-reports")
  (call-with-values 
    (lambda ()
      (with-code-coverage (make-vm)         ;; for guile-2.0. I think for guile-2.2 just remove (make-vm)
                          test-function))
    (lambda (data result)
      ;; and we save the result into tempdir
      (let ((port (open-output-file "/tmp/lcov.info")))
        (coverage-data->lcov data port)
        (close port)))))

The result of all this hard work is a coverage log.

We can download lcov from http://ltp.sourceforge.net/coverage/lcov.php

git clone https://github.com/linux-test-project/lcov.git
mkdir html
cd html
../lcov/bin/genhtml /tmp/lcov.info

And the coverage log is converted to an html report. Example report output. Excerpt as follows.

Project 1 Completed Dec 2017

When I was offered opportunity to completely overhaul, I have sought to fix Transaction Report as much as possible, and add options to derive as much value as possible with the underlying data presentable as a customized TR.

This document will serve as useful summary for users, and also as a roadmap for rewriting the git history.

1. General thoughts

The original TR was a complete mess, grown and hacked together by years of accumulated crud. Many functions were created for single use, numerous lists of splits, options, and sortkeys being passed around for no particular reason. I have flattened the TR to a reasonable level; and I haven't quite finalized it yet. There are further flattening/abstracting refinements that can need to take place. e.g. the generic and versatile TR can be massaged to produce a report suitable for reconciliation, just by setting the right options. I can formalise it by creating another report initialized with the above options. I can also rewrite the Income GST Statement to also exist within transaction.scm (or ideally another file) that will just call the options-generator and the renderer with new values. These may require refactoring to allow modification of calculated-cells

2. Bugs were fixed

 a) bug for pre-1970 dates whereby the wrong weekday was selected
 b) bug for 'register-order sortkey being classed as a date-subtotal-type
 c) fixing debit/credit amount columns - sign reversal strategy was flawed
 d) fixing date sorting to understand periodic sorting, rather than strict daily sorting

3. Additional features were added

 a) proper debit/credit subtotals in the appropriate columns
 b) multicolumn values and subtotals
 c) friendly headers for debit/credit
 d) optionally render Account Description in the subheading
 e) add 'daily subtotal strategy - useful for "daily report" types
 f) optionally hide the transactional data - but only a subtotals are enabled
 g) new filters - transaction/account substring/regex filters, reconciled-status
 h) new sortkey - reconciled status unreconciled->cleared->reconciled with subtotals
 i) new infobox - summarise options used and optionally render at the top of report
 j) sign reversal strategy - will default to follow the global pref
 k) optionally indent left columns according to grouping strategy

4. Unsure how to fix

 a) debit/credit signs are wrong if the sortkeys are 'other-account types