With many thanks to Anthropic for supporting the Ledger project

[John Wiegley]

As some of you who watch the GitHub activity may have noticed, I've been using AI a lot recently to help me increase the amount of testing coverage, address bugs, clean up some of the documentation and comments, add many more validation steps into our CI, and even modernize the codebase by updating it to C++17 standards. And then there's the rledger port to Rust as well that's been underway…

Yesterday, Anthropic gifted six months of usage of their Opus model to help further this development. With many thanks to them, my hope is that, using gifts like these, we will be able to get down to zero open bugs, 100% code coverage, and at least 10% further improvement in overall performance of common operations. And hopefully it won't even take six months to get there!

I also have a few other improvements planned, like rewriting the report query parser to use a real parser instead of the token-based hack that it uses now, as well as a better approach to external scripting that may allow for languages other than Python (while also improving the Python support that we have currently).

Stay tuned!

  John

[mb...@mbork.pl]

While I'm rather an LLM skeptic (even if I use Claude Code myself), this
is good news. May I humbly ask whether there's a chance of improving
the documentation, too? (Emacs Ledger mode, while great, could also use
some minor improvements.)

Since the common answer to such questions is "this is a FOSS project,
PRs are welcome", I think I can safely say that I can try and work on
a few aspects - either via submitting patches (especially for the docs)
or reporting bugs/feature requests.

Thanks for your work on Ledger, John! (BTW, I've been using it for well
over a decade now, being a former GNUCash user.)

Best,

--
Marcin Borkowski
https://mbork.pl

[Igbanam Ogbuluijah]

This is exciting news, John! 

Could Ruby be considered as one of those scripting languages? I will do my best to help with this one. Also, since you're already thinking about Reports — if it's not too much trouble — could you consider tabular views for these reports?

Thanks for the awesome work here as always. 

Igbanam

--

---
You received this message because you are subscribed to the Google Groups "Ledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ledger-cli/874imuke49.fsf%40mbork.pl.

[John Wiegley]

>>>>> "m" == mbork <mb...@mbork.pl> writes:

> While I'm rather an LLM skeptic (even if I use Claude Code myself), this is
> good news. May I humbly ask whether there's a chance of improving the
> documentation, too? (Emacs Ledger mode, while great, could also use some
> minor improvements.)

Hi Marcin!

Yes, I’m in the middle of a fairly large documentation revision -- both in the
code and the manual. The remaining stages of this plan are in the file:

https://github.com/ledger/ledger/blob/main/DOC-WORK-PLAN.md

I hadn’t considered updating the Emacs mode until you mentioned it, but that’s
a worthwhile next project after this.

John

[John Wiegley]

>>>>> "IO" == Igbanam Ogbuluijah <xigb...@gmail.com> writes:

> This is exciting news, John!
>
> Could Ruby be considered as one of those scripting languages? I will do my
> best to help with this one. Also, since you're already thinking about
> Reports — if it's not too much trouble — could you consider tabular views
> for these reports?

Alexis Hildebrandt has been talking about using SWIG so that almost any other
scripting language could be used. This would entirely remove all Python bits
from within Ledger, changing it to a calculational “core” library that
provides exports any other scripting languages can link into. It will depends
on all of the core types being able to map into that language (such as
amounts, balances, etc), but I intend to explore this further once my Claude
allocation resets tonight. Turns out that the Max 20x plan is nowhere near
enough for all the work I want to get done in this project!

> Thanks for the awesome work here as always.

Thank you all!

John

[John Wiegley]

>>>>> "IO" == Igbanam Ogbuluijah <xigb...@gmail.com> writes:

> Also, since you're already thinking about Reports — if it's not too much
> trouble — could you consider tabular views for these reports?

On the reporting question, it may be better for Ledger to provide better data
exporting so that other languages can turn that data into fancy reports of
various kinds. The core C++ engine already does quite a lot, and reports are a
much more highly personal thing that should be easier for the user to
customize and modify than what the current reporting schemes in Ledger allow
for (or that I could ever be able to fully predict).

John

[mb...@mbork.pl]

On 2026-03-05, at 06:22, "John Wiegley" <jwie...@gmail.com> wrote:

> Hi Marcin!
>
> Yes, I’m in the middle of a fairly large documentation revision -- both in the
> code and the manual. The remaining stages of this plan are in the file:
>
> https://github.com/ledger/ledger/blob/main/DOC-WORK-PLAN.md

I'm getting 404.

> I hadn’t considered updating the Emacs mode until you mentioned it, but that’s
> a worthwhile next project after this.

Thanks! I'll try to either submit a PR or at least report one annoying
bug I've noticed.

[John Wiegley]

>>>>> mbork <mb...@mbork.pl> writes:

>> https://github.com/ledger/ledger/blob/main/DOC-WORK-PLAN.md

> I'm getting 404.

I moved quickly enough that the result of all the work is now in main and has
been completed. At least for this first phase.

>> I hadn’t considered updating the Emacs mode until you mentioned it, but
>> that’s a worthwhile next project after this.

> Thanks! I'll try to either submit a PR or at least report one annoying bug
> I've noticed.

Thank you!

John

[Tavis Ormandy]

On 2026-03-05, John Wiegley wrote:
> Yesterday, Anthropic gifted six months of usage of their Opus model to help
> further this development. With many thanks to them, my hope is that, using
> gifts like these, we will be able to get down to zero open bugs, 100% code
> coverage, and at least 10% further improvement in overall performance of
> common operations. And hopefully it won't even take six months to get there!
>

I'm less enthusiastic about this, I feel like I have to keep watching
the repo like a hawk to make sure the features I use won't get broken by
claude in the next release :(

I know humans can break features too, but humans generate code at a
pace that other humans can keep up with.

Tavis.

--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger tav...@sdf.org
_\_V _( ) _( ) @taviso

[mb...@mbork.pl]

On 2026-03-21, at 03:41, Tavis Ormandy <tav...@gmail.com> wrote:

> On 2026-03-05, John Wiegley wrote:
>> Yesterday, Anthropic gifted six months of usage of their Opus model to help
>> further this development. With many thanks to them, my hope is that, using
>> gifts like these, we will be able to get down to zero open bugs, 100% code
>> coverage, and at least 10% further improvement in overall performance of
>> common operations. And hopefully it won't even take six months to get there!
>>
>
> I'm less enthusiastic about this, I feel like I have to keep watching
> the repo like a hawk to make sure the features I use won't get broken by
> claude in the next release :(

My (admittedly limited) experience with Claude is that it's a nice
productivity tool in the hand of a senior (or mid) programmer,
a possible time sink/procrastination tool in the hand of anyone, and
an analogue of a (sometimes slightly jamming) chainsaw operated by
a teenager with a hangover in the hand of a junior.

So, given John's expertise, I would be pretty assured that no breakage
should occur.

[Tavis Ormandy]

No, I mean, it's literally breaking features right now. I would strongly
recommend you check main branch to see if your ledger still works -
there's a good possibility you will have to make changes.

For example, if you use effective dates in automated transactions, they
probably won't work anymore:

= expr "cleared and aux_date"
assert aux_date != date

This was caused by a claude change:
https://github.com/ledger/ledger/commit/227dac58bf816ce687d1954d0c542f92d71ae7e1
Co-Authored-By: Claude Sonnet 4.6 <nor...@anthropic.com>

In fact, the way balance assertions work with effective dates is now completely
different, so if you use effective dates (e.g. 2001/12/12=2002/12/12 or
[=2021/12/12]), I would *strongly* recommend testing with main!

There's more, you used to be able to do this:

2018/12/31 * Test
Assets:Foo = $78.90
Assets:Bar

That won't work with --permissive anymore, another claude change broke it:

https://github.com/ledger/ledger/commit/a5e80a1cb2510b11c9756af5b483295201a10795
Co-Authored-By: Claude Sonnet 4.6 <nor...@anthropic.com>

The way the format directive works has also changed, you used to be able
to do things like this:

commodity $
format $1,000.00

But now that will generate warnings in strict mode if you use any
expressions, e.g.:

define salestax = 1.09625

2024/12/05 * Foo
Expenses:Bar ($6.99 * salestax)
Assets:Baz

https://github.com/ledger/ledger/commit/8da7395f23670f1d616617bb29f04b96b0be94dc
Co-Authored-By: Claude Sonnet 4.6 <nor...@anthropic.com>

I'm not sure if this is a bug or not, but the way regexes are escaped is
now different and this broke my ledger, e.g. this will now cause an
error, but used to work fine:

tag rating
assert value =~ /^\\*{0,5}$/

This was changed in:
https://github.com/ledger/ledger/commit/d84f628801b3babaacfebd240ba7a9f2907b86c0
Co-Authored-By: Claude Sonnet 4.6 <nor...@anthropic.com>

These are just the changes I bisected tonight that caused my ledger
files to stop working. If I don't use the feature I won't notice the
problem so can't report it. I would strongly recommend everyone on the
list check the features they use.

I still haven't got my ledger parsing fully with main yet, I'm slowly
working through the changes.

I personally value the stability, predictability and reliability of
ledger, and I'm just saying these changes worry me.

[Tavis Ormandy]

On 2026-03-21, Tavis Ormandy wrote:
> I still haven't got my ledger parsing fully with main yet, I'm slowly
> working through the changes.
>
> I personally value the stability, predictability and reliability of
> ledger, and I'm just saying these changes worry me.
>
> Tavis.
>

There was only one more change I needed to get my ledger to parse, the
way computed lot prices work has changed (e.g. 100 FOO @@ $1,000 and
{{$,1000}}).

This isn't really a bad idea, but it will break old ledgers that rely
on the way precision used to work, like mine :(

https://github.com/ledger/ledger/commit/b7029e469fbc6002bcf6bcddf0e7c895b252c2a6

Co-Authored-By: Claude Sonnet 4.6 <nor...@anthropic.com>

I think occasional breakage for complicated ledgers like mine is
understandable - that's why I test main to report problems before
release...but claude is making these rapidfire changes daily,
and I can't keep up.

[Simon Michael (sm)]

Those are some excellent regression reports.

I'm interested in this topic too of course. I will say it's incredibly
hard to avoid causing regressions for some existing data or workflows
when changing or fixing things in a PTA app, even with an extensive test
suite.

I wouldn't be sure if the AI use specially is the cause, or if AI was
simply the enabling factor allowing the human dev to become active.
Any dev activity increases the risk of breaking somebody's usage.

How could the risk be reduced ? More tests ? (AI could help with that.)
Stable and unstable branches ? Easy quick reporting & fixing of regressions ?

[John Wiegley]

>>>>> "TO" == Tavis Ormandy <tav...@gmail.com> writes:

> I'm less enthusiastic about this, I feel like I have to keep watching the
> repo like a hawk to make sure the features I use won't get broken by claude
> in the next release :(
>
> I know humans can break features too, but humans generate code at a pace
> that other humans can keep up with.

Hi Travis,

My apologies in advance for some of the breakages that will happen, although
it’s also true I’ve broken things as a human creating commits in the recent
past, so it doesn’t surprise me that Claude would sneak some of these past…

I had tried very hard to increase test coverage before letting the AI “loose”,
so to speak, in the hopes of nailing down existing behavior and restricting
modifications to only the bug being fixed. It appears, however, that the test
coverage is still not nearly good enough.

Given that, I think it’s likely time to let this experiment slow down, after
this weekend (more fixes coming tomorrow). Perhaps we need a few months now of
catching up and making sure that everything broken is righted again. Your
recent bug reports will help greatly with this, as I can turn each into a
regression test to guard these future breakage.

My goal right now is to get the issue list down to zero, if possible; to
increase testing and stability; and to get C++Ledger to a point where it
represents as much of a bug-free, stable base for accounting as possible.
There are further changes to be made to move further from Boost toward the
standard libraries, and to begin adopting some of the improvements in C++20.
But other than that I have no further major plans beyond testing and
stability.

John

[John Wiegley]

>>>>> "SM(" == Simon Michael (sm) <si...@joyful.com> writes:

> How could the risk be reduced ? More tests ? (AI could help with that.)
> Stable and unstable branches ? Easy quick reporting & fixing of regressions?

Good questions!

If I know there is a more active core of “early adopters”, I’d be happy to
move this AI development to a `next` branch, where it only release into `main`
once that group is happened that nothing significant has broken.

As it stands, the current `main` seems a little far from being ready for
release. It will need a good while for the dust to settle and the remaining
regression reports to come in, before I’m confident that it won’t break others
upon release.

John

[Tavis Ormandy]

On 2026-03-22, Simon Michael (sm) wrote:
> Those are some excellent regression reports.
>
> I'm interested in this topic too of course. I will say it's incredibly
> hard to avoid causing regressions for some existing data or workflows
> when changing or fixing things in a PTA app, even with an extensive test
> suite.
>
> I wouldn't be sure if the AI use specially is the cause, or if AI was
> simply the enabling factor allowing the human dev to become active.
> Any dev activity increases the risk of breaking somebody's usage.
>
> How could the risk be reduced ? More tests ? (AI could help with that.)
> Stable and unstable branches ? Easy quick reporting & fixing of regressions
> ?
>

Those ideas all sound good to me, I can't think of any reason not to be
happy about more tests and code coverage, I don't have any concerns
about AI helping with that.

I definitely wish I had submitted more tests! If that process can
be streamlined in future, e.g. an easy form where you paste some
transactions, rather than having to go through the PR process.

(Not that submitting a PR is onerous, it's just a lot of friction)

[Tavis Ormandy]

Thanks John! I would definitely volunteer to test.

I think if main has something like Linux's "Don't break userspace", but
any new features must get added to next first, that's a strong enough
incentive for people to test (because if you want to submit a PR with a
new feature, you have to add it to next!).

[John Wiegley]

Hi Travis,

Today, your use case made me realize that I need to ask AI to generate a new kind of testing tool. This will be a tool that, given a data file that lives on your own machine, will run every possible report and options combination for each of those reports against that data file. It will write them all to a series of output files that can be compared against the latest master commit.

This way I can use this tool along with the AI to detect whether any changes are affecting these reports that I generate from my own data files. You can then use it to help validate updates on main rather than having to come across it by chance as you run your reports.

John (from my iPhone)

[mb...@mbork.pl]

On 2026-03-22, at 11:57, John Wiegley <jwie...@gmail.com> wrote:

> Hi Travis,
>
> Today, your use case made me realize that I need to ask AI to generate
> a new kind of testing tool. This will be a tool that, given a data
> file that lives on your own machine, will run every possible report
> and options combination for each of those reports against that data
> file. It will write them all to a series of output files that can be
> compared against the latest master commit.
>
> This way I can use this tool along with the AI to detect whether any
> changes are affecting these reports that I generate from my own data
> files. You can then use it to help validate updates on main rather
> than having to come across it by chance as you run your reports.

So, basically, snapshot tests? I come from JS world, so Ava seems
a natural choice for me
(https://github.com/avajs/ava/blob/main/docs/04-snapshot-testing.md),
but I'm pretty sure there are plenty of tools for that, no need to
create another one.

[John Wiegley]

>>>>> "TO" == Tavis Ormandy <tav...@gmail.com> writes:

> Thanks John! I would definitely volunteer to test.

OK, I’ve just pushed a PR that hopefully will address some or all of the
issues you posted. Can you please try this out? Still working on main for the
moment, until we get the breakages settled.

Also currently working on that “usage coverage” tool.

> I think if main has something like Linux's "Don't break userspace", but any
> new features must get added to next first, that's a strong enough incentive
> for people to test (because if you want to submit a PR with a new feature,
> you have to add it to next!).

Yes, hopefully! Maybe we can switch to this new “git-flow” model by end of
month.

John

[Tavis Ormandy]

On 2026-03-23, John Wiegley wrote:
>>>>>> "TO" == Tavis Ormandy <tav...@gmail.com> writes:
>
>> Thanks John! I would definitely volunteer to test.
>
> OK, I’ve just pushed a PR that hopefully will address some or all of the
> issues you posted. Can you please try this out? Still working on main for the
> moment, until we get the breakages settled.

Thanks John, looks like it handles my files! The new strict warning
warns on some cases where I did have more precision from a statement,
but wanted nicely aligned figures so set a less precise format.

I don't mind it, I will just manually truncate my data :)

I did have to make some changes to my transactions, because balance
assertions and --effective work differently now, i.e. transactions are
reordered now.

e.g. in release, this is fine:

2024/09/13 * Cafe ; Coffee
Expenses:Dining $5
Liabilities:CreditCard
2024/09/25=2024/10/01 * Visa ; Pay Off Credit Card
Liabilities:CreditCard $5 = $0
Assets:Checking
2024/09/30 * Cafe ; Coffee
Expenses:Dining $5
Liabilities:CreditCard -$5 = -$5

That will no longer work in main:

$ ledger --effective --args-only --no-pager -f test.ldg bal
While parsing file "test.ldg", line 9:
While parsing posting:
Liabilities:CreditCard -$5 = -$5
^^^
Error: Balance assertion off by $5 (expected to see $-10)

I dunno if this is intended or not, I understand the logic of the
change, but it's a big difference from how it used to work? You used to
be able to turn effective on or off at runtime, which was nice because
you could have "real" dates and "idealized" dates (e.g. nudge payments
into the month they apply to for budgeting reasons). Now you can't, and
have to choose if you always want --effective or not.

I'll file a bug because you probably want a testcase no matter which
output is correct!

>
> Also currently working on that “usage coverage” tool.
>
>> I think if main has something like Linux's "Don't break userspace", but any
>> new features must get added to next first, that's a strong enough incentive
>> for people to test (because if you want to submit a PR with a new feature,
>> you have to add it to next!).
>
> Yes, hopefully! Maybe we can switch to this new “git-flow” model by end of
> month.
>
> John
>

[John Wiegley]

>>>>> "TO" == Tavis Ormandy <tav...@gmail.com> writes:

> I'll file a bug because you probably want a testcase no matter which output
> is correct!

Thank you! That help me think through this.

>> Also currently working on that “usage coverage” tool.

I’ve added this as a PR now: https://github.com/ledger/ledger/pull/2967

As I test I created a local branch that set my repository back to the “Before
AI” times (roughly commit 5eeaef91b2ea46d603b62c19a2836966beb0b210). Then I
ran the test tool on set of combinations both computed and inferred from the
docs and the tests (at that time):

--- Snapshot Summary ---
Total: 752
Success: 483
Warnings: 5 (exit 0 + stderr)
Errors: 262
Timeouts: 2
Elapsed: 30.2s

Then I run the test using a binary from today, but inferring option groups
from the same source tree:

--- Snapshot Summary ---
Total: 764
Success: 595
Warnings: 5 (exit 0 + stderr)
Errors: 163
Timeouts: 1
Elapsed: 30.3s

Sadly the diffs are 163 MB in size, so it’s not going to be very meaningful to
look at “what changed”. However, if use between a small range of commits, it
should be very helpful in identifying whether recent Ledger changes have
broken your setup, without needing to make your data available or even try to
anonymize it. See the new `README-snapshot.md` in that PR.

I have one more forecasting-related PR going in, and then will cool my heels
until you’re back to golden, Tavis.

John

[Alexandre Rademaker]

https://leodemoura.github.io/blog/2026-2-28-when-ai-writes-the-worlds-software-who-verifies-it/ and
https://leodemoura.github.io/blog/2026-3-16-who-watches-the-provers/

"Testing can show the presence of bugs, never their absence."

It's not trivial, but I'd like to see the ledger fully formally verified. Helping this kind of project is one of the goals of https://www.cslib.io/.

Happy to elaborate if that makes sense.

Best,

--
Alexandre Rademaker
http://arademaker.github.io

[Tavis Ormandy]

On 2026-03-23, John Wiegley wrote:

>>>>>> "TO" == Tavis Ormandy <tav...@gmail.com> writes:
>
>> I'll file a bug because you probably want a testcase no matter which output
>> is correct!
>
> Thank you! That help me think through this.
>
>>> Also currently working on that “usage coverage” tool.
>
> I’ve added this as a PR now: https://github.com/ledger/ledger/pull/2967
>

Ahh, I see what you mean, neat!

> I have one more forecasting-related PR going in, and then will cool my heels
> until you’re back to golden, Tavis.
>

Thanks John, really appreciate it! I filed one more bug, I just noticed
the precision change doesn't always work correctly if the lots don't
divide perfectly. e.g.:

2025/01/01 * Testing
Assets:Brokerage 101 FOO @@ $250.00
Assets:Brokerage -$250
2025/01/02 * Testing
Assets:Brokerage -101 FOO {{$250}} [2025-01-01] @@ $500
Assets:Brokerage $500
Income:Capital Gains

I think this should result in no lots, and Assets:Brokerage having $250, but it doesn't:

$ ledger --args-only --no-pager -f test.ldg bal --lots
$250
101 FOO {$2.47524752} [2025/01/01]
-101 FOO {$2.475248} [2025/01/01] Assets:Brokerage
$-250 Income:Capital Gains
--------------------
101 FOO {$2.47524752} [2025/01/01]

I think this is because of:

https://github.com/ledger/ledger/commit/b7029e469fbc6002bcf6bcddf0e7c895b252c2a6

If I temporarily round everything up to be perfectly divisible,
everything seems to work for me.

Tavis.

[John Wiegley]

>>>>> "AR" == Alexandre Rademaker <arade...@gmail.com> writes:

> It's not trivial, but I'd like to see the ledger fully formally verified.

I would love this too. First, we need a formal semantics are what a ledger
actually *is*. One thing that makes Ledger easier to formally verify is that
it’s always a pure function from inputs to output, so we need to define the
category of inputs, and the category of each of the outputs, so that we can
always know whether an output exists within the space of what is allowed by
the corresponding input.

I’ve done some drafting of ideas around this before, a few times in fact, but
never got to the point of writing code yet. Rocq is my preferred prover, but
I’m also interested in Lean these days.

John

[Simon Michael]

Have you seen

On Double-Entry Bookkeeping: The Mathematical Treatment by David Ellerman ?

https://arxiv.org/abs/1407.1898
http://www.ellerman.org/double-entry-bookkeeping

I saved a few more links at https://hledger.org/accounting.html#theory .

> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Ledger" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ledger-cli/6O6LYXFhH1s/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> ledger-cli+...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/ledger-cli/m2qzpaceug.fsf%40hera.lan.

[Tavis Ormandy]

On 2026-03-23, Tavis Ormandy wrote:
> Thanks John, really appreciate it! I filed one more bug, I just noticed
> the precision change doesn't always work correctly if the lots don't
> divide perfectly. e.g.:
>

Oops, one more issue I only noticed because when I piped a report into
gnuplot the graph didn't look right...

This commit changed how averaging works in the period reports:

https://github.com/ledger/ledger/commit/e44c39f7ddf84e35dbf0e28547ad7accffef9568

Now if you use distributed costs, the report drops the average to zero
for some reason:

https://github.com/ledger/ledger/issues/2980

[John Wiegley]

>>>>> "SM" == Simon Michael <si...@joyful.com> writes:

> Have you seen
> On Double-Entry Bookkeeping: The Mathematical Treatment by David Ellerman ?

I hadn’t! Will take a look, thank you.

John

[John Wiegley]

Hi Tavis,

Since I had spare tokens that were about to expire out last night, I decided
to set Claude on fixing every remaining issue in GitHub with a “bug” label.
The result -- so far -- is 89 PRs (and counting) waiting for review.

I was wondering if you’d like to check out any of these that might affect
areas you’re interested in:

https://github.com/ledger/ledger/pulls?page=1&q=is%3Apr+is%3Aopen

Once this set goes in, we’re going to be getting very close to “inbox zero” on
our GitHub issues, with just feature requests remaining.

John

[Tavis Ormandy]

I can test -- no problem at all! Can you keep the new changes in a
branch temporarily?

I see there's a lot of changes, I just think that will make it easier to
compare this new batch to main.

I'm currently minimizing things manually, maybe I should automate that
if it looks like it might be a big job... I'll wait to see if it's easy :)

[Tavis Ormandy]

On 2026-03-27, Tavis Ormandy wrote:
> On 2026-03-27, John Wiegley wrote:
>> Hi Tavis,
>>
>> Since I had spare tokens that were about to expire out last night, I decided
>> to set Claude on fixing every remaining issue in GitHub with a “bug” label.
>> The result -- so far -- is 89 PRs (and counting) waiting for review.
>>
>> I was wondering if you’d like to check out any of these that might affect
>> areas you’re interested in:
>>
>> https://github.com/ledger/ledger/pulls?page=1&q=is%3Apr+is%3Aopen
>>
>> Once this set goes in, we’re going to be getting very close to “inbox zero” on
>> our GitHub issues, with just feature requests remaining.
>>
>
> I can test -- no problem at all! Can you keep the new changes in a
> branch temporarily?
>
> I see there's a lot of changes, I just think that will make it easier to
> compare this new batch to main.
>

I'm not really a git expert, but I tried something like...

for branch in $(git branch -a | grep 'johnw/fix-'); do
git merge --abort
git reset --hard main
git clean -fd -e build/ -e check.sh

if git merge "$branch" --no-edit; then
cmake ...
if diff -u <(build/ledger bal) <(ledger bal); then
...
fi
fi
done

There are a lot of breaking changes, it might take some time to minimize
testcases. What is the best way to handle it?

[John Wiegley]

>>>>> "TO" == Tavis Ormandy <tav...@gmail.com> writes:

> I can test -- no problem at all! Can you keep the new changes in a branch
> temporarily?
>
> I see there's a lot of changes, I just think that will make it easier to
> compare this new batch to main.

I think the easiest way to do that would just be to make a local tag of the
current main branch, since right now all of the GitHub PRs target main, so
merging them will bring them into that branch.

> I'm currently minimizing things manually, maybe I should automate that if it
> looks like it might be a big job... I'll wait to see if it's easy :)

Minimizing?

John

[John Wiegley]

>>>>> "TO" == Tavis Ormandy <tav...@gmail.com> writes:

> There are a lot of breaking changes, it might take some time to minimize
> testcases. What is the best way to handle it?

Very good question. I think first I’d like to know: Which are the ones that
yield no differences?

John

[Tavis Ormandy]

On 2026-03-28, John Wiegley wrote:
>>>>>> "TO" == Tavis Ormandy <tav...@gmail.com> writes:
>

>> I'm currently minimizing things manually, maybe I should automate that if it
>> looks like it might be a big job... I'll wait to see if it's easy :)
>

> Minimizing?
>

I just mean finding a minimal set of transactions that demonstrate the problem.

>> There are a lot of breaking changes, it might take some time to minimize
>> testcases. What is the best way to handle it?
>
> Very good question. I think first I’d like to know: Which are the ones that
> yield no differences?
>

These ones seem okay from initial (automated) testing:

remotes/origin/johnw/fix-1045
remotes/origin/johnw/fix-1048
remotes/origin/johnw/fix-1065
remotes/origin/johnw/fix-1091
remotes/origin/johnw/fix-1100
remotes/origin/johnw/fix-1110
remotes/origin/johnw/fix-1114
remotes/origin/johnw/fix-1115
remotes/origin/johnw/fix-1122
remotes/origin/johnw/fix-1128
remotes/origin/johnw/fix-1129
remotes/origin/johnw/fix-1130
remotes/origin/johnw/fix-1134
remotes/origin/johnw/fix-1145
remotes/origin/johnw/fix-1154
remotes/origin/johnw/fix-1164
remotes/origin/johnw/fix-1165
remotes/origin/johnw/fix-1556
remotes/origin/johnw/fix-1565
remotes/origin/johnw/fix-1585
remotes/origin/johnw/fix-1593
remotes/origin/johnw/fix-1602
remotes/origin/johnw/fix-1604
remotes/origin/johnw/fix-1607
remotes/origin/johnw/fix-1608
remotes/origin/johnw/fix-1625
remotes/origin/johnw/fix-1634
remotes/origin/johnw/fix-2945
remotes/origin/johnw/fix-573
remotes/origin/johnw/fix-583
remotes/origin/johnw/fix-586
remotes/origin/johnw/fix-588
remotes/origin/johnw/fix-590
remotes/origin/johnw/fix-594
remotes/origin/johnw/fix-603
remotes/origin/johnw/fix-606
remotes/origin/johnw/fix-612
remotes/origin/johnw/fix-617
remotes/origin/johnw/fix-620
remotes/origin/johnw/fix-622
remotes/origin/johnw/fix-623
remotes/origin/johnw/fix-628
remotes/origin/johnw/fix-636
remotes/origin/johnw/fix-647
remotes/origin/johnw/fix-649
remotes/origin/johnw/fix-652
remotes/origin/johnw/fix-655
remotes/origin/johnw/fix-663
remotes/origin/johnw/fix-664
remotes/origin/johnw/fix-668
remotes/origin/johnw/fix-670
remotes/origin/johnw/fix-671
remotes/origin/johnw/fix-675
remotes/origin/johnw/fix-696
remotes/origin/johnw/fix-697
remotes/origin/johnw/fix-698
remotes/origin/johnw/fix-707
remotes/origin/johnw/fix-717
remotes/origin/johnw/fix-723
remotes/origin/johnw/fix-725
remotes/origin/johnw/fix-729
remotes/origin/johnw/fix-731
remotes/origin/johnw/fix-737
remotes/origin/johnw/fix-767
remotes/origin/johnw/fix-779
remotes/origin/johnw/fix-797
remotes/origin/johnw/fix-815
remotes/origin/johnw/fix-816
remotes/origin/johnw/fix-834
remotes/origin/johnw/fix-842
remotes/origin/johnw/fix-854
remotes/origin/johnw/fix-865
remotes/origin/johnw/fix-870
remotes/origin/johnw/fix-911
remotes/origin/johnw/fix-954
remotes/origin/johnw/fix-958
remotes/origin/johnw/fix-963