sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Missing doc for torch.distributions functions
Labels: module: distributions,module: docs,triaged

The following functions and classes are not documented correctly: they are part of the public API but do not show up on the [docs website](https://pytorch.org/docs/master/)
This means that we want to do either:
- Add a docstring and make sure it is properly added to a .rst file so that it appears on the docs website
- Make it private by prepending a `_` to the function name
- Remove it from the public API by deleting it from your `__init__.py` file (like [here](https://github.com/pytorch/pytorch/blob/708f7b120957f47f22752f49d52c08d5a0ca7fc0/torch/__init__.py#L696))


torch.distributions.constraints
-------------------------------
Functions:
 * is_dependent

Classes:
 * cat -- missing methods:

   - check
 * greater_than -- missing methods:

   - check
 * greater_than_eq -- missing methods:

   - check
 * half_open_interval -- missing methods:

   - check
 * independent -- missing methods:

   - check
 * integer_interval -- missing methods:

   - check
 * interval -- missing methods:

   - check
 * less_than -- missing methods:

   - check
 * multinomial -- missing methods:

   - check
 * stack -- missing methods:

   - check

torch.distributions.transforms
------------------------------
Classes:
 * AffineTransform -- missing methods:

   - forward_shape
   - inverse_shape
   - log_abs_det_jacobian
   - with_cache
 * CatTransform
 * ComposeTransform -- missing methods:

   - forward_shape
   - inverse_shape
   - log_abs_det_jacobian
   - with_cache
 * CorrCholeskyTransform -- missing methods:

   - forward_shape
   - inverse_shape
   - log_abs_det_jacobian
 * ExpTransform -- missing methods:

   - log_abs_det_jacobian
 * IndependentTransform -- missing methods:

   - forward_shape
   - inverse_shape
   - log_abs_det_jacobian
   - with_cache
 * PowerTransform -- missing methods:

   - forward_shape
   - inverse_shape
   - log_abs_det_jacobian
   - with_cache
 * ReshapeTransform -- missing methods:

   - forward_shape
   - inverse_shape
   - log_abs_det_jacobian
   - with_cache
 * SigmoidTransform -- missing methods:

   - log_abs_det_jacobian
 * SoftmaxTransform -- missing methods:

   - forward_shape
   - inverse_shape
 * StackTransform -- missing methods:

   - log_abs_det_jacobian
   - with_cache
 * StickBreakingTransform -- missing methods:

   - forward_shape
   - inverse_shape
   - log_abs_det_jacobian
 * TanhTransform -- missing methods:

   - log_abs_det_jacobian
 * Transform -- missing methods:

   - with_cache

cc @fritzo @neerajprad @alicanb @nikitaved @brianjo @mruberry
Repository: pytorch
Issue: Missing doc for torch.jit functions
Labels: oncall: jit,module: docs

The following functions and classes are not documented correctly: they are part of the public API but do not show up on the [docs website](https://pytorch.org/docs/master/)
This means that we want to do either:
- Add a docstring and make sure it is properly added to a .rst file so that it appears on the docs website
- Make it private by prepending a `_` to the function name
- Remove it from the public API by deleting it from your `__init__.py` file (like [here](https://github.com/pytorch/pytorch/blob/708f7b120957f47f22752f49d52c08d5a0ca7fc0/torch/__init__.py#L696))

torch.jit
---------
Functions:
 * export_opnames

Classes:
 * CompilationUnit
 * Error
 * Future
 * ScriptFunction -- missing methods:

   - graph_for

torch.jit.unsupported_tensor_ops
--------------------------------
Functions:
 * execWrapper


cc @brianjo @mruberry
Repository: pytorch
Issue: [Documentation] Incomplete FX module
Labels: triaged,module: fx

## 📚 Documentation

I have been reading on the newly released FX module as part of the 1.10 PyTorch annoucement.

In this Overview document, there are multiple parts are marked as TODOs.  
https://github.com/pytorch/pytorch/blob/v1.10.0/torch/fx/OVERVIEW.md

Finishing up these TODOs would be very useful to learn the background context of this module and how it can be leveraged by PyTorch users. 
Thank you!

cc @ezyang @SherlockNoMad
Repository: go
Issue: wiki: CodeReviewComments should have better example for lowercasing error strings
Labels: Documentation,NeedsInvestigation

In the Readme https://github.com/golang/go/wiki/CodeReviewComments#error-strings it states: 
> Error Strings
> Error strings should not be capitalized (unless beginning with proper nouns or acronyms) or end with punctuation, since they are usually printed following other context. That is, use fmt.Errorf("something bad") not fmt.Errorf("Something bad"), so that log.Printf("Reading %s: %v", filename, err) formats without a spurious capital letter mid-message. This does not apply to logging, which is implicitly line-oriented and not combined inside other messages.

The example is bad and the justification given is weak. For example, a sentence case error message parsed by `log.Printf("Reading %s: %v", filename, err)` might produce the following: `Reading file.txt: Something bad`. This is perfectly fine English. Programming style conventionally follows American usage, "A colon is not normally followed by a capital letter in British usage, though American usage often prefers to use a capital." Thus, there is no problem presented in the example given, and in fact, American usage should by rights protest the lack of the capital letter. Surely there is a better example that should be given for this rule! 

Furthermore, I think it much more likely that the reason for requiring error messages to be lowercase is to avoid the issues that arise if mixed case error messages are acceptable. For example, if one error message is `Something bad` and another is `something bad`, an issue occurs that the error messages are different but likely had the same intended meaning. By requiring the case to be one way and not the other, we reduce the risk of accidentally creating new messages. 

In conclusion, the rule is good. We should continue to start error messages with lowercase letters, but we should drop these bad examples and (in my opinion) post hoc excuses to justify the rule.
Repository: PowerToys
Issue: Better folder searching to navigate explorer
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

Locate a folder is a very troublesome thing when current folder has many folders.
by default, when you press 'C' in `C:\Windows` folder, the explorer change focus to `CbsTemp` folder, then you can press 'C' jump to next folder/file name start with 'C'. It's not very convenient.
Fortunately, there is a third part app called `listary`, it provide a smart way to jump between same prefix files/folders, it's so fast and incredible, but the app seems no longer maintained, and I think the feature can increase productivity, it should be provide by Microsoft and as a part of windows
![image](https://user-images.githubusercontent.com/7759897/139172548-9a5b5670-27c3-4f9b-a820-7b9f3e93054e.png)


### Scenario when this would be used?

navigation to file/folder in a folder use some letters in explorer

### Supporting information

refer to [listary docs](https://www.listary.com/docs/getting-started#Basic_hotkeys)
Repository: react
Issue: [react-is] The major versions of react and react-is must be peerDependencies related.
Labels: Type: Discussion,React 18

(This is not directly related to React 18, but it is a discussion about breaking changes, so I'm proposing it as a topic for the next major release.)
Clearly react-is works on the assumption that it will be used with a matching version of react.
Therefore, **react should be listed as a peerDependencies of react-is.**

I brought this up from a discussion involving a package that depends on react-is downstream.
Repository: godot
Issue: GDScript 2.0: Static typing on signals isn't enforced
Labels: discussion,topic:gdscript

### Godot version

v4.0.dev.custom_build [a851012b1]

### System information

Windows 10

### Issue description

The following code:
```gdscript
signal test(a: Node2D, b: Camera3D)

func _ready():
	test.connect(func(a, b): print(a + b))
	test.emit(Vector2.UP, Vector2.RIGHT)
```
compiles without any errors, and prints `(1, -1)`.
<hr>

It should produce an error, something like:
```
Invalid argument for "emit()" function: argument 1 should be Node2D but is Vector2.
Invalid argument for "emit()" function: argument 2 should be Camera3D but is Vector2.
```

### Steps to reproduce

See above.

### Minimal reproduction project

_No response_
Repository: rust
Issue: Comparing &[u8] is ~3x slower on Windows
Labels: I-slow,O-windows

My initial description of this focused too much on `fastcmp` and confused a lot of people. Update here: https://github.com/rust-lang/rust/issues/90360#issuecomment-956563763

---

Someone shared this crate in the Rust community Discord server: https://github.com/saschagrunert/fastcmp

At first look, this shouldn't help. The trait method compiles to 65.6 kB of code, for goodness' sake. And, on Linux, it doesn't. The benchmarks report this:
```
test fast_compare_equal    ... bench:          10 ns/iter (+/- 0) = 25600 MB/s
test fast_compare_unequal  ... bench:          10 ns/iter (+/- 0) = 25600 MB/s
test slice_compare_equal   ... bench:          10 ns/iter (+/- 0) = 25600 MB/s
test slice_compare_unequal ... bench:          10 ns/iter (+/- 0) = 25600 MB/s
```
Except... On Windows (`x86_64-pc-windows-msvc`):
```
test fast_compare_equal    ... bench:           9 ns/iter (+/- 0) = 28444 MB/s
test fast_compare_unequal  ... bench:           9 ns/iter (+/- 0) = 28444 MB/s
test slice_compare_equal   ... bench:          29 ns/iter (+/- 1) = 8827 MB/s
test slice_compare_unequal ... bench:          29 ns/iter (+/- 0) = 8827 MB/s
```

🤯 

I have a fair bit of experience profiling programs on Linux; enough to know exactly what's going on there: a huge jump table, each arm a long chain of move+compare+jump. I don't have a godbolt link because the builds time out trying to optimize this crate. But I have no insight at all into what's happening on Windows. Is the MSVC `memcmp` really just 3x slower?

---
```
rustc 1.58.0-nightly (29b124802 2021-10-25)
binary: rustc
commit-hash: 29b1248025b19bd132c8047fc710ea9314b9b76b
commit-date: 2021-10-25
host: x86_64-pc-windows-msvc
release: 1.58.0-nightly
LLVM version: 13.0.0
```
Repository: create-react-app
Issue: could not extract package when I use tasks/cra.js
Labels: stale,needs triage,issue: bug report

environment: windows、node v14.17.3
output:
Installing packages. This might take a couple of minutes.

Could not extract the package name from the archive: Cannot find module 'C:\Users\PC\AppData\Local\Temp\tmp-31908-HfJboKVeNQmr\package.json'
Require stack:
- C:\Users\PC\Desktop\G\create-react-app\packages\create-react-app\createReactApp.js
- C:\Users\PC\Desktop\G\create-react-app\packages\create-react-app\index.js

Aborting installation.
Unexpected error. Please report it as a bug:
TypeError: Cannot read property '1' of null
    at C:\Users\PC\Desktop\G\create-react-app\packages\create-react-app\createReactApp.js:740:10
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async Promise.all (index 0)
Repository: godot
Issue: CODEOWNERS file missing defined owners for some top-level editor/ files
Labels: enhancement

### Godot version

N/A

### System information

N/A

### Issue description

Noted that in some PRs ([example](https://github.com/godotengine/godot/pull/54102)) the reviewing team (e.g. `@godotengine/core`) isn't automatically populated. There doesn't seem to be a way for PR authors to assign the field manually either (according to a quick google search). Wasn't sure if this was intentional & by design or if this slipped through the cracks.

### Steps to reproduce

N/A

### Minimal reproduction project

_No response_
Repository: electron
Issue: [Feature Request]: Expose `interruptionLevel` for time sensitive notifications on macOS
Labels: enhancement :sparkles:,platform/macOS,component/notifications

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] 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

It is currently not possible to send a time sensitive notification on macOS 12 and above, which is able to break through do not disturb mode.

### Proposed Solution

Expose the macOS-only property [`interruptionLevel`](https://developer.apple.com/documentation/usernotifications/unnotificationcontent/3747256-interruptionlevel) property for Notification. Applications can set this value to [`timeSensitive`](https://developer.apple.com/documentation/usernotifications/unnotificationinterruptionlevel/timesensitive) in order to support this feature.

### Alternatives Considered

None possible.

### Additional Information

_No response_
Repository: pytorch
Issue: Avoid warnings when jitting pytorch modules
Labels: oncall: jit

## 🚀 Feature

Add an `assert`like API for implementing module checks like shape or dtypes that cause warnings when executed under jit trace.

## Motivation

When running modules using `torch.jit.trace`, sometimes the output gets flooded with warnings related to trivial checks on torch internal modules and becomes hard to detect errors. We don't want to filter all warnings because some of them are necessary, but trivial checks in PyTorch-provided modules shouldn't raise these warnings.

## Pitch

In some modules, this kind of checks:

https://github.com/pytorch/pytorch/blob/0117ada47c3f9ff9e235d7bb8c74791715c9f697/torch/nn/functional.py#L3166-L3172

Cause the following warning.

```
torch.jit._trace.TracerWarning: Converting a tensor to a Python boolean might cause the trace to be incorrect. We can't record the data flow of Python values, so this value will be treated as a constant in the future. This means that the trace might not generalize to other inputs!
```

We think that there should be an alternative to ignore this kind of situation for trivial checks that just do a check->error that could be replaced with simple assertions. On other modules, where the module behavior explicitly depends on the input, the warning makes total sense.


cc @albanD @mruberry @kmaehashi @asi1024
Repository: flutter
Issue: [Docs] Mouse Input MultiDragGestureRecognizer Example
Labels: framework,d: api docs,f: gestures,a: mouse,P2,team-framework,triaged-framework

@Hixie Could you provide a simple example? For instance, how would one register a left mouse click and a right mouse click while the left is still pressed?

_It sounds like you want a MultiDragGestureRecognizer. You'll need to create a StatefulWidget that instantiates the MultiDragGestureRecognizer, then have your build function have a Listener that routes the onPointerDown event to the recognizer._

_Originally posted by @Hixie in https://github.com/flutter/flutter/issues/11600#issuecomment-322057313_
Repository: rust
Issue: 2021 edition's binding to sub-pattern doesn't work on enum with copyable fields
Labels: A-borrow-checker,C-bug,A-patterns

I tried the new "binding to sub-patterns" feature in the 2021 edition and it did not work as I expected, or consistently. [Here's a playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=4a14b694497d8cece3bacb75fcdba5bf).

First, I tried:

```rust
// NOT copy!
#[derive(Debug)]
enum One {
    A,
    B(bool),
}

fn main() {
    let a = One::B(true);
    
    match a {
        One::A => println!("A"),
        other @ One::B(success) => {
            println!("{:?}", other);
            println!("{}", success);
        }
    }
}
```

I expected that even though the wrapping enum is not `Copy`, because the nested `bool` value *is*, it would be copied into `success`. However, I get the error:

```text
error[E0382]: use of moved value: `a`
  --> src/main.rs:13:24
   |
9  |     let a = One::B(true);
   |         - move occurs because `a` has type `One`, which does not implement the `Copy` trait
...
13 |         other @ One::B(success) => {
   |         ---------------^^^^^^^-
   |         |              |
   |         |              value used here after move
   |         value moved here

For more information about this error, try `rustc --explain E0382`.
error: could not compile `playground` due to previous error
```

Comparing this to the [example in the release notes](https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html#new-bindings-in-binding--pattern), where there's a non-`Copy` container (`Matrix`) with a `Copy`-able field (`row_len`), I don't see why it shouldn't work the same way.

Strangely (I think), if I [remove the `A` variant](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a77830e71e9a27ac9a3ee24062959f79), it works. So infallible patterns allow this.

It will also work if I do `ref other @ One::B(success)`, but then I can't take ownership of `other`.

Rust version: `rustc 1.56.0 (09c42c458 2021-10-18)`  
Platform: Ubuntu 21.04  
Installed via Rustup
Repository: flutter
Issue: [pigeon] missing error message when missing return type
Labels: d: api docs,package,team-ecosystem,p: pigeon,P2,triaged-ecosystem

@gaaclarke 

When running pigeon on a class containing a function without named return type, it throws the mysterious error:

> Null check operator used on a null value

This is due to https://github.com/flutter/packages/blob/db9d8c247b77f6c7ad072e09a5fe705a184f8bb2/packages/pigeon/lib/pigeon_lib.dart#L744
Especially as this does not seem to be documented anywhere, it would be critical for user-friendliness to print a proper error message, saying unnamed return types is not supported. rather than throwing an null exception.
Repository: pytorch
Issue: Exception in thread when using dataloader
Labels: module: dataloader,triaged,module: multithreading

### 🐛 Describe the bug

The majority of the time I am running the piece of code below, I am getting a thread exception. Unfortunately, there is not enough information for understanding the issue.

```python
import torch
from torch.utils.data import DataLoader, IterableDataset


class CustomIterableDataset(IterableDataset):
    
    def __iter__(self):
        class Iterator:
            def __getitem__(self, _):
                return torch.tensor([2, 2])
        
        return iter(Iterator())


def collate_wrapper(batch):
    return batch


if __name__ == '__main__':
    
    dataset = CustomIterableDataset()
    loader = iter(DataLoader(dataset, batch_size=None, num_workers=1,
                             pin_memory=True, collate_fn=collate_wrapper))
    
    print('Torch available', torch.cuda.is_available())
    for i in range(2):
        print(next(loader))
```

Outputs:

(1)
```bash
Torch available True
tensor([2, 2])
tensor([2, 2])
Exception in thread 
````

(2)
```bash
Torch available True
tensor([2, 2])
tensor([2, 2])
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/integria/miniconda3/envs/integria/lib/python3.8/threading.py", line 932, in _bootstrap_inner
```



### Versions

PyTorch version: 1.9.0+cu102
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
Libc version: glibc-2.27

Python version: 3.8.10 (default, Jun  4 2021, 15:09:15)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.4.0-89-generic-x86_64-with-glibc2.17
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: Quadro RTX 5000
GPU 1: Quadro RTX 5000
GPU 2: Quadro RTX 5000
GPU 3: Quadro RTX 5000

Nvidia driver version: 460.91.03
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.21.0
[pip3] perlin-numpy==0.0.0
[pip3] torch==1.9.0
[pip3] torch-summary==1.4.5
[pip3] torchvision==0.10.0
[conda] cudatoolkit               10.0.130                      0  
[conda] numpy                     1.21.0                   pypi_0    pypi
[conda] perlin-numpy              0.0.0                    pypi_0    pypi
[conda] torch                     1.9.0                    pypi_0    pypi
[conda] torch-summary             1.4.5                    pypi_0    pypi
[conda] torchvision               0.10.0                   pypi_0    pypi


cc @SsnL @VitalyFedyunin @ejguan @NivekT
Repository: terminal
Issue: Windows Terminal failed to restore the position in the 2nd or 3rd monitor with maximized window mode.
Labels: Issue-Bug,Product-Terminal,Priority-3,Area-Windowing

### Windows Terminal version (or Windows build number)

1.12.2922.0

### Other Software

_No response_

### Steps to reproduce

Given two or three monitors installed.

  1. Primary monitor: 3840x2160
  2. Second monitor: 1920x1080
  3. Third monitor: 1920x1080
 
Steps:
1. Move Windows Terminal to secondary monitor with normal size (not maximized), close it and reopen it. Windows Terminal got restored in secondary monitor which is as expected.
2. Move Windows Terminal to secondary monitor with maximized size, close it and reopen it. This time, Windows Terminal windows is restored in the primary monitor instead, with the size of the secondary monitor.


### Expected Behavior

Persist window layout on window close even with maximized window mode.

### Actual Behavior

Windows Terminal windows is restored in the primary monitor instead, with the size of the secondary monitor.
Repository: PowerToys
Issue: Warn user when a second PowerToys shortcut is the same as a current one or replaces a Microsoft Windows defined shortcut.
Labels: Idea-Enhancement,Product-Settings

### Description of the new feature / enhancement

1. Warn the user when attempting to set (change to) a PowerToys shortcut that is the same as the current shortcut for a different PowerToys utility.  Identify the other utility (noting that it will be cleared -- disabled(?)) and ask for confirmation.  If confirmed, clear the other shortcut.  That might require disabling that utility, as I don't see a way to have no shortcut.  This logic should also be checked when enabling a utility that has a shortcut.
2. Warn the user when attempting to set a PowerToys shortcut that will replace a defined shortcut in the current Microsoft Windows environment.  Identify the action that will be disabled (i.e., this shortcut is used by default for some-action within whichever-Windows-is-used).

### Scenario when this would be used?

1. In PowerToys 0.47.1, more than one utility can be set to the same shortcut without warning.  This will prevent that from happening.  
2. This may help prevent unexpected behavior while also assisting in selecting an optimal shortcut.  
I see these as being two cases of the same basic problem when (re)assigning shortcuts: lots of potential conflicts and our imperfect knowledge and recall.


### Supporting information

In my less-than-cursory testing, the first shortcut set has precedence while the second is ignored.  I can easily imagine someone installing PowerToys primarily for one utility but enabling all of them.  Suppose a default is replaced with a shortcut that is already a PT default.  If that is the utility of interest, then PowerToys will immediately be perceived as broken.  If it is noticed later, then PowerToys is just buggy.  
Warning the user even when enabling a utility also has the benefit of calling attention to the fact that at least one PowerToys default shortcut replaces a Microsoft Windows default shortcut (Alt+Space for Run).