Hi all,
This probably has a very small audience, but
Both the hand written ABNF parser and the generated parsers are using nimble_parsec
.
Example usage: https://github.com/princemaple/elixir-imap/blob/master/lib/imap/parser.ex
Hi all,
This probably has a very small audience, but
Both the hand written ABNF parser and the generated parsers are using nimble_parsec
.
Example usage: https://github.com/princemaple/elixir-imap/blob/master/lib/imap/parser.ex
Not so small, will definitely use it
Thanks for the great work!
[Removed, looks like I suck at copy pasing]
Gosh those RFCs are hard to use. I cant’ find a version without the body being cut with footer and headers.
By the way, thank you very much for this project.
Indeed I have been having some problems when generating parsers. One example,
I took the IRI grammar from RFC 3987 - Internationalized Resource Identifiers (IRIs) and saved it as a file: jsv/priv/grammars/iri.abnf at main · lud/jsv · GitHub
But it does not seem to fully parse this IRI: https://en.wiktionary.org/wiki/Ῥόδος
, it returns {:ok, ...}
but does not consume the whole string.
Hi @lud , I did a quick test and indeed the given url is not parsed fully. I also tested swapping the last part with Chinese “你好” and it parsed correctly. I’m not an expert in encoding and am currently unsure if it’s the functionality or the data that’s causing this. Shall we move the discussion to an issue on the repo?
Yes I’ll create the issue.
Edit: here you go
v1.3.0 was released with a special byte mode, in case your ABNF describes byte representation in stead of codepoints.
core.abnf
*HEXDIG
on "1A"
, instead of getting [49, 65]
, you get ["1", "A"]
List.to_string
on either one gives you the same result - "1A"
char
defined,CHAR
will be ignored as well