sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: create-react-app
Issue: Bump the Hooks lint plugin to 2.0.1
Labels: issue: proposal,needs triage

This adds https://github.com/facebook/react/pull/16455. Technically a breaking change because it might uncover new violations.
Repository: pytorch
Issue: DataLoader slow down when `pin_memory=False`
Labels: module: performance,module: multiprocessing,module: dataloader,triaged

## 🐛 Bug

We have also observed that `pin_memory=False` leads to very slow data loading in the pytorch main process.
After examining code, I found a possible explanation:
a) `worker_result_queue.get()`(type `torch.multiprocessing.Queue`)  is much slower (40~100ms) compared to `data_queue.get()` (type `torch._six.queue`, takes <5ms).
b) When `pin_memory=True`, there is a back ground thread moving data from `worker_result_queue` to `data_queue`. And this causes additional CPU memory usage (in my case, ~120GB v.s. 145GB).
c) When `pin_memory=False`, `data_queue` is `worker_result_queue`, and pytorch uses a fore ground thread in main process to fetch data from the `data_queue` and re-order them, causing a delay varying from 40ms (no re-order) to 800ms (worse case re-order with 10 data workers) when calling `data_loader_iter.next()`. The delay can be even larger when main process is CPU bounded due to context switching between threads.
I believe the slow `worker_result_queue.get()` is due to unpickling, as in b) it shows the unpickled data (in `data_queue` when `pin_memory=True`) is larger than the pickled one (in `worker_result_queue`).
The solution to this issue can be:
Also use a background thread to move data from `worker_result_queue` to `data_queue` when `pin_memory=False`.
However, we need to be careful about this solution. As described in #24927, having multiple data loader iterator instances alive at the same time can lead to main process stuck in `pin_memory_loop`. If we implement a background thread to move data, I am worried that it could stuck similarly at some edge cases.

## To Reproduce

N/A, description already identified where the issue is.

## Expected behavior

`data_loader_iterator.next()` should return almost immediately when samples are pre-fetched.

## Environment

 - PyTorch Version (e.g., 1.0): `1.2.0a0+a5e6586`
 - OS (e.g., Linux): Ubuntu 14.04
 - How you installed PyTorch (`conda`, `pip`, source): source
 - Build command you used (if compiling from source): bazel
 - Python version: 2.7.6
 - CUDA/cuDNN version: 10.0.130/7
 - GPU models and configuration: v100/1080ti
 - Any other relevant information:

## Additional context

<!-- Add any other context about the problem here. -->


cc @SsnL
Repository: pytorch
Issue: Data worker should fetch a sample instead of a batch.
Labels: module: dataloader,triaged,enhancement

## 🚀 Feature

In multiprocess data loader, each data worker should fetch a sample instead of fetching a batch. (for `MapDataset` type)

## Motivation

1. Data workers will focus more on front part of the data queue, making the immediate needed batch faster to return. For example, when instantiating a new data loader iterator with batch size 2 and sampling sequence `[[1, 2], [3, 4]]`, there will be two workers fetching simultaneously for sample `[1, 2]` instead of only one worker fetching `[1, 2]` and the other worker fetching `[3, 4]`, making the 1st batch faster to be available. The effect is even more beneficial when `batch_size` is larger, e.g. `batch_size=1` v.s. `batch_size=10`.
2. Consume less CPU memory with the same `num_workers`. Right now the pre-fetching queue size is `2 * batch_szie * num_workers`, making the queue size proportional to `batch_size`. This however, makes CPU memory consumption significantly more when increasing `batch_size`. For example, when I increase `batch_size` from 1 to 10, I need 10x CPU memory to hold the queue, but the data loading speed stays the same because `num_workers` stays the same. Using per-sample fetching can essentially decouple queue memory consumption from `batch_size`, and allow to increase `num_workers` to speed up data loading (while with current per-batch fetching we cannot increase `num_workers` because we have hit the memory limit).

## Pitch

We can flatten the batch sampler and send individual samples to data workers. In terms of determinism, the samples will still be returned in the same order (for `MapDataset` type).
For example, with 2 workers, sending `[[1, 2], [3, 4]]` to workers will get back as `[[1, 2], [3, 4]]`. Sending `[1, 2, 3, 4]` to workers will still get back as `[1, 2, 3, 4]` after the reordering logic.
The operational difference between the two is `collate_fn` will be running in the main process instead of in the data worker process. So if `collate_fn` is CPU intensive, I can foresee some CPU bottleneck happening in the main process.
Another aspect on determinism is when `timeout` is enabled in data loader. In per-batch fetching, when a timeout happens, a batch is dropped. But in per-sample fetching, a timeout will only drop one sample, making the rest part of batches mis-aligned. For example, if in `[[1, 2], [3, 4], [5, 6]]`,  fetching sample 3 timed out, with per-batch fetching the data loader will return `[[1, 2], [5, 6]]`, but with per-sample fetching it will return `[[1, 2], [4, 5]]`. However, I believe if `timeout` is enabled, we are losing determinism anyway, so this behavior should be fine.
## Alternatives

Right now we are chaining a `MapDataset` loader (`batch_size=1`, `num_workers=<desired num of workers>`) with a `iterableDataset` loader (`batch_size=<desired batch size`, `num_workers=0`) in order to achieve this per-sample fetching structure.
It would be cleaner if PyTorch improves the data loading structure directly.

## Additional context

N/A

cc @SsnL
Repository: flutter
Issue: Remove generated Pod directory on `flutter clean`
Labels: tool,t: xcode,P3,team-tool,triaged-tool

## Proposal
Remove Pod/ directory on `flutter clean`.  See discussion at https://github.com/flutter/flutter/pull/38992#issuecomment-523644487.
Repository: TypeScript
Issue: Fourslash server tests silently ignore compiler option directives
Labels: Infrastructure

The existing working solution is to create a `tsconfig.json` fourslash-file, which is probably a better way to do things given that the server tests are supposed to mimic reality more closely, so my proposal would be to throw early when double-slash-attersand compiler directives are encountered.

Semi-related: #25081
Repository: neovim
Issue: API: nvim_input_flush
Labels: enhancement,api,input,event-loop

Proposal 1: API clients want a deterministic way to wait until "all input since _now_" has been processed.

1. new API function e.g. `nvim_input_flush()` ?
2. the function generates a new  token and puts it in the input queue: https://github.com/neovim/neovim/issues/30760
   - the token is a pseudokey like `<id:xxx>` where `xxx` is a monotonic integer
3. `nvim_input_flush()` blocks until the token is seen by `os_inchar`

Proposal 2 (alternative/additionally?): API clients want to know when _specific input_ has been processed.

1. new API function `nvim_input2({keys}, {callback})`: https://github.com/neovim/neovim/issues/30760
2. same as (2) in Proposal 2.
3. When `os_inchar` sees a token it 
    - invokes registered callbacks
    - emits `nvim_input_event({token})`

Reference:

-  #6247
-  https://github.com/neovim/neovim/pull/4448#issuecomment-196264209 
- https://github.com/neovim/neovim/pull/4448#issuecomment-523667181
Repository: pytorch
Issue: [C++] Call find_package(Torch REQUIRED) more than one time in downstream project causes CMake configuration error
Labels: module: build,triaged

## 🐛 Bug

Please see below minimal code to reproduce the problem

CMakeLists.txt
```
cmake_minimum_required(VERSION 3.11)

project(sample)

find_package(Torch REQUIRED)
find_package(Torch REQUIRED)

add_executable(${PROJECT_NAME} main.cpp)

target_link_libraries(${PROJECT_NAME} torch)
```

main.cpp
```
#include <ATen/ATen.h>

int main(){
  return 0;
}
```

## Expected behavior

After

```
mkdir build
cd build
cmake ..
```

I expect my downstream cmake configuration to work like usual, but here's the error message I get

```
CMake Error at /usr/share/cmake/Caffe2/public/mkl.cmake:3 (add_library):
  add_library cannot create imported target "caffe2::mkl" because another
  target with the same name already exists.
Call Stack (most recent call first):
  /usr/share/cmake/Caffe2/Caffe2Config.cmake:109 (include)
  /usr/share/cmake/Torch/TorchConfig.cmake:40 (find_package)
  CMakeLists.txt:6 (find_package)


-- Configuring incomplete, errors occurred!
```

I understand it's unusual to have the need to call `find_package(Torch REQUIRED)` twice but calling it twice for other popular libraries like OpenCV, TensorFlow, etc does not result in an error. Can someone please fix this?

## Environment
 - OS : Ubuntu
 - How you installed PyTorch: source
 - Build command you used:
```
cmake -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release -DBUILD_CUSTOM_PROTOBUF=OFF -DBUILD_PYTHON=OFF -DBUILDING_WITH_TORCH_LIBS=ON -DUSE_SYSTEM_NCCL=ON ..
make -j
```
 - CMake version: 3.15.2
 - Python version: 2.7
 - CUDA/cuDNN version: 10.0.130
 - GPU models and configuration: GeForce GTX TITAN Black


cc @ezyang
Repository: create-react-app
Issue: Revisit SVG data URI
Labels: issue: proposal,needs triage

### Background

SVG files are treated differently than other images in CRA.
(https://create-react-app.dev/docs/adding-images-fonts-and-files)

https://github.com/facebook/create-react-app/issues/1153 disabled automatic conversion of small SVG files into data URIs. The reason for that was incompatibility with SVG sprite systems, where the "fat" SVG document needs to be an external entity (or it could be inlined).

Oddly, the referenced `svg-sprite` and `gulp-svg-sprite` projects are not very active, with last releases ~1year ago each. Does that make the sprite technique obsolete? grandfathered? in active use?

I suspect that the `<style>` limitation (see below), also applies to SVG sprite systems.

It's odd to have special handling for SVG in CRA, when a sprite system is not bundled by default.

### Inline SVG
(https://create-react-app.dev/docs/adding-images-fonts-and-files#adding-svgs)
There's an alternative of using inline SVG XML, with some limitations:
* namespaces
* inline `<style>` elements

The core of the latter is that SVG styles are global, i.e. style in one inlined SVG pollutes all inlined SVG and even HTML. There are projects that attempt to inline the style into the SVG elements, but that's not always possible, for example, keyframes cannot be inlined. It may be possible to rename all inline styles to unique names for a given project [link? help needed to reference such projects].

SVG is typically designed in variety of 3rd party tools (let's say design team vs. dev team), thus it's unrealistic to require users to "make better SVG".

### Proposal.

As it is now, SVG handling is an ugly nit.

Let's reinstate data URI conversion of SVG files by default. This allows isolation between SVG files. I believe that's what most users expect. It's certainly more common for beginners than advanced techniques like sprites.

Let's optionally provide an escape hatch for sprite system users.
Repository: flutter
Issue: Support Flutter add-to-library
Labels: c: new feature,engine,d: api docs,a: existing-apps,c: proposal,P3,team-engine,triaged-engine


## Use case

Now I have a iOS framework to be used within other apps to integrate account and use center
features. Since we have framework on both iOS and android, I want to use flutter to write some
new pages proposed.

## Proposal

Now how add-to-app works is that flutter has to depend on iOS or android Lifecycles if I am correct, so in a iOS framework we have no access to host app's appDelegate or that would be additional work for our framework users.  So I wonder is there a solution for that, Thank you very much and wish flutter best and cheer for the flutter team.
Repository: pytorch
Issue: Benchmark cuDNN affine_grid_generator vs native
Labels: module: performance,module: cudnn,module: nn,module: cuda,triaged

Similarly to https://github.com/pytorch/pytorch/issues/24470, the cuDNN `affine_grid_generator` should be benchmarked against the native CUDA version.

The dispatch to cuDNN for `affine_grid` was disabled in https://github.com/pytorch/pytorch/pull/24929, but it's good to verify that performance hasn't notably regressed.

I wouldn't advocate for re-enabling the dispatch to cuDNN for `affine_grid` in any case, because it seems to be a headache to maintain compatibility, and can only even be dispatched to under a limited set of circumstances anyway (see the growing list of conditions [here](https://github.com/seung-lab/pytorch/blob/5377478e94a7e2c86181a7686a7a492ecd147815/torch/nn/_functions/vision.py#L7-L8) and [here](https://github.com/seung-lab/pytorch/blob/5377478e94a7e2c86181a7686a7a492ecd147815/aten/src/ATen/native/GridSampler.cpp#L470-L476)).
The better remedy in case of a performance regression would probably be to optimize the native CUDA kernel.

cc @SsnL
Repository: electron
Issue: setContentProtection not working on macOS
Labels: platform/macOS,bug :beetle:,7-0-x

<!--  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 an issue that matches the one I want to file, without success.

### Issue Details

* **Electron Version:**
 6.0.x , 7.0.x
* **Operating System:**
  * macOS 10.14 , macos 10.15
* **Last Known Working Electron version:**
  *4.x.x

### Expected Behavior
The function {browserwindow}.setContentProtection(true) , should make the app unrecordable for "Electron desktopCapturer" module.

### Actual Behavior
It does not work . 

### To Reproduce
Make a simple blank app, setContentProtection of the browserWindow, capture the desktop stream using the desktopCapturer module and show it on a canvas.
Repository: vscode
Issue: [html] don't validate custom event handlers as JavaScript
Labels: bug,html

- VSCode Version: 1.37.1  
- OS Version: Windows 10  
  
**Consider the following code snippet:**  
  
`<div onInvalidAttribute="test test" otherInvalidAttributeWithoutOnPrefix="test test"></div>`  
  
If the name of the attribute is prefixed with **“on”** and its value contains an empty space, then the following error is shown on the UI: “‘;’ expected. (js)”  and in the console output:
  
```
{
	"resource": "/d:/test ext/test.html",
	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 8,
	"message": "';' expected.",
	"source": "js",
	"startLineNumber": 1,
	"startColumn": 31,
	"endLineNumber": 1,
	"endColumn": 35
}
```
  
I believe vs code thinks the attribute is an event or special in some way because it begins with  “on” and performs some stricter validations on its value.  
    
**Steps to Reproduce:**  
  
1. Create HTML file  
2. Add any kind of html tag   
3. Add an attribute with “on” prefix to that tag (**onInvalidAttribute** was used in this example)
4. Give it a value containing an empty space in between  (**test test** was used in this example)
  
Does this issue occur when all extensions are disabled? Yes, I have launched vs code using`code --disable-extensions`, the issue remains the same.

**I am looking for a way to disable this specific error as the stricter validation is probably intended. Ideally I do not want to change / rename the attributes beginning with "on".**
Repository: ant-design
Issue: Allow collapsible sider to be used in fixed position
Labels: Inactive

- [x] 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?
Presently, in `Layout Sider`, the `collapsible sider` is in `position:relative` by default. To use a `fixed sider`, we must use a non-collapsible design because when position is set as fixed for the sider, the content of the `Layout` is manually set to 200px to the right.

Collapsible navigation is a great tool, but cannot be used in  fixed mode and this causes multiple problem:
1. When we set 200px for margin-right, we have to manually change this value in the content css which is not good design. It's not good design because, let's say we have layout A, B, C. A is the parent component containing B  and C. B is the sider, and C is the content. If we do not have redux setup (for simple projects), communication of this 200px/collapse status/animation of content sliding becomes a tedious task.

### What does the proposed API look like?
The solution is really simple. For the first children inside a sider, there is a div with the `class`: `.ant-layout-sider-children`. 

I was thinking, we check `if(collapsible  && position==fixed)`, then we add the following css rules to the above-mentioned class:
```css
.ant-layout-sider-children {
     width: inherit;
     position: fixed;
}
```
This fixes all the problem, and we can use fixed collapsible navigation with a really easy fix.

I am willing to submit a PR to fix this, I just need to be guided in the right direction.

Thanks in advance!

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: go
Issue: cmd/go: allow 'go mod vendor' to omit replaced modules
Labels: NeedsInvestigation,FeatureRequest,modules

<!-- 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.9 darwin/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="/Users/mkeeler/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/mkeeler/.go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/mkeeler/Code/repos/consul/master/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/dc/5dk846911dbdkmjk4bj47hhm0000gn/T/go-build297831786=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

1. `git clone https://github.com/hashicorp/consul`
2. `go mod vendor`

### What did you expect to see?

I didn't expect vendor/modules.txt to contain the nested modules within it nor having those nested modules be vendored into the top level vendor folder.

### What did you see instead?

Nested submodules are vendored.

We currently get around this by postprocessing the modules.txt and the vendor directory. I realize that nested modules might not be a great idea (it has caused me a number of headaches) however for code living in the same repo the current `go mod vendor` behavior of vendoring our own code doesn't make much sense to me. Is this intended behavior or just something that isn't protected against.
Repository: go
Issue: proposal: add explicit decision doc for large changes
Labels: Proposal

#33670 talks about how to identify large changes. Having done that, we should expect a large discussion. It can't be the case that you have to read the whole discussion to participate. That doesn't scale.

The goal of the discussion should be to identify all the pros and cons and tradeoffs involved in the decision. Often that makes the decision clear, but not always, especially for large ones. 

We've always collected these pros and cons informally; at best we occasionally write a discussion summary. For large changes it may make sense to write a formal, explicit “decision document” that lays out the pros, cons, and tradeoffs. Then the goal of the discussion is to complete this document. Someone who wants to participate in the discussion could start by reading the document and checking whether anything is left to add. 

The current proposal process description hints at the discussion feeding back into the main proposal doc, but I think it would be clearer to have a separate document that is the discussion summary / inputs to the decision / tradeoffs.

Someone proposing a large change would be responsible for incorporating discussion into the design document, or else for finding someone who will. 

The same kind of decision document could be written for design drafts (maybe a pre-decision document).
Repository: TypeScript
Issue: Type metadata is lost in generic type interfaces
Labels: Bug,Domain: Quick Info

**TypeScript Version:**  3.6.1-rc

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

generic function metadata
generic type jsdoc
mapped type jsdoc

**Code**

```ts
interface Example {
    /** This is property A. */
    a: number;
}

function one(param: Example): void {};

one({
    a: 1 // ✅ Hover over `a` to see description
});

function two<T extends Example>(param: T): void {};

two({
    a: 2 // ❌ Description is lost
});

function three<T = Example>(param: T): void {};

three({
    a: 3 // ❌ Description is lost
});

function four<T extends Example = Example>(param: T): void {};

four({
    a: 4 // ❌ Description is lost
});

// Unexpectedly:
four<Example>({
    a: 4 // ✅ Hover over `a` to see description
});

```

**Expected behavior:**

I would expect to see the description on hover for at least the fourth or fifth examples, but I don't.

**Playground Link:** [**demo**](http://www.typescriptlang.org/play/index.html#code/JYOwLgpgTgZghgYwgAgKIA84FsAOAbFAbwFgAoZC5AegCobkAVAC2AGdk3kcoB7HaMAE9kAQQB0yGlTKVkcAFzIQAVywAjaAG4yAXzJkYykAjDAeIZOYgAKHHCjZFGbPggBKRQDcewACbJCHW1SMitrEnJKBWQARmoqZEBQcmQACR5PaEsMqGQAAzhc5DAeZFYIFF8IVgQoYBxTc103YIMjEzMLMAB3HgAeBmQIdEgQX3ZnXAIAPlt7R0YPZG8-AKD9Um6ecJkoxQAmeORAGXJkABEqmrqGi048HlYwJpbSQ2NroqYocv7kAF40TCTCAzOwOLCKBiLZb+QLPMCfcrbSIUaIAZkOJ3O1Vq9Q6HHYdweT3Wr3a5mQMB4yigPyGIzGAJcBD+jKBILm4IWXh8MLWIReVKgSNk0QALBizhcce9bvdHqQdM11lQEgBVEBDfgmCC+PCCeQGQW9CauGYREWKcUqpKpdKZO05fKFYqlcrISrYq4dJ5AA)

**Related Issues:**

This is similar to #21489, but that involves mapped types while this involves generics.