sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: [GitHub] GPG key for bug reporting
Labels: Idea-Enhancement,Area-GitHub workflow,Area-Bug Report Tool

### Description of the new feature / enhancement

As @crispinb says in https://github.com/microsoft/PowerToys/issues/13221#issuecomment-920341497, we should generate a GPG key for those who want to encrypt their bug reporting file due to security and privacy concerns.

### Scenario when this would be used?

For anyone who wants to protect their bug reporting file when filing issues.

### Supporting information

_No response_
Repository: pytorch
Issue: _disabled_torch_function_impl should not be necessary for __torch_dispatch__
Labels: triaged,module: __torch_function__

The default behavior of Tensor.__torch_function__ is preserve subclasses but based on conversations with, well, basically everyone doing custom subclasses with __torch_dispatch__ is this is NEVER what you want (example, @anjali411).

I propose that if `__torch_dispatch__` is defined, `__Torch_function__` SHOULD NOT do default subclass preservation behavior.

cc @hameerabbasi @rgommers @peterbell10 @albanD @zou3519
Repository: pytorch
Issue: Add function that retrieves a batch from a DataLoader
Labels: module: dataloader,triaged,enhancement

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->

## Motivation
`DataLoader.__getitem__(self, index)` retrieves a single item from a dataloader at a time. Depending on where the data is coming from, there is potentially a huge performance gain to be had if we retrieve multiple items at a time. For example, if data is coming from a database, querying multiple items at a time is much faster than running a separate query for each item.

## Pitch

Add `DataLoader.get_batch(self, indexes) -> Iterable[Tuple[Tensor, Tensor]]` (use whatever name or method signature you like) whose default implementation delegates to `DataLoader.__getitem__(self, index)`. This would retain backwards compatibility for existing implementations while allowing users to override the batch operation to improve performance.

Alternatively, provide a mechanism for implementations to peek into the list of upcoming indexes so `__getitem__` could cache a batch of samples every once in a while, then return elements directly from the cache.

This would reduce the need for worker processes in some cases and reduce overall memory usage.

## Clarification
This problem is specific to `DataLoader`s who shuffle their data. There is no way for an existing implementation to know which indexes to retrieve ahead of time.

cc @SsnL @VitalyFedyunin @ejguan
Repository: pytorch
Issue: Indexing a tensor with a NumPy array sometimes works and sometimes doesn't
Labels: triaged,module: numpy,module: advanced indexing

## 🐛 Bug

when indexing a tensor with a numpy array (shape: p * q), if q=1 and 2<p<32, it will be an error. when p >= 32, it behave correctly like a tensor. 

## To Reproduce

Steps to reproduce the behavior:
```
import torch
import numpy as np
a = torch.rand(100,5)
a[np.array([[1]]*2)]
a[np.array([[1]]*3)]
a[np.array([[1]]*31)]
a[np.array([[1]]*32)]
```



## Expected behavior

error in : 
a[np.array([[1]]*3)]
a[np.array([[1]]*31)]

## Environment


 - PyTorch Version (e.g., 1.0):1.7.1
 - OS (e.g., Linux):ubuntu 18.04
 - How you installed PyTorch (`conda`, `pip`, source):pip
 - Build command you used (if compiling from source):
 - Python version:3.6
 - CUDA/cuDNN version:10.0 7.6
 - GPU models and configuration:no gpu was use
 - Any other relevant information:
 - numpy version 1.19.5

## Additional context

<!-- Add any other context about the problem here. -->


cc @mruberry @rgommers @heitorschueroff
Repository: godot
Issue: Viewport update_mode issue on ViewportContainer ENTER_TREE or VISIBILITY_CHANGED Notification
Labels: bug,topic:core

### Godot version

3.3.stable

### System information

Windows 10

### Issue description

If a ViewportContainer is visible_in_tree it will set update_mode to all children Viewports to Viewport::UPDATE_ALWAYS when receiving a NOTIFICATION_ENTER_TREE or NOTIFICATION_VISIBILITY_CHANGED.
This will cause performance issues if you are dealing with a lot of ViewportContainer containing a Viewport (in my case for exemple, in the hundreds causing fps drop and CPU over usage).

### Steps to reproduce

- Create a ViewportContainer
- Create a sub Viewport (child to the ViewportContainer)
- Duplicate the ViewportContainer hundreds of time, and see the computational impact (using CPU monitoring f. ex).

### Minimal reproduction project

_No response_
Repository: go
Issue: net/http: performs unexpected retry on GET requests under specific conditions
Labels: Documentation,NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version go1.16.6 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jonathan/.cache/go-build"
GOENV="/home/jonathan/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/jonathan/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jonathan/go"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/usr/lib/golang"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.6"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1539237600=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
https://play.golang.org/p/w-oW1oYN0ZN

The above playground provides a small example of `http.Get()` performing a retry
under specific circumstances. This does not happen with POST requests, which can be
demonstrated by setting `post` to `true` in the playground.

### What did you expect to see?
No automatic retries.
Aka seeing "HELLO WORLD!" printed exactly 3 times in all cases.


### What did you see instead?
"HELLO WORLD!" printed 4 times, due to the retry of a failed request.
The retry happens only if there has been a successful request directly before it.
Repository: TypeScript
Issue: Allow specifying diagnostic code in ts-expect-error
Labels: Suggestion,In Discussion

# Suggestion

## 🔍 Search Terms
ts-expect-error

## ✅ Viability Checklist
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

Allow @ts-expect-error to specify diagnostic codes to be more precise in expectations.
**Example:**
`// @ts-expect-error TS1234` 

Will only expect that diagnostic code. If the same line triggers a different diagnostic code, the expectation will error as if there was no error on the proceeding line.

## 📃 Motivating Example

This feature will be particularly useful when migrating code (1) between repositories with different TS configs, or even for (2) a slightly safer path when upgrading TS versions if all issues are not immediately fixed.

## 💻 Use Cases

The Teams Org is facing a code migration that I expect will benefit from this greatly. Please reach out to me (or I will come to office hours) and we can go through that example.

## Code

I have attached a PR which implements the change as an example. Let me know what you think!
Repository: vscode
Issue: Add code lens option/alternative for native testing
Labels: feature-request,testing

We have the gutters, but some users prefer code lenses. We should have an option (probably off by default) to include them.
Repository: pytorch
Issue: at::parallel_for created max_threads for inputs larger than GRAIN_SIZE
Labels: module: performance,triaged,module: openmp,module: multithreading

The problem with the current code is that `#pragma omp parallel` in the following code snippet will create a parallel region with maximum number of threads. https://github.com/pytorch/pytorch/blob/0559cb37cd2dbee6dce25c6afcd155e2fdd1f335/aten/src/ATen/ParallelOpenMP.h#L23-L30

A better approach is demonstrated here https://github.com/pytorch/pytorch/pull/65228/files#diff-90912bb911f60387d665bf730a0fadf860c101f377bcc2e624a185a806f55f11R287-R310

cc @VitalyFedyunin @ngimel
Repository: material-ui
Issue: Outlined variants of paper have wrong background-color in dark-mode when resting on an elevated paper
Labels: new feature,component: Paper

tl;dr
I propose to respect the `elevation` prop for `outlined` variants of paper with regard to the background color. (Paper becoming lighter with elevation)

---

An outlined paper sitting on top of an elevated paper should have a relative elevation of 0. 
In the current implementation, the elevation of outlined paper is absolute. 

In light mode, this is fine, since the background color doesn't change.

In dark mode, paper(/material) gets lighter the higher it is. 
But since an outlined paper is always at elevation 0, the background color won't get lighter. 

This leads to outlined variants "punching a hole" into the paper it is resting on:
![image](https://user-images.githubusercontent.com/2965273/133831156-50c7b247-d5cc-4bbd-92e3-f8be2a5642c1.png)

How it should look like: 
![image](https://user-images.githubusercontent.com/2965273/133831306-03154f92-441d-4f5b-b3e4-41e8ce14e354.png)

## Possible ways of dealing with this issue

(First the more complicated, but more general solution.
1. Properly stacking of paper. 
  Keep track of the current absolute elevation of a sheet of paper based on the elevation the paper is sitting on, and setting the background color based on that. 
  I don't know how best to accomplish this. Ideas on how to do this:
    - Nested CSS 
    - Keeping an elevation context
    - Using a transparent background. 

This would solve the problem of non-outlined paper on paper, which is currently wrong as well.
(However, for non-outlined paper, this is less of a problem, as you can manually set the `elevation` prop to fix this issue)

![image](https://user-images.githubusercontent.com/2965273/133832715-65aa1002-cdba-4b03-8eb6-1e32bd3f0e09.png)


2. The easy workaround:
Respect the `elevation` prop for `outlined` variants with regard to the background color. 
(This does not have to be a dark mode exclusive solution.)

---- 
Related: 
https://github.com/mui-org/material-ui/pull/21748 https://github.com/mui-org/material-ui/issues/18309
Repository: terminal
Issue: Vim.exe can disable ctrl+v to paste in conhost, but not in Windows Terminal
Labels: Issue-Feature,Product-Conpty,Area-Input,Product-Terminal

I map the Ctrl+V to Paste in Windows Terminal:
        {
            "command": "paste",
            "keys": "ctrl+v"
        },
to simulate what I can do in cmd.exe.

However, when I use the command-line version of vim, from cmd.exe, in Normal mode, if I hit "Ctrl+V", it correctly puts it into "Visual mode".
When I'm in cmd.exe outside of vim, just typing at the console, Ctrl+V will paste to the console as it's supposed to.

In Windows Terminal, with the above setting, Ctrl+V works from the console window, but in vim doesn't see the key-combination.

It would be good for Windows Terminal key bindings to only be in effect when it's typed at the console.
Repository: rust
Issue: Better diagnostics for out-of-scope traits
Labels: A-diagnostics,T-compiler

[See this Twitter thread with @ekuber for context](https://twitter.com/bascule/status/1438888671923654666)

The current diagnostics are able to give this helpful suggestion when a trait is not in scope:

```
    = help: items from traits can only be used if the trait is in scope
    = note: the following trait is implemented but not in scope; perhaps add a `use` for it:
            `use aes_gcm::NewAead;`
```

That's great, however [that helpful suggestion is often buried at the bottom of the error message under a large cascade of obligations which distract from the problem being an out-of-scope trait](https://gist.github.com/oberien/ef76672e210bd219c28f17fab04bc372).

As a suggestion, I think it would be helpful if the diagnostics could detect cases where importing the trait is probably the most likely resolution to the error, and in such cases make the suggestion at the top of the error message, rather than at the very bottom.

If the diagonstics could determine that importing the trait is the unambiguous solution to the problem and elide the rest of the error message in that case, that'd be gravy.
Repository: go
Issue: x/website/blog: missing embedding metadata
Labels: NeedsFix

The pages of the blog are missing metadata for embedding into the likes of Twitter and Slack.

Twitter doesn't expand a card at all, which means there is much less screen real estate for it.
https://cards-dev.twitter.com/validator

On Slack the title is correct, but the description is a generic text and not the blog summary.
Repository: rust
Issue: Add a suggestion to make inaccessible items accessible
Labels: A-diagnostics,T-compiler

Follow-up for https://github.com/rust-lang/rust/pull/88838#issuecomment-921720642. After #88838 is merged, to help users who are still relatively unfamiliar with Rust, we should add a suggestion to make local inaccessible items accessible, by making the item (and its parents, as necessary) `pub`.
Repository: pytorch
Issue: TestCppExtensionJit's test_crash_handler fails for force_on_cpu job on GHA
Labels: oncall: jit,triaged

When migrating the force_on_cpu job from Circle to GHA, I ran into the following failure
![image](https://user-images.githubusercontent.com/31798555/133860737-5c5cb6b4-cd96-47f2-ae57-5ec7d8e2b04f.png)
from PR #65094 and logs: https://github.com/pytorch/pytorch/pull/65094/checks?check_run_id=3626827858

This failure did not occur on CircleCI, so we suspect it is likely something to do with the GHA Windows runner environment. For now, the test is skipped for the force_on_cpu config, and fixing this issue would require re-enabling the test.
Repository: godot
Issue: Enabling verbose output makes `add_surface_from_arrays` 100 times faster
Labels: bug,platform:windows,topic:rendering,needs testing,performance

### Godot version

3.4 beta4
3.3.2
3.2.3
3.1.1

### System information

Windows 10 64 bits GLES3 GeForce GTX 1060 6GB/PCIe/SSE2

### Issue description

I noticed in my voxel engine that if I turn off `-v` (verbose output) from command line arguments, my scene takes 28 seconds to finish loading. If `-v` is specified, my scene takes 4 seconds only.
Note: during that time, nothing gets printed either way, because I dont print anything.

I tracked it down to `add_surface_from_arrays`. More precisely, this piece of code in `rasterizer_storage_gles3.cpp` takes about 15 ms to complete (array_size is maximum 20,000 and index_array_size is 5,700 maximum), no matter how big or small the data is:
![image](https://user-images.githubusercontent.com/1311555/133860422-9617a69c-a562-47ba-8426-259f5f16c25d.png)
Specifically, the first call to `glGenBuffers`. The next calls are fast.
With `-v`, all of it takes about 100 microseconds.

Basically performance is very bad without verbose output. Counter-intuitive, you'd think the opposite would happen^^
That setting is off by default as well, which is expected in exported games too, but it means by default we get the slow experience.
However I expected performance to be high no matter if that setting is enabled or not, because it is about printing in the console, not how fast OpenGL runs (unless there is some hidden debug thing going on about it?).

### Steps to reproduce

Call `add_surface_from_arrays` within `_process`.


### Minimal reproduction project

[AddSurfaceFromArraysPerformance.zip](https://github.com/godotengine/godot/files/7188725/AddSurfaceFromArraysPerformance.zip)

1) Launch the main scene.
2) This project creates a dummy mesh in `_ready`. Observe it is quick, only about 200 microseconds, printed in the console
3) Press space bar to create a dummy mesh within `_process`: observe the printed time is way higher, about 15 milliseconds.
4) Stop the scene, enable verbose output in project settings (or change command line), and restart the scene
5) Press space bar again. The mesh is now created in only 100 microseconds.

Note: timings are for my graphics card, yours might vary.

---------

More info:
The only piece of code that I could find affecting the renderer is this:
```cpp
	if (OS::get_singleton()->is_stdout_verbose()) {
		if (GLAD_GL_ARB_debug_output) {
			glEnable(_EXT_DEBUG_OUTPUT_SYNCHRONOUS_ARB);
			glDebugMessageCallbackARB(_gl_debug_print, nullptr);
			glEnable(_EXT_DEBUG_OUTPUT);
		} else {
			print_line("OpenGL debugging not supported!");
		}
	}
```
And as dumb as it sounds, if I let the logic inside the `if` always run, it makes it fast.
For some odd reason, the fact of NOT setting up this debugging extension slows things down a lot 🤔
Repository: rust
Issue: Drop support for FreeBSD 10 and 11 from std
Labels: T-compiler,O-freebsd,disposition-merge,finished-final-comment-period,T-libs

Rust's standard library currently uses a FreeBSD 10 compatible ABI.  But FreeBSD 10 went EoL on October 31, 2018.  And now FreeBSD 11 will itself be EoL on September 30, 2021.  Isn't it finally time to drop FreeBSD 10 support and update the standard library's ABI to FreeBSD 12, or at least 11?
Repository: pytorch
Issue: Add an `all_paths` method to PackageExporter
Labels: triaged,oncall: package/deploy,imported

## Background:
`torch.package` is a way to create hermetic packages of arbitrary Python code, used to distribute PyTorch models. For more information, check out: https://pytorch.org/docs/master/package.html

## Task:
Users of PackageExporter occasionally want to know why a certain module has been included in the packaged dependencies. We should expose a method:
```
def all_paths(self, src: str, dst: str) -> DiGraph: ...
```

The return value would be a subgraph rooted at `src` that shows all the paths to `dst`.

## Code Pointers:

`PackageExporter` stores dependency information in a DAG ([`self.dependency_graph`](https://github.com/pytorch/pytorch/blob/afa25c77f14851d611ec299f0c2ec4382eec5f51/torch/package/package_exporter.py#L203-L208)). 

You will probably be doing most of the implementation in a generic method on [`DiGraph`](https://github.com/pytorch/pytorch/blob/afa25c77f14851d611ec299f0c2ec4382eec5f51/torch/package/_digraph.py#L1), which is the directed graph abstraction backing `self.dependency_graph`.

## Implementation notes
Some care must be taken implementing the `allpaths` method efficiently; a naive implementation can get pretty bad (as the problem is exponential time in the worst case). A reasonable way to do it (taken from [Buck](https://github.com/facebook/buck/commit/d5d4be0cafd25bc243a68faaf71ff79b1797b6f6)) is to do:
1. Compute the forward transitive closure of `src` (all things reachable from `src`). Call this `reachableFromSrc`.
2. Assuming `dst` is in that `reachableFromSrc`, walk the reverse dependencies of `dst`, adding each node to the output graph iff it is also present in `reachableFromSrc`.
Repository: rust
Issue: Linkchecker tool report failed for a non-English heading in a translation of TRPL
Labels: A-testsuite,C-bug,A-intra-doc-links

URL to the section(s) of the book translation with this problem:
https://rust-lang-vn.github.io/book/ch01-02-hello-world.html

Description of the problem:

I'm translating the section `1.2. Hello, World!` into Vietnamese. For the link:
```diff
-[troubleshooting]: ch01-01-installation.html#troubleshooting
+[troubleshooting]: ch01-01-installation.html#xử-lý-sự-cố
```

After I commit, the Actions CI report failed on task `Run lints` [that runs the linkchecker script from this repo](https://github.com/rust-lang/book/blob/eb1282ec444db94055fa9531b6f3f803e86bb382/.github/workflows/main.yml#L59-L64):

```text
ch01-02-hello-world.html:222: broken link fragment `#x%E1%BB%AD-l%C3%BD-s%E1%BB%B1-c%E1%BB%91` pointing to `ch01-01-installation.html`
...
Error: Process completed with exit code 1.
```
I double-checked it manually and confirmed it wasn't a broken link as reported.
I think the linkchecker tool can't compare between raw string `#xử-lý-sự-cố` and encode string `#x%E1%BB%AD-l%C3%BD-s%E1%BB%B1-c%E1%BB%91`.
Thanks!
Repository: godot
Issue: Failed to load assembly in export linux
Labels: bug,platform:linuxbsd,needs testing,topic:dotnet,topic:export

### Godot version

v3.4.beta4.mono.official [6a058cbf3]

### System information

Debian 11 - C#

### Issue description

During export into linux I have this error in godot terminal:

```
ERROR: Cannot load assembly (refonly): 'Dapper.Contrib'.
   at: get_assembly_dependencies (modules/mono/editor/godotsharp_export.cpp:95)
ERROR: Cannot load one of the dependencies for the assembly: 'GodotUtilities'.
   at: get_assembly_dependencies (modules/mono/editor/godotsharp_export.cpp:101)


```
But I don't use this library in my project

```
<Project Sdk="Godot.NET.Sdk/3.3.0">
  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
    <Reference Include="GodotUtilities">
      <HintPath>..\Utils\Utils\bin\Debug\netstandard2.0\GodotUtilities.dll</HintPath>
    </Reference>
  </ItemGroup>
</Project>

```
Instead I use it in my "GodotUtilities.dll"

```
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="GodotSharp">
      <HintPath>/home/vale/Downloads/godot_mono/Godot_v3.4-beta4_mono_x11_64/GodotSharp/Api/Debug/GodotSharp.dll</HintPath>
    </Reference>
    <PackageReference Include="CsvHelper" Version="27.1.1"/>
    <PackageReference Include="Dapper" Version="2.0.78"/>
    <PackageReference Include="Dapper.Contrib" Version="2.0.78"/>
  </ItemGroup>
</Project>

```
It is a missing step in my side? Or its a bug? I'm not 100% sure.

The exported file seems work fine so far.

### Steps to reproduce

Export in Linux/X11


### Minimal reproduction project

NA