This allows us to guarantee that the report periods are well-formed and
don't contain errors (e.g. empty spans, spans not contiguous, spans not
a partition).
Note the underlying representation is now for disjoint spans, whereas
previously the end date of a span was equal to the start date of the
next span, and then was adjusted backwards one day when needed.
* Forbid solving for hashtables 1.3
On modern gccs, this sometimes causes build failures, see
https://github.com/gregorycollins/hashtables/issues/97
* Propagate constraint to package.yaml too
* stack98: include valid hashtables version
* stack92: add valid hashtables version
* stack94: add valid hashtables version
* stack96: add valid hashtables version
This upgrades Account to enable it to store a multiperiod balance, with
a separate balance for each date period. This enables it do the hard
work in MultiBalanceReport.
Some new types are created to enable convenient operation of accounts.
- `BalanceData` is a type which stores an exclusive balance, inclusive
balance, and number of postings. This was previously directly stored
in Account, but is now factored into a separate data type.
- `PeriodData` is a container which stores date-indexed data, as well as
pre-period data. In post cases, this represents the report spans,
along with the historical data.
- Account becomes polymorphic, allowing customisation of the type of
data it stores. This will usually be `BalanceData`, but in
`BudgetReport` it can use `These BalanceData BalanceData` to store
both actuals and budgets in the same structure. The data structure
changes to contain a `PeriodData`, allowing multiperiod accounts.
Some minor changes are made to behaviour for consistency:
- --declared treats parent accounts consistently.
- --flat --empty ensures that implied accounts with no postings are not displayed, but
accounts with zero balance and actual postings are.
Previously our cabal files used cabal-version 1.12, and were in theory
buildable with any ancient version of cabal. Now at least cabal 2.2
(or a version of stack built with with similar Cabal version) is
required to build hledger.
When running `cd hledger-lib && ghci test/unittest.hs`, ghci complains
with:
```
test/unittest.hs:7:1: error:
Could not find module ‘Hledger’
It is not a module in the current program, or in any known package.
|
7 | import "hledger-lib" Hledger (tests_Hledger)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Failed, no modules loaded.
```
This commit removes the "hledger-lib" package-qualified import, such
that above ghci command works as expected.
However, there is a comment in hledger-lib/test/unittest.hs that says:
> package-qualified import to avoid cabal missing-home-modules warning
> (and double-building ?)
The missing-home-modules warning and the double building can indeed be
reproduced by running (after removing the "hledger-lib"
package-qualified import): `cd hledger-lib && cabal build unittest`. It
will first build `hledger-lib`, then show a warning about
missing-home-modules, and then build `hledger-lib` again.
After comparing the unittest sections of hledger.cabal and
hledger-lib.cabal, the solution turned out to be to remove `./` from
hs-source-dirs for unittest. Don't ask me why though!
Overall it's a nice cleanup.
Previously, hledger could read CSV files containing non-ascii
characters only if they are UTF8-encoded. Now there is a new CSV
rule, encoding ENCODING, which allows reading CSV files with other
encodings.
This adds a dependency on the encoding library, which supports fewer
encodings than text-icu but does not require a third-party C library.
To avoid build issues on various platforms, we require version 0.10+.
This adds some use of the ImplicitParams language extension, required
by encoding's API, but only in a small code region.
This also changes the type of Reader's rReadFn; it now takes
a `Handle` rather than a `Text`, allowing more flexibility.
This fixes the error displayed when quitting the pager with long output.
It also replaces the pager lib with more robust homegrown pager utilities,
which should prevent a number of failure modes.