You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@parrt , I installed the antlr4-tools but it turned out I wasn't taking advantage of them. An old installation left me with an alias for antlr4 that I wasn't paying attention to/had forgotten about (Doohhh!). It was running java and directly loading an Antlr4 .jar. Consequently, I was mystified by the lack of the expected -v option to the antlr4 command. Now that is fixed.
Question/Discussion
I'm wondering if the README.md can be updated with a reminder to clean out old installations to make way for using the antlr4-tools. Perhaps a few suggestions of what might constitute cleaning operations. (Can of worms? Maybe!)
I like the -v option. Since the latest IntelliJ IDEA editor's Antlr4 plugin is stuck (at the moment) on running v4.12.0, being able to easily change the antlr4 command's target version is ideal. (I want my shell scripts to mirror what I'm doing in the plugin.) However, the Python3 runtime doesn't automatically get changed as well. Should the antlr4-tools keep the Python3 runtime up to date as well? I realize that not everybody is using Python3 as the Antlr4 target. So, I'm not sure what the best approach would be here for the antlr4-tools. Given the increasing number of targets and the dependencies on various runtimes, it may require to much intelligence or a bunch of obtuse switches to the antlr4 command to keep up. Just hopeful I guess.
Going forward, is it the plan to use the antlr4-tools as the preferred/blessed/optimal approach for installation? Or is it just a helpful alternative?
One gotcha on the Python3 runtime is that other tools may have dependencies on the Python3 runtime. The systemrdl-compiler application uses Antlr4 and is determined to use the 4.11.0 runtime. I couldn't upgrade the runtime until I uninstalled the systemrdl-compiler. Is there an approach that allows all runtimes to co-exist?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
A little background
@parrt , I installed the
antlr4-tools
but it turned out I wasn't taking advantage of them. An old installation left me with an alias forantlr4
that I wasn't paying attention to/had forgotten about (Doohhh!). It was running java and directly loading an Antlr4.jar
. Consequently, I was mystified by the lack of the expected-v
option to the antlr4 command. Now that is fixed.Question/Discussion
antlr4-tools
. Perhaps a few suggestions of what might constitute cleaning operations. (Can of worms? Maybe!)-v
option. Since the latest IntelliJ IDEA editor's Antlr4 plugin is stuck (at the moment) on running v4.12.0, being able to easily change the antlr4 command's target version is ideal. (I want my shell scripts to mirror what I'm doing in the plugin.) However, the Python3 runtime doesn't automatically get changed as well. Should the antlr4-tools keep the Python3 runtime up to date as well? I realize that not everybody is using Python3 as the Antlr4 target. So, I'm not sure what the best approach would be here for theantlr4-tools
. Given the increasing number of targets and the dependencies on various runtimes, it may require to much intelligence or a bunch of obtuse switches to the antlr4 command to keep up. Just hopeful I guess.antlr4-tools
as the preferred/blessed/optimal approach for installation? Or is it just a helpful alternative?systemrdl-compiler
application uses Antlr4 and is determined to use the 4.11.0 runtime. I couldn't upgrade the runtime until I uninstalled thesystemrdl-compiler
. Is there an approach that allows all runtimes to co-exist?Beta Was this translation helpful? Give feedback.
All reactions