Cliparser with grammar #324
Conversation
|
This was a mistake. It doesn't even work. Sorry. |
|
It does work now, and I think I probably should've left this PR open with just the note that it didn't work yet. I'm not sure in how far the PR is linked to the branch I want to merge into rakudo, but if this PR always tracks the branch as-is, and not as-was-when-the-PR-was-opened, then reopening should work, I think. That's why I'm going to try that now. As for actual information re: what this PR does: I've implemented a grammar for parsing commandline options and their values as well as arguments. The grammar lives in Perl6::CommandLine::Parser and gives back a HLL::CommandLine::Result, just as HLL::CommandLine::Parser did. With a grammar we can rather easily handle things like the delimited options which S19 specs. Those also work, even though they don't go through to any specific subsystem yet, e.g.: I suppose subsystem options could be stored in some parsed structure inside Additionally, prints stagestats, but doesn't print &usage. Parsing of options with optional values (like |
|
(Yes, re-opening works! Github just picks it up. However, you can't rebase PRs) |
This obviously means that it doesn't really work.
This obviously makes thorough testing rather difficult, but at least stopping on -e and -- works as well as multiple -I.
This is barely a semi-clean solution. The core problem is --stagestats having an optional value, this only prevents it taking values that start with '-'.
Apparently the TOP rule in Perl6::CommandLine::Parser was bogus, and it didn't parse the case "only one argument", which resulted in not being able to rune make spectest.
This also included a few bug fixes, spectest runs and is clean.
peschwa
force-pushed
the
cliparser-with-grammar
branch
from
de6d3f3
to
5564fcb
Compare
|
Rebased onto nom as of today, to clean this PR up a little. |
|
I'm not at all happy with the approach of joining the command line arguments with a zero-byte and then re-parsing them. Even if we can ensure that all our platforms disallow zero-bytes within the command line arguments (and I have no idea if maybe windows has an alternative API that allows it), it still feels very wrong. Maybe this is the road to world domination, but I don't see it yet. I'd welcome comments from other Rakudo developers. |
|
i'd like to see this in rakudo. we can use a private use unicode character instead of a nullbyte to get around that particular piece of worry. |
I don't think it's better. |
|
This is way outdated, and in conflict with a good bit of the codebase. Also, the approach has raised a certain amount of polemic, and it does not really solve any issue. If conflicts are not solved and there's some degree of support for this I'm closing it in the next few days/weeks. |
|
Closed for this issue in the problem-solving repo |
|
So I'm looking at this and it feels like it's just not ready yet. At first I didn't see any problem with joining things with a null byte (as indeed you cannot have null bytes in your arguments), but then I saw this: So if you have empty arguments it'll just eat right through them. And then: So we don't even know if we're in between the arguments or not? We can of course fix it, but the whole idea of squishing things together only to reparse them later is indeed an anti-pattern of some sort. Why does it have to be a grammar that parses the whole thing at once? Just don't do it, it'll be simpler and less buggy. |
|
I think this PR can be closed. Too much has changed since, looks like. If nobody objects, I will close this PR in the coming days. |
|
Closing based on last several comments. Thank you for the effort |
No description provided.