sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: nn.DataParallel should raise error when provided with list of tensors
Labels: triaged,module: data parallel

## 🐛 Bug

First of all, that you for all the nice work.

Currently, DataParallel does not raise any warning or error if the input is a list or other iterable. The user may assume that if a DataParallel model is given a list of tensors in the forward mode, that it'd send different tensors of that list to different GPUS. For example, a list of 4 tensors each of shape ``[C, H, W]`` on a machine with 4 GPUs could be expected to send one ``[C, H, W]`` tensor to each GPU. Instead, DataParallel slices along the ``C`` dimension. That's not necessarily bad behavior, it just needs to be made clear in the documentation and preferably also raise an error it the input is a list of tensors.

**Note:** torchvision ``GeneralizedRCNN`` module actually produces lists of tensors and is incompatible with DataParallel, as discussed in this [issue](https://github.com/pytorch/vision/issues/1659). I unwittingly used parts of their pipeline with Dataparallel and it was a real pain to track down the issue.

## To Reproduce

Steps to reproduce the behavior: No need, issue already formulated clearly in this [issue](https://github.com/pytorch/vision/issues/1659).

## Expected behavior

An error if the input is a list of tensors.

## Environment
```
Collecting environment information...
PyTorch version: 1.7.1
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.5 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: Could not collect

Python version: 3.8 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: GeForce RTX 2080 Ti
GPU 1: GeForce RTX 2080 Ti
GPU 2: GeForce RTX 2080 Ti
GPU 3: GeForce RTX 2080 Ti

Nvidia driver version: 460.32.03
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.4
[pip3] torch==1.7.1
[pip3] torchvision==0.8.2
[conda] Could not collect
```
Repository: vscode
Issue: Update enable/disable setting descriptions
Labels: feature-request,ux,config

Brought up [through user feedback](https://twitter.com/_tomalak/status/1378989217905266688) that our settings that mention "enabled/disable" in the description are confusing:

<img width="600" src="https://user-images.githubusercontent.com/35271042/113591373-a948bd80-95e8-11eb-9f37-9a36b5753ec7.png">

I realize that this is inconsistent with how we describe other settings and tend to use "Enable" only, to make that clear:

<img width="450" src="https://user-images.githubusercontent.com/35271042/113591705-19574380-95e9-11eb-92a4-ecb92567b141.png">
Repository: go
Issue: doc: explain when to use -ldflags=-extar when cross-compiling
Labels: Documentation,help wanted,NeedsFix

### What version of Go are you using (`go version`)?
go version go1.16.3 darwin/amd64

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
darwin + amd64

### What did you do?

I am compiling Go into a static archive to be called with C code. It works when I compile for the native platform. It does not work when I try to cross-compile for Windows using mingw64

Works:
- cross-compile C for Win using mingw64 (no Go code) (to confirm that my C cross-compile toolchain works)
  `x86_64-w64-mingw32-gcc only_c.c -o only_c.exe`

- native compile: Go to static archive, exporting a function `myExportedFunction`, called by C executable:
  `go build -buildmode=c-archive test.go` # ( exports myExportedFunction )
  `clang test.c test.a -o test` # ( test.c calls myExportedFunction )

No errors or warnings:
- compile Go to static archive targeting Windows (cross-compiled on OSX for use with mingw64)
  `CC=x86_64-w64-mingw32-gcc GOOS=windows CGO_ENABLED=1 go build -o test.w64a -buildmode=c-archive test.go`
- I have also tried using the below to build the archive (no change-- yields the same error below)
  `CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ CPP=x86_64-w64-mingw32-cpp RANLIB=x86_64-w64-mingw32-ranlib AR=x86_64-w64-mingw32-ar LIBTOOL=/opt/mingw64/bin/libtool GOARCH=amd64 GOOS=windows CGO_ENABLED=1 go build -o test.w64a -buildmode=c-archive test.go`

Fails:
- compile executable: C code to call exported Go function, cross-compiled on OSX targeting Windows using mingw64
  `x86_64-w64-mingw32-gcc test.c test.w64a -o test.exe`
- error:
  `/.../x86_64-w64-mingw32-ld: /.../ccmb8owx.o:test.c:(.text+0x29): undefined reference to "myExportedFunction"`

### What did you expect to see?
No error message, and test.exe file created


### What did you see instead?
Error message
Repository: storybook
Issue: Jest Add On Feature Request
Labels: feature request,addon: jest

**Is your feature request related to a problem? Please describe**
My feature is not related to a problem, but is related to why we cannot use the jest test view that is displayed on the jest add on page.

**Describe the solution you'd like**
I would like the ability to choose the view shared in the Jest plugin directory.

**Describe alternatives you've considered**
I can stick with using the current view that the add on displays for my jest test, but I would prefer to use the view that is displayed on the jest add on github page.

**Are you able to assist to bring the feature to reality?**
I can if the help is required.

**Additional context**
Currently when you add the jest add on to storybook you get a view that is different than the view that is displayed on the github page. While the current view displays the correct information I believe the view on the github page is better for viewing the Jest tests components.
Repository: kubernetes
Issue: storage e2e: make read-only block optional
Labels: sig/storage,priority/important-longterm,kind/failing-test,lifecycle/rotten,needs-triage

<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -->

#### Which jobs are failing:
vsphere CSI

#### Which test(s) are failing:
CSI Volumes [Testpattern: Dynamic PV (block volmode)] multiVolume [Slow] should concurrently access the single read-only volume from pods on the same node

#### Since when has it been failing:
since the test was introduced

#### Testgrid link:
n/a

#### Reason for failure:
```
FailedMapVolume: MapVolume.MapPodDevice failed for volume "pvc-5ccaf85d-af04-4c7f-a2b6-aeb239f33e96" : rpc error: code = InvalidArgument desc = read only not supported for Block Volume
```

#### Anything else we need to know:
Repository: vscode
Issue: Non-executable notebook code cells
Labels: under-discussion,notebook-execution

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
I want Notebook support for cells that:
- Are not executable
- Are not markdown
- Are syntax highlighted

If I'm creating a notebook, I may want to add a code block that I do not expect to execute. Perhaps I want a block of CSS, HTML, YAML, or something else that is not (usually) executable. Or maybe I want to add a block of code in a language that is not supported by the notebook. Or maybe I want to add a block of code with a syntax error or some other kind of error, as an example of what *not* to do.

I can embed a code block within a Markdown cell, but A) a separate cell has better UX, and B) that does not work for Markdown Notebooks (when the MD notebook is reopened, the codeblock will become a cell).
Repository: pytorch
Issue: Split test/cpp_extensions/setup.py per orthogonal extension module and/or do Python build from ninja too
Labels: module: build,module: cpp-extensions,triaged

Edit-compile loop for test/cpp_extensions is somewhat slow because Python always relinks each extension module even if there are no changes. One way to fix this is to make it possible to only rebuild one extension (the one you're interested in); another way is to build the Python extension itself from ninja too, so recomp avoidance is properly applied.

cc @malfet @seemethere @walterddr @yf225 @glaringlee
Repository: pytorch
Issue: CI not surfacing some failures (-Werror?) on PR
Labels: module: ci,triaged

## 🐛 Bug

https://github.com/pytorch/pytorch/pull/54896 was reverted because it broke trunk. On the PR, the failures looked like infra flakiness: the displayed message was `sccache: error: couldn't connect to server`. The actual error was buried in the full log.

## To Reproduce

Steps to reproduce the behavior:
1. Send a copy of https://github.com/pytorch/pytorch/pull/54896 out as a PR to PyTorch.

Full error message:
```
Apr 02 23:04:30 In file included from [01m[K/var/lib/jenkins/workspace/c10/core/TensorImpl.cpp:1:0[m[K:
Apr 02 23:04:30 [01m[K/var/lib/jenkins/workspace/c10/core/TensorImpl.h:1851:41:[m[K [01;31m[Kerror: [m[K'[01m[Kc10::TensorImpl::has_contiguity_[m[K' is too small to hold all values of '[01m[Kenum class c10::TensorImpl::HasContiguityPolicy[m[K' [[01;31m[K-Werror[m[K]
Apr 02 23:04:30    HasContiguityPolicy has_contiguity_ : [01;31m[K2[m[K;
Apr 02 23:04:30                                          [01;31m[K^[m[K
Apr 02 23:04:30 cc1plus: all warnings being treated as errors
Apr 02 23:04:30 c10/CMakeFiles/c10.dir/build.make:326: recipe for target 'c10/CMakeFiles/c10.dir/core/TensorImpl.cpp.o' failed
Apr 02 23:04:30 make[2]: *** [c10/CMakeFiles/c10.dir/core/TensorImpl.cpp.o] Error 1
Apr 02 23:04:30 CMakeFiles/Makefile2:3823: recipe for target 'c10/CMakeFiles/c10.dir/all' failed
Apr 02 23:04:30 make[1]: *** [c10/CMakeFiles/c10.dir/all] Error 2
Apr 02 23:04:30 make[1]: *** Waiting for unfinished jobs....
```

## Expected behavior

Error in the PR text should read something like 
```
Apr 02 23:04:30 In file included from [01m[K/var/lib/jenkins/workspace/c10/core/TensorImpl.cpp:1:0[m[K:
Apr 02 23:04:30 [01m[K/var/lib/jenkins/workspace/c10/core/TensorImpl.h:1851:41:[m[K [01;31m[Kerror: [m[K'[01m[Kc10::TensorImpl::has_contiguity_[m[K' is too small to hold all values of '[01m[Kenum class c10::TensorImpl::HasContiguityPolicy[m[K' [[01;31m[K-Werror[m[K]
Apr 02 23:04:30    HasContiguityPolicy has_contiguity_ : [01;31m[K2[m[K;
Apr 02 23:04:30                                          [01;31m[K^[m[K
```

(perhaps with the non-printable terminal colorization characters cleaned up)

## Environment

CI on PyTorch GitHub PR.


cc @ezyang @seemethere @malfet @walterddr @pytorch/pytorch-dev-infra
Repository: pytorch
Issue: Tests should be runnable without run_test.py
Labels: triaged,module: testing

I don't really like run_test.py; I prefer to run my tests directly if at all possible. There are numerous reasons:

* I can use pytest
* I can attach my debugger to the test process without having to follow into the child subprocess
* It's one less layer of indirection where something could go wrong

However, there are some tests that *require* to be run via run test, otherwise they don't work. These include the cpp_extensions tests (run_test.py takes care of recompiling the cpp extensions before the test program loads them up), and distributed, where some process wide environment variables and custom runners (mpiexec) have to be run.

I'd like it to be easier to run these tests without run_test.py. Ideally, we figure out how to run these tests from a normal Python invocation without any other mucking about, so they integrate seamlessly with pytest
Repository: godot
Issue: Rotated VehicleWheel spins in the wrong direction
Labels: bug,confirmed,topic:physics,breaks compat,topic:3d

**Godot version:**
Godot 3.2.3

**OS/device including version:**
Windows 10 64 bits

**Issue description:**
I started experimenting with `VehicleBody` and `VehicleWheel`, and quickly noticed the axis convention for "forward" on the wheels is +Z, which is against the convention Godot uses (-Z) for other things such as the camera and `look_at`. So I decided to flip wheels by rotating them by 180 degrees. The vehicle properly moves in the opposite direction, and steers in the same relative direction. However MeshInstances I added as child of the wheels rotate backward now, which is inconsistent with the physical result.

**Steps to reproduce:**
Create a `VehicleBody` with 4 wheels, and set wheel Y rotations to 180 degrees.

**Minimal reproduction project:**
[VehicleWheels.zip](https://github.com/godotengine/godot/files/6260923/VehicleWheels.zip)
Repository: electron
Issue: [Feature Request]: query user notification authorization status and settings
Labels: enhancement :sparkles:,platform/macOS,component/notifications

### Preflight Checklist

I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Electron APIs don't let apps query the authorization status and settings of user notifications:
https://www.electronjs.org/docs/api/notification

### Proposed Solution

Expose the available macOS APIs to let apps query authorization status and settings of user notifications:
https://developer.apple.com/documentation/usernotifications/unnotificationsettings?language=objc

For example, an app could check with either `alertSetting` or `alertStyle` whether it is allowed to post alerts (persistent notifications).

### Alternatives Considered

You could write a native addon for node, see here: https://nodejs.org/api/n-api.html#n_api_node_api. You would probably write a library in XCode (using Swift or Obj-C) and then create bindings for it using N-API.

### Additional Information

See screenshot.

![CleanShot 2021-04-05 at 15 24 00@2x](https://user-images.githubusercontent.com/439447/113634109-7c3eee00-966e-11eb-9360-c57c2845ec47.png)
Repository: pytorch
Issue: [RFC] Plan to deduplicate test_c10d and distributed_test 
Labels: oncall: distributed,triaged,better-engineering

## Problem 
We currently have 2 distinct test files for testing features of the `torch.distributed` package: test_c10d.py and distributed_test.py. As a result, several of our tests are scattered across these two files, and there is no clear line signifying which tests belong in which file. For example, test_c10d.py contains tests for collective comm. APIs as well as DistributedDataParallel, while distributed_test.py also contains some tests for DDP and collective comm.

This makes it hard for developers in a few ways, mostly by taking extra time searching through both files to find if a particular feature is tested, and slight semantics differences in using fork/spawn/multiprocessing for the 2 files, such as the issue in https://github.com/pytorch/pytorch/issues/53623. 

## Desired Outcome
The desired outcomes of this effort is to 1) Make it easier and clearer for developers and OSS contributors to write and run their tests in PT distributed, 2) Eliminate a class of issues such as https://github.com/pytorch/pytorch/issues/53623 around fork() and spawn() (similar to what we did for `distributed_test.py`) and 3) modularize test files to unittest single components of torch.distributed.

## Pitch
To begin with, we should dedupe the 2 files such that `distributed_test.py` contains all DDP and other misc tests, while `test_c10d` contains multiprocessing comm. backend/collectives tests (things specific to process groups and collectives such as `all_reduce`). 

Also, `test_c10d` has several test classes that don't use multiprocessing, such as `StoreTest`. The pitch here is to move all these non-multiprocessing test to their standalone files, which will also reduce file size and increase readability. For example, we will move `StoreTest` to a `test_store.py` file. After that, `test_c10d` will be left with the following multiprocessing tests:

1) DistributedDataParallelTest (to be deduped and put into distributed_test.py)
2) NcclErrorHandlingTest
3) ProcessGroupGlooTest
4) CommTest

In addition, we will move all communication backend/collectives tests from `distributed_test.py` to test_c10d as part of this change.

Finally, while doing this deduping we will automatically address https://github.com/pytorch/pytorch/issues/53623 as we won't be forking after initializing CUDA from a different test anymore (since all tests in test_c10d will inherit from `MultiProcessTestCase`).

In addition, we should move all tests from `test_c10d_spawn` to `test_c10d`, and default to always running `test_c10d` with spawn multiprocessing which is the general mode we recommend as forking a multithreaded process with cuda context is problematic. We can still run `fork` tests internally to maintain signal, similar to what we do for rpc tests.

Open to any thoughts/questions about this approach.


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu
Repository: flutter
Issue: FlutterComputePlatformResolvedLocaleCallback does not provide user_data baton
Labels: engine,e: embedder,P3,c: tech-debt,team-engine,triaged-engine

`FlutterComputePlatformResolvedLocaleCallback` (set in the `compute_platform_resolved_locale_callback` field of the `FlutterProjectArgs` struct) does not provide the standard `user_data` baton provided to the engine in `FlutterEngineRun`.

Adding this parameter to the existing callback would be an ABI-breaking change. Instead, we should provide an additional callback signature that adds the `user_data` baton parameter, and an additional `FlutterProjectArgs` struct member where the user can register this callback. During callback registration in, embedder.cc we would then check for the new variant, and if present, call that; otherwise fall back to the original variant so as not to break existing embedders who drop in a new flutter embedder shared lib. 

When we do this, we should update the documentation to clarify that embedder authors should implement the new callback, and probably mark the old field as deprecated, potentially renaming it to `compute_platform_resolved_locale_callback__deprecated__` as a signal to embedders to migrate on their next rebuild.

There's no need to do this until we we get a request for it, but if we ever bump the embedder ABI version; this is something we should fix.
Repository: storybook
Issue: @storybook/angular renderer component selector issue
Labels: question / support,angular

**Description**
Looks like the storybook renderer for angular doesn't account for components with selectors containing attributes (see example).

**To Reproduce**
Steps to reproduce the behavior:

1. Create a component with an attribute selector: ```@Component({ selector: 'my-component[type=text]'})```
2. Create a story for the component. My story has a template e.g. ```export const default = (args) => ({ props: args, template: '<my-component type="text"></my-component>' })```, but I suspect that even without one this issue would occur.
3. Observe a syntax error when trying to view the story. ```SyntaxError: Unexpected character "="```

**Expected behavior**
The story should render.

**System**
Environment Info:

  System:
    OS: Windows 10 10.0.18363
    CPU: (8) x64 Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz
  Binaries:
    Node: 12.18.3 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 6.14.6 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 89.0.4389.90
    Edge: Spartan (44.18362.449.0)
  npmPackages:
    @storybook/addon-controls: ^6.2.0-beta.15 => 6.2.0-beta.15
    @storybook/addon-docs: ^6.2.0-beta.15 => 6.2.0-beta.15
    @storybook/addons: ^6.2.0-beta.15 => 6.2.0-beta.15
    @storybook/angular: ^6.2.0-beta.15 => 6.2.0-beta.15
    @storybook/builder-webpack5: ^6.2.0-rc.12 => 6.2.0-rc.12

**Additional context**
FYI this was working in 6.2.0-alpha.19
I did some debugging and it looks like the error happens as a result of the computesTemplateFromComponent method in this file: https://github.com/storybookjs/storybook/blob/edb8b41d1850830a9e3696322f77383d9f6bb04b/app/angular/src/client/preview/angular-beta/ComputesTemplateFromComponent.ts

The last line returns a string with a closing tag that computes the closing tag using `ngComponentMetadata.selector` and unfortunately, in my case `ngComponentMetadata.selector` isn't a simple element selector. It has attributes as well, and so the method ends up returning something like `"<my-input[type="text"]><my-input[type=text]>"`.

Ultimately, the string above gets passed to `prettier` by the `sourceDecorator()` method, and `prettier` complains about the closing tag having invalid syntax.

If you have a quick workaround that doesn't involve changing my component's selector, that'd be great. I'm also happy to keep digging into this myself if you like.

*edit: formatting
Repository: TypeScript
Issue: Array destructuring is transpiled with `__read` helper even when asking for no transpilation and no inline helper functions.
Labels: Bug,Domain: JS Emit,Rescheduled

# Bug Report

### 🔎 Search Terms

array destructuring
`downLevelIteration`
`importHelpers`
ESNEXT
CommonJS

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about `importHelpers`

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?downlevelIteration=true&importHelpers=true&target=99&module=1#code/CYUwxgNghgTiAEAzArgOzAFwJYHtVJxwAoBKALnilQE8BuAKHpAA8AHHGDeMPAZy4DaAQQA08AGoBdeAF4CxErSA)

Note: I'm not sure how to reliably get the `target` option to encode into the URL; you may need to set the target manually to `ESNext` (or any other value >= `ES2015`)

### 💻 Code

```ts
declare function foo(): any;

export const [A, V] = foo();
```

### 🙁 Actual behavior

The `__read` transpilation helper was injected into the output JS, even though I specified that I didn't want transpilation (through `target=ESNEXT`).  Additionally, the transpilation helper was injected inline even though I specified the `importHelpers=true` option.

```js
"use strict";
var __read = (this && this.__read) || function (o, n) {
    var m = typeof Symbol === "function" && o[Symbol.iterator];
    if (!m) return o;
    var i = m.call(o), r, ar = [], e;
    try {
        while ((n === void 0 || n-- > 0) && !(r = i.next()).done) ar.push(r.value);
    }
    catch (error) { e = { error: error }; }
    finally {
        try {
            if (r && !r.done && (m = i["return"])) m.call(i);
        }
        finally { if (e) throw e.error; }
    }
    return ar;
};
var _a;
Object.defineProperty(exports, "__esModule", { value: true });
exports.V = exports.A = void 0;
_a = __read(foo(), 2), exports.A = _a[0], exports.V = _a[1];
```

### 🙂 Expected behavior

I was expecting output that leveraged the `target=ESNEXT` setting to include the array destructuring in the output code, like:

```js
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.V = exports.A = void 0;
const [A, V] = foo();
exports.A = A;
exports.V = V;
```