-
Notifications
You must be signed in to change notification settings - Fork 5
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
ami section
fails with valid --summary
argument
#48
Comments
Have you tried removing |
Note - being run programmatically. Here's the test:
I'll run it with varying Option definitions: no arity
gives
arity 1..*
gives
|
I found the cause: Picocli interprets We need to disambiguate this somehow. An alternative is to require end users to quote the value for the
(The latter means a minor code change in AMI:
|
On Sun, Jul 5, 2020 at 12:06 AM Remko Popma ***@***.***> wrote:
I found the cause:
figure is also the name of the AMIFigureTool, which is a sibling command
of section.
WELL DONE! I hope it didn't take too long.
It's obvious in retrospect.
Picocli interprets figure as a new command (since we configured AMI with subcommandsRepeatable
= true); and thus concludes that the --summary option was missing a
mandatory parameter.
Understood
We need to disambiguate this somehow.
One idea is to rename either the name for AMIFigureTool, or the
AMISectionTool.SummaryType enum value.
The single fix is easy - I will rename the enum value.
It's clearly a generic problem and common to any system which uses reserved
names. I sometimes us "default" as a name in Java until the compiler
refuses.
An alternative is to require end users to quote the value for the
--summary option:
-p src\test\resources\org\contentmine\ami\zika10 --forcemake section --sections ALL --summary "figure"
I don't think we need this. It's best for me to choose non-clashing
keywords.
The enums are under my control. In principle we could check the values
against commands.
Another idea would be syntax for the commands, e.g. case or prefix. I don't
like this but it would be safe:
ami -p foo c_search ... c_summary
Are there other scenarios for clashes?
…--
Peter Murray-Rust
Founder ContentMine.org
and
Reader Emeritus in Molecular Informatics
Dept. Of Chemistry, University of Cambridge, CB2 1EW, UK
|
I haven’t searched if any other enum values could clash with other command names. I agree that renaming is probably the easiest and most reliable solution. |
The problem is that it only surfaces when the enum value is used.
I think I need a way of validating enum values at regular intervals.
Does the use of "=" to identify parameter values avoid this?
P.
…On Sun, Jul 5, 2020 at 9:18 AM Remko Popma ***@***.***> wrote:
I haven’t searched if any other enum values could clash with other command
names.
I agree that renaming is probably the easiest and most reliable solution.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#48 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFTCS7PHWLEBN6PWOWF3SLR2AZM3ANCNFSM4OQL45WA>
.
--
Peter Murray-Rust
Founder ContentMine.org
and
Reader Emeritus in Molecular Informatics
Dept. Of Chemistry, University of Cambridge, CB2 1EW, UK
|
I haven’t checked but I suspect that putting |
Also,
what happens with uncontrolled strings? e.g. if a project has the same name
as a reserved (sub) command:
```
ami -p search search --dictionary search
```
where I have a project `search` (sloppy, easy to do) and a dictionary
called `search` (maps to `search.xml`).
It's not easy building parsers - I know. I use/d ANTLR which is powerful
but wasn't easy to load - but I think it's improved over the years. Is
there a formal language specification for picocli? Could one generate a
parser from the Commands and Options. Maybe a Parser generator would show
the conflicts.
P.
…On Sun, Jul 5, 2020 at 10:04 AM Remko Popma ***@***.***> wrote:
I haven’t checked but I suspect that putting = between the option name
and the value doesn’t help. That is a good point and potentially something
to improve in picocli. (Requires some thought.)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#48 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFTCS64A23AQYGV432ZL5DR2A63FANCNFSM4OQL45WA>
.
--
Peter Murray-Rust
Founder ContentMine.org
and
Reader Emeritus in Molecular Informatics
Dept. Of Chemistry, University of Cambridge, CB2 1EW, UK
|
Good point. I had not thought of this. With picocli 4.3.x, the string "search" will be accepted and assigned to the The picocli 4.4 release notes mention the related case of using option names as option value, for example, what if you have a project that was named
However, application authors may want to allow values that match subcommands (or even values that match option names) as option parameters... I am beginning to think the picocli parser is now too strict. I will think about how to address this in a future version of picocli.
I am familiar with ANTLR. I don't want to bring in ANTLR as a dependency, but I see your point about formalizing how the picocli parser works. There is no formal language specification, because each picocli application has a unique grammar, defined in their app with picocli annotations. That said, it may be worth formalizing the grammar for the composing elements. At any rate, I need to think about how to give application flexibility in how to treat ambiguous parameter values. |
Closing since the original problem has been resolved and any follow-up work is in the picocli project. |
runs correctly without options. and with
but fails with
see: https://github.com/petermr/ami3/blob/master/src/test/java/org/contentmine/ami/tools/AMISectionToolTest.java
The text was updated successfully, but these errors were encountered: