kaitai_struct_webide
kaitai_struct_webide copied to clipboard
Invalid line number while parsing YAML if comments are used
Report: https://github.com/kaitai-io/kaitai_struct_webide/issues/61#issuecomment-365401658 Example:
# Line 1
# Line 2
# Line 3
# Line 4
types:
animal:
doc: An animal species
seq:
- id: species
type: s4
plant:
seq:
- id: species
type: s4
Shows error at line 4, while the error is at line 7.
Depending on the purpose of the comments, a workaround (subject to another set of issues) is to use a doc
tag. I had an 18 line block comment at the top of my .ksy
file which I replaced with a giant blob of doc
. That "removed" 18 lines worth of incorrect line counting from the error I used to recreate the issue. When I calculated the number of incorrect lines (5 ...) I found 5 additional comment lines which began with #
between the error and the top of the file. Another workaround, which may be less painful, is adding whitespace to the start of the line. <--- @koczkatamas Tamas, that may be your clue as to where the parser is losing line counts.
I also confirmed that the new comment blob was added to the top of the generated JavaScript file as the doc
tag I added was located just after the meta
tag.
We are using this yaml parser: https://github.com/jeremyfa/yaml.js , and this causes the issue.
In the long run we have to switch to another YAML parsing library, because I also need to know every node's exact position (for better error reporting). We were talking about writing our own, which can be translated to Java AND JavaScript, so the WebIDE and the compiler would behave exactly the same ( https://github.com/kaitai-io/kaitai_struct/issues/229 ).
The problem is that currently we don't have enough resources to go further.
Tamas -
Yeah, and I'd love to volunteer because this seems like a cool project, but between my full-time job, my part-time job, my volunteer job, my cats and my garden, I'm thinking no ...
Has this been reported to that project? I checked the issues for the project and I don't see anything about it. Getting this fixed in the upstream might be faster than making a new YAML parser ...
I may have even found the root cause! See reference to https://github.com/jeremyfa/yaml.js/issues/107 above.