sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: youtube-dl
Issue: Not downloading from twitcast (i think they changed servers again)
Labels: broken-IE

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2021.12.17. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Make sure that all provided video/audio/playlist URLs (if any) are alive and playable in a browser.
- Make sure that all URLs and arguments with special characters are properly quoted or escaped as explained in http://yt-dl.org/escape.
- Search the bugtracker for similar issues: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a broken site support
- [x] I've verified that I'm running youtube-dl version **2021.12.17**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
- [x] I've searched the bugtracker for similar issues including closed ones


## Verbose log

<!--
Provide the complete verbose output of youtube-dl that clearly demonstrates the problem.
Add the `-v` flag to your command line you run youtube-dl with (`youtube-dl -v <your command line>`), copy the WHOLE output and insert it below. It should look similar to this:
 [debug] System config: []
 [debug] User config: []
 [debug] Command-line args: [u'-v', u'http://www.youtube.com/watch?v=BaW_jenozKcj']
 [debug] Encodings: locale cp1251, fs mbcs, out cp866, pref cp1251
 [debug] youtube-dl version 2021.12.17
 [debug] Python version 2.7.11 - Windows-2003Server-5.2.3790-SP2
 [debug] exe versions: ffmpeg N-75573-g1d0487f, ffprobe N-75573-g1d0487f, rtmpdump 2.4
 [debug] Proxy map: {}
 <more lines>
-->

```
PASTE VERBOSE LOG HERE
```


## Description

<!--
Provide an explanation of your issue in an arbitrary form. Provide any additional information, suggested solution and as much context and examples as possible.
If work on your issue requires account credentials please provide them or explain how one can obtain them.
-->

WRITE DESCRIPTION HERE

Was trying to download a stream with three m3u8 links (cuz it was three hours long) and it was mentioned to me that they possibly changed servers in order to keep ppl from downloading.

The said error comes up when I try to dl:
```
[TwitCasting] 721738886: Downloading webpage
ERROR: Unable to extract movie playlist; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
```
Repository: opencv
Issue: treatment of float value ranges differs between imshow and imwrite
Labels: RFC

I've seen several people confused by this behavior, so I'd like to discuss this.

Say you have a Mat/array of float type (`CV_32F` or `CV_64F`). `imshow` assumes the range to be 0.0 to 1.0, while `imwrite` assumes the range to be 0 to 255.

I know these behaviors were probably implemented two decades ago, are now considered solid API, and can't be brought in line now (_or can they?_).

What I'd like to propose is either or both of two things:

1. Both functions, when given floats, do a `minMaxLoc` or similar operation, and issue a warning if those ranges indicate accidentally wrong use (near `[0, 1]` for imwrite, near `[0, 255]` for imshow). The check could be disableable but I think it should be on by default (because newbies). It could be a one-time warning, the check disabled after it's triggered once.
2. Improve documentation for both functions. [`imwrite`](https://docs.opencv.org/4.x/d4/da8/group__imgcodecs.html#gabbc7ef1aa2edfaa87772f1202d67e0ce) currently doesn't discuss data types and value ranges at all. [`imshow`](https://docs.opencv.org/4.x/d7/dfc/group__highgui.html#ga453d42fe4cb60e5723281a89973ee563) could be a little clearer and more precise. I think both should contain references to each other and clarify the behavior symmetrically ("in contrast to ..., this function behaves like... case case case")

I'd work on a patch for the documentation and offer a pull request (unless I forget).

On the first point, I'd like some opinions/preferences though. That check would very likely cost some CPU time, with little benefit to anyone other than newbies. Depending on how much is going on already, maybe it could be nearly zero cost for at least one of both APIs (image libraries might emit some usable statistics already).
Repository: pytorch
Issue: `LayerNorm` triggers INTERNAL ASSERT
Labels: high priority,module: cpu,module: error checking,triaged,module: norms and normalization

### 🐛 Describe the bug

`LayerNorm` triggers INTERNAL ASSERT

```python
import torch
normalized_shape = [1024]
layer = torch.nn.LayerNorm(normalized_shape)
input = torch.randint(0,8, [0, 1, 1024])
res = layer(input)
# RuntimeError: isDifferentiableType(variable.scalar_type())INTERNAL ASSERT FAILED at "../torch/csrc/autograd/functions/utils.h":65, please report a bug to PyTorch.
```

I think this is because `LayerNorm` skips the dtype check for empty tensor. For example, 
```python
import torch
normalized_shape = [1024]
layer = torch.nn.LayerNorm(normalized_shape)
input = torch.randint(0,8, [1, 1, 1024])
res = layer(input)
# RuntimeError: "LayerNormKernelImpl" not implemented for 'Long'
```

### Versions

pytorch: 1.10.1

cc @ezyang @gchanan @zou3519 @VitalyFedyunin
Repository: create-react-app
Issue: More verbose output from yarn start
Labels: needs triage

When running yarn start, there is no output between "Starting development server" and "Compiled successfully!". In the codebase of my large company, this means there is no output for over a minute. I want to debug our slow setup so I want to see what's going on in that minute. Is there any way to set a "verbose" mode that outputs what's going on during that time?

I've included a video of this from a fresh create-react-app for reference: 
https://drive.google.com/file/d/1RkVN_O8RAzcNfw-Xb1iZCzdIfGMmgXYx/view
Repository: pytorch
Issue: [feature request] Support tensor count vector argument in torch.split 
Labels: module: bootcamp,triaged,enhancement

### 🚀 The feature, motivation and pitch

Currently `torch.split` can accept a tuple of ints, implementing `split_with_sizes` (I propose `torch.split_with_sizes` to be then made private / deprecated instead of documenting: https://github.com/pytorch/pytorch/issues/58181)

Sometimes it's convenient to pass in sizes as a tensor instead of tuple. Tensor could also be a CUDA tensor then without forcing GPU->CPU copy. This can be useful when synchronizing a "nested" tensor list:
```
>>> torch.rand(10, device = 'cuda').split(torch.tensor([5, 5], device = 'cuda'))
Traceback (most recent call last):
  File ".../vadim/prefix/miniconda/lib/python3.9/site-packages/torch/_tensor.py", line 510, in split
    split_size = int(split_size)
ValueError: only one element tensors can be converted to Python scalars

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../vadim/prefix/miniconda/lib/python3.9/site-packages/torch/_tensor.py", line 513, in split
    return super(Tensor, self).split_with_sizes(split_size, dim)
TypeError: split_with_sizes(): argument 'split_sizes' (position 1) must be tuple of ints, not Tensor

>>> torch.rand(10, device = 'cuda').split(torch.tensor([5, 5], device = 'cuda').tolist())
(tensor([0.0725, 0.3508, 0.9368, 0.2485, 0.2627], device='cuda:0'), tensor([0.3593, 0.4366, 0.6633, 0.6635, 0.5102], device='cuda:0'))
```
```python
def all_gather_tensors(tensor):
    if get_world_size() == 1:
        return [tensor]

    shape_tensor = torch.tensor(tensor.shape, dtype = torch.int64, device = tensor.device)
    shapes = list(torch.zeros([world_size, len(tensor.shape)], dtype = torch.int64, device = tensor.device).unbind())
    torch.distributed.all_gather(shapes, shape_tensor)

    max_shape = torch.stack(shapes).amax(dim=0).tolist()
    pad = sum([[0, max_dim - dim] for max_dim, dim in reversed(list(zip(max_shape, tensor.shape)))], [])
    padded_tensor = F.pad(tensor, pad = pad)

    tensors = list(torch.zeros([world_size, *padded_tensor.shape], dtype=padded_tensor.dtype, device=padded_tensor.device).unbind())
    torch.distributed.all_gather(tensors, padded_tensor)

    for i, shape in enumerate(shapes):
        tensors[i] = tensors[i][[slice(x) for x in shape.tolist()]]

    return tensors

def all_gather_tensors_cat(tensors):
    return torch.cat(all_gather_tensors(torch.cat(tensors)))

def all_gather_tensors_nested(tensors):
    counts = torch.tensor(list(map(len, tensors)), dtype = torch.int64)
    counts = torch.cat(all_gather_tensors(counts))
    tensor = all_gather_tensors_cat(tensors)
    return tensor.split(counts.tolist())
``` 

### Alternatives

_No response_

### Additional context

_No response_
Repository: pytorch
Issue: Cuda lacks checking of "out of bound"
Labels: module: nn,module: loss,module: cuda,module: error checking,triaged

### 🐛 Describe the bug

Cuda lacks checking of "out of bound" in some APIs. For example,

```python
results = dict()
import torch
arg_class = torch.nn.MultiLabelMarginLoss()
input_tensor = torch.rand([1, 4], dtype=torch.float32)
target_tensor = torch.randint(256,16384,[1, 4], dtype=torch.int64)

try:
  results["res_cpu"] = arg_class(input_tensor.clone(), target_tensor.clone())
except Exception as e:
  results["err_cpu"] = "ERROR:"+str(e)

arg_class = arg_class.cuda()
try:
  results["res_gpu"] = arg_class(input_tensor.clone().cuda(), target_tensor.clone().cuda())
except Exception as e:
  results["err_gpu"] = "ERROR:"+str(e)

print(results)
# {'err_cpu': "ERROR:argument #2 'target' is out of range", 'res_gpu': tensor(6.9519, device='cuda:0')}
```

`MultiLabelMarginLoss` fails in cpu but works in cuda.

Other APIs
```python
torch.nn.functional.cross_entropy
torch.nn.functional.nll_loss
torch.scatter
torch.take
torch.gather
torch.index_select
```

### Versions

PyTorch: 1.10.2
GPU: RTX 3080 Ti
Cuda: 11.3

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @ngimel
Repository: pytorch
Issue: Floating point exception in _nnpack_spatial_convolution
Labels: high priority,module: cpu,module: error checking,module: convolution,triaged,module: nnpack

### 🐛 Describe the bug

### Example to reproduce

```python
import torch

input = torch.full((1, 2, 6, 6,), 1, dtype=torch.float32, requires_grad=False)
weight = torch.full((1, 2, 6, 6,), 1, dtype=torch.float32, requires_grad=False)
bias = torch.full((1, 2, 6, 6,), 1, dtype=torch.float32, requires_grad=False)
padding = [0, 0]
stride = [0, 0]
torch._nnpack_spatial_convolution(input, weight, bias, padding, stride)
```

### Result
```floating point exception```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using fuzz testing.

### Versions

### Version information

PyTorch version: 1.9.0a0+git4d36e60
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.2
[pip3] torch==1.9.0a0+git4d36e60
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.19.5                   pypi_0    pypi
[conda] torch                     1.9.0a0+git4d36e60           dev_0    <develop>

cc @ezyang @gchanan @zou3519 @VitalyFedyunin
Repository: pytorch
Issue: Segmentation fault in _sobol_engine_ff_
Labels: module: error checking,triaged,module: random,module: edge cases

### 🐛 Describe the bug

Segmentation fault in `_sobol_engine_ff_` when `n` and `dimension` are large.

### Example to reproduce

```python
import torch

self = torch.full((2,), 1, dtype=torch.int64, requires_grad=False)
n = 1250999896764
sobolstate = torch.full((2, 30,), 1, dtype=torch.int64, requires_grad=False)
dimension = 1250999896764
num_generated = 0
torch._sobol_engine_ff_(self, n, sobolstate, dimension, num_generated)
```

### Result
```segmentation fault```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using fuzz testing.

### Versions

PyTorch version: 1.9.0a0+git4d36e60
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.2
[pip3] torch==1.9.0a0+git4d36e60
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.19.5                   pypi_0    pypi
[conda] torch                     1.9.0a0+git4d36e60           dev_0    <develop>

cc @pbelevich @ezyang @gchanan @zou3519
Repository: pytorch
Issue: Segmentation fault in _sobol_engine_initialize_state_
Labels: module: error checking,triaged,module: random,module: edge cases

### 🐛 Describe the bug

Segmentation fault in `_sobol_engine_initialize_state_` when `dimension` is large.

### Example to reproduce

```python
import torch

self = torch.full((2, 30,), 1, dtype=torch.int64, requires_grad=False)
dimension = 1250999896764
torch._sobol_engine_initialize_state_(self, dimension)
```

### Result
```segmentation fault```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using fuzz testing.

### Versions

PyTorch version: 1.9.0a0+git4d36e60
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.2
[pip3] torch==1.9.0a0+git4d36e60
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.19.5                   pypi_0    pypi
[conda] torch                     1.9.0a0+git4d36e60           dev_0    <develop>

cc @pbelevich @ezyang @gchanan @zou3519
Repository: pytorch
Issue: Segmentation fault in _sobol_engine_scramble_
Labels: module: error checking,triaged,module: random,module: edge cases

### 🐛 Describe the bug

Segmentation fault in `_sobol_engine_scramble_` when `dimension` is large.

### Example to reproduce

```python
import torch

self = torch.full((100, 30,), 1, dtype=torch.int64, requires_grad=False)
ltm = torch.full((100, 30, 30,), 1, dtype=torch.int64, requires_grad=False)
dimension = 1250999896764
torch._sobol_engine_scramble_(self, ltm, dimension)
```

### Result
```segmentation fault```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using fuzz testing.

### Versions

PyTorch version: 1.9.0a0+git4d36e60
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.2
[pip3] torch==1.9.0a0+git4d36e60
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.19.5                   pypi_0    pypi
[conda] torch                     1.9.0a0+git4d36e60           dev_0    <develop>

cc @ezyang @gchanan @zou3519 @pbelevich
Repository: pytorch
Issue: Segmentation fault in fractional_max_pool2d
Labels: high priority,module: cpu,module: error checking,triaged,module: pooling

### 🐛 Describe the bug

Segmentation fault in `fractional_max_pool2d` when `output_size` contains 0s.

### Example to reproduce

```python
import torch

self = torch.full((1, 3, 7, 6,), 1, dtype=torch.float64, requires_grad=False)
kernel_size = [0, 0]
output_size = [0, 0]
random_samples = torch.full((1, 3, 7, 6,), 1, dtype=torch.float64, requires_grad=False)
torch._C._nn.fractional_max_pool2d(self, kernel_size, output_size, random_samples)
```

### Result
```segmentation fault```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using fuzz testing.

### Versions

PyTorch version: 1.9.0a0+git4d36e60
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.2
[pip3] torch==1.9.0a0+git4d36e60
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.19.5                   pypi_0    pypi
[conda] torch                     1.9.0a0+git4d36e60           dev_0    <develop>

cc @ezyang @gchanan @zou3519 @VitalyFedyunin
Repository: pytorch
Issue: Segmentation fault in fractional_max_pool3d
Labels: high priority,module: cpu,module: error checking,triaged,module: pooling

### 🐛 Describe the bug

Segmentation fault in `fractional_max_pool3d` when `output_size` contains 0s.

### Example to reproduce

```python
import torch

self = torch.full((2, 4, 5, 5, 5,), 1, dtype=torch.float64, requires_grad=False)
kernel_size = [0, 0, 0]
output_size = [0, 0, 0]
random_samples = torch.full((2, 4, 5, 5, 5,), 1, dtype=torch.float64, requires_grad=False)
torch._C._nn.fractional_max_pool3d(self, kernel_size, output_size, random_samples)
```

### Result
```segmentation fault```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using fuzz testing.

### Versions

PyTorch version: 1.9.0a0+git4d36e60
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.2
[pip3] torch==1.9.0a0+git4d36e60
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.19.5                   pypi_0    pypi
[conda] torch                     1.9.0a0+git4d36e60           dev_0    <develop>

cc @ezyang @gchanan @zou3519 @VitalyFedyunin
Repository: pytorch
Issue: Segmentation fault in max_pool1d
Labels: module: error checking,triaged,module: pooling,module: edge cases

### 🐛 Describe the bug

Segmentation fault in `max_pool1d` when `kernel_size`, `stride` and `dilation` are large.

### Example to reproduce

```python
import torch

self = torch.full((2, 10, 4,), 0.5, dtype=torch.float64, requires_grad=False)
kernel_size = [1250999896764]
stride = [1250999896764]
padding = [0]
dilation = [1250999896764]
ceil_mode = True
torch.max_pool1d(self, kernel_size, stride, padding, dilation, ceil_mode)
```

### Result
```segmentation fault```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using fuzz testing.

### Versions

PyTorch version: 1.9.0a0+git4d36e60
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.2
[pip3] torch==1.9.0a0+git4d36e60
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.19.5                   pypi_0    pypi
[conda] torch                     1.9.0a0+git4d36e60           dev_0    <develop>

cc @ezyang @gchanan @zou3519