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

Make generated parsers usable on the web #461

Open
stephanemagnenat opened this issue Jun 7, 2024 · 2 comments
Open

Make generated parsers usable on the web #461

stephanemagnenat opened this issue Jun 7, 2024 · 2 comments

Comments

@stephanemagnenat
Copy link

stephanemagnenat commented Jun 7, 2024

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:

  • use a poly-fill such as web-time,
  • 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.

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 call Instant::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 when Instant::now() is unsupported, for example in worklets, which I would say is strictly a good thing.

@ltratt
Copy link
Member

ltratt commented Jun 7, 2024

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.

@stephanemagnenat
Copy link
Author

stephanemagnenat commented Jul 18, 2024

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.

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

2 participants