The textual output needs to be fully transposed instead of just the cell
values. The multi-period csv handling code already does the right thing
so just use those values.
The change in CompoundBalanceCommand.hs is just to match signatures
since commodity-column is not yet enabled there.
We can't filter out empty commodity strings since that is a legitimate
group. Simultaneously, we should only include the empty commodity if it
is explicitly used (part of a posting) and not generated as part of
`Amounts.amounts`
A gain report will report on unrealised gains by looking at the
difference between the valuation of an amount (by default, --value=end),
and the valuation of the cost of the amount.
Previously would not actually display anything since the Cell's
WideBuilders are single-element list. Just dispatch to showMixedAmountB
to do the right thing.
Add documentation and sample output for `--commodity-column` behavior
and functional tests e.g single-period balance, yearly balance, and
yearly budget
This adds the `--commodity-column` option that displays each commodity
on a separate line and the commodities themselves as a separate column.
The initial design considerations are at
simonmichael.hledger.issues.1559
The single-period balance report with `--commodity-column` does not
interoperate with custom formats.
rather than as a postprocessing step. (#1638)
This allows us to have a uniform procedure for balancing transactions,
whether they are normal transactions or forecast transactions, including
dealing with balance assignments, balance assertions, and auto postings.
We officially support GHC 8.6+ (and 8.8+ for hledger-web) now.
Hackage matrix builder shows all packages building successfully
with GHC 8.4+, somehow, so we'll adjust the base bound to
allow that but prevent any attempts to build with older GHCs,
AccountTransactionsReport.
Only a limited number of journal transformations are allowed in
accountTransactionReports due to the need to include the original
transaction. Document these.
Make sure to remove currency and amount queries from the reportq, so
they do not cause problems after valuation.
Avoid confusion by calculating transaction date at one point, and
passing that down with the transaction.
valuation after all reportq filtering is done (in both the historical
and recent postings), and make sure filtering is done at the correct
point based on whether --txn-dates is set. (#1634)
style amounts according to that argument. journalAddForecast and
journalTransform now return an Either String Journal.
This improves efficiency, as we no longer have to restyle all amounts in
the journal after generating auto postings or periodic transactions.
Changing the return type of journalAddForecast and journalTransform
reduces partiality.
To get the previous behaviour for modifyTransaction, use modifyTransaction mempty.
This makes it possible to keep multiple named budgets in one journal,
and select the one you want with --budget's argument.
More precisely, you can select the subset of periodic transactions
rules which contain a certain fixed, case-insensitive substring.
Only one such --budget argument is supported, the last one on the
command line takes precedence.
This is done to be more consistent with future field naming conventions,
and to make automatic generation of lenses simpler. See discussion in
\#1545.
rsOpts -> _rsReportOpts
rsToday -> _rsDay
rsQuery -> _rsQuery
rsQueryOpts -> _rsQueryOpts
In Amount, aismultiplier is a boolean flag that will always be False,
except for in TMPostingRules, where it indicates whether the posting
rule is a multiplier. It is therefore unnecessary in the vast majority
of cases. This posting pulls this flag out of Amount and puts it into
TMPostingRule, so it is only kept around when necessary.
This changes the parsing of journals somewhat. Previously you could
include an * before an amount anywhere in a Journal, and it would
happily parse and set the aismultiplier flag true. This will now fail
with a parse error: * is now only acceptable before an amount within an
auto posting rule.
Any usage of the library in which the aismultiplier field is read or set
should be removed. If you truly need its functionality, you should
switch to using TMPostingRule.
This changes the JSON output of Amount, as it will no longer include
aismultiplier.
reportq from the ReportSpec, rather than being supplied as a separate
option.
This is the same approach used by the other reports, e.g. EntryReport,
PostingReport, MultiBalanceReport. This reduces code duplication, as
previously the reportq had to be separately tweaked in each of 5
different places.
If you call accountTransactionreport, there is no need to separately
derive the report query.
In each info manual's DIR-ENTRY metadata, it's best to use just the
filename, with no subdirectory. This should facilitate working info
manuals in packaged versions of hledger, eg in nix.
I don't remember the detail of why I added those and I'm not going to
spend a couple of hours retesting; hopefully no other significant
workflows will be affected.
I have left the subdirectory paths in the dir file - this is intended
for hledger developers and they hopefully don't cause a problem there.
This change provides more predictable and intuitive behaviour when
using -S/--sort-amount with multiple commodities.
It implements a custom Ord (and Eq) instance for MixedAmount
which substitutes zero for any missing commodities.
As a consequence, all the ways of representing zero with a MixedAmount ([],
[A 0], [A 0, B 0, ...]) are now Eq-ual (==), whereas before they were
not. We have not been able to find anything broken by this change.
* imp: lib: Compare MixedAmounts by substituting zero for any missing commodities. (#1563)
* ;doc: Update docs for new multicommodity sort by amount rules.
Also corrects a regression introduced in
8ab29f84b32288a34ae7627a2204081fae31900f where transaction modifier
postings without multipliers would incorrectly be filtered by commodity.
This continues the work begun by #1585. It moves each info manual's
directory metadata to the top of the file, where it needs to be.
I couldn't see a way to do this with pandoc/makeinfo, so the Shake
recipe prepends it from a separate file.
With this metadata in place, the hledger info manuals can be added to
an Info dir file using install-info. Eg:
$ install-info hledger/hledger.info /usr/local/share/info/dir
$ info
Secondly, the Shake "manuals"/"infomanuals" recipes now also generate
an Info dir file in each package directory, so you can also just add
the package directories to your INFOPATH. Eg:
$ export INFOPATH=~/src/hledger/hledger:~/src/hledger/hledger-ui:~/src/hledger/hledger-web:$INFOPATH
$ info
The hledger manuals shall now use at most four levels of headings,
avoiding loss of structure when viewed in Info format.
CSV fields list, field assignemt, and field names section have
been expanded.
The individual field headings have been renamed ("X field") to avoid
clashing with "Transactions"'s subheadings. They can now be opened
directly in info mode, eg: hledger help 'amount field'
transactions are balanced possibly using explicit prices, but without
inferring any prices. This is included in --strict mode.
Renames check autobalanced to check balancedwithautoconversion.
instead of a list of Amounts. No longer export Mixed constructor, to
keep API clean (if you really need it, you can import it directly from
Hledger.Data.Types). We also ensure the JSON representation of
MixedAmount doesn't change: it is stored as a normalised list of
Amounts.
This commit improves performance. Here are some indicative results.
hledger reg -f examples/10000x1000x10.journal
- Maximum residency decreases from 65MB to 60MB (8% decrease)
- Total memory in use decreases from 178MiB to 157MiB (12% decrease)
hledger reg -f examples/10000x10000x10.journal
- Maximum residency decreases from 69MB to 60MB (13% decrease)
- Total memory in use decreases from 198MiB to 153MiB (23% decrease)
hledger bal -f examples/10000x1000x10.journal
- Total heap usage decreases from 6.4GB to 6.0GB (6% decrease)
- Total memory in use decreases from 178MiB to 153MiB (14% decrease)
hledger bal -f examples/10000x10000x10.journal
- Total heap usage decreases from 7.3GB to 6.9GB (5% decrease)
- Total memory in use decreases from 196MiB to 185MiB (5% decrease)
hledger bal -M -f examples/10000x1000x10.journal
- Total heap usage decreases from 16.8GB to 10.6GB (47% decrease)
- Total time decreases from 14.3s to 12.0s (16% decrease)
hledger bal -M -f examples/10000x10000x10.journal
- Total heap usage decreases from 108GB to 48GB (56% decrease)
- Total time decreases from 62s to 41s (33% decrease)
If you never directly use the constructor Mixed or pattern match against
it then you don't need to make any changes. If you do, then do the
following:
- If you really care about the individual Amounts and never normalise
your MixedAmount (for example, just storing `Mixed amts` and then
extracting `amts` as a pattern match, then use should switch to using
[Amount]. This should just involve removing the `Mixed` constructor.
- If you ever call `mixed`, `normaliseMixedAmount`, or do any sort of
amount arithmetic (+), (-), then you should replace the constructor
`Mixed` with the function `mixed`. To extract the list of Amounts, use
the function `amounts`.
- If you ever call `normaliseMixedAmountSquashPricesForDisplay`, you can
replace that with `mixedAmountStripPrices`. (N.B. this does something
slightly different from `normaliseMixedAmountSquashPricesForDisplay`,
but I don't think there's any use case for squashing prices and then
keeping the first of the squashed prices around. If you disagree let
me know.)
- Any remaining calls to `normaliseMixedAmount` can be removed, as that
is now the identity function.
we know we won't need them.
Knowing whether we need them is accomplished by pulling the "show-costs"
option used by the Close command up into ReportOpts.
existing representation is small enough.
Previously the JSON representation of Decimal was rounded to 10 points
of precision before serialising. This sometimes results in an
unnecessary increase of precision.
Prior to this commit,
- hledger still builds with GHC 8.0
- hledger-ui does if you use the build plan specified by stack8.0.yaml,
but you are likely to hit problems if you let cabal pick one
(https://github.com/jtdaugherty/vty/issues/198 and others)
- hledger-web might, if you could find the right build plan
The hassles are enough and GHC 8.0 is old enough (first released in
2016) that I'm letting it go; 8.2 is the new minimum version for all
hledger packages.
This allows a bunch of cleanups to conditional imports, which I leave
for later.
Also, updated the tested-with minor versions.
It was reported on #hledger that bal -O csv capitalises "account"
differently for single and multi-period reports. All lower case seems
to be the most common, so I have dropped the capitalisation. Also
the trailing colon from --transpose's "total:".
It now uses the same JSON representation as Maybe Word8. This means that
the JSON serialisation is now broadly compatible with that used before the
commit f6fa76bba7, differing only in
how it handles numbers outside Word8 and that it can now produce null
for NaturalPrecision.
Strip prices after valuing postings in PostingsReport.
Use renderRow interface for Register report.
For reg -f examples/10000x10000x10.journal, this results in:
- Heap allocations decreasing by 55%, from 68.6GB to 31.2GB
- Resident memory decreasing by 75%, from 254GB to 65GB
- Total (profiled) time decreasing by 55%, from 37s to 20s
former being a simple wrapper around the latter.
This removes the need for the showNormalised option, as showMixedAmountB
will always showNormalised and showAmountsB will never do so.
We also strip prices from MixedAmount before displaying if not displaying prices.
Exceptions are for dealing with the pamount field, which is really just
dealing with an unnormalised list of amounts.
This creates an API for dealing with MixedAmount, so we never have to
access the internals outside of Hledger.Data.Amount.
Also remove a comment, since it looks like #1207 has been resolved.
supplant the old interface, which relied on the Num typeclass.
MixedAmount did not have a very good Num instance. The only functions
which were defined were fromInteger, (+), and negate. Furthermore, it
was not law-abiding, as 0 + a /= a in general. Replacements for used
functions are:
0 -> nullmixedamt / mempty
(+) -> maPlus / (<>)
(-) -> maMinus
negate -> maNegate
sum -> maSum
sumStrict -> maSum
Also creates some new constructors for MixedAmount:
mixedAmount :: Amount -> MixedAmount
maAddAmount :: MixedAmount -> Amount -> MixedAmount
maAddAmounts :: MixedAmount -> [Amount] -> MixedAmount
Add Semigroup and Monoid instances for MixedAmount.
Ideally we would remove the Num instance entirely.
The only change needed have nullmixedamt/mempty substitute for
0 without problems was to not squash prices in
mixedAmount(Looks|Is)Zero. This is correct behaviour in any case.
price directives after the last transaction/posting date if using
--value=end.
Also enlarges the reportspan to encompass full intervals for budget
goals.
If you forget that the argument is required by the --match
option, and not the command as a whole - eg if instead of
hledger print --match somebank -x
you write:
hledger print --match -x somebank
that gets quietly parsed as:
hledger print --match="-x"
which is not great. Adding --debug now at least gives some insight:
hledger print --match -x somebank --debug
finding best match for description: "-x"
similar transactions:
...
add --debug=1 shows the top hits for similar past transactions.
added:
Hledger.Cli.Utils.journalSimilarTransaction
provides --debug=1 output
changed:
Hledger.Cli.Commands.Add.transactionsSimilarTo -> Hledger.Data.Journal.journalTransactionsSimilarTo
now takes an extra number-of-results argument
For clarity; infer-value was too vague. The old spelling remains
supported for compatibility, but is now deprecated.
When typing, --infer-market or even --infer (for now) is sufficient.
Ensures parseable and more sensible-looking output in more cases, and behaves more like Ledger's print.
There is still an issue with adding trailing zeroes, which would be nice to prevent.
Since this is option is now just an alias for -B/--cost, and since it
may be removed soon, we make it undocumented, though it will still
behave as before. --value=cost,COMM is unsupported as well.
independently.
You can now combine costing and valuation, for example "--cost
--value=then" will first convert to costs, and then value according to
the "--value=then" strategy. Any valuation strategy can be used with or
without costing.
If multiple valuation and costing strategies are specified on the
command line, then if any of them include costing
(-B/--cost/--value=cost) then amounts will be converted to cost, and for
valuation strategy the rightmost will be used.
--value=cost is deprecated, but still supported and is equivalent to
--cost/-B. --value=cost,COMM is no longer supported, but this behaviour can be
achieved with "--cost --value=then,COMM".
costing and valuation.
This currently is given a dummy NoCost argument and is equivalent to
"maybe id (*ApplyValuation ...)", but provides a constant interface so
that internal behaviour can be changed freely.
aregister always shows transactions to subaccounts as well, ignoring any depth limit, so that the register's final total matches a corresponding balance report.
This was broken since 2020-09-02 c45663d41.
Across the rest of the documentation and other accounting documentation
it appears to imply that the more traditional top level name would be
revenue. In fact the income statement says that is a subtraction between
revenue and expenses to derive the income. While the account types that
hledger supports are named revenue so it seems more natural to name this
revenue.
simplifySign now covers a few more sign combinations that might arise.
And in particular, it strips a standalone sign with no number,
which simplifies sign flipping with amount-in/amount-out.
Also adds a postingDate argument to amountApplyValuation, and re-orders
the ValuationType and (Transaction/Posting) arguments to
(transaction/posting)ApplyValuation, to be consistent with
amountApplyValuation.
Error messages for these four are now a bit fancier and more
consistent. But not yet optimised for machine readability.
Cf #1436.
Added to hledger-lib: chomp1, linesPrepend[2].
This simplifies the --help/-h and --version flags by making them
position independent: no matter where they appear in the command line,
if there is a command argument they will show the command's help or
version (where applicable), instead of the hledger executable's.
hledger CMD --info will now open CMD's info node,
hledger CMD --man will scroll the man page to CMD's section, and
hledger help -i/-m/-p TOPIC will do similar.
This is not perfectly robust but hopefully will be good enough in
practice.
Also the help command's long --info/--man/--pager flags have been
dropped in favour of -i/-m/-p.
A "hledger check" argument may now be a quoted string containing
the check name followed by space-separated arguments, for
checks which make use of those. This means the check command
can replicate "check-dates --unique" and (in principle)
"check-fancyassertions ASSERTIONS..". Eg:
hledger check "dates --unique"
I think it'll be better for checks to take no arguments or options,
so this is probably just a transitional feature for compatibility.
This is intended to work in three modes:
- hledger check: just run the standard data checks, like all other
commands but with no output on success. Equivalent to
hledger stats >/dev/null but simpler and platform-independent.
- hledger check --strict: run the standard + strict data checks,
like other commands in strict mode.
- hledger check CHECK1 CHECK2 ...: run the named checks. This allows
running more or less checks than the default or strict mode, or
a single check of interest. The arguments are standard lowercase names
for the checks. For now this command supports two checks: "dates" and
"leafnames". These are equivalent to the check-dates and check-dupes
commands which are now hidden and considered deprecated, though
still supported for the moment.
This command needs more work and I'm rushing it a little, but I think
it's the right direction and I'd like to put it out there to get
feedback.
