Created
March 30, 2021 20:39
-
-
Save Whateverable/71259030fc06a43208c54d003d6eb5f2 to your computer and use it in GitHub Desktop.
bisectable6
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
old=2021.02.1 sub MAIN (DateTime(Str) :f(:$from) = ~Date.today.DateTime.earlier(:1day), DateTime(Str) :t(:$to) where * > $from = ~Date.today.DateTime) { say "$from - $to"; } |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bisecting: 50 revisions left to test after this (roughly 6 steps) | |
[0f44ab226a6a518f63c85a2825d13496acacb7e6] Revert "Subtly change semantics of R:I.NORMALIZE_ENCODING" | |
»»»»» Testing 0f44ab226a6a518f63c85a2825d13496acacb7e6 | |
»»»»» Script output: | |
Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu) | |
in block <unit> at /tmp/8SHtxmNqSB line 1 | |
»»»»» Script exit code: 1 | |
»»»»» Bisecting by exit code | |
»»»»» Current exit code is 1, exit code on “old” revision is 0 | |
»»»»» If exit code is not the same as on “old” revision, this revision will be marked as “new” | |
»»»»» Therefore, marking this revision as “new” | |
»»»»» ------------------------------------------------------------------------- | |
»»»»» Testing 18612841f9ec858b09fb013e35a0311dbcf180b5 | |
»»»»» Script output: | |
Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu) | |
in block <unit> at /tmp/8SHtxmNqSB line 1 | |
»»»»» Script exit code: 1 | |
»»»»» Bisecting by exit code | |
»»»»» Current exit code is 1, exit code on “old” revision is 0 | |
»»»»» If exit code is not the same as on “old” revision, this revision will be marked as “new” | |
»»»»» Therefore, marking this revision as “new” | |
»»»»» ------------------------------------------------------------------------- | |
»»»»» Testing 69aca754085b96a012312bd355dcd25e43d82d6c | |
»»»»» Script output: | |
Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu) | |
in block <unit> at /tmp/8SHtxmNqSB line 1 | |
»»»»» Script exit code: 1 | |
»»»»» Bisecting by exit code | |
»»»»» Current exit code is 1, exit code on “old” revision is 0 | |
»»»»» If exit code is not the same as on “old” revision, this revision will be marked as “new” | |
»»»»» Therefore, marking this revision as “new” | |
»»»»» ------------------------------------------------------------------------- | |
»»»»» Testing 67143a6de4ae281f122030d4befa3858c459a631 | |
»»»»» Script output: | |
Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu) | |
in block <unit> at /tmp/8SHtxmNqSB line 1 | |
»»»»» Script exit code: 1 | |
»»»»» Bisecting by exit code | |
»»»»» Current exit code is 1, exit code on “old” revision is 0 | |
»»»»» If exit code is not the same as on “old” revision, this revision will be marked as “new” | |
»»»»» Therefore, marking this revision as “new” | |
»»»»» ------------------------------------------------------------------------- | |
»»»»» Testing 20e6f50e26b4b8705c4e41060a6fd764ed6f7d29 | |
»»»»» Script output: | |
2021-03-29T00:00:00Z - 2021-03-30T00:00:00Z | |
»»»»» Script exit code: 0 | |
»»»»» Bisecting by exit code | |
»»»»» Current exit code is 0, exit code on “old” revision is 0 | |
»»»»» If exit code is not the same as on “old” revision, this revision will be marked as “new” | |
»»»»» Therefore, marking this revision as “old” | |
»»»»» ------------------------------------------------------------------------- | |
»»»»» Testing 5a4372b48436179b62f5ed624191466933888e38 | |
»»»»» Script output: | |
2021-03-29T00:00:00Z - 2021-03-30T00:00:00Z | |
»»»»» Script exit code: 0 | |
»»»»» Bisecting by exit code | |
»»»»» Current exit code is 0, exit code on “old” revision is 0 | |
»»»»» If exit code is not the same as on “old” revision, this revision will be marked as “new” | |
»»»»» Therefore, marking this revision as “old” | |
67143a6de4ae281f122030d4befa3858c459a631 is the first new commit | |
commit 67143a6de4ae281f122030d4befa3858c459a631 | |
Author: Daniel Sockwell <daniel@codesections.com> | |
Date: Wed Feb 24 14:42:27 2021 -0500 | |
Implement space-delimited CLI arguments (S06; S19) (#4209) | |
This commit resolves the exiting TODO item: | |
> Allow both = and space before argument of double-dash args | |
and thereby implements missing functionality described in S06 and S19. | |
Specifically, this commit adds an additional feature to the | |
command-line programs Raku generates: users may now pass arguments to | |
options separated by whitespace. That is, if a program takes a | |
`--port` option, users can now call it with `--port 4242` in addition | |
to with `--port=4242`. This behavior is specified in S06 and S19; it | |
also makes the syntax for invoking Raku CLIs more similar to standard | |
Linux utilities. | |
This feature was previously discussed in 2011, but was not implemented | |
because no resolution could be found to two issues. First, whitespace | |
delimited arguments can be ambiguous: does `--profile foo` pass `foo` | |
as an argument to `--profile` or as a positional argument to the | |
program? (One potential solution to this ambiguity is to inspect | |
whether `foo` starts with `-`. But this can create hard-to-debug | |
issues for unusual `foo`s and is generally not reliable enough for use | |
in scripts.) Second, is there a way to pass multiple arguments to a | |
single option that allows users to use shell globing? That is, can a | |
call like `--input-files *.jpg` be made to DWIM? | |
This commit resolves these issues in a way that is inspired by | |
getopt(1) and thus should be familiar to Linux users. It also avoids | |
making any changes that would be incompatible with existing Raku | |
CLIs. Before discussing the details, here is an example. Consider a | |
`demo` program with the following source: | |
subset name of Any where Str|True; | |
subset port of Str; | |
multi MAIN( | |
$file, | |
name :$profile, #= Write profile information to a file | |
port :$debug-port, #= Listen for debugger connections on the specified port | |
Bool :v($verbose), #= Display verbose output | |
) {} | |
multi MAIN("--process-files", *@images) {} | |
This program generates the following usage message: | |
Usage: | |
demo [--profile[=name]] [--debug-port=<port>] [-v] <file> | |
demo --process-files [<images> ...] | |
--profile[=name] Write profile information to a file | |
--debug-port=<port> Listen for debugger connections on the specified port | |
-v Display verbose output | |
The following are valid ways to call `demo`: | |
demo --profile ~/foo | |
demo --profile=/tmp/bar ~/foo | |
demo --debug-port 4242 ~/foo | |
demo --debug-port=4242 ~/foo | |
demo -v ~/foo | |
demo --process-files *.jpg | |
These, however, are not valid | |
demo --profile /tmp/bar ~/foo | |
demo --debug-port ~/foo | |
The first is invalid because `/tmp/bar` and `~/foo` are both parsed as | |
positional arguments, which means `demo` was called with too many | |
positional arguments. The second is invalid because `~/foo` is parsed | |
as an argument to `--debug-port`, and thus `demo` lacks the required | |
positional argument. | |
Here's how it works: | |
Raku now distinguishes between three types of options: | |
* Boolean options (like `-v`), which _never_ take an argument; they | |
are ether present or absent. | |
* Options with a mandatory argument (like `--debug-port`), which | |
always take an argument. If you give them an argument with `=`, | |
they will use that; if not, they'll take the following argument. | |
* Options with an optional argument (like `--profile`), which are | |
valid both with and without an argument. You can _only_ give these | |
arguments an option with the `=` syntax; if there is a space after | |
the option, that means it was called without an argument. | |
And here's the signature that produces each type of argument: | |
* Boolean options: A `Bool` type constraint. | |
* Options with a mandatory argument: A type that does not `.ACCEPT` a | |
`Bool` | |
* Options with an optional argument: A type that `.ACCEPTS` a | |
`True` (because passing an option without an argument is equivalent | |
to passing `True`) | |
This fully resolves the ambiguity discussed above in a way | |
that should feel fairly intuitive to most users (despite how long | |
explaining it takes!) because it basically boils down to "space | |
separated arguments are fine, unless you don't need to specify a | |
value; then you've got to use =". This is the same solution employed | |
by getopt(1) and should be familiar from standard utilities like `ls` | |
and `cp`. | |
However, distinguishing between options with mandatory/required | |
arguments introduces one potential trap into the language: Types from | |
which `Bool`s inherit will produce an argument that takes an optional | |
argument. This group includes some numeric types, which may trip up | |
some users. Thus `sub MAIN(Int :$debug-port)` requires `--debug-port` | |
to be called with `=` (or get a default value of 1), which may | |
surprise some users. After this feature is added, I will update the | |
documentation to clearly note this issue. | |
The code in this commit takes an additional step to mitigate this | |
footgun: it modifies the usage message to indicate which option | |
arguments are optional by marking them with `[...]` (as was already | |
done for optional positional arguments). | |
Finally, the desire to allow multiple arguments to be passed to a | |
single option can be accommodated using the subcommand syntax, as | |
shown in the `--process-files` example above. | |
Because argument parsing is so often used in interactive CLI programs, | |
it is important that it be as fast as possible and I have written this | |
commit perform as well as possible. As a result I believe that, | |
despite the increased functionality, the revised code runs ~1ms | |
faster (out of ~6ms previously spent parsing arguments). This | |
decrease, however, is within the margin of error reported by my | |
benchmarking tool and reflects only one machine. | |
I have prepared a companion commit that adds 10 tests to Roast (and | |
removes 5 tests marked `todo`) that test this functionality. | |
Additionally, I have ensured that this test does not break bundling of | |
short flags (a feature that is not specified/tested in Roast but that | |
Raku supports) and have added tests to verify that compatibility. | |
:040000 040000 8c868cb8d8c4e7e38df6976702378b5ddc750a5c c900f59ce66e40db088d26fab41d0799660b7dfb M src | |
:040000 040000 a00b415ba39dcc894aaa43d544a2ba7cddc43cec db803c5d6bfdac089ea44390f6002b5f2410fb2e M t |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment