Open stephanemagnenat opened 4 months ago
modify grmtools to disable timeout, for example by creating an abstraction around the notion of "enough work has been done", and allow other conditions such as number of trials.
There's definitely potential to do this. One simple way of doing this might be to take a hard example (e.g. the "((((((" problem), see how many repairs are done in 0.5s on a normal machine, and use that number as a proxy for timeouts on platforms (e.g. WASM) which lack timing facilities.
Please note that the duration 0.5s for recovery is not ideal to be hard-coded: for example, on the web where multi-threading is a pain (one needs to use web workers), in many cases of simple grammars one might want to use a very short duration for error recovery to stick within an unnoticeable delay, at the expense of worst recovery, to avoid having to deal with web workers.
As discussed in #145, currently the generated parsers are not available on WebAssembly in browsers, due to
Instant::now()
panicking. I have an application (https://cand.li) which requires me to run the generated parser on the browser, so I would like to solve this compatibility problem. I see two ways forward:I do not have a strong opinion either way.
Alternatively (or in addition, also mentioned in #145, but never done), we could also slightly refactor
parser.rs:371
to not callInstant::now()
when recovery is not used. That might be the cheapest way, in term of changes, but of course only brings us half way (works on the web without error recovery, but at least it would allow the traditional lex/yacc use case there). As an additional benefit, it would enable using the parser without error recovery even whenInstant::now()
is unsupported, for example in worklets, which I would say is strictly a good thing.