ANN: hledger 1.99.5

News
1

I'm pleased to announce hledger 1.99.5 (2.0 preview 5): the fastest hledger yet, with
UI translations, find-anywhere query, compact transactions report,
lossless print --export, CSV merge rule, includable CSV & rules files,
gains at cost basis, short positions, auto-updating hledger-ui,
hledger-web balance reports, paging and dark mode.
By using it you'll help make 2.0 better!

https://hledger.org/relnotes.html
https://hledger.org/install

1 Like
2

When can we expect this in HomeBrew?

3

I started with 1.99.4 and am already running the fifth preview release and it's only been goodness. Very happy to have no bugs, issues or concerns to report.

1 Like
4

I'm not sure, ping the most recent homebrew maintainers ? Usually they are fast.

5

I think it is because that 1.99.5 is not a declared production release. From setup:

is up to date ? checking latest... yes latest is 1.52.4, 1.99.5 is installed

6

Well that was a nice improvement:

hledger 1.52.1
Runtime stats : 1.37 s elapsed, 15984 txns/s, 87 MB live, 204 MB alloc

hledger 1.99.5-gbeb262a6f-20261001
Runtime stats : 0.48 s elapsed, 45450 txns/s, 62 MB live, 147 MB alloc

7

Oh yes that makes sense.

8

3x speed up, on real world data ? We love to see it!

1 Like
9

Yup, all real world data.

Congratulations on the speed up, not every day you can see a 3x improvement!

1 Like
10

I should note too that 1.51 to 1.99.4 have a stats bug, their real txns/s is about 20% less than what they report.

11

The release notes mention,

An old limitation has been lifted: journal files can now include CSV/SSV/TSV files or CSV rules files.

This sounds interesting, and I'm curious what motivating use-case(s) drove that change. (I searched the repo's pull requests and commits, but wasn't able to find the relevant changes.)

12

Here's the commit: https://github.com/hledgerorg/hledger/commit/634b349e45d2d98b4ea696e5517beb670d503f2a

and doc mention: https://hledger.org/1.99.5/hledger.html#include-directive

I have usually used the journal as my master data, since it is the most expressive; but if csv rules can give a good enough conversion, sometimes it may be preferable to keep the data in csv, eg because

  • you want consistency not expressiveness
  • future improvements to your rules or hledger's conversion abilities will apply automatically
  • no need for an import / new transaction detection step
  • or simply to reduce the number of data formats involved.

Where previously you had to do the csv conversion as a separate step, now you can just include the csv or rules file directly. Then on each run, instead of parsing a journal, hledger applies csv rules. There might also be a performance difference between these, for large data (it wasn't noticeable with mine).

To answer more concretely: I had a good number of of transactions in a csv that's hard to convert well, and I expected the rules would improve over time; so I didn't want to bake today's converted entries into (multiple yearly) journals, which would add hassle tomorrow when I want to redo them.

2 Likes