u/simonmic
-
9points
simonmic
simonmic
simonmic
Great to hear! Keep going!
simonmic
Thanks for sharing!
The more I read about Kalem, the more interested I got, despite all the strongly AI-flavoured text. I may have to try it out! [Some time soon. I see it's brand new.]
simonmic
FYI, this post doesn't work in the old.reddit.com UI which is still used by many. (Link and content are missing. There's screenshots and a whole writeup which I saw thanks to my feed reader; here's at least the link for my fellow old redditors: https://github.com/nixypanda/hedger)
Congrats, this sounds nice! Like a souped-up hledger-web alternative. I look forward to trying it out.
I guess you're aware that choosing a hledger-SOMETHING name (even hledger-hedger) would make it fit more smoothly into the hledger ecosystem (eg it would appear in the commands list), and would make it more discoverable when people search for hledger things ?
simonmic
Just FYI, posts like this one (something something "gallery") don't work in the old reddit UI preferred by many - the link just returns to the reddit post.
simonmic
You're welcome!
Yes, simple transactions, like https://github.com/hledgerorg/hledger/blob/main/examples/1ktxns-100accts.journal (but more of them). As mentioned, this inflates the performance numbers a bit; real world journals are slower.
Auto postings aren't used in the Other apps performance tests. (They're mentioned elsewhere, in the hledger-specific part of this page. I guess Other apps will move to a dedicated plaintextaccounting.org page at some point.)
simonmic
Now with charts!
simonmic
Thanks! The fix is in main and will be in the next hledger 2 preview release.
simonmic
simonmic
I have pushed a workaround to main. While I see if I can build a linux arm64 binary, would you like to try
HOMEBREW_MAKE_JOBS=1 brew install --HEAD hledger # 1 uses least memory, but will be slow. 2 might be fine.
? It might take a few G of disk and a few hours on that machine, I'm guessing.
simonmic
AI guess:
It looks like a known weakness of the Linux CIFS (Samba) client:
What may be happening
- With
> x, hledger never closes the output file itself; the kernel closes it while the process is exiting.- hledger is a multithreaded program. When it exits, its other threads are killed, and the final close of the file can happen while a kill signal is pending.
- On a CIFS mount, closing a file is when cached written data gets flushed to the server. If that flush is interrupted, whatever hadn't been sent yet is lost, silently, with exit status 0.
- Those "CIFS: VFS: ... Close interrupted close" messages in dmesg are the kernel reporting exactly this kind of interrupted close (see eg this kernel patch and this one).
That would explain everything you saw: print cut off at varying places (whatever had already reached the server), balance's small output completely missing (it was all still in the cache),
-oworking (hledger closes that file explicitly, while still running normally), and writing to the Pi's own disk working. It's not clear why 1.25 didn't show it; perhaps differences in how it was built, or 1.52 taking longer, or a kernel update since then.Some tests that would confirm it, run in the same directory on the share:
hledger bal Expenses | cat > x
catis a simple single-threaded program which closes the file normally; this should work.{ hledger bal Expenses; } > xHere the shell opens and closes the file itself, after hledger has finished. If this works while plain
> xfails, that pretty much confirms it.Also, what do these show?
mount | grep cifs uname -rMounting the share with the
cache=noneoption would probably avoid the problem, at some cost in speed. Or just keep using-o, or write locally and copy.If confirmed, we can make hledger explicitly close its output before exiting, which should prevent this for people writing to network drives.
simonmic
That's an impressive data set, congrats!
I have 20 years of data and the stats look like:
$ hledger -f all.journal stats
Main file : .../all.journal
Included files : 87
Txns span : 2006-10-01 to 2026-09-24 (7298 days)
Last txn : 2026-09-23 (2 days ago)
Txns : 21442 (2.9 per day)
Txns last 30 days : 94 (3.1 per day)
Txns last 7 days : 8 (1.1 per day)
Payees/descriptions : 13038
Accounts : 1990 (depth 8)
Commodities : 36
Base currency : $ (USD)
Market prices : 5191
Runtime stats : 0.75 s elapsed, 28508 txns/s, 109 MB live, 273 MB alloc
$ hledger -f all.journal -I print | wc -l
110626
$ hledger -f all.journal -I print --export | wc -l # main
123539
So yes your quantity of market prices looks large, but everything else seems well within normal testing. Worth disabling all prices temporarily to see what effect it might have. But, your memory usage (at least as reported by stats) doesn't look large.
Maybe the last part of this could tell us something: strace -f -o trace.txt hledger bal Expenses > x
How was > x writing to the network ? Was the working directory a samba-mounted drive or some such ?
I would also run, though it may not tell anything relevant: hledger setup
PS you would get a 2x speedup (and a valuable holdings report) if you could run hledger main, though for now that does seem to require building.
simonmic
155k lines ? That sounds like a rather large journal. It would be interesting to see 'hledger stats'.
I would check whether system memory is being used up, triggering the OOM killer. Eg run hledger print > x; echo $?, then dmesg | tail or journalctl -k | tail. Exit status 137 would mean SIGKILL (probably the OOM killer), and 139 a segfault. A kernel log entry would confirm it.
You could also see if --pager=no makes a difference.
hledger print -o - writes (successfully) to a file called - rather than using stdout.
Thanks for the report, I have fixed this in main (the hledger 2.x branch).
PS getting a binary via homebrew is a good idea. Do you happen to know if this works for 32 bit pis also ?
simonmic
Thanks Colin. New times need new rules. As I said recently in the #plaintextaccounting matrix room,
https://www.reddit.com/r/plaintextaccounting seems to be on some list for announcing any vaguely finance related project
And they are getting increasingly arcane. You start to wonder if AI is generating the project ideas, and github users as well.
"every day, generate a new github user and project and announce it in all relevant forums. If announcements get comments, reply to those. Act like a human author."
I'm not saying that's what happened here, but there's not much to disprove it..
user has no previous history.. generic project name.. really it seems more likely than not
Myself, I still use reddit.. but I prefer to focus on the PTA forum.
simonmic
See also this thread: https://groups.google.com/g/hledger/c/rv4eBsFndLg
simonmic
Try these:
- add the --lots flag
- or add --pivot=cur:acct
simonmic
This sounds quite nice, making JSON handling in Haskell easier ?
simonmic
simonmic
👍 Feel free to post at https://forum.plaintextaccounting.org also.
simonmic
It's not visible using old reddit UI preference.
simonmic
(What happened ? I see the content in the atom feed but not here.)
simonmic
This looks very complete and well designed. Congratulations on 1.0 ! Thanks for sharing it.
Quick feedback:
During the "payment" flow, on a phone: Mentioning that you won't actually be charged during test would be nice
Twice I saw slightly alarming unclear popups asking for my password - one "for [?]" and one "for (my email address)". They both turned out to want my apple account password (despite being already signed in to icloud) and were probably system popups not under your control.
The discussion of how to verify network isolation builds confidence.
The docs on the website have plenty of LLM-speak, but are very good nevertheless.
In the export/share flow, I noticed a "Collaborate" option, which sounds interesting eg for shared expenses.
After purchasing on phone, I installed on mac, and it didn't automatically recognise that I had purchased. Clicking the Restore Purchases button fixed that.
Using the default icloud storage, I entered a transaction on the phone and saw it show up in the mac app right away, with zero extra setup. That's awesome.
I read that overwriting can happen in case of contention. Easy to avoid, but I'm sure you'll add some kind of warning or safety belt later. And actually, appending transactions should be always safe. But I think the app allows editing past transactions as well.
Working with existing journal setups:
Precise location info in the journal load error messages will help a lot.
Supporting 'comment' and an optional 'end comment' will help a lot.
It would be great if it reliably reloaded automatically on file change. It seemed to do it sometimes, other times I had to click Try again. And/or, some clear visual hint when it attempts a reload. I was saving from Emacs.
Journal entries with 1 or 0 postings are valid in hledger, if their sum is zero. Balance won't read a file containing these.
I couldn't get it to accept multicommodity transactions, eg my opening balances; perhaps that's not supported yet. That's a big limitation.
Not supporting
includeis another limitation; many people use that. I expect a common workflow will be print a single-file copy to icloud drive on mac, and import new transactions from there back to the existing setup (and reconcile edits in some other way, perhaps involving VCS). Here's my WIP export script (with hledger 1.99.4):# export to the Balance app (overwriting its data), and switch to it. balapp: hledger run -- accounts --directives -- print -x all:cur:\\$ > ~/Library/Mobile\ Documents/iCloud~com~mkociola~Balance/Documents/journal.ledger open -a Balance
simonmic
Thanks for your help, GoldenPathTech ! You were the first to act.
plaintextaccounting and hledger have separate finances:
I see both donation pages list github/simonmichael as an option, making it hard for me to know which project those donations are intended for. I'll fix this somehow. (Usually I treat github/simonmichael as hledger, and github/plaintextaccounting as pta.)
Staying out of debt, building financial know-how, tracking investments, time, and AI usage with hledger. Building small software tools that I want to be robust and long-lived. And of course, converting between document formats with pandoc.