sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: TestXNNPACKConv1dTransformPass.test_conv1d_with_relu_fc takes 2+ min to finsh
Labels: module: ci,module: tests,triaged

From https://app.circleci.com/pipelines/github/pytorch/pytorch/224304/workflows/2571002d-2075-4e53-877b-4bac675037de/jobs/8062979:
```
TestXNNPACKConv1dTransformPass.test_conv1d_with_relu_fc  time: 134.20 seconds
```

cc @ezyang @seemethere @malfet @walterddr @mruberry @VitalyFedyunin
Repository: rust
Issue: Add a blanket impl for `core::fmt::Write` if there is an impl for `std::io::Write`
Labels: T-libs-api,C-feature-request,A-fmt

### Advantages

Types which implement `std::io::Write` get an implementation of `core::fmt::Write` for free. `core::fmt::Write` is useful if you only want to accept UTF-8 data.

### Disadvantages

Could it hurt type inference? If so, is there some way of allowing `impl core::fmt::Write for Foo {}` (i.e., empty impl body) if there is an impl for `std::io::Write`?

---

Cc raphlinus/pulldown-cmark#492
Repository: pytorch
Issue: NCCL watchdog thread should log warnings about long-running GPU operations instead of silently hanging
Labels: module: bootcamp,triaged,pt_distributed_rampup,module: c10d

## 🚀 Feature
This was originally proposed offline by @pritamdamania87. Currently the NCCL watchdog thread does proactive error handing on operations timeout when the environment variables `NCCL_BLOCKING_WAIT` and `NCCL_ASYNC_ERROR_HANDLING` are set. When these are not set, the watchdog thread silently hangs when there is a desynchronization/GPU operation error. Instead of this, the watchdog thread can probably log warnings when GPU operations seem stuck (according to some set threshold timeout). 

## Motivation
We have built robust error handling solutions with the above 2 environment variables. However, for runs that don't use these flags, it would still be good to have some logs printed out to help us debug when there are errors. 

## Pitch

Query `workMetaList_` as is currently being done but also outside of `asyncErrorHandling_` condition. For work objects that have been running for longer than a given time period, log verbose information about them (such as the rank that's logging, collective operation name, input tensor sizes, etc). We could use `opTimeout_` as this threshold, but it is by default 30 minutes, a smaller timeout might be useful for these warning type of logs.



cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528 @osalpekar @jiayisuse @agolynski
Repository: opencv
Issue: Mat conversions for macOS/AppKit
Labels: feature,category: imgcodecs,platform: ios/osx

##### System information (version)

- OpenCV => latest
- Operating System / Platform => iOS/macOS
- Compiler => Xcode

##### Detailed description

A conversion method between Mat and UIImage is provided for iOS (UIKit), but it does not exist for macOS (AppKit).
I created a PR https://github.com/opencv/opencv/pull/18547 to solve this.
Repository: flutter
Issue: Outlined TextField Label start position doesn't meet Material Design Specs
Labels: a: text input,framework,f: material design,a: fidelity,has reproducible steps,P2,found in release: 3.3,found in release: 3.6,team-design,triaged-design

On issue #54028 the height of the label was fixed with a opt-in fix. I can't comment on the original issue, as it's locked, but from what I can see not only the height is shifted, but also where the label starts.

This is a screenshot from the original issue:

![image](https://user-images.githubusercontent.com/8120472/95542392-07933b80-09cc-11eb-9c43-f2687a25890d.png)

I added some vertical red lines to show the difference in start positions.

From what I can verify the issue persists. On the left is the https://material.io/components/text-fields, on the right in purple is a Flutter App:

![image](https://user-images.githubusercontent.com/8120472/95542878-5ee5db80-09cd-11eb-964d-13f2c227fd56.png)

As you can see the start position of the label on the Flutter App is too much on the left side.

This is the Material spec on the start position of the label:

![image](https://user-images.githubusercontent.com/8120472/95543130-14b12a00-09ce-11eb-9dbd-f6057c1ca89c.png)

I think this initial position should be fixed to match the specs, but also I would like to suggest that the user has the option to provide a "start position" value that can push the label to the end if positive and to the start if negative. This is useful when we change the radius of the outline border and the label gets in the middle of a hole:

![image](https://user-images.githubusercontent.com/8120472/95543340-9bfe9d80-09ce-11eb-902d-160aea27eb7a.png)

So having a more customizable border will help to avoid this behavior.

In summary:

* Match the floating label start position to the Material Design specifications.
* Add more customization to the outline border so we can vary the label's start position and the distance from the label to the outline (the gap size).

I understand this will break many golden image tests, but also did #54028.
Repository: flutter
Issue: Provide window position, size and constraint for flutter desktop
Labels: c: new feature,framework,engine,platform-mac,platform-windows,platform-linux,a: desktop,P3,team-framework,triaged-framework

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe the alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

Some desktop programming languages have features to limit window size such as minimum and maximum length and height, default position, selection of default state such as maximized and so on, when the application is run. Currently, we can do that by adding to each platform individually.

## Proposal

<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching images showing what you are imagining.

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->

flutter can provide an easy way to adjust the window size, window constraints and the default window position.
Repository: pytorch
Issue: In PyTorch Tutorials, RuntimeError: CUDA error: out of memory happen
Labels: module: memory usage,triaged

## 🐛 Bug

when I learned how to use CUDA Tensors in Toturials "WHAT IS PYTORCH?" of "DEEP LEARNING WITH PYTORCH: A 60 MINUTE BLITZ", I executed 
    if torch.cuda.is_available():
    device = torch.device("cuda")          # a CUDA device object
    y = torch.ones_like(x, device=device)  # directly create a tensor on GPU
    x = x.to(device)                       # or just use strings ``.to("cuda")``
    z = x + y
    print(z)
    print(z.to("cpu", torch.double))       # ``.to`` can also change dtype together!
when I executed 'y = torch.ones_like(x, device=device)' , python showed that RuntimeError: CUDA error: out of memory. But I checked out my GPU usage, it seemed have about 100MB to use. 
What' more,  I found that if my executed 'x = x.to(device)' before ' y = torch.ones_like(x, device=device)' , it would work without error.

## To Reproduce

Steps to reproduce the behavior:

1. open a python terminal 
2. run the code above with a GPU with about 500MB left to use

In my computer:
(RL) seth@seth-Precision-3630-Tower:~$ python
Python 3.7.9 (default, Aug 31 2020, 12:42:55) 
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> x=torch.tensor(1)
>>> x
tensor(1)
>>> device = torch.device("cuda") 
>>> y = torch.ones_like(x, device=device)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: CUDA error: out of memory

## Expected behavior
it should work
## Environment
PyTorch version: 1.6.0
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: version 3.10.2

Python version: 3.7 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: 10.0.130
GPU models and configuration: GPU 0: Quadro P620
Nvidia driver version: 450.51.06
cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.2
[pip3] torch==1.6.0
[pip3] torchvision==0.7.0
[conda] numpy                     1.19.2                   pypi_0    pypi
[conda] torch                     1.6.0                    pypi_0    pypi
[conda] torchvision               0.7.0                    pypi_0    pypi

## Additional context
I know my GPU capacity is small, but I used a tensor(1) which should not obtain much more than 500 MB to use.
Importantly, I changed the execution order and it worked. I don't know why and if it really means something, I think the tutorials can remind us.
Repository: godot
Issue: Wrong error reported when placing double brackets
Labels: enhancement,topic:gdscript,usability

<!-- 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.stable

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Manjaro Linux, kernel 5.8.11-1-MANJARO

**Issue description:**
<!-- What happened, and what was expected. -->
The editor reports "Expected ')' in expression" error if you write a double bracket when calling a method.

**Steps to reproduce:**
Write something like:
```
var l = []
l.append((3, 245))
```

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[DoubleBracketError.zip](https://github.com/godotengine/godot/files/5353616/DoubleBracketError.zip)
Repository: go
Issue: proposal: testing: Provide `TestMain` with stats so that it can print a custom summary.
Labels: Proposal

## Background

There have been several requests in the past for a summary in the end of a test suite run:
* #27755 - proposal: cmd/go: go test summary
* #30507 - cmd/go: add summary at end of go test results
* #41748 - proposal: testing: re-print failed test names before exiting

All these requests have been denied as it isn't clear which summary style/format would clearly be beneficial.

The proposed workaround was to run the tests with `-json` and to use the output to generate a suitable summary.
For instance [gotestsum](https://github.com/gotestyourself/gotestsum) provides just that but it is an external tool and so developers and automation need to diverge from their usual workflow in order to utilize `gotestsum`.

## Proposal

Add test stats to `testing.M` so that `TestMain` can print a custom test results summary after `m.Run()`.

The test stats should include:
* List of all tests.
* List of all examples.
* List of all benchmarks.
* List of successful tests.
* List of successful examples.
* List of successful benchmarks.
* List of skipped tests.
* List of skipped examples (in case of -failfast).
* List of skipped benchmarks (in case tests or examples failed).
* List of failed tests.
* List of failed examples.
* List of failed benchmarks.

This could be done by enhancing the `runTests`, `runExamples` and `runBenchmarks` functions to produce these lists.
All lists would be of type `[]InternalTest`, `[]InternalExample` or `[]InternalBenchmark`.
Repository: godot
Issue: Godot crashes when a resource remaped through translation is missing
Labels: bug,topic:core,crash

<!-- 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-stable

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Manjaro Linux, 5.8.11-1-MANJARO

**Issue description:**
<!-- What happened, and what was expected. -->
When renaming a file, which is referenced in the translation remaping, from outside the editor, no error is reported on the editor and the game seems to work fine if the file you renamed is **not in the language you are currently using**. However, if you export the game (or run it directly) and open it in the language the renamed file is for, Godot crashes.

If you rename a file on your current language and open the game though the editor, the editor will **not** crash and it will report the error correctly.

My concern is that if you rename a file in a language you are not using, the editor doesn't recognize that it _will_ crash in another language, and so you can ship a version that won't work and will have an error that is difficult to diagnose.


**Steps to reproduce:**

Add a file in two or more languages and reference it on the file remapping tool for translations. Rename a file for a language you are not currently using and export (or run) the game and launch it in that language using the `--language` parameter.

Use my minimal reproduction project, which has three versions (three commits) of the project you can checkout to.

You can checkout to `no-chash`, `crash-en` or `crash-es` to try the different versions, the difference being that the file that will make the game crash ends with `_lel.png`.

For example, if you want the game to crash only when you launch it in English use `git checkout crash-en`


**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[FileRenameCrash.zip](https://github.com/godotengine/godot/files/5353948/FileRenameCrash.zip)


**Important note:**
This is a bug that I encountered this weekend on the Ludum Dare and this reproduction of the crash error does not give exact same results I encountered. Specifically, I remember the editor reported an error every time I launched the game but it would just continue running, it would only crash on the exported version. I can take a look at the commit history of the project if this seems relevant.
Repository: go
Issue: x/tools/cmd/present2md: conversion strips comments and .caption commands
Labels: NeedsInvestigation,Tools

<!--
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
go version go1.15.2 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="on"
GOARCH="amd64"
GOBIN="/home/user/bin"
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/user/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/user/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/user/go/src/go.mod"
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-build264055988=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

present2md from golang/tools@96877f285f7e9048cc5e405a8c798ecf58e84f90

### 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.
-->

Invoke present2md on a file like so:
```
topic

Presenter McPresenterface

* Introduction

# Comment about this slide for internal use.

Content

.image https://blog.golang.org/lib/godoc/images/footer-gopher.jpg

.caption The gopher
```


### What did you expect to see?

All the comments and .captions remaining.
```
# topic

Presenter McPresenterface

## Introduction

// Comment about this slide for internal use.

Content

.image https://blog.golang.org/lib/godoc/images/footer-gopher.jpg

.caption The gopher
```

### What did you see instead?

Stripped like so:
```
# topic

Presenter McPresenterface

## Introduction

Content

.image https://blog.golang.org/lib/godoc/images/footer-gopher.jpg
The gopher
```
Repository: material-ui
Issue: [Autocomplete] Broken for iOS VoiceOver
Labels: accessibility,component: autocomplete

- [x] The issue is present in the latest release.
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

Using VoiceOver on iOS, I am unable to either find or activate any of the suggestions in the list. This is a critical accessibility barrier for visually impaired mobile users.

I can find the input, type text into it and get results, but I cannot set focus on the listbox containing the results. As soon as I move VoiceOver focus from the input field, the listbox disappears.  It does not matter if I use explore-by-touch or the swipe-forwards gesture. 

See video demo of the problem:
https://youtu.be/VfFfFncFcUs 

## Expected Behavior 🤔

- No big UI changes should happen when I move VoiceOver focus on the page.
- The listbox should stay open when VoiceOver focus leaves the search field.
- I should be able to set focus to the results in the listbox by swiping forwards from the combobox, or by searching with my finger on the screen

Compare with the WAI-ARIA Authoring practices 1.1 example pattern (https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html) which displays the expected behavior:

Video demo of expected behavior:
https://youtu.be/8bzbR2vhVtY

## Steps to Reproduce 🕹

Steps:

1. Go to https://material-ui.netlify.app/components/autocomplete/ 
2. Start VoiceOver
3. Activate the combobox and start typing
4. Try to find and activate a suggestion in the list

## Context 🔦

This is a critical accessibility barrier with no way to get around it for a majority of visually impaired mobile users. iOS VoiceOver is used by 71% of mobile users according to WebAim Screen reader user survey #8 (https://webaim.org/projects/screenreadersurvey8/#mobilescreenreaders)

Also, this appears to be new behavior. Compare with screenshots in https://github.com/mui-org/material-ui/issues/18191 where the listbox did stay open when leaving the input field and you could find suggestions by explore-by-touch.

I am not sure if there have been any system-level changes affecting this going from iOS version 12 to 13 and 14, or if the component itself has changed. I tried looking at older versions of the component but could not find one that did not exhibit this bug.

## Your Environment 🌎

| Tech        | Version |
| ----------- | ------- |
| Material-UI | 4.11.0 (and 5.0.0-alpha.11) |
| React       |    16.13.1   |
| iOS   |    14.0.1     |
| iOS Safari  |    14.0.1     |
| iOS Chrome    |    85.0.4183.109     |
Repository: transformers
Issue: Add FAVOR+ / Performer attention
Labels: New model

# 🌟 FAVOR+ / Performer attention addition

Are there any plans to add this new attention approximation block to Transformers library?

## Model description
The new attention mechanism with linear time and space complexity was introduced in
 _Rethinking Attention with Performers_ [[https://arxiv.org/abs/2009.14794](https://arxiv.org/abs/2009.14794)].
Authors of the paper claim that the new attention mechanism is backward-compatbile with already existing models 
> Backwards compatibility with pretrained models is available as a benefit from softmax approximation, via small finetuning (required due to error propagation)


<!-- Important information -->

## Open source status

* [x] the model implementation is available: it's an original Trax implementation from Google: https://github.com/google-research/google-research/tree/master/performer/fast_self_attention
* [ ] the model weights are available: probably not required as it's a building block for models rather than fully new architecture
* [x] who are the authors: Krzysztof Choromanski, Valerii Likhosherstov, David Dohan, Xingyou Song, Andreea Gane, Tamas Sarlos, Peter Hawkins, Jared Davis, Afroz Mohiuddin, Lukasz Kaiser, David Belanger, Lucy Colwell, Adrian Weller
Repository: storybook
Issue: Separators deprecation message when using `${obj.attr}` in Meta title
Labels: bug,mdx

**Describe the bug**
I just started to migrate to SB 6 and I get the deprecation message about hierarchy separators even if I already used '/' as separator. It seems to be caused by using `${obj.attr}` in the Meta title: I import the `package.json` file to insert the version number in the sidebar:

```
import pkg from '../package.json'
import { Meta } from '@storybook/addon-docs/blocks'

<Meta title={`Docs v${pkg.version}/Changelog`} />
```

Probably a too generic regex.

**To Reproduce**
Steps to reproduce the behavior:

1. Create a `.mdx` file with the example above
2. Check the browser console

**Expected behavior**
No deprecation message

**System**
```
  System:
    OS: Windows 10 10.0.19041
    CPU: (12) x64 Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
  Binaries:
    Node: 12.18.2 - C:\Program Files\nodejs\node.EXE
    npm: 6.14.6 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 86.0.4240.75
    Edge: Spartan (44.19041.423.0), Chromium (85.0.564.68)
  npmPackages:
    @storybook/addon-actions: ^6.0.26 => 6.0.26
    @storybook/addon-docs: ^6.0.26 => 6.0.26
    @storybook/addon-knobs: ^6.0.26 => 6.0.26
    @storybook/addon-links: ^6.0.26 => 6.0.26
    @storybook/addon-storyshots: ^6.0.26 => 6.0.26
    @storybook/vue: ^6.0.26 => 6.0.26
```