Avoiding potentially confusing silent fallback. Also,
- Drop support for Ledger's legacy LEDGER environment variable;
we now support only LEDGER_FILE, for simplicity.
- Clarify the behaviour, eg when a glob pattern matches multiple files
or when the value is empty.
Since 1.50, sourceFilePath, which does IO operations, was being called for every item in the journal.
On my machine this was causing a ~40% slowdown,
but probably it could be more depending on storage system.
Now it's once again called only once per include directive.
Speed seems slightly better now than 1.43 for some reason
(eg: 13k txns/s -> 8k txns/s -> 14k txns/s).
PeriodData's use of Int keys caused wrong results with periodic
reports involving dates outside the machine-specific limits of Int.
Those were:
64 bits: -25252734927764696-04-22..25252734927768413-06-12
32 bits: -5877752-05-08..5881469-05-27
16 bits: 1769-02-28..1948-08-04
8 bits: 1858-07-12..1859-03-24
32 bits is supported by MicroHS; 16 and 8 bits aren't supported by
any known haskell version, but that could change in future.
For example, on 64 bit machines we got:
25252734927768413-06-12 PeriodData's max date
(expenses) 1
25252734927768414-01-01 next year past PeriodData's max date
(expenses) 2
$ hledger reg -O csv --yearly
"txnidx","date","code","description","account","amount","total"
"0","-25252734927764696-11-10","","","expenses","1","1"
Now it uses Integer (like the time package), fixing the bug.
And benchmarking shows memory and time usage slightly improved
(surprisingly; tested with up to 500 subperiods, eg
hledger -f examples/10ktxns-1kaccts.journal reg -1 cur:A -D >/dev/null)
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.
7 is no longer considered a scary shell character.
(This appears to have been harmless, used only for formatting the
balance assertion failure message.)
* 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
System.IO.hGetContents' was the latest paper cut; I could keep
supporting ghc 8.10.7, or at least 9.0-9.4, released 2021-2023;
but feck it. Debian Stable has 9.6 and this time can be better spent.
