May also fix#1154, #1033, #708, #536, #73: testing is needed.
This aims to solve all problems where misconfigured locales lead to
parsers failing on utf8-encoded data. This should hopefully avoid
encoding issues, but since it fundamentally alters how encoding is dealt
with it may lead to unexpected outcomes. Widespread testing on a number
of different platforms would be useful.
This increases composability and avoids some ugly case handling. We
re-export runExceptT in Hledger.Read.
The final return types of the following functions has been changed from
IO (Either String a) to ExceptT String IO a. If this causes a problem,
you can get the old behaviour by calling runExceptT on the output:
readJournal, readJournalFiles, readJournalFile
Or, you can use the easy functions readJournal', readJournalFiles', and
readJournalFile', which assume default options and return in the IO
monad.
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.
env -S isn't a thing on linux of course. Go back to using standard
env, which means using a stack options line, which means not using
"ghc". This new setup is probably simpler anyway. I've just had to
give up on the goal of having each script's required packages being
defined in one place; now (to they extent they are required) they
must be defined both in the script header and in compile.sh.
Using stack's script command meant that the scripts needed to be
compatible, and regularly tested, with a hledger release in stackage,
rather than the latest hledger source. This created hassles for
maintainers, contributors and sometimes for users.
To simplify things overall, we now require script users to check out
the hledger source tree and run the scripts (or, bin/compile.sh) from
there once so they compile themselves. Some notes on alternative
setups are included (in one of the scripts, and referenced by the
others). This ensures that users and our CI tests are building scripts
the same way.
Current stack does not allow a stack options line to be used with the
"stack ghc" command, unfortunately, so instead we are using env's -S
flag, which hopefully has sufficiently wide support by now, and
putting all arguments in the shebang line.
This method will probably require complete explicit --package options,
unlike "stack script", so more testing and tweaking is expected.
Probably we're going to end up with some long shebang lines.
This isn't pretty but seems like a possible way to keep things
manageable.
