sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Dispatch table for linalg_norm is fishy
Labels: triaged,module: dispatch,better-engineering,module: norms and normalization

Current native_functions.yaml entry is:

```
- func: linalg_norm(Tensor self, Scalar? ord=None, int[1]? dim=None, bool keepdim=False, *, ScalarType? dtype=None) -> Tensor
  python_module: linalg
  variants: function

- func: linalg_norm.ord_str(Tensor self, str ord, int[1]? dim=None, bool keepdim=False, *, ScalarType? dtype=None) -> Tensor
  python_module: linalg
  variants: function

- func: linalg_norm.out(Tensor self, Scalar? ord=None, int[1]? dim=None, bool keepdim=False, *, ScalarType? dtype=None, Tensor(a!) out) -> Tensor(a!)
  use_c10_dispatcher: hacky_wrapper_for_legacy_signatures
  python_module: linalg
  variants: function

- func: linalg_norm.ord_str_out(Tensor self, str ord, int[1]? dim=None, bool keepdim=False, *, ScalarType? dtype=None, Tensor(a!) out) -> Tensor(a!)
  use_c10_dispatcher: hacky_wrapper_for_legacy_signatures
  python_module: linalg
  variants: function
```

As there is no dispatch table, all of the linalg_norm entries are registered as Math, implying that they work universally. But this doesn't seem to be true:

```
======================================================================
ERROR: test_norm_matrix_meta_float32 (__main__.TestLinalgMETA)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/users/ezyang/pytorch-tmp/torch/testing/_internal/common_utils.py", line 955, in wrapper
    method(*args, **kwargs)
  File "/data/users/ezyang/pytorch-tmp/torch/testing/_internal/common_device_type.py", line 292, in instantiated_test
    raise rte
  File "/data/users/ezyang/pytorch-tmp/torch/testing/_internal/common_device_type.py", line 287, in instantiated_test
    result = test_fn(self, *args)
  File "/data/users/ezyang/pytorch-tmp/torch/testing/_internal/common_device_type.py", line 584, in dep_fn
    return fn(slf, device, *args, **kwargs)
  File "test/test_linalg.py", line 1289, in test_norm_matrix
    run_test_case(input, ord, dim, keepdim)
  File "test/test_linalg.py", line 1259, in run_test_case
    result = torch.linalg.norm(input, ord, dim, keepdim)
RuntimeError: matrix norm only supports CPU AND CUDA device type, got: meta
```

I don't mind diagnosing this particular problem but it seems like we still have some sort of education problem about how to properly setup dispatch tables for new operators.

cc @ailzhang @kurtamohler @mruberry
Repository: node
Issue: NodeJS fails to build on Oracle Solaris 11.4
Labels: build

<!--
Thank you for reporting an issue.

This issue tracker is for bugs and issues found within Node.js core.
If you require more general support please file an issue on our help
repo. https://github.com/nodejs/help


Please fill in as much of the template below as you're able.

Version: output of `node -v`
Platform: output of `uname -a` (UNIX), or output of `"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" })"` in PowerShell console (Windows)
Subsystem: if known, please specify affected core module name
-->

* **Version**: Right from the trunk
* **Platform**: Oracle Solaris 11.4, x86_64
* **Subsystem**:

### What steps will reproduce the bug?
Try to build NodeJS from source, using `./configure && gmake`, on Oracle Solaris 11.4, if you have CLANG 11 and Python 3.5 installed.

### How often does it reproduce? Is there a required condition?
I think it occurs every time.

### What is the expected behavior?
I expect that NodeJS successfully builds.

### What do you see instead?
There are linker errors saying `pthread_attr_get_np` cannot be found, and there are TypeErrors inside the `genv8constants.py` file.

### Additional information
I have found some seemingly simple way to fix that problem: https://github.com/nodejs/node/pull/37772
I am not a professional programmer, and I don't know how to make sure that fix does not break something.
Repository: TypeScript
Issue: Evaluate user-defined generic type aliases on hover
Labels: Suggestion,Awaiting More Feedback

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
Let's say we have a class like this:

```typescript
class A
{
    readonly x = 99;
    s: string;

    constructor(initialiser: { [K in Exclude<keyof A, 'x'>]: A[K] })
    {
        for (const k in initialiser) this[k] = initialiser[k];
    }
}
```
Now, when I hover over the ctor param, VS Code shows me the type: ```{ s: string; }```.

Since I need such an initialiser for several classes, I have written a generic type alias:

```typescript
type InitialiserExclude<C, Keys extends keyof C> = { [K in Exclude<keyof C, Keys>]: C[K] };
```
When I replace the ```initialiser``` type by ```InitialiserExclude<A, 'x'>```, that's exactly what I see when hovering over the ctor param.

It would be very nice if VS Code evaluated such user-defined type aliases as it does with e. g. the built-in ```Exclude<T, U>``` and showed the resulting object type.

This is not only a matter of usability of the class. To create more complex initialiser types, it can be necessary to define multiple generic type aliases and use one within another, and the only way I know to check if such an initialiser works as expected is to declare a variable with that type and hover over it.
Repository: TypeScript
Issue: Go to definition on callable property returns two definitions
Labels: Suggestion,Needs Proposal

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

- go to definition
- callable

### 🕗 Version & Regression Information

4.3.0-dev.20210316

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?#code/PTAEFkE9QYwewCYFNQHM5IM6gBZIE5JA)

### 💻 Code

```ts
interface ICallable {
    (): any
}
class K {
    callable: ICallable;
}

new K().callable()
```

Run go to definition on `callable`

### 🙁 Actual behavior

Two definitions are returned, for for `K.callable` and one for `(): any` in `ICallable`

### 🙂 Expected behavior

Just the definition for `K.callable` is returned
Repository: vscode
Issue: [Request] [Notebook] Allow notebook webview to have access to media devices
Labels: feature-request,notebook-output,notebook-api

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
Notebook output is commonly HTML/JavaScript and user-facing websites can request access to the user's webcam/microphone and this could be hugely beneficial in notebooks as well, particularly for machine learning and speech recognition scenarios, but it's not exposed by electron by default.  See [here](https://github.com/electron/electron/issues/27208).

Consider the following scenario, modified from a [this](https://developers.google.com/web/fundamentals/media/recording-audio) blog post:

1. Install the .NET Interactive extension.
2. Create a new blank .NET Interactive notebook.
3. Set the first cell's language to "JavaScript (.NET Interactive)"
4. Set the cell contents to:

``` javascript
#!javascript
navigator.mediaDevices.getUserMedia({ audio: true, video: false }).then(stream => {
    const context = new AudioContext();
    const source = context.createMediaStreamSource(stream);
    const processor = context.createScriptProcessor(1024, 1, 1);

    source.connect(processor);
    processor.connect(context.destination);

    processor.onaudioprocess = function(e) {
        // Do something with the data, e.g. convert it to WAV
        console.log(e.inputBuffer);
    };
});
```

Result:
Error: NotAllowedError: Permission denied

Expected:
The user should be prompted to allow access to the microphone.
Repository: pytorch
Issue: cdist skip for manual backward is kind of janky
Labels: triaged,module: dispatch,better-engineering,module: distance functions

The fix in #31167 is pretty cute but it is kind of janky.  What I mean by this is that the function `cdist_impl` is sometimes expected to be able to automatically compute autograd (in particular, when `p == 2 && (mode == 1 || (mode == 0 && (r1 > 25 || r2 > 25)))`), but other times it does NOT compute autograd and you're expected to have called it in a context with manual backward. I can see why the PR was done this way (in the way it is implemented, you get to keep standard error checking), but I think it would be clearer and more obvious to readers if we were able to split `cdist_impl` into its two separate cases, one that is fully composite, and the other that requires a manual autograd.

One concrete consequence of this, is that `cdist` advertises itself as working for all backends (as it is a Math kernel), but the error checking requires CPU/CUDA. I was able to fix it with this minipatch, but a more comprehensive fix would be the refactor as above.

```
diff --git a/aten/src/ATen/native/Distance.cpp b/aten/src/ATen/native/Distance.cpp
index 1d672e6585..ea6798d5d2 100644
--- a/aten/src/ATen/native/Distance.cpp
+++ b/aten/src/ATen/native/Distance.cpp
@@ -44,12 +44,11 @@ Tensor _euclidean_dist(const Tensor& x1, const Tensor& x2) {
 static Tensor cdist_impl(const Tensor& x1, const Tensor& x2, const double p, c10::optional<int64_t> compute_mode) {
   TORCH_CHECK(at::isFloatingType(x1.scalar_type()), "cdist only supports floating-point dtypes, X1 got: ", x1.scalar_type());
   auto device1 = x1.device().type();
-  TORCH_CHECK(device1 == kCPU || device1 == kCUDA, "cdist only supports CPU and CUDA devices, X1 got: ", device1);
   TORCH_CHECK(at::isFloatingType(x1.scalar_type()), "cdist only supports floating-point dtypes, X2 got: ", x2.scalar_type());
   auto device2 = x2.device().type();
-  TORCH_CHECK(device2 == kCPU || device2 == kCUDA, "cdist only supports CPU and CUDA devices, X2 got: ", device2);
   TORCH_CHECK(p >= 0, "cdist only supports non-negative p values");
   TORCH_CHECK(device1 == device2, "X1 and X2 must have the same device type. X1: ", device1, " X2: ", device2);
+  // TODO: This is bad; this test should apply universally
   TORCH_CHECK(!x1.is_cuda() || x1.get_device() == x2.get_device(), "device of X1 (", x1.get_device(), ") must match device of X2 (", x2.get_device(), ")");
   int64_t c1 = x1.size(-1);
   int64_t c2 = x2.size(-1);
@@ -62,6 +61,14 @@ static Tensor cdist_impl(const Tensor& x1, const Tensor& x2, const double p, c10
 
   int64_t r1 = x1.size(-2);
   int64_t r2 = x2.size(-2);
+
+  if (!(p == 2 && (mode == 1 || (mode == 0 && (r1 > 25 || r2 > 25))))) {
+    TORCH_CHECK(device1 == kCPU || device1 == kCUDA, "cdist only supports CPU and CUDA devices, X1 got: ", device1);
+    TORCH_CHECK(device2 == kCPU || device2 == kCUDA, "cdist only supports CPU and CUDA devices, X2 got: ", device2);
+  }
+
   auto dim1 = x1.dim();
   auto dim2 = x2.dim();
 
```

@emcastillo @ngimel
Repository: pytorch
Issue: TorchVision and TorchAudio wheels for AArch64 absent from https://download.pytorch.org/whl/torch_stable.html
Labels: module: build,triaged,module: vision,module: arm

## 🐛 Bug

TorchVision and TorchAudio wheels for AArch64 absent from https://download.pytorch.org/whl/cpu/torch_stable.html

AArch64 wheels for the PyTorch v1.8 release are now available (although there are some issues already identified on CentOS - https://github.com/pytorch/pytorch/issues/53597). However, while there are up-to-date TorchVision and TorchAudio wheels provided for other architectures,  are currently none available for AArch64.

## To Reproduce

Steps to reproduce the behaviour:

1. `pip install torch -f https://download.pytorch.org/whl/cpu/torch_stable.html`
Works as expected.

2. `pip install torchvision -f https://download.pytorch.org/whl/cpu/torch_stable.html`
In the absence of a TorchVision v0.9.x wheel, installs `torchvision-0.2.2.post3-py2.py3-none-any.whl`.

3. `pip install torchaudio -f https://download.pytorch.org/whl/cpu/torch_stable.html`
Fails:
```
Looking in links: https://download.pytorch.org/whl/cpu/torch_stable.html
ERROR: Could not find a version that satisfies the requirement torchaudio
ERROR: No matching distribution found for torchaudio
```

## Expected behavior

`pip install torch torchvision torchaudio -f https://download.pytorch.org/whl/cpu/torch_stable.html` would install the latest stable releases of PyTorch TorchVision and TorchAudio (1.8.0, 0.9.0, 0.8.0 respectively).

## Environment

```
Collecting environment information...
PyTorch version: 1.8.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.10 (aarch64)
GCC version: (Ubuntu 10.2.0-13ubuntu1) 10.2.0
Clang version: Could not collect
CMake version: version 3.16.3

Python version: 3.8 (64-bit runtime)
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.20.1
[pip3] torch==1.8.0
[pip3] torchvision==0.2.2.post3
[conda] Could not collect

```

cc @malfet @seemethere @walterddr @fmassa @vfdev-5
Repository: pytorch
Issue: torch.put is divergent from np.put
Labels: triaged,module: numpy

Both their signatures and behavior are different.

PyTorch's signature is:

```python
put_(indices, tensor, accumulate=False)
```

while NumPy's is

```python
np.put(a, ind, v, mode='raise')
```

The behavior is also different when the "tensor" tensor or "v" array isn't the same size as the "indices" tensor or "ind" array:

```python
# Behavior is the same when indices is the same size
a = torch.tensor((1, 2))
b = torch.tensor((3, 4))
a.put_(torch.tensor((0, 1)), b)
: tensor([3, 4])

a = np.array((1, 2))
b = np.array((3, 4))
np.put(a, np.array((0, 1)), b)
a
: array([3, 4])

# PyTorch throws an error when indices is a different size
a = torch.tensor((1, 2))
c = torch.tensor((1))
a.put_(torch.tensor((0, 1)), c)
: RuntimeError: invalid argument 3: src should have the same number of elements as index at /pytorch/aten/src/TH/generic/THTensorEvenMoreMath.cpp:160

# NumPy will repeat the smaller array
a = np.array((1, 2))
c = np.array((1))
np.put(a, np.array((0, 1)), c)
a
: array([1, 1])
```

cc @mruberry @rgommers @heitorschueroff
Repository: opencv
Issue: Possible memory leak with MSMF backend for cv::videoCapture
Labels: category: videoio,platform: win32

Hey there

I have noticed a noticeable and consistent amount of memory not being returned after using MSMF with cv::VideoCapture in combination with accessing each frame and saving via cv::VideoWriter (OPENCV_MJPEG backend).

For a 1280x720p video at 24fps, a short sequence used in the manner below costs 40MB of non-returned memory, on every execution.

However, if you swap the VideoCapture api for the OCV_MJPG one, no such memory loss occurs.

This was tested on Debug and Release profiles, on:
- Windows 10 x64
- OpenCV 4.5.1 (tagged release)
- OpenCV 4.0.0 (tagged release)
- OpenCV 4.5.2 (b19f8603)



```
std::string filepathInput ("pathToSourceMovie.avi");
std::string filepathOutut ("pathToOutputMovie.avi");

int apiMSMF = cv::CAP_MSMF;
int apiMJPG = cv::CAP_OPENCV_MJPEG;
int codec = cv::VideoWriter::fourcc('M', 'J', 'P', 'G');
cv::Mat frame;

cv::VideoCapture input (filepathInput, apiMSMF); //=== Swap api option to compare MSMF vs OCV_MJPG

std::cout << input.getBackendName();

int totalFrames = input.get(cv::CAP_PROP_FRAME_COUNT);
cv::Size vidSize = cv::Size(input.get(cv::CAP_PROP_FRAME_WIDTH), input.get(cv::CAP_PROP_FRAME_HEIGHT));

cv::VideoWriter output (filepathOutut,
                apiMJPG,
                codec,
                24,
                vidSize);

//std::cout << output.getBackendName();

for ( int f = 0; f < totalFrames; f++)
{
    input.read(frame);
    output.write(frame);
}

output.release();
input.release();
```

Hope this info makes sense.  Please let me know if I can add any more helpful information.

Cheers, Jeff
Repository: godot
Issue: 'Standalone expression (the line has no effect)' warning when short circuiting.
Labels: bug,topic:gdscript,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.3, 3.2.4 RC4, 4.2-dev2

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Windows 7 SP1.

**Issue description:**
<!-- What happened, and what was expected. -->
I've got the 'Standalone expression (the line has no effect)' warning. I expected no warning since the `a && foo()` expression has an effect on control flow.

**Steps to reproduce:**
Create any scene, add the script from MRP to its root and run it. Then change `false` to `true` and run it again.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
```
extends Node

var a = false

func _ready():
	a && foo()

func foo():
	print("foo")

```
Repository: flutter
Issue: Flutter output is too dark to read on Windows
Labels: c: new feature,tool,a: accessibility,platform-windows,a: quality,c: proposal,P2,team-tool,triaged-tool

## Use case

When launching a flutter application from the Windows command prompt, Flutter sometimes prints things such as errors in very dark colours.  Please see the first screenshot below.  At the top you can see that it is printing some compilation errors in dark red and these are not readable unless I turn my monitor brightness up super high.

I have not been able to find any issues related to this, nor other people having this problem.  I have also not been able to find any way to alter these colours, apart from changing the colours used by my terminal, which is more a workaround than a solution.

I understand that this is more a problem with Windows setting too dark colours than with Flutter.  The problem also happens with git.

## Proposal

At the bottom of the first screenshot below you can see some output from git.  You will notice that it is very easy to read.  Git allows you to change the colours it uses by editing its .gitconfig file like this:

[color.status]
	changed = red bold
	updated = green bold
	unmerged = red bold
	untracked = red bold

This allowed me to change the colours used to be brighter so that I could actually read the output!  Before making the configuration change, git was using the same unreadable dark red output as Flutter.

I was looking for a similar feature for Flutter but could not find any.  Thus this feature request.  If you could introduce a configuration file to enable setting the colours used for output of text it would be very much appreciated!  Perhaps this functionality already exists?  If so, I was unable to find it.

Alternatively, you could simply make Flutter always choose the bold versions of these colours so that they are readable by default.  This is the approach taken by GCC when outputting coloured errors on Windows.  See the second screenshot below for an example - the warnings from GCC are very easy to read, without requiring any configuration.

![Screenshot_1](https://user-images.githubusercontent.com/29058809/111434788-40180d80-8700-11eb-9443-039d47b0c241.png)
![Screenshot_2](https://user-images.githubusercontent.com/29058809/111434802-44dcc180-8700-11eb-8dbe-46ad26b3ba9a.png)

Many thanks for taking the time to help an old C++ hacker (now also a Dart hacker) whose eyesight is not as good as it used to be.  :-)
Repository: PowerToys
Issue: [msi] uninstaller processes termination 
Labels: Area-Setup/Install,Area-Quality,Planning-Consideration

The uninstaller tries to terminate some processes:
https://github.com/microsoft/PowerToys/blob/013be4bbb8745dfc7cde51401e6a5b0b95deb521/installer/PowerToysSetupCustomActions/CustomAction.cpp#L607-L611

The code needs to be reviewed since terminating `PowerToys.exe` should be enough to cause the other processes to quit as well.

See https://github.com/microsoft/PowerToys/pull/10241#issuecomment-800921405 that describes an issues when PowerToys is running as admin and the settings app is open then the uninstaller is exeecuted.
Repository: create-react-app
Issue: CVE-2021-27290 in `react-scripts` due to using old version of `webpack`
Labels: stale,needs triage,issue: bug report

### Describe the bug

[CVE-2021-27290](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27290)

> ssri 5.2.2-8.0.0, fixed in 8.0.1, processes SRIs using a regular expression which is vulnerable to a denial of service. Malicious SRIs could take an extremely long time to process, leading to denial of service. This issue only affects consumers using the strict option.

Looking at https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/package.json it pulls in `webpack` @ `4.44.2` which ends up with this tree:
```
  ┬ react-scripts@4.0.3
  ├─┬ terser-webpack-plugin@4.2.3
  │ └─┬ cacache@15.0.5
  │   └── ssri@8.0.1 
  └─┬ webpack@4.44.2
    └─┬ terser-webpack-plugin@1.4.5
      └─┬ cacache@12.0.4
        └── ssri@6.0.1 
```

Moving to the latest `webpack` currently `5.26.2` will fix this.