Use `spack commands --format=bash` to generate shell completion #14393

tgamblin · 2020-01-06T07:41:20Z

This PR adds a --format=bash option to spack commands to auto-generate the Bash programmable tab completion script. It can be extended to work for other shells.

Progress:

Things I would like to save for future PRs:

Support for other shells, like zsh (Feature/zsh completion #2356) and fish (@JBlaschke)
Fix BrokenPipeError for spack commands --format=rst | head in Python 3 (see comment)
Docs?

This PR also necessitates a significant refactoring of ArgparseWriter. Previously, ArgparseWriter was mostly a single _write method which handled everything from extracting the information we care about from the parser to formatting the output. Now, _write only handles recursion, while the information extraction is split into a separate parse method, and the formatting is handled by format. This allows subclasses to completely redefine how the format will appear without overriding all of _write.

JBlaschke · 2020-01-06T15:04:35Z

Thanks, I'll take a look.

It looks like fish completions are defined somewhat differently (but still tediously). I will first try existing bash-to-fish completions generators. Otherwise I can write a SpackFishCompletionsWriter based on your bash one.

I agree that we don't want to maintain 2 parallel 1000+ line scripts, and this looks like the solution.

adamjstewart · 2020-01-06T21:38:44Z

@tgamblin This looks great! Some thoughts:

I'm wondering if we should roll this into spack commands --format={bash,zsh,fish} instead of creating a new command.
I think the only way this will actually be helpful is if we also autocomplete things like $(_all_packages). What I'm envisioning is a short spack-completion.{bash,zsh,fish} that mainly defines one or two functions, and then a separate file (completely auto-generated by this command) that gets sourced within it. Otherwise, there is still a lot of manual labor involved in updating the file. Would it be possible to parse the "positional arguments" to determine which autocompletion function to call? We may need to be more consistent with our positional argument naming.

If you want to focus on the concretizer, I would be happy to hack on this over the next couple weeks.

tgamblin · 2020-01-07T01:12:22Z

I'm wondering if we should roll this into spack commands --format={bash,zsh,fish} instead of creating a new command.

Sounds fine to me. I'd call the completion formats bash-completion, zsh-completion, etc., just so it's clear what's being generated.

I think the only way this will actually be helpful is if we also autocomplete things like $(_all_packages)

Yep this is what I meant by "smarts around things like completing package names".

What I'm envisioning is a short spack-completion.{bash,zsh,fish} that mainly defines one or two functions, and then a separate file (completely auto-generated by this command) that gets sourced within it. Otherwise, there is still a lot of manual labor involved in updating the file.

Or just have this command prepend the initial function definitions to the generated output -- that's what I was thinking based on how the bash completion currently looks. Up to you.

Would it be possible to parse the "positional arguments" to determine which autocompletion function to call? We may need to be more consistent with our positional argument naming.

This is exactly what I was thinking. basically if the argument name is specs do one thing and mirrors do another. I was also saying above that the command writer could help by writing hints in the command module -- not sure if you need that or if a naming convention is sufficient.

If you want to focus on the concretizer, I would be happy to hack on this over the next couple weeks.

Yes please!

adamjstewart · 2020-01-07T20:28:07Z

Question for everyone involved:

Previously, the tab-completion for something like spack [TAB] would run $(spack commands) to generate an up-to-date list of subcommands. With this PR in its current state, we are hard-coding that list of subcommands.

Disadvantage:

whenever someone adds/removes a command (infrequent), it won't tab-complete properly

Advantage:

spack [TAB] is significantly faster

I think this situation isn't particularly controversial, just because commands are added/removed so infrequently. But what about package names?

Currently, every time you hit spack install [TAB], spack install py-[TAB], we re-run $(spack list). At least on my system, this takes a non-negligible amount of time. How would people feel about hard-coding this list of package names? I've tried to figure out how to cache this information within Bash in the past, but never managed to figure it out. Once we're able to auto-generate the tab completion script, this should be easy to update with every release (or every commit!).

Vote 👍 for faster hard-coding and 👎 for slower but more up-to-date

greenc-FNAL · 2020-01-07T20:39:48Z

@adamjstewart The slower, up-to-date methods for command and package completion will include extension commands and packages from configured external repos, respectively. I could go with caching based on ages of configuration files and the modification times on configured packages/ directories, but hard-wiring would seem to introduce restrictions in scope that a user of (say) a remote installation would have to internalize and take account of. One would also want to take account of environments and chains, I would have thought.

adamjstewart · 2020-01-07T20:43:55Z

@chissg Correct, hard-coding wouldn't work for commands/packages that only exist in other repositories. Commands like spack find wouldn't be hard-coded, as there is no way to know what will be installed ahead of time. The best we could do is hard-code a list of all package names, not just installed ones.

If anyone can figure out how to cache these functions from within Bash, that would make things a lot faster.

adamjstewart · 2020-01-08T04:07:52Z

Okay, I figured out how to cache the results in Bash, I think this will make everyone happy. Basically, you can do something like this:

diff --git a/share/spack/spack-completion.bash b/share/spack/spack-completion.bash
index e1b10f676d..c05b146363 100755
--- a/share/spack/spack-completion.bash
+++ b/share/spack/spack-completion.bash
@@ -87,7 +87,8 @@ function _bash_completion_spack {
     # Make sure function exists before calling it
     if [[ "$(type -t $subfunction)" == "function" ]]
     then
-        COMPREPLY=($($subfunction))
+        $subfunction
+        COMPREPLY=($(compgen -W "$SPACK_COMPREPLY" -- "$cur"))
     fi
 }
 
@@ -718,16 +719,16 @@ function _spack_info {
 function _spack_install {
     if $list_options
     then
-        compgen -W "-h --help --only -u --until -j --jobs --overwrite
+        SPACK_COMPREPLY="-h --help --only -u --until -j --jobs --overwrite
                     --keep-prefix --keep-stage --dont-restage --use-cache
                     --no-cache --cache-only --show-log-on-error --source
                     -n --no-checksum -v --verbose --fake --only-concrete
                     -f --file --clean --dirty --test --run-tests
                     --log-format --log-file --help-cdash -y --yes-to-all
                     --cdash-upload-url --cdash-build --cdash-site
-                    --cdash-track --cdash-buildstamp" -- "$cur"
+                    --cdash-track --cdash-buildstamp"
     else
-        compgen -W "$(_all_packages)" -- "$cur"
+        _all_packages
     fi
 }
 
@@ -1347,7 +1348,11 @@ function _subcommands {
 }
 
 function _all_packages {
-    spack list
+    if [[ -z $SPACK_ALL_PACKAGES ]]
+    then
+        SPACK_ALL_PACKAGES=$(spack list)
+    fi
+    SPACK_COMPREPLY=$SPACK_ALL_PACKAGES
 }
 
 function _all_resource_hashes {

Caching wasn't working before because we were running each function in a subshell, and you can't pass variables from a subshell to a supershell. By running everything in the current shell, we can cache the results of each call to spack list for the rest of that Bash session. I'll wait to update this until I get this PR working and we can auto-generate the whole thing.

adamjstewart · 2020-01-08T19:23:50Z

For the record, if we want to unit test the Bash completion script, we can do something like https://brbsix.github.io/2015/11/29/accessing-tab-completion-programmatically-in-bash/

adamjstewart

Still need to replace positionals with calls to subfunctions, but this is pretty close now!

lib/spack/llnl/util/argparsewriter.py

adamjstewart · 2020-01-09T22:50:16Z

lib/spack/llnl/util/argparsewriter.py

+            str: the function definition beginning
+        """
+        name = prog.replace('-', '_').replace(' ', '_')
+        return '_{0} () {{'.format(name)


I went with the POSIX-compliant function definition so this won't need to be changed for most shells.

lib/spack/spack/test/cmd/commands.py

adamjstewart · 2020-01-09T22:52:16Z

share/spack/bash/spack-completion.in

@@ -0,0 +1,194 @@
+# Copyright 2013-2020 Lawrence Livermore National Security, LLC and other


How do we get GitHub/vim to recognize this filetype, add a shebang or use .gitattributes?

.gitattributes works for GitHub but not for vim. # vim: set filetype=sh : didn't work for me locally, but maybe I don't have modelines enabled. A shebang worked, but since this script is sourced, I'm not sure if it should have a shebang.

We could also replace the extension with .bash or .sh, but then it isn't clear what the difference is between this file and the actual file you source.

adamjstewart · 2020-01-09T22:53:57Z

share/spack/spack-completion.bash

+    done
+}
+
+complete -o bashdefault -o default -F _bash_completion_spack spack


Git's tab completion also uses -o bashdefault which we weren't using before. I tested this with the system Bash on macOS (3.2.57) and Spack-installed Bash (5.0.11).

share/spack/spack-completion.bash

adamjstewart · 2020-01-10T03:58:10Z

How do we want to handle the translation of positional args to Bash subroutines? I see three possible avenues:

Decide on a consistent positional arg naming scheme. We could either rely on the option name, dest, or metavar. Right now, we're using a pretty random mix of package, PACKAGE, packages, pkg, spec, specs, constraints, name. I propose the following standardization:
- Commands that only accept package names use "package"
- Commands that accept any kind of spec use "spec" or "specs"
- Commands that require an installed package/spec are prefaced with "installed_"
- Always lowercase
The other option would be to introduce a module-level variable like level, which we currently use to decide whether a command belongs in the short docs or the long docs. The problem with this is that it works for things like spack install, but not for spack compiler where there are subsubcommands with different completions. I don't see a way to introduce a subparser-level variable, but let me know if I'm missing something.
Screw it, always complete all commands like this with a list of Spack packages, not necessarily installed packages.

greenc-FNAL · 2020-01-10T13:55:16Z

@adamjstewart I'm in favor of 1, specifically:
Name all the relevant bash completion helper functions such that the metavar can be obtained algorithmically, viz. _ch_<x>s? -> <x> ('s' being an optional plural). That way, there's a rule to be followed when adding new helper functions for other types of completion. In the rare case when a command writer doesn't want completion, they can use X instead, remaining consistency with the semantics of the metavar but disabling completion. This is better than 2 IMO because the latter won't deal with complex subcommands with multiple positional arguments with different completion semantics if I understand you correctly.

tgamblin · 2020-01-10T18:54:45Z

I also like (1), except this part:

Never make option name plural

Some commands can take multiple specs/package names/etc., and some can only take one. I think that should be understandable from the command line options, and if we're consistent about it users will have an easier time understanding the different commands.

It doesn't have to be relevant for completion, though -- the completion can just know that both of, e.g., installed_spec and installed_specs imply the same type of completion.

adamjstewart · 2020-01-10T19:53:06Z

@tgamblin there are a couple of ways to handle the plural thing. For a command like spack find that accepts multiple specs, we currently use nargs=argparse.REMAINDER, which causes the help message to be formatted like:

usage: spack find [-hdplLcfumvMN] [--format FORMAT | --json] [--groups]
                  [--no-groups] [-t TAGS] [--show-full-compiler] [-x | -X]
                  [--deprecated] [--only-deprecated] [--start-date START_DATE]
                  [--end-date END_DATE]
                  ...

list and search installed packages

positional arguments:
  constraint            constraint to select a subset of installed packages

~~If we change that to nargs='+', we get:~~

usage: spack find [-hdplLcfumvMN] [--format FORMAT | --json] [--groups]
                  [--no-groups] [-t TAGS] [--show-full-compiler] [-x | -X]
                  [--deprecated] [--only-deprecated] [--start-date START_DATE]
                  [--end-date END_DATE]
                  constraint [constraint ...]

list and search installed packages

positional arguments:
  constraint            constraint to select a subset of installed packages

~~When we use the former, something like constraints may make sense, but if we use the latter, constraint makes more sense. What do you think about that?~~

EDIT: In my own code, when I run into this situation, I usually make dest plural and metavar singular so that I access my variables via args.things and the help message contains thing [thing ...].

EDIT: Now I remember why argparse.REMAINDER was necessary, nargs='+' doesn't allow things like hdf5 -mpi because it interprets -mpi as optional flags. So you're right, we will need plurals.

lib/spack/llnl/util/argparsewriter.py

share/spack/spack-completion.bash

adamjstewart · 2020-01-20T04:31:16Z

share/spack/qa/completion-test.sh

+contains 'python' _spack_completions spack extensions ''
+
+# XFAIL: Fails for Python 2.6 because pkg_resources not found?
+#contains 'compilers.py' _spack_completions spack test ''


This is likely due to #9034

adamjstewart · 2020-01-20T05:09:28Z

How can I see coverage for spack-completion.bash? When I click on the coverage tests, it won't display coverage for spack-completion.bash because there's no data in develop to compare to.

EDIT: nvm, found it: https://codecov.io/gh/spack/spack/src/features%2Fautogenerate-completion/share/spack/spack-completion.bash

Any idea why it doesn't consider function definitions to be covered?

EDIT: This was likely fixed by SimonKagstrom/kcov#258. The version of kcov in Travis is too old, so I may have to swap foo () for foo() unless we want to wait for it to be updated.

Any idea why that one if-statement claims not to be covered?

EDIT: Putting things on a single line gets us to 100% coverage!

adamjstewart · 2020-01-21T02:52:39Z

Alright, we now cache all subroutine calls in our tab completion. This makes repeated tab completion of the same command, like spack install [TAB], spack install py-[TAB], spack install py-num[TAB] significantly faster.

Unfortunately, the completion-test.sh don't run any faster because each succeeds and contains call runs in a subshell, so the variables are deleted when the shell is deleted. This means that completion-test.sh is still really slow (takes about 2 minutes). It's a shame to add 2 minutes to all Travis runtimes, but I agree with running unit tests in a subshell to prevent variable leaking.

share/spack/qa/setup-env-test.sh

adamjstewart · 2020-01-21T03:01:34Z

share/spack/qa/setup-env-test.sh

 set -u

 # Source setup-env.sh before tests
-.  share/spack/setup-env.sh
+. "$SHARE_DIR/setup-env.sh"


Previously this script only worked if you ran it from $SPACK_ROOT

share/spack/spack-completion.bash

adamjstewart · 2020-01-21T03:07:15Z

share/spack/spack-completion.bash

+_config_sections() {
+    if [[ -z "${SPACK_CONFIG_SECTIONS:-}" ]]
+    then
+        SPACK_CONFIG_SECTIONS="compilers mirrors repos packages modules config upstreams"


adamjstewart · 2020-01-21T03:07:34Z

share/spack/spack-completion.bash

+_extensions() {
+    if [[ -z "${SPACK_EXTENSIONS:-}" ]]
+    then
+        SPACK_EXTENSIONS="aspell go-bootstrap go icedtea jdk kim-api lua matlab mofem-cephas octave openjdk perl python r ruby rust tcl yorick"


adamjstewart · 2020-01-21T03:10:17Z

share/spack/spack-completion.bash

    else
-        compgen -W "regenerate enable disable" -- "$cur"
+        SPACK_COMPREPLY=""


This is something I still need to fix. The actual positional arg is {regenerate,enable,disable}. If we reimplement this using subcommands, the problem goes away.

adamjstewart · 2020-01-21T03:11:05Z

share/spack/spack-completion.bash

    else
-        compgen -W "$(installed_packages)" -- "$cur"


This was a bug, we were missing the leading underscore. Same below for _spack_gpg_sign.

adamjstewart · 2020-01-21T03:31:13Z

@tgamblin There are still a few bugs to work out, but this PR should be ready for review. Note that the spack-completion.bash tests increase our coverage by a whole 0.5%, bumping us up to 78% coverage overall.

tgamblin

@adamjstewart: a couple minor change requests and I think this is ready to merge.

tgamblin · 2020-01-22T06:05:02Z

lib/spack/llnl/util/argparsewriter.py

+
+    def format(self, prog, description, usage,
+               positionals, optionals, subcommands):
+        string = self.begin_command(prog)


This should be a StringIO

What's the benefit of using StringIO? I've never used it before.

See https://docs.python.org/3/faq/programming.html#what-is-the-most-efficient-way-to-concatenate-many-strings-together. When writing a large file like this use string IO for efficiency.

tgamblin · 2020-01-22T06:06:12Z

lib/spack/llnl/util/argparsewriter.py

+            usage (str): the command usage
+            positionals (list): list of positional arguments
+            optionals (list): list of optional arguments
+            subcommands (list): list of subcommand parsers


These 6 args are kind of begging to be a little ParsedArgs data class so that we don't have to pass all 6 around.

lib/spack/spack/cmd/common/arguments.py

tgamblin · 2020-01-22T06:51:43Z

@adamjstewart: when you push this, can you squash the commits into a single one (or a few) by you that I can rebase? If I squash this PR, it'll credit the work to me (as I opened the bare-bones prototype)

This PR adds a `--format=bash` option to `spack commands` to auto-generate the Bash programmable tab completion script. It can be extended to work for other shells. Progress: - [x] Fix bug in superclass initialization in `ArgparseWriter` - [x] Refactor `ArgparseWriter` (see below) - [x] Ensure that output of old `--format` options remains the same - [x] Add `ArgparseCompletionWriter` and `BashCompletionWriter` - [x] Add `--aliases` option to add command aliases - [x] Standardize positional argument names - [x] Tests for `spack commands --format=bash` coverage - [x] Tests to make sure `spack-completion.bash` stays up-to-date - [x] Tests for `spack-completion.bash` coverage - [x] Speed up `spack-completion.bash` by caching subroutine calls This PR also necessitates a significant refactoring of `ArgparseWriter`. Previously, `ArgparseWriter` was mostly a single `_write` method which handled everything from extracting the information we care about from the parser to formatting the output. Now, `_write` only handles recursion, while the information extraction is split into a separate `parse` method, and the formatting is handled by `format`. This allows subclasses to completely redefine how the format will appear without overriding all of `_write`. Co-Authored-by: Todd Gamblin <tgamblin@llnl.gov>

haampie · 2022-01-06T09:37:45Z

This PR broke completion of flags:

$ spack install --ver[tab] zlib
$ spack install - zlib

tgamblin added commands new-command labels Jan 6, 2020

tgamblin requested a review from adamjstewart January 6, 2020 07:41

tgamblin assigned adamjstewart Jan 6, 2020

tgamblin mentioned this pull request Jan 6, 2020

Fix outdated bash tab completion #14392

Merged

tgamblin force-pushed the features/autogenerate-completion branch from ccffede to bc1190a Compare January 6, 2020 08:04

tgamblin mentioned this pull request Jan 7, 2020

Add fish shell support #9279

Merged

adamjstewart force-pushed the features/autogenerate-completion branch from bc1190a to 0dc19c6 Compare January 8, 2020 18:51

adamjstewart changed the title ~~commands: add spack completion command to generate shell completion~~ Use spack commands --format=bash to generate shell completion Jan 8, 2020

adamjstewart added refactoring shell-support and removed new-command labels Jan 9, 2020

adamjstewart reviewed Jan 9, 2020

View reviewed changes

adamjstewart reviewed Jan 10, 2020

View reviewed changes

share/spack/spack-completion.bash Outdated Show resolved Hide resolved

adamjstewart mentioned this pull request Jan 10, 2020

Reformat Bash tab completion script #14456

Merged

2 tasks

adamjstewart force-pushed the features/autogenerate-completion branch from 9926e86 to ed55a9f Compare January 10, 2020 17:38

adamjstewart reviewed Jan 10, 2020

View reviewed changes

lib/spack/llnl/util/argparsewriter.py Show resolved Hide resolved

adamjstewart reviewed Jan 11, 2020

View reviewed changes

share/spack/spack-completion.bash Outdated Show resolved Hide resolved

adamjstewart requested review from scheibelp and becker33 January 19, 2020 18:09

adamjstewart reviewed Jan 20, 2020

View reviewed changes

adamjstewart reviewed Jan 21, 2020

View reviewed changes

share/spack/qa/setup-env-test.sh Show resolved Hide resolved

adamjstewart reviewed Jan 21, 2020

View reviewed changes

share/spack/spack-completion.bash Outdated Show resolved Hide resolved

adamjstewart reviewed Jan 21, 2020

View reviewed changes

tgamblin commented Jan 22, 2020

View reviewed changes

tgamblin force-pushed the features/autogenerate-completion branch from 572773f to 48f5abd Compare January 23, 2020 01:51

tgamblin force-pushed the features/autogenerate-completion branch from 48f5abd to b989e52 Compare January 23, 2020 04:36

tgamblin force-pushed the features/autogenerate-completion branch from b989e52 to bc438ee Compare January 23, 2020 04:46

tgamblin merged commit 11f2b61 into develop Jan 23, 2020

tgamblin deleted the features/autogenerate-completion branch January 23, 2020 05:31

JBlaschke mentioned this pull request Jan 30, 2020

Add fish tab completion JBlaschke/spack#2

Open

adamjstewart mentioned this pull request Jan 30, 2020

Feature/zsh completion #2356

Closed

tgamblin added this to Todo in Spack v0.14.0 release via automation Feb 23, 2020

tgamblin moved this from Todo to Done in Spack v0.14.0 release Feb 23, 2020

adamjstewart mentioned this pull request Mar 31, 2020

spack test #15702

Merged

haampie mentioned this pull request Jan 6, 2022

Fix spack install --v[tab] spec #28278

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use `spack commands --format=bash` to generate shell completion #14393

Use `spack commands --format=bash` to generate shell completion #14393

tgamblin commented Jan 6, 2020 •

edited by adamjstewart

JBlaschke commented Jan 6, 2020

adamjstewart commented Jan 6, 2020

tgamblin commented Jan 7, 2020

adamjstewart commented Jan 7, 2020

greenc-FNAL commented Jan 7, 2020

adamjstewart commented Jan 7, 2020

adamjstewart commented Jan 8, 2020 •

edited

adamjstewart commented Jan 8, 2020 •

edited

adamjstewart left a comment

adamjstewart Jan 9, 2020

adamjstewart Jan 9, 2020 •

edited

adamjstewart Jan 12, 2020

adamjstewart Jan 20, 2020

adamjstewart Jan 9, 2020

adamjstewart commented Jan 10, 2020 •

edited

greenc-FNAL commented Jan 10, 2020 •

edited

tgamblin commented Jan 10, 2020

adamjstewart commented Jan 10, 2020 •

edited

adamjstewart Jan 20, 2020

adamjstewart commented Jan 20, 2020 •

edited

adamjstewart commented Jan 21, 2020

adamjstewart Jan 21, 2020

adamjstewart Jan 21, 2020

adamjstewart Jan 21, 2020

adamjstewart Jan 21, 2020

adamjstewart Jan 21, 2020

adamjstewart commented Jan 21, 2020

tgamblin left a comment

tgamblin Jan 22, 2020

adamjstewart Jan 22, 2020

tgamblin Jan 22, 2020

tgamblin Jan 22, 2020

tgamblin commented Jan 22, 2020 •

edited

haampie commented Jan 6, 2022

		@@ -0,0 +1,194 @@
		# Copyright 2013-2020 Lawrence Livermore National Security, LLC and other

Use spack commands --format=bash to generate shell completion #14393

Use spack commands --format=bash to generate shell completion #14393

Conversation

tgamblin commented Jan 6, 2020 • edited by adamjstewart

JBlaschke commented Jan 6, 2020

adamjstewart commented Jan 6, 2020

tgamblin commented Jan 7, 2020

adamjstewart commented Jan 7, 2020

greenc-FNAL commented Jan 7, 2020

adamjstewart commented Jan 7, 2020

adamjstewart commented Jan 8, 2020 • edited

adamjstewart commented Jan 8, 2020 • edited

adamjstewart left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamjstewart Jan 9, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamjstewart commented Jan 10, 2020 • edited

greenc-FNAL commented Jan 10, 2020 • edited

tgamblin commented Jan 10, 2020

adamjstewart commented Jan 10, 2020 • edited

Choose a reason for hiding this comment

adamjstewart commented Jan 20, 2020 • edited

adamjstewart commented Jan 21, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamjstewart commented Jan 21, 2020

tgamblin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tgamblin commented Jan 22, 2020 • edited

haampie commented Jan 6, 2022

Use `spack commands --format=bash` to generate shell completion #14393

Use `spack commands --format=bash` to generate shell completion #14393

tgamblin commented Jan 6, 2020 •

edited by adamjstewart

adamjstewart commented Jan 8, 2020 •

edited

adamjstewart commented Jan 8, 2020 •

edited

adamjstewart Jan 9, 2020 •

edited

adamjstewart commented Jan 10, 2020 •

edited

greenc-FNAL commented Jan 10, 2020 •

edited

adamjstewart commented Jan 10, 2020 •

edited

adamjstewart commented Jan 20, 2020 •

edited

tgamblin commented Jan 22, 2020 •

edited