Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Parser error reporting #231

Open
the-solipsist opened this issue Sep 5, 2022 · 7 comments
Open

[Feature Request] Parser error reporting #231

the-solipsist opened this issue Sep 5, 2022 · 7 comments

Comments

@the-solipsist
Copy link
Contributor

Other {h}ledger-language grammar add-ons (such as the grammar for Atom) recognizes parser errors, and thus prevents you from making mistakes while adding/editing entries.

It'd be great if this could be made an optional feature with an override command.

@mhansen
Copy link
Owner

mhansen commented Sep 5, 2022 via email

@the-solipsist
Copy link
Contributor Author

I'm not a coder, but I believe this is the code which the Atom add-on uses:
https://github.com/4ourbit/language-ledger/blob/master/lib/language-ledger.coffee#L46-L91

@mhansen
Copy link
Owner

mhansen commented Sep 5, 2022 via email

@simonmichael
Copy link

simonmichael commented Sep 5, 2022 via email

@the-solipsist
Copy link
Contributor Author

And as per @simonmichael, hledger check (or perhaps hledger check parseable) would be the fastest / most appropriate command for checking validity.

@mhansen
Copy link
Owner

mhansen commented Sep 6, 2022

Looks like hledger-flycheck emacs plugin invokes "hledger check" on the shell: https://github.com/DamienCassou/flycheck-hledger/blob/master/flycheck-hledger.el#L63

Thanks for the pointers. Let's try some benchmarks on my shiny new M1 (which should be a bit faster than my other laptop):

$ hyperfine "hledger check" "hledger check parseable" "hledger bal" "hledger stats"
Benchmark #1: hledger check
  Time (mean ± σ):     471.3 ms ±   5.1 ms    [User: 438.8 ms, System: 26.9 ms]
  Range (min … max):   465.7 ms … 477.8 ms    10 runs
 
Benchmark #2: hledger check parseable
  Time (mean ± σ):     471.5 ms ±   6.0 ms    [User: 439.8 ms, System: 26.4 ms]
  Range (min … max):   465.1 ms … 480.2 ms    10 runs
 
Benchmark #3: hledger bal
  Time (mean ± σ):     582.1 ms ±   6.0 ms    [User: 545.0 ms, System: 30.8 ms]
  Range (min … max):   575.4 ms … 593.4 ms    10 runs
 
Benchmark #4: hledger stats
  Time (mean ± σ):     559.5 ms ±   4.8 ms    [User: 527.9 ms, System: 26.1 ms]
  Range (min … max):   555.9 ms … 568.2 ms    10 runs
 
Summary
  'hledger check' ran
    1.00 ± 0.02 times faster than 'hledger check parseable'
    1.19 ± 0.02 times faster than 'hledger stats'
    1.24 ± 0.02 times faster than 'hledger bal'

Looks like hledger check and hledger check parseable are about the same speed, both 19% faster than stats and 24% faster than bal.

Some stats about my journal:

$ hledger stats
...
Transactions span        : 2008-05-19 to 2022-09-04 (5221 days)
Last transaction         : 2022-09-03 (3 days ago)
Transactions             : 15529 (3.0 per day)
...
Run time (throughput)    : 0.57s (27471 txns/s)

I imagine it'd be near-instant if I split by year. I don't really want to split by year though.

Maybe to be quick, an extension could use hledger check on the currently-edited individual file along with --ignore-assertions, because none of my individual files balance correctly without other files. I was a bit surprised that check and check parseable apply the balance assertions (I would have guessed that's beyond the scope of parsing?).

@simonmichael
Copy link

simonmichael commented Sep 6, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants