sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Accelerate PyTorch just-in-time compilation using MKL-DNN
Labels: oncall: jit,feature,triaged,module: mkldnn

## 🚀 Feature
Accelerate PyTorch just-in-time compilation using MKL-DNN
 
## Motivation
PyTorch's just-in-time (JIT) compiler rewrites and runs Pytorch model at production-efficiency. MKL-DNN is built to accelerate deep learning applications in production environment. With the high performance primitives like conv, rnn, and gemm, MKL-DNN accelerates most deep learning models significantly on multiple Intel CPU generations using AVX2, AVX512, AVX512-VNNI and future deep learning acceleration technology. 
 
With MKL-DNN enabled in JIT compiler, user can use JIT mode to get best performance with MKL-DNN with minimum change of Pytorch code. In imperative mode, user needs to explicitly insert format conversion for MKL-DNN operations using tensor.to_mkldnn() and to_dense(). In JIT mode, user doesn’t have to do so. User may need to pass an explicit flag or invoke a specific MKL-DNN optimization pass. It automatically converts CPU path op to MKL-DNN op, and propagates mkl-dnn format across neighbor MKL-DNN operations. It includes all performance benefits possibly achieved in imperative mode and additional graph optimization.
 
## Pitch
Use PyTorch just-in-time compilation to get MKL-DNN acceleration with one flag (or function call)
 
## Additional context
 
The MKL-DNN optimization pass includes mkl-dnn format propagation and fusion as initial step. The mkl-dnn formation propagation converts CPU ops to MKL-DNN ops. Format conversion ops are added in-between CPU and MKL-DNN ops.

The implementation of PyTorch MKL-DNN JIT backend will be located in the ‘backend’ directory in JIT sub-directory
Repository: vscode
Issue: Support prompt for QuickPick as well as InputBox
Labels: feature-request,quick-pick

I would like the createQuickPick and showQuickPick APIs to support a `prompt` field, the same way InputBox does, so I can show more information to the user that does not disappear when they begin to type.
Repository: go
Issue: cmd/compile: review "expected expression" error messages
Labels: NeedsInvestigation,compiler/runtime

The compiler's parser (cmd/compile/internal/syntax) reports errors of the form:
```
syntax error: unexpected }, expecting expression
```
etc. Review these error messages; perhaps a form that uses `missing expression` is clearer.
Repository: rust
Issue: Const validation rejects references that might be dangling (but could actually be valid at run-time)
Labels: T-lang,C-feature-request,A-const-eval,needs-rfc,requires-nightly

Apparently it's undefined behaviour to use:
```
const gpio: &RegisterBlock = unsafe { (& (*lpc176x5x::GPIO::ptr())) };
```

but not undefined to use: 
```
fn x() {
  let gpio: &RegisterBlock = unsafe { (& (*lpc176x5x::GPIO::ptr())) };
  (...)
}
```

with:
```
    pub const fn ptr() -> *const gpio::RegisterBlock {
        0x2009_c000 as *const _
    }
```

Error message is:
```
error[E0080]: it is undefined behavior to use this value
  --> src/rtos.rs:27:1
   |
27 | const gpio: &RegisterBlock = unsafe { (& (*lpc176x5x::GPIO::ptr())) };
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered dangling reference (created from integer)
   |
   = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rust compiler repository if you believe it should not be considered undefined behavior
```

This is happening on in an embedded envrionment, where there is no MMU, and access to that address is correct.
I'm not sure why it would be undefined to use it as a const, but not undefined to use it as a variable value?
Perpahs it has something to do with the borrow checker not being able to track mutable and unmutable references to that value, but this is an immutable access, so it *should* be fine?
Repository: pytorch
Issue: Bogus "Your compiler (clang++) is not compatible" message
Labels: module: build,triaged,module: macos

I used `cpp_extension` on OS X and I got:

```
                               !! WARNING !!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Your compiler (clang++) is not compatible with the compiler Pytorch was
built with for this platform, which is clang++ on darwin. Please
use clang++ to to compile your extension. Alternatively, you may
compile PyTorch from source using clang++, and then you can also use
clang++ to compile your extension.

See https://github.com/pytorch/pytorch/blob/master/CONTRIBUTING.md for help
with compiling PyTorch from source.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

                              !! WARNING !!

```

This looks pretty bogus to me.
Repository: flutter
Issue: ui.Image.toByteData can't use the default rawRgba format if it's later used for Image.memory
Labels: engine,a: images,has reproducible steps,P2,found in release: 3.3,found in release: 3.7,team-engine,triaged-engine

To reproduce, run the app in https://gist.github.com/liyuqian/560c3edefe2bce147147a49db0ec4e98 and remove its PNG encoding specification (search for `!!!`).

My Flutter version is c8be195e953c0366592aa253baa774ef5b718eb6 when this issue is reproduced locally. This issue may have been there for a while. For example, cl/260167188 was using PNG because of this.
Repository: node
Issue: HTTP2 compatibility layer tries to write the header multiple times.
Labels: http2

I was given this bug report:

https://i.imgur.com/YcJtGBJ.png

Yes, I was given just an image.

The issue is: this very same code runs smooth as butter for 4 years now on sites with great amounts of traffic and writing headers twice was NEVER and issue. The same poster said the person that he contacted insisted the issue was with my software. I'd ask you to look at this issue again, is not the first time my software stumbles with issues on the compatibility module. The moment this user changed from the http2 to the http module, the issue disappeared.
Repository: kubernetes
Issue: Generated DeleteCollection methods make it impossible to use pagination correctly
Labels: kind/bug,sig/api-machinery,lifecycle/frozen,lifecycle/stale

DeleteCollection supports the full set of list options -- under the hood, it just calls the same List & ListPredicate machinery in the Store implementation.  This means that it's perfectly viable to call DeleteCollection via REST calls directly with the pagination options (limit & continue), and, in fact, it behaves as expected when you do that (passing limit deletes a limitted set of results, returns those results, and gives back a continue token that can be passed to the next call to delete the next page of results).

However, our DeleteCollection generated Go methods don't actually return anything but an error, making it impossible to access the continue token, meaning that it's not possible, AFAICT, to use pagination correctly with the generated deletecollection methods.

Furthermore, since people look at the generated Go clients as a form of example/documention, we've effectively got misleading examples sitting around.

API calls tested against 1.13.7, relevant source code from k8s.io/apiserver & k8s.io/client-go examined @ HEAD-ish (bb707c8fe2e2b0b6ea8320e232f7725efda8de34)

/sig api-machinery
/kind bug
Repository: go
Issue: encoding/json: marshaling RawMessage has poor performance
Labels: Performance,NeedsDecision

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12.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
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jrittner/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jrittner/go-workspace"
GOPROXY=""
GORACE=""
GOROOT="/home/jrittner/go"
GOTMPDIR=""
GOTOOLDIR="/home/jrittner/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build506812392=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Ran a benchmark to compare marshaling a `json.RawMessage`, a `string` and a `[]byte`.

```
package jsontest

import (
	"encoding/json"
	"testing"
)

const msg = `{"a":"aaaaaaa","b":{"c":["d","e"]}}`

var benchmarkResult interface{}

func BenchmarkRawMessage(b *testing.B) {
	x := json.RawMessage(msg)
	for i := 0; i < b.N; i++ {
		j, err := json.Marshal(x)
		if err != nil {
			b.Fatal(err)
		}
		benchmarkResult = j
	}
}

func BenchmarkString(b *testing.B) {
	x := msg
	for i := 0; i < b.N; i++ {
		j, err := json.Marshal(x)
		if err != nil {
			b.Fatal(err)
		}
		benchmarkResult = j
	}
}

func BenchmarkBytes(b *testing.B) {
	x := []byte(msg)
	for i := 0; i < b.N; i++ {
		j, err := json.Marshal(x)
		if err != nil {
			b.Fatal(err)
		}
		benchmarkResult = j
	}
}
```

### What did you expect to see?

I expected marshaling a `json.RawMessage` to have the best performance of the three, since it should be a no-op.

### What did you see instead?

It is 2 times slower than marshaling a `string`, and 3 times slower than marshaling a `[]byte`. 

BenchmarkRawMessage-2   	 1000000	      1513 ns/op	     232 B/op	       7 allocs/op
BenchmarkString-2       	 2000000	       869 ns/op	     112 B/op	       3 allocs/op
BenchmarkBytes-2        	 3000000	       561 ns/op	     128 B/op	       3 allocs/op
Repository: electron
Issue: Would like a way to open a separate devtools window instance for each worker
Labels: enhancement :sparkles:

<!--  As an open source project with a dedicated but small maintainer team, it can sometimes take a long time for issues to be addressed so please be patient and we will get back to you as soon as we can.
-->

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

### Problem Description
In my Electron app, I create a shared worker. When I have the devtools attached to the main renderer, I cannot debug the shared worker, and vice versa. It seems there can be only 1 instance of the devtools window at a time. This makes it hard to debug an operation that starts in the main renderer and continues in the worker.

### Proposed Solution
Proposal is to open a new devtools windows for each worker. So there can be a devtools window attached to the main renderer, and separate devtools windows for any workers, all debuggable at the same time. 

### Alternatives Considered
This kind of debugging can be achieved by launching Electron with the --remote-debugging-port switch, and opening a url to debug workers as a workaround.

### Additional Information
<!-- Add any other context about the problem here. -->
Repository: godot
Issue: Persistent connections are not saved when created with tools for non-editable children
Labels: topic:core,topic:editor,documentation

**Godot version:** 3a6102a6f

**Issue description:** Suppose I have a scene and instanced the scene A with child B. Connecting a signal from B with the flag `CONNECT_PERSIST` will fail (silently) to actually persist unless `editable_children` is true for A.

**Steps to reproduce:** Call the connect function from an editor plugin, something like `B.connect("somesignal", other_node, [], CONNECT_PERSIST)`. The connection will work while the scene is loaded, but will stop working on reloading.

I understand non-editable children properties should *not* be saved, but this fails silently. The `error` returned by `connect()` is 0 in both cases. *edit: Note this work for connections **to** B.*

This is another reason why exposing `editable_children` to scripts would be useful. See #20292, [this comment](https://github.com/godotengine/godot/issues/27828#issuecomment-506451476_) and this [rejected PR](https://github.com/godotengine/godot/pull/20569).

[**Minimal reproduction project**](https://github.com/godotengine/godot/files/3459194/Test.zip): Press space to create the connection and switch/reload scenes with/without `editable_children` on.
Repository: pytorch
Issue: segmentation faults when using multiprocessing_context='spawn' with large number of processes
Labels: oncall: distributed,module: multiprocessing,module: dataloader,triaged

Pytorch version `1.2.0.dev20190801+cu100` running into problem using `multiprocessing_context='spawn'` in the DataLoader

It works for 48 processes over two machines using `spawn` or 384 processes using default method, but segfaults for 384 processes using spawn after warnings like this ([log](https://app.wandb.ai/yaroslavvb/imagenet18/runs/ftvkloea/logs))
```
user/anaconda3/envs/pytorch_p36/lib/python3.6/multiprocessing/semaphore_tracker.py:143: UserWarning: semaphore_tracker: There appear to be 11 leaked semaphores to clean up at shutdown 
  len(cache)) 
```
384 processes comes from 3 DataLoaders per process (test, validation, train), 8 workers per DataLoader, and separate process per GPU for 16 GPUs

cc @SsnL @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera
Repository: pytorch
Issue: Using PyTorch on AWS EFA network
Labels: module: dependency bug,oncall: distributed,triaged

Opening this bug to collect PyTorch-side information needed to get PyTorch running on AWS EFA network.

AWS-side is on https://github.com/aws/aws-ofi-nccl repo.

Related bugs:
- PyTorch EFA performance optimization/settings: https://github.com/aws/aws-ofi-nccl/issues/19
- Default DataLoaders cause crash on EFA, must use spawn: https://github.com/aws/aws-ofi-nccl/issues/20

Getting around EFA mpirun restrictions for DataLoader requires switching to `multiprocessing_context='spawn'` in latest PyTorch, [this](https://github.com/pytorch/pytorch/issues/23720) bug currently limits the number of workers you can use to lower than desired
Repository: opencv
Issue: OpenCV failed due to "error C2039: 'min': is not a member of 'std'" under /permissive- + MSVC
Labels: category: build/install,category: 3rdparty

Hi All,

OpenCV failed due to "error C2039: 'min': is not a member of 'std'" under /permissive- mode when built on MSVC. You use std::min, but don’t have <algorithm> included until later. Could you please help take a look at this? Thanks in advance!

**You can repro this issue as the steps below:**

1. git clone https://github.com/opencv/opencv D:\OpenCV\src
2. git clone https://github.com/opencv/opencv_extra D:\OpenCV\src\extra
3. open a VS 2017 x86 prompt and browse to D:\OpenCV
4. mkdir build_x86 && pushd build_x86
5. set _CL_=/permissive-
6. cmake -G "Visual Studio 15 2017" -DCMAKE_SYSTEM_VERSION=10.0.17134.0 -DWITH_IPP=ON -DBUILD_SHARED_LIBS=OFF -DBUILD_PERF_TESTS=ON -DBUILD_TESTS=ON -DBUILD_EXAMPLES=ON -DWITH_OPENCL=OFF -DBUILD_DOCS=OFF -DWITH_CUDA=OFF ..\src
7. msbuild /p:Configuration=Release;Platform=Win32 .\OpenCV.sln /t:Rebuild /m /p:BuildInParallel=true

**Error info:**
D:\OpenCV\src\3rdparty\openexr\Imath\ImathQuat.h(633): error C2039: 'min': is not a member of 'std'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\include\iomanip(20): note: see declaration of 'std'
Repository: flutter
Issue: FlutterTextInputPlugin for iOS transfers unsupported NSUIntegers over MethodChannels
Labels: framework,engine,P2,team-engine,triaged-engine

The FlutterTextInputPlugin for iOS sends NSUIntegers (unsigned integers) over MethodChannels, example (see composingBase, etc):

https://github.com/flutter/engine/blob/ab745140cd30bb9a85a7f59c641fad75d0d707be/shell/platform/darwin/ios/framework/Source/FlutterTextInputPlugin.mm#L590-L610

As long as the concrete NSUInteger value fits into a dart int (which is always signed) everything works out fine. If the NSUInteger exceeds that range (e.g. when you transfer NSUIntegerMax), it gets funky: The MethodChannel in question (`flutter/textinput`) uses the FlutterJSONMethodCodec and Apple's NSJSONSerialization has no problem representing that large integer as a String in the json. On The Flutter framework side, the JsonDecoder realizes that it cannot represent that large integer as a dart int and instead silently decodes it into a double in the resulting Map<String, dynamic>. This is problematic, because the framework really expects int values in these places:

https://github.com/flutter/flutter/blob/b2497822e84f18f543a8dd6eaaa34977c04054d2/packages/flutter/lib/src/services/text_input.dart#L504-L518

https://github.com/flutter/flutter/blob/387f885481cd8441237680de0cfcd0802c0af48c/packages/flutter/lib/src/services/text_editing.dart#L21-L25

Interestingly, when the double from the Map<String, dynamic> is assigned to the int of TextRange the exception that should be thrown there is swallowed. It doesn't appear in any log. (This needs more investigation to figure out where the exception goes).

Switching the FlutterJSONMethodCodec to a FlutterStandardMethodCodec also doesn't help as that one doesn't support NSUIntegers at all and just transfers them as signed integers (NSUIntegerMax is therefore transferred as -1).

It seems like we just shouldn't be using NSUIntegers for things that go over the method channel. Even if we fix the MethodCodecs to deal with them properly, we can't represent them as dart ints in the framework.
Repository: pytorch
Issue: Failed to build pytorch ...
Labels: module: build,triaged


```console
TORCH_CUDA_ARCH_LIST="5.2" BUILD_BINARY=1 USE_TENSORRT=1 BUILD_CUSTOM_PROTOBUF=0 USE_GLOO_IBVERBS=1 NAMEDTENSOR_ENABLED=1 BUILD_TEST=1 USE_MKLDNN=1 FULL_CAFFE2=1 python setup.py build
```

```console
-- Could NOT find CUB (missing: CUB_INCLUDE_DIR) 
```

...

```console
-- Excluding image processing operators due to no opencv
-- Excluding video processing operators due to no opencv
```
...

```console
-- Configuring done
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_CUDA_COMPILE_WHOLE_COMPILATION
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_CUDA_COMPILE_WHOLE_COMPILATION
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid
Traceback (most recent call last):
  File "setup.py", line 748, in <module>
    build_deps()
  File "setup.py", line 321, in build_deps
    cmake=cmake)
  File "....../pytorch/tools/build_pytorch_libs.py", line 61, in build_caffe2
    rerun_cmake)
  File "....../pytorch/tools/setup_helpers/cmake.py", line 312, in generate
    self.run(args, env=my_env)
  File "....../pytorch/tools/setup_helpers/cmake.py", line 133, in run
    check_call(command, cwd=self.build_dir, env=env)
  File "/usr/lib/python3.7/subprocess.py", line 347, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '-GNinja', '-DBUILD_BINARY=1', '-DBUILD_CUSTOM_PROTOBUF=0', '-DBUILD_PYTHON=True', '-DBUILD_TEST=True', '-DCMAKE_BUILD_TYPE=Release', '-DCMAKE_CXX_FLAGS= ', '-DCMAKE_C_FLAGS= ', '-DCMAKE_EXE_LINKER_FLAGS=', '-DCMAKE_INSTALL_PREFIX=....../pytorch/torch', '-DCMAKE_PREFIX_PATH=/usr/lib/python3/dist-packages', '-DCMAKE_SHARED_LINKER_FLAGS=', '-DINSTALL_TEST=True', '-DNUMPY_INCLUDE_DIR=/home/lvision/.local/lib/python3.7/site-packages/numpy/core/include', '-DPYTHON_EXECUTABLE=/usr/bin/python', '-DPYTHON_INCLUDE_DIR=/usr/include/python3.7m', '-DPYTHON_LIBRARY=/usr/lib/libpython3.7m.so.1.0', '-DTORCH_BUILD_VERSION=1.2.0a0+acc5ced', '-DUSE_CUDA=True', '-DUSE_DISTRIBUTED=True', '-DUSE_GLOO_IBVERBS=1', '-DUSE_MKLDNN=1', '-DUSE_NUMPY=True', '-DUSE_SYSTEM_EIGEN_INSTALL=OFF', '-DUSE_TENSORRT=1', '-DUSE_GLOO_IBVERBS=1', '-DUSE_IBVERBS=1', '....../pytorch']' died with <Signals.SIGABRT: 6>.
```
Repository: ant-design
Issue: Adding to the ValidateFieldOptions type to support the async-validator 1.11.3 addition of the suppressWarning option
Labels: Inactive

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### What problem does this feature solve?
This keeps ant-design in line with async-validator and removes those console warnings, particularly when testing, that pop up when a form is submitted with un-validated fields.

### What does the proposed API look like?
This is only a small change adding an optional property to the ValidateFieldOptions Type. 

components/form/Form.tsx - immediately after line 134: 
```javascript
/** async-validator: suppressWarning option */
suppressWarning?: boolean;
```

components/form/index.en-US.md - immediately after line 121:
```markdown
| options.suppressWarning | Set to `true` to remove async-validator warnings when fields fail validation on submission | boolean | false | 3.9.3 |
```

And my Chinese is rusty (read non-existent) components/form/index.zh-CN.md - immediately after line 124:
```markdown
| options.suppressWarning | 调成 `true` 去除 async-validator 字段在提交时验证失败时发出警告 | boolean | false | 3.9.3 |
```

As for the version numbers in each of the markdown files I'd suppose that they would need to be updated in line with what version number was used.


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: nn.Module.forward signature with **kwargs
Labels: module: checkpoint,module: nn,triaged,enhancement

Hi there!

The other day I was working on improving `utils.checkpoint` module and I found out there is no way right now to pass `**kwargs `to checkpointed function. This is probably in order to by compliant with the `nn.Module.forward` method. 

Now, I could not think about any argument against having `**kwargs` in `forward` method and many people overload this method with `**kwargs` because it is nice and lit :) I was about to change it and create pull request but before I do it I decided to go smart and ask you guys if there is some obvious reason why we should not do it. Otherwise, I am more than happy to start working on it.

Thanks :- )
Repository: neovim
Issue: unibi_from_term called twice (via libtermkey and neovim)
Labels: performance,tui,complexity:low

When looking into https://github.com/neovim/neovim/issues/9071 I've found that `unibi_from_term` gets called twice usually:
https://github.com/neovim/libtermkey/blob/b7fe3af141c53cce71a244282b69ea860452120a/driver-ti.c#L413
https://github.com/neovim/neovim/blob/b92a5bc3c4bdfddfc21638556ace6ef3fd90155c/src/nvim/tui/tui.c#L230

Given that it pokes at the file system etc it might be nice if this could be done only once, e.g. by re-using the information from libtermkey, or passing the information from Neovim to libtermkey (but currently libtermkey gets it first).