Testing: Print test reproduction command on failure #104537

jbschlosser · 2023-07-03T20:34:41Z

Stack from ghstack (oldest at bottom):

MS2 of the Reproducible Testing BE initiative. For context, this is the ask:

Another thing that would be really great as we start to have more dependent 
systems or types of tests (functorch, dynamo, crossref) would be to have a 
minimally reproducible version of the test (something at the end of the HUD 
comment like: "Run python test/test_file.py -k test_name" but also if you need 
flags, like crossref it would be like "Run <flag to run crossref> python test/..." ). I'll 
often go through the test infra to find the flags that I need to pass when 
something only breaks crossref/dynamo tests.

Implementation details:

Adds a new flag PRINT_REPRO_ON_FAILURE that is settable through the environment variable PYTORCH_PRINT_REPRO_ON_FAILURE=1
- Default is ON but I can be persuaded otherwise
When the flag is enabled, our base TestCase will wrap the test method in a context manager that catches any non-skip exceptions and appends a repro string to the exception message. The repro includes setting of necessary test flags through env vars. Example:

To execute this test, run the following from the base repo dir:
    PYTORCH_TEST_WITH_CROSSREF=1 python test/test_ops.py -k test_foo_add_cuda_float32

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0

To keep track of flag settings, this PR introduces a new TestEnvironment class that defines global flags by querying related environment variables. Flag and env var names are purposefully kept searchable via full names. Example usages:

TestEnvironment.def_flag("TEST_WITH_TORCHINDUCTOR", env_var="PYTORCH_TEST_WITH_INDUCTOR")
# can track implication relationships to avoid adding unnecessary flags to the repro
TestEnvironment.def_flag(
    "TEST_WITH_TORCHDYNAMO",
    env_var="PYTORCH_TEST_WITH_DYNAMO",
    implied_by_fn=lambda: TEST_WITH_TORCHINDUCTOR or TEST_WITH_AOT_EAGER)
# can use include_in_repro=False to keep the flag from appearing in the repro command
TestEnvironment.def_flag(
    "DISABLE_RUNNING_SCRIPT_CHK", env_var="PYTORCH_DISABLE_RUNNING_SCRIPT_CHK", include_in_repro=False)
# the default default value is False, but this can be changed
TestEnvironment.def_flag(
    "PRINT_REPRO_ON_FAILURE", env_var="PYTORCH_PRINT_REPRO_ON_FAILURE", default=(not IS_FBCODE), include_in_repro=False)

AFAICT it is only feasible to achieve this from within the test framework rather than at the CI level. This is because CI / run_test.py are unaware of individual test cases. Implementing it in our base TestCase class has the broadest area of effect, as it's not isolated to e.g. OpInfo tests.
I couldn't find an easy way to test the logic via test_testing.py, as the logic for extracting the test filename doesn't work for generated test classes. I'm open to ideas on testing this, however.

[ghstack-poisoned]

pytorch-bot · 2023-07-03T20:34:44Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/104537

📄 Preview Python docs built from this PR
📄 Preview C++ docs built from this PR
❓ Need help or want to give feedback on the CI? Visit the bot commands wiki or our office hours

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit 675fe55:
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

ezyang

I don't want to be too picky about what eventually goes in, since it is better to have something rather than nothing, but I think my comments are definitely worth looking into.

torch/testing/_internal/common_utils.py

MS2 of the Reproducible Testing BE initiative. For context, this is the ask: ``` Another thing that would be really great as we start to have more dependent systems or types of tests (functorch, dynamo, crossref) would be to have a minimally reproducible version of the test (something at the end of the HUD comment like: "Run python test/test_file.py -k test_name" but also if you need flags, like crossref it would be like "Run <flag to run crossref> python test/..." ). I'll often go through the test infra to find the flags that I need to pass when something only breaks crossref/dynamo tests. ``` Implementation details: * Adds a new flag `PRINT_REPRO_ON_FAILURE` that is settable through the environment variable `PYTORCH_PRINT_REPRO_ON_FAILURE=1` * **Default is ON but I can be persuaded otherwise** * When the flag is enabled, our base `TestCase` will wrap the test method in a context manager that catches any non-skip exceptions and appends a repro string to the exception message. The repro includes setting of necessary test flags through env vars. Example: ``` To execute this test, run the following from the base repo dir: PYTORCH_TEST_WITH_CROSSREF=1 python test/test_ops.py -k test_foo_add_cuda_float32 ``` * AFAICT it is only feasible to achieve this from within the test framework rather than at the CI level. This is because CI / `run_test.py` are unaware of individual test cases. Implementing it in our base `TestCase` class has the broadest area of effect, as it's not isolated to e.g. OpInfo tests. * I couldn't find an easy way to test the logic via `test_testing.py`, as the logic for extracting the test filename doesn't work for generated test classes. I'm open to ideas on testing this, however. [ghstack-poisoned]

MS2 of the Reproducible Testing BE initiative. For context, this is the ask: ``` Another thing that would be really great as we start to have more dependent systems or types of tests (functorch, dynamo, crossref) would be to have a minimally reproducible version of the test (something at the end of the HUD comment like: "Run python test/test_file.py -k test_name" but also if you need flags, like crossref it would be like "Run <flag to run crossref> python test/..." ). I'll often go through the test infra to find the flags that I need to pass when something only breaks crossref/dynamo tests. ``` Implementation details: * Adds a new flag `PRINT_REPRO_ON_FAILURE` that is settable through the environment variable `PYTORCH_PRINT_REPRO_ON_FAILURE=1` * **Default is ON but I can be persuaded otherwise** * When the flag is enabled, our base `TestCase` will wrap the test method in a context manager that catches any non-skip exceptions and appends a repro string to the exception message. The repro includes setting of necessary test flags through env vars. Example: ``` To execute this test, run the following from the base repo dir: PYTORCH_TEST_WITH_CROSSREF=1 python test/test_ops.py -k test_foo_add_cuda_float32 This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0 ``` * To keep track of flag settings, this PR introduces a new `TestEnvironment` class that defines global flags by querying related environment variables. Flag and env var names are purposefully kept searchable via full names. Example usages: ```python TestEnvironment.def_flag("TEST_WITH_TORCHINDUCTOR", env_var="PYTORCH_TEST_WITH_INDUCTOR") # can track implication relationships to avoid adding unnecessary flags to the repro TestEnvironment.def_flag( "TEST_WITH_TORCHDYNAMO", env_var="PYTORCH_TEST_WITH_DYNAMO", implied_by_fn=lambda: TEST_WITH_TORCHINDUCTOR or TEST_WITH_AOT_EAGER) # can use include_in_repro=False to keep the flag from appearing in the repro command TestEnvironment.def_flag( "DISABLE_RUNNING_SCRIPT_CHK", env_var="PYTORCH_DISABLE_RUNNING_SCRIPT_CHK", include_in_repro=False) # the default default value is False, but this can be changed TestEnvironment.def_flag( "PRINT_REPRO_ON_FAILURE", env_var="PYTORCH_PRINT_REPRO_ON_FAILURE", default=(not IS_FBCODE), include_in_repro=False) ``` * AFAICT it is only feasible to achieve this from within the test framework rather than at the CI level. This is because CI / `run_test.py` are unaware of individual test cases. Implementing it in our base `TestCase` class has the broadest area of effect, as it's not isolated to e.g. OpInfo tests. * I couldn't find an easy way to test the logic via `test_testing.py`, as the logic for extracting the test filename doesn't work for generated test classes. I'm open to ideas on testing this, however. [ghstack-poisoned]

ghstack-source-id: 19f27ae Pull Request resolved: #104537

MS2 of the Reproducible Testing BE initiative. For context, this is the ask: ``` Another thing that would be really great as we start to have more dependent systems or types of tests (functorch, dynamo, crossref) would be to have a minimally reproducible version of the test (something at the end of the HUD comment like: "Run python test/test_file.py -k test_name" but also if you need flags, like crossref it would be like "Run <flag to run crossref> python test/..." ). I'll often go through the test infra to find the flags that I need to pass when something only breaks crossref/dynamo tests. ``` Implementation details: * Adds a new flag `PRINT_REPRO_ON_FAILURE` that is settable through the environment variable `PYTORCH_PRINT_REPRO_ON_FAILURE=1` * **Default is ON but I can be persuaded otherwise** * When the flag is enabled, our base `TestCase` will wrap the test method in a context manager that catches any non-skip exceptions and appends a repro string to the exception message. The repro includes setting of necessary test flags through env vars. Example: ``` To execute this test, run the following from the base repo dir: PYTORCH_TEST_WITH_CROSSREF=1 python test/test_ops.py -k test_foo_add_cuda_float32 This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0 ``` * To keep track of flag settings, this PR introduces a new `TestEnvironment` class that defines global flags by querying related environment variables. Flag and env var names are purposefully kept searchable via full names. Example usages: ```python TestEnvironment.def_flag("TEST_WITH_TORCHINDUCTOR", env_var="PYTORCH_TEST_WITH_INDUCTOR") # can track implication relationships to avoid adding unnecessary flags to the repro TestEnvironment.def_flag( "TEST_WITH_TORCHDYNAMO", env_var="PYTORCH_TEST_WITH_DYNAMO", implied_by_fn=lambda: TEST_WITH_TORCHINDUCTOR or TEST_WITH_AOT_EAGER) # can use include_in_repro=False to keep the flag from appearing in the repro command TestEnvironment.def_flag( "DISABLE_RUNNING_SCRIPT_CHK", env_var="PYTORCH_DISABLE_RUNNING_SCRIPT_CHK", include_in_repro=False) # the default default value is False, but this can be changed TestEnvironment.def_flag( "PRINT_REPRO_ON_FAILURE", env_var="PYTORCH_PRINT_REPRO_ON_FAILURE", default=(not IS_FBCODE), include_in_repro=False) ``` * AFAICT it is only feasible to achieve this from within the test framework rather than at the CI level. This is because CI / `run_test.py` are unaware of individual test cases. Implementing it in our base `TestCase` class has the broadest area of effect, as it's not isolated to e.g. OpInfo tests. * I couldn't find an easy way to test the logic via `test_testing.py`, as the logic for extracting the test filename doesn't work for generated test classes. I'm open to ideas on testing this, however. [ghstack-poisoned]

Finishes the job from #104537. See #104537 (review) [ghstack-poisoned]

jbschlosser · 2023-07-10T15:21:46Z

@huydhn do you have any insight on the other test failures? Doesn't seem related to my stuff. I can repro locally without my changes, but then I don't see those failures in the HUD. what should I do?

MS2 of the Reproducible Testing BE initiative. For context, this is the ask: ``` Another thing that would be really great as we start to have more dependent systems or types of tests (functorch, dynamo, crossref) would be to have a minimally reproducible version of the test (something at the end of the HUD comment like: "Run python test/test_file.py -k test_name" but also if you need flags, like crossref it would be like "Run <flag to run crossref> python test/..." ). I'll often go through the test infra to find the flags that I need to pass when something only breaks crossref/dynamo tests. ``` Implementation details: * Adds a new flag `PRINT_REPRO_ON_FAILURE` that is settable through the environment variable `PYTORCH_PRINT_REPRO_ON_FAILURE=1` * **Default is ON but I can be persuaded otherwise** * When the flag is enabled, our base `TestCase` will wrap the test method in a context manager that catches any non-skip exceptions and appends a repro string to the exception message. The repro includes setting of necessary test flags through env vars. Example: ``` To execute this test, run the following from the base repo dir: PYTORCH_TEST_WITH_CROSSREF=1 python test/test_ops.py -k test_foo_add_cuda_float32 This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0 ``` * To keep track of flag settings, this PR introduces a new `TestEnvironment` class that defines global flags by querying related environment variables. Flag and env var names are purposefully kept searchable via full names. Example usages: ```python TestEnvironment.def_flag("TEST_WITH_TORCHINDUCTOR", env_var="PYTORCH_TEST_WITH_INDUCTOR") # can track implication relationships to avoid adding unnecessary flags to the repro TestEnvironment.def_flag( "TEST_WITH_TORCHDYNAMO", env_var="PYTORCH_TEST_WITH_DYNAMO", implied_by_fn=lambda: TEST_WITH_TORCHINDUCTOR or TEST_WITH_AOT_EAGER) # can use include_in_repro=False to keep the flag from appearing in the repro command TestEnvironment.def_flag( "DISABLE_RUNNING_SCRIPT_CHK", env_var="PYTORCH_DISABLE_RUNNING_SCRIPT_CHK", include_in_repro=False) # the default default value is False, but this can be changed TestEnvironment.def_flag( "PRINT_REPRO_ON_FAILURE", env_var="PYTORCH_PRINT_REPRO_ON_FAILURE", default=(not IS_FBCODE), include_in_repro=False) ``` * AFAICT it is only feasible to achieve this from within the test framework rather than at the CI level. This is because CI / `run_test.py` are unaware of individual test cases. Implementing it in our base `TestCase` class has the broadest area of effect, as it's not isolated to e.g. OpInfo tests. * I couldn't find an easy way to test the logic via `test_testing.py`, as the logic for extracting the test filename doesn't work for generated test classes. I'm open to ideas on testing this, however. [ghstack-poisoned]

…RADCHECK flag" Finishes the job from #104537. See #104537 (review) [ghstack-poisoned]

Finishes the job from #104537. See #104537 (review) [ghstack-poisoned]

huydhn · 2023-07-10T17:25:32Z

@huydhn do you have any insight on the other test failures? Doesn't seem related to my stuff. I can repro locally without my changes, but then I don't see those failures in the HUD. what should I do?

From what I see, they are all disabled tests and shouldn't be run at all in the PR. Looking at an example failure, I see it was run as:

Executing ['/opt/conda/envs/py_3.9/bin/python', '-bb', 'test_type_hints.py', '--shard-id=0', '--num-shards=1', '-v', '-vv', '-rfEX', '-p', 'no:xdist', '--use-pytest', '-x', '--reruns=2']

while the correct command should be:

Executing ['/opt/conda/envs/py_3.9/bin/python', '-bb', 'test_type_hints.py', '--shard-id=0', '--num-shards=1', '-v', '-vv', '-rfEX', '-p', 'no:xdist', '--use-pytest', '--sc=test_type_hints_0', '-x', '--reruns=2', '--import-slow-tests', '--import-disabled-tests']

So there are several missing parameters:

--sc=test_type_hints_0
--import-slow-tests
and --import-disabled-tests

They are all controlled via env variables I think, so let's double check these parts.

huydhn · 2023-07-10T17:30:28Z

Or may be the issue is in how IS_CI env variable is exposed. All three of the missing flags are available only on CI:

This doesn't looks like a coincidence. So my theory is that IS_CI isn't set correctly in run_test.py

jbschlosser · 2023-07-10T17:36:46Z

This doesn't looks like a coincidence. So my theory is that IS_CI isn't set correctly in run_test.py

Awesome investigation, thanks! Looking into it now.

Edit: Figured it out. The old code was doing this:

IS_CI = bool(os.getenv('CI'))

which is True more often than os.getenv('CI') == '1'. So I guess the CI env var is being set to something other than 1 when launching run_test.py.

huydhn · 2023-07-10T18:00:02Z

Ohh, that's the reason. The CI variable comes from GitHub itself https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables and it's set to true according to GitHub doc.

MS2 of the Reproducible Testing BE initiative. For context, this is the ask: ``` Another thing that would be really great as we start to have more dependent systems or types of tests (functorch, dynamo, crossref) would be to have a minimally reproducible version of the test (something at the end of the HUD comment like: "Run python test/test_file.py -k test_name" but also if you need flags, like crossref it would be like "Run <flag to run crossref> python test/..." ). I'll often go through the test infra to find the flags that I need to pass when something only breaks crossref/dynamo tests. ``` Implementation details: * Adds a new flag `PRINT_REPRO_ON_FAILURE` that is settable through the environment variable `PYTORCH_PRINT_REPRO_ON_FAILURE=1` * **Default is ON but I can be persuaded otherwise** * When the flag is enabled, our base `TestCase` will wrap the test method in a context manager that catches any non-skip exceptions and appends a repro string to the exception message. The repro includes setting of necessary test flags through env vars. Example: ``` To execute this test, run the following from the base repo dir: PYTORCH_TEST_WITH_CROSSREF=1 python test/test_ops.py -k test_foo_add_cuda_float32 This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0 ``` * To keep track of flag settings, this PR introduces a new `TestEnvironment` class that defines global flags by querying related environment variables. Flag and env var names are purposefully kept searchable via full names. Example usages: ```python TestEnvironment.def_flag("TEST_WITH_TORCHINDUCTOR", env_var="PYTORCH_TEST_WITH_INDUCTOR") # can track implication relationships to avoid adding unnecessary flags to the repro TestEnvironment.def_flag( "TEST_WITH_TORCHDYNAMO", env_var="PYTORCH_TEST_WITH_DYNAMO", implied_by_fn=lambda: TEST_WITH_TORCHINDUCTOR or TEST_WITH_AOT_EAGER) # can use include_in_repro=False to keep the flag from appearing in the repro command TestEnvironment.def_flag( "DISABLE_RUNNING_SCRIPT_CHK", env_var="PYTORCH_DISABLE_RUNNING_SCRIPT_CHK", include_in_repro=False) # the default default value is False, but this can be changed TestEnvironment.def_flag( "PRINT_REPRO_ON_FAILURE", env_var="PYTORCH_PRINT_REPRO_ON_FAILURE", default=(not IS_FBCODE), include_in_repro=False) ``` * AFAICT it is only feasible to achieve this from within the test framework rather than at the CI level. This is because CI / `run_test.py` are unaware of individual test cases. Implementing it in our base `TestCase` class has the broadest area of effect, as it's not isolated to e.g. OpInfo tests. * I couldn't find an easy way to test the logic via `test_testing.py`, as the logic for extracting the test filename doesn't work for generated test classes. I'm open to ideas on testing this, however. [ghstack-poisoned]

…RADCHECK flag" Finishes the job from #104537. See #104537 (review) [ghstack-poisoned]

Finishes the job from #104537. See #104537 (review) [ghstack-poisoned]

jbschlosser · 2023-07-10T20:36:36Z

@pytorchbot merge

pytorchmergebot · 2023-07-10T20:39:12Z

Merge failed

Reason: This PR needs a release notes: label
If your changes are user facing and intended to be a part of release notes, please use a label starting with release notes:.

If not, please add the topic: not user facing label.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "topic: not user facing"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

Details for Dev Infra team

Raised by workflow job

janeyx99 · 2023-07-10T20:51:58Z

@pytorchbot merge

pytorchmergebot · 2023-07-10T20:53:34Z

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging

Check the merge workflow status
here

Finishes the job from #104537. See #104537 (review) Pull Request resolved: #104819 Approved by: https://github.com/huydhn

Testing: Print test reproduction command on failure

cae140a

[ghstack-poisoned]

jbschlosser requested a review from a team as a code owner July 3, 2023 20:34

jbschlosser mentioned this pull request Jun 23, 2023

Print the index and summary of the SampleInput that failed an OpInfo test #99444

Closed

github-actions bot requested review from SherlockNoMad, albanD, antoniojkim, bdhirsh, ezyang, miladm, voznesenskym and wconstab July 3, 2023 20:34

jbschlosser requested review from janeyx99 and zou3519 and removed request for SherlockNoMad, albanD, antoniojkim, bdhirsh, ezyang, miladm, voznesenskym and wconstab July 3, 2023 20:40

jbschlosser added the module: testing Issues related to the torch.testing module (not tests) label Jul 3, 2023

ezyang approved these changes Jul 4, 2023

View reviewed changes

jbschlosser requested a review from ezyang July 6, 2023 22:02

jbschlosser added a commit that referenced this pull request Jul 6, 2023

Testing: Print test reproduction command on failure

1c0200a

ghstack-source-id: 19f27ae Pull Request resolved: #104537

jbschlosser mentioned this pull request Jul 8, 2023

Update run_test.py to use TEST_WITH_SLOW_GRADCHECK flag #104819

Closed

jbschlosser added a commit that referenced this pull request Jul 8, 2023

Update on "Update run_test.py to use TEST_WITH_SLOW_GRADCHECK flag"

8d60d33

Finishes the job from #104537. See #104537 (review) [ghstack-poisoned]

jbschlosser added a commit that referenced this pull request Jul 10, 2023

Update base for Update on "Update run_test.py to use TEST_WITH_SLOW_G…

9e2e37e

…RADCHECK flag" Finishes the job from #104537. See #104537 (review) [ghstack-poisoned]

jbschlosser added a commit that referenced this pull request Jul 10, 2023

Update on "Update run_test.py to use TEST_WITH_SLOW_GRADCHECK flag"

b008a64

Finishes the job from #104537. See #104537 (review) [ghstack-poisoned]

jbschlosser added a commit that referenced this pull request Jul 10, 2023

Update base for Update on "Update run_test.py to use TEST_WITH_SLOW_G…

3a5948f

…RADCHECK flag" Finishes the job from #104537. See #104537 (review) [ghstack-poisoned]

jbschlosser added a commit that referenced this pull request Jul 10, 2023

Update on "Update run_test.py to use TEST_WITH_SLOW_GRADCHECK flag"

ebbc7f5

Finishes the job from #104537. See #104537 (review) [ghstack-poisoned]

pytorchmergebot added the merging label Jul 10, 2023

pytorchmergebot removed the merging label Jul 10, 2023

janeyx99 added the topic: not user facing topic category label Jul 10, 2023

pytorchmergebot added the merging label Jul 10, 2023

pytorchmergebot added Merged and removed merging labels Jul 10, 2023

pytorchmergebot closed this in c2e286d Jul 10, 2023

huydhn mentioned this pull request Jul 11, 2023

Document CI retry rules #103482

Open

pytorchmergebot pushed a commit that referenced this pull request Jul 11, 2023

Update run_test.py to use TEST_WITH_SLOW_GRADCHECK flag (#104819)

ece19bf

Finishes the job from #104537. See #104537 (review) Pull Request resolved: #104819 Approved by: https://github.com/huydhn

facebook-github-bot deleted the gh/jbschlosser/86/head branch July 14, 2023 14:33

jbschlosser mentioned this pull request Sep 11, 2023

Collect more env variables in collect_env.py #108784

Open

Testing: Print test reproduction command on failure #104537

Testing: Print test reproduction command on failure #104537

Uh oh!

Conversation

jbschlosser commented Jul 3, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pytorch-bot bot commented Jul 3, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/104537

✅ No Failures

Uh oh!

ezyang left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jbschlosser commented Jul 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

huydhn commented Jul 10, 2023

Uh oh!

huydhn commented Jul 10, 2023

Uh oh!

jbschlosser commented Jul 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

huydhn commented Jul 10, 2023

Uh oh!

jbschlosser commented Jul 10, 2023

Uh oh!

pytorchmergebot commented Jul 10, 2023

Merge failed

Uh oh!

janeyx99 commented Jul 10, 2023

Uh oh!

pytorchmergebot commented Jul 10, 2023

Merge started

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jbschlosser commented Jul 3, 2023 •

edited

Loading

pytorch-bot bot commented Jul 3, 2023 •

edited

Loading

jbschlosser commented Jul 10, 2023 •

edited

Loading

jbschlosser commented Jul 10, 2023 •

edited

Loading