-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
[antlr4-python3-runtime-4.13.1] ANTLR runtime and generated code versions disagree: 4.13.1!=4.11.2-SNAPSHOT #4655
Comments
My mistake, apparently it is only an informative message. But running tests coming with runtime show them. |
Actually, it's worse than this one issue. Not only are the generated files inconsistent in timestamps/versions, the XPathLexer.g4's are slightly different, and not just in target-specific code, or symbol renaming because target-agnostic format is not followed. I see a token range difference in the .g4 grammar.
Note: For one of the current ongoing rewrites of Antlr, I'd highly recommend a complete rewrite of the Antlr tree representation in order to support tree edits and querying of off-channel content, along with replacing the current XPath engine in the with a real one, preferably Selenium, which is the gold standard. Trash uses a port of the ancient Xerces engine, which is excellent, but only supports XPath version 2. I'm still porting Selenium to C#. |
A difference in case. Not sure why there is such a difference, but it I can't see how this is an issue. I've never had to write a target agnostic frontend/compiler in the last 3 decades... er, ever. Also, ANTLR produces parse trees. They are only useful for facilitating production of a more formal AST. That's where we do the micro optimizations. If writing a real world compiler, generate LLVM and leave it there. This is not an official position in any way. Just my thoughts. Python for parsing? Hmmm |
|
I think you know what I mean. Or perhaps not.
…On Thu, Jul 11, 2024 at 09:34 Ken Domino ***@***.***> wrote:
A difference in case.
'\uFDF0'..'\uFFFF' is not the same range as '\uFDF0'..'\uFFFD'. It is not
a matter of a difference in case.
—
Reply to this email directly, view it on GitHub
<#4655 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJ7TMAIGNOFGKWOAHDFSBTZL2QX5AVCNFSM6AAAAABKOVPXACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRTGI3DANRTGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Any updates on this ? Or is there an option to hide the test, in the source, it seems that it cannot be skipped ? |
we don't always regen those but I'm gonna do a release soon and will try to regen those. |
Should we propose PR to remove this print/check from python runtime ? |
@Thomasb81 no, the check is in every runtime (and should stay there, we don't want to deal with very complex errors caused by an undetected change in serialization format) |
@ericvergnaud Sorry I do not understand. I can't see equivalent code to
implemented here by a simple print:
in other implementation java : https://github.com/antlr/antlr4/blob/dev/runtime/Java/src/org/antlr/v4/runtime/tree/xpath/XPathLexer.java. I understand the utility of such check to ensure some compatibility and avoid a first level of support for user that would use tool in version A and runtime in version B. I can't avoid this print when I use xpath feature with python3 -runtime download from pypi, which is very annoying. What is the right fix to propose : regenerate xpath lexer grammar or align runtime feature or both ? |
@ericvergnaud But the check is still with 4.11.2-SNAPSHOT whereas multiple commits switched to 4.13 |
The Java version is handwritten hence the difference.
The right fix is to regenerate the path lexer, which is already on its way. |
An alternative approach would be to handwrite the XPathLexer for Python, I'll happily accept the corresponding PR. |
Trying to get antlr 4.13.2 out. Will try to regen all XPath lexers. |
Hello
This a bug report for https://pypi.org/project/antlr4-python3-runtime/
Apparently something went wrong during the release process of 4.13.1, the generated lexer of the xpath feature has not been regenerated.
This lead to systematic runtime error, when we try to use any antlr4-python3-runtime different than
4.11.2-SNAPSHOT
ie:
antlr4/runtime/Python3/src/antlr4/xpath/XPathLexer.py
Line 1 in 1855d9a
antlr4/runtime/Python3/src/antlr4/xpath/XPathLexer.py
Line 66 in b3bb743
Actually the issue still exist in dev branch,:
https://github.com/antlr/antlr4/blob/dev/runtime/Python3/src/antlr4/xpath/XPathLexer.py
Probably the release procedure describe here https://github.com/antlr/antlr4/blob/master/doc/releasing-antlr.md miss this update ?
@parrt any thought ?
The text was updated successfully, but these errors were encountered: