sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: NodeJS blocks response from CONNECT
Labels: net

On my Linode VPS (Nanode) I host two separated apps: file streamer and forward proxy. The file streamer is written in NodeJS and streams files from remote servers to clients. A forward proxy is a classic forward proxy. The problem I have is that after a while of serving files, file streamer starts to block responses from the proxy. Connections to the proxy are ok, also file streamer responds normally.

As a proxy, I've tried Squid, Tinyproxy or even simple NodeJS proxy. All result to the same error, broken pipe. It seems that file streamer somehow blocks responses from different apps/streams. Even if the file streamer no longer sends any files, it still blocks the proxy. Once this condition happens, the only thing it helps is restarting the file streamer.

Here is the simplified code of file streamer. It uses pipes, there is no magic:

```js
// File Streamer
const server = http.createServer((sreq, sres) => {
    const url = 'some user defined url';
    const options = {some options};
    const req = https.request(url, options, (res) => {
        sres.writeHead(res.statusCode, res.headers);
        res.pipe(sres);
    });
    req.end();
});
```
Do you have some ideas about why the file streamer (NodeJS) blocks responses from the other apps? I didn't detect any memory leaks, any CPU overloading, any high I/O operations, etc.

UPDATE:
I tried to merge File Streamer script (above) and Forward Proxy script into one server. Unfortunately, it didn't help. Interesting is, that File Streamer works properly, but Forward Proxy returns `Error: write EPIPE`.
```js
// Forward Proxy
server.on('connect', (req, socket, head) => {
    debug('CONNECT');
    const srvUrl = url.parse(`http://${req.url}`);
    const srvSocket = net.connect(srvUrl.port, srvUrl.hostname, () => {
        socket.write('HTTP/1.1 200 Connection Established\r\n' +
            '\r\n');
        srvSocket.write(head);
        srvSocket.pipe(socket);
        socket.pipe(srvSocket);
        socket.on('error', (err) => {
            debug('Some socket error.');
            debug(err.stack); // Error: write EPIPE <--- ERROR
        });
    });
});
```

UPDATE 2:
I believe that problem must be in the file streamer part. But I wasn't able to determine where. Probably it's something wrong with NodeJS on low level. Now I stream files only with NGiNX, it's flawless and it consumes 3x less memory.
Repository: react
Issue: Devtools v4 does not work with Firefox's private window
Labels: Type: Bug,Component: Developer Tools

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**

* bug
* This issue has been reported in https://github.com/facebook/react-devtools/issues/1383

**What is the current behavior?**


Steps to Reproduce is here:

1. Environments are:
2. Open the page which uses react with a private window.
3. Open Firefox's devtools.

Actual Result is:

* react devtools' _component_ pane show `Unable to find React on the page.`
* From about:debugging, we can see the below messsage:

```
SecurityError: Permission denied to access property "container" on cross-origin object main.js:51:305877
    Kl moz-extension://56db142d-3d36-b04e-91ca-a7504c7708a5/build/main.js:51
    apply self-hosted:4417
    applySafeWithoutClone resource://gre/modules/ExtensionCommon.jsm:588
    asyncWithoutClone resource://gre/modules/ExtensionCommon.jsm:2400
```



**What is the expected behavior?**

react devtools work

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

* Firefox 68
* react devtools v4.0.5
* react v16.9
Repository: pytorch
Issue: [FYI] NestedTensor Project Progress
Labels: feature,triaged,module: nestedtensor

### Purpose of this issue
This issue tracks RFCs and PRs related to the design and implementation of NestedTensors. It reflects the current state of the project. It is however **not** to discuss details of the projects, but solely for information purposes. For discussion please refer to the corresponding RFCs and PRs. You can expect this issue to be edited frequently to reflect the current state of the project.


### RFCs

- [x] [0.0.1](https://github.com/pytorch/pytorch/issues/22169) - Introduction, tensor-wise operations, implementation considerations.

- [x] [0.0.2](https://github.com/pytorch/pytorch/issues/25112) - Definition of nested and tensor dimensions; tensor dimension only broadcasting and reductions; tensor+mask construction functions; prototype dispatch implementation; implicit autograd support; unbind, to_tensor; as_nested_tensor; nested_dim; nested_size(i)

- [ ] 0.0.3 - Definition of ```__iter__```, ```__getitem__```, flatten, tensor-wise tuple/list arguments, contiguous. Migration plan into pytorch/pytorch. Rename tensorwise to vmap.

- [ ] 0.0.4 - Definition of expand, reshape, view, narrow, squeeze, select.

- [ ] 0.0.5 - Performance benchmarks and implementations, explicit autograd support (if necessary), improved dispatch (if necessary/available), release.

### 
PR

- [ ]  Prototype implementation of 0.0.1 and 0.0.2 to support current feature branches https://github.com/pytorch/pytorch/pull/22783


### Repository

- [pytorch/nestedtensor](https://github.com/pytorch/nestedtensor) with pypi as ```pip install nestedtensor``` (needs update).

### Examples

- [pytorch/nestedtensor/examples](https://github.com/pytorch/nestedtensor/tree/master/examples)

### Feature branches
These are updated frequently. They don't always comply with the RFCs and might exhibit usage of experimental or undocumented features. They mainly serve as playgrounds for dogfooding and as examples. They won't land before NestedTensors are actually part of a PyTorch release and up to the respective project standards. 

- https://github.com/facebookresearch/ParlAI/compare/master...cpuhrsch:nestedtensor
- https://github.com/cpuhrsch/vision/compare/formatting...cpuhrsch:ntsegmentation2
- https://github.com/pytorch/vision/compare/master...cpuhrsch:imglist2

### POCs
@cpuhrsch
Repository: svelte
Issue: Nested async components error when switching components
Labels: compiler

**Describe the bug**

When nesting dynamic components that are imported via `await import('/SomeComponent.js')`, when the top-most component class is changed, the following error is thrown.

**Logs**

`TypeError: undefined is not an object (evaluating 'outros.c')`

(full traceback below)

**To Reproduce**

I was unable to reproduce this in the REPL (I assume it doesn't support dynamic imports), so here is a repro repository: https://github.com/taylorzane/svelte-async-import-repro

Just run `yarn build && yarn start` and then open up the webpage and attempt to click the button. It will switch the to-be-imported component from `Child1` to `Child2` (both of which dynamically import `SubChild`)

**Expected behavior**

The component switch/transition should not throw an error.

**Stacktraces**

<details>
  <summary>Stack trace</summary>
<pre>
[Error] Unhandled Promise Rejection: TypeError: undefined is not an object (evaluating 'outros.c')
	transition_out (Child1.js:150)
	o (Child1.js:603)
	transition_out (bundle.js:165)
	p (bundle.js:358)
	p (bundle.js:455)
	update (bundle.js:126)
	flush (bundle.js:100)
	promiseReactionJob
</pre>
</details>

**Information about your Svelte project:**

- Your browser and the version: Safari 12.1.2

- Your operating system: macOS 10.14.6

- Svelte version: v3.9.1

- Rollup

**Severity**

Currently makes multi-page (sapper) svelte usage entirely unusable.

**Additional context**
 
Might be related to #3165, but seems slightly different (`outros` is definitely defined)
Repository: pytorch
Issue: make add_module accept tuples as well or change containers(ModuleList, Sequential, etc) to allow this
Labels: module: nn,triaged,enhancement

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->

## Motivation
The API is not consistent with the way architectures are made. That is you can do some actions using a set of methods, but cant do the same actions using a slightly different version of the same methods. To be more clear for example, currently if you want to alter/use a part of an existing architecture you may use `model.children()`  like this : 
1. method 1 :    
```
model = torchvision.models.resnet18(pretrained=True)
model_features = nn.ModuleList(model.children())[ : -1] 
...
```
2. or a slightly different version 
```
model = torchvision.models.resnet18(pretrained=True)
model_features = list(model.children())[ : -1]
model_features = nn.Sequential(*model_features) 
...
```
However, the very time you  try to use the named version of same method (i.e `model.named_children`), you no longer can do the same thing and will face the error : 
`TypeError: tuple is not a Module subclass`
in the process of using only `children()` method in such situations, you lose the information originally placed in the architecture, meaning you no longer have access to the modules using their names. 
The source of the issue lies in  the `add_module()` method which interestingly accepts a name and a module by default. 

  
## Pitch
allow for `nn.ModuleList()`, `nn.Sequential()` and alikes that accept modules, also accept named modules. meaning these two snippets be interchangeable : 

using modules only (`children()`)
```
model = torchvision.models.resnet18(pretrained=True)
model_features = nn.ModuleList(model.children())[ : -1] 
```
using tuple (`named_children()`)
```
model = torchvision.models.resnet18(pretrained=True)
model_features = nn.ModuleList(model.named_children())[ : -1] 
```



cc @SsnL
Repository: godot
Issue: Project destroyed on system crash
Labels: platform:windows,discussion,topic:editor

Godot 3.1.1.stable
Windows 7
ATI Radeon HD 4870
Intel Core 2 Duo E6400

My system crashed while editing a project, and now my `project.godot`, all my scenes (including an already forgotten tileset.tscn), and one of the scripts, are all like this:
```
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
# repeated many more lines
```

~~The script that was detroyed was a tool script, so it's possible that this was related to it? My system crashes on occasion, but I never had a project destroyed by it. I also rarely use tool scripts, so I'm connecting the two things, though maybe they're not related. That script exported some vars and updated a Sprite2D and a CollisionPolygon2D in real time in the editor.~~

Nevermind that, it still happened more times while no using tool scripts. 

---

EDIT: I didn't lose a lot from this. This happened in a prototype I started just a few hours ago. I only had 6 simple scenes. I just thought I ought to bring it up here, in case this is related to some obscure problem in Godot and there's something that can be done about it.
Repository: pytorch
Issue: Add new interpolation modes to `grid_sample`
Labels: module: nn,triaged,function request,module: interpolation

_Note: This issue is expanded out of https://github.com/pytorch/pytorch/issues/24870 to allow more room for discussion._

## 🚀 Feature

Currently, `torch.nn.functional.grid_sample()` supports two interpolation modes: `bilinear` and `nearest`.

Other interpolation modes that could be added:

- [ ] [`bicubic`](https://en.wikipedia.org/wiki/Bicubic_interpolation): This is already implemented for `torch.nn.functional.interpolate()` [here](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/UpSampleBicubic2d.cpp), so this shouldn't be difficult to adapt for `grid_sample`, which should work in a similar way.
There has been mention of this in the past ([forum/39515](https://discuss.pytorch.org/t/bicubic-grid-sampler/39515), https://github.com/pytorch/vision/issues/514#issuecomment-402718886), but so far no real plan. (Also see discussions regarding its implementation in `interpolate`: #9849, #19703.)

- [ ] `area`: Like `bicubic`, this mode already exists in `torch.nn.functional.interpolate()`. However, it is not as clear how to adapt this to work in `grid_sample` where the sampling points will in general not be a regular grid. This might require some research and definition design, and discussion is ongoing in #21457.

- [ ] [`lanczos`](https://en.wikipedia.org/wiki/Lanczos_resampling): Another option for smoother interpolation. This is currently [implemented](https://github.com/torch/image/blob/5aa18819b6a7b44751f8a858bd232d1c07b67985/generic/image.c#L1894) in [Torch](https://github.com/torch/image/blob/master/doc/paramtransform.md), so a PyTorch implementation could possibly take inspiration from there.
I am personally not particularly familiar with the practical uses of this mode, so we could discuss whether this is a desired feature, or if other interpolation/sampling filters are more in demand.

cc @albanD @mruberry @SsnL @fmassa @ailzhang
Repository: pytorch
Issue: [Distance functions] F.pdist backward CUDA invalid configuration
Labels: module: cuda,triaged,module: distance functions

## 🐛 Bug

After passing the input through a `torch.nn.functional.pdist` function, the gradient *w.r.t.* to the input can not be correctly calculated on a cuda device.

## To Reproduce
```python
import torch
import torch.nn.functional as F

def test(device, dim=1024):
    x = torch.rand(dim, 4, requires_grad=True).to(device)
    y = torch.ones(dim, 1).to(device)
    vdist = F.pdist(x, 2)
    tdist = F.pdist(y, 1)

    vdist = 1/(1+vdist**2)
    loss = F.binary_cross_entropy(vdist, tdist)
    loss.backward()
    print(x.grad.data)
```
Steps to reproduce the behavior:

3. When increasing the tensor size and running
```python
test(torch.device('cuda'), dim=4096)
```
the error message is:
```
Traceback (most recent call last):
  File "test_pdist.py", line 16, in <module>
    test(torch.device('cuda'), 4096)
  File "test_pdist.py", line 12, in test
    loss.backward()
  File "/n/home/user/app/anaconda3/envs/myenv/lib/python3.6/site-packages/torch/tensor.py", line 118, in backward
    torch.autograd.backward(self, gradient, retain_graph, create_graph)
  File "/n/home/user/app/anaconda3/envs/myenv/lib/python3.6/site-packages/torch/autograd/__init__.py", line 93, in backward
    allow_unreachable=True)  # allow_unreachable flag
RuntimeError: CUDA error: invalid configuration argument
```

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

<!-- A clear and concise description of what you expected to happen. -->

## Environment

Please copy and paste the output from our
[environment collection script](https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py)
(or fill out the checklist below manually).

You can get the script and run it with:
```
wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py
```

 - PyTorch Version: **1.2.0**
 - OS (e.g., Linux): **CentOS 7.6.1810 (Core)**
 - How you installed PyTorch (`conda`, `pip`, source): **conda**
 - Build command you used (if compiling from source): N/A
 - Python version: **3.6.7**
 - CUDA/cuDNN version: **V10.0.130**
 - GPU models and configuration: **GeForce GTX 1080**
 - Any other relevant information:

## Additional context

<!-- Add any other context about the problem here. -->

cc @ngimel
Repository: rust
Issue: Resolve unsound interaction between noalias and self-referential data (incl. generators, async fn)
Labels: T-lang,I-unsound,C-bug,A-coroutines,A-async-await,AsyncAwait-Triaged

Self-referential generators violate LLVM's expectations for `noalias` due to the overlapping bounds of the interior references and the `&mut self` argument to the `Generator::resume` function.

Original issue description: async/await is possibly unsound -- I don't consider myself an authority here, so feel free to edit this top post with relevant information.

Current discussion happened in https://github.com/rust-lang/rust/pull/63209
Repository: pytorch
Issue: ctc_loss computes different losses and gradients on batched utterances vs. individual utterances
Labels: module: loss,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->
`ctc_loss` computes different loss values and different gradients when run on a batch of utterances than when it is run on each utterance individually. In batch mode, some of the computed gradients are -inf

## To Reproduce

Steps to reproduce the behavior:

1. Unpack the attached archive, `CTC-bug.zip`
1. `cd CTC-bug`
1. `python bug.py`

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

<!-- A clear and concise description of what you expected to happen. -->
I expect to get the same (or very nearly the same, within reasonable tolerances) loss and gradient values when running on batches of utterances or individual utterances.

## Environment

PyTorch version: 1.2.0
Is debug build: No
CUDA used to build PyTorch: 9.2.148

OS: Red Hat Enterprise Linux Server release 7.4 (Maipo)
GCC version: (GCC) 5.4.0
CMake version: version 2.8.12.2

Python version: 3.7
Is CUDA available: No
CUDA runtime version: 8.0.44
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect

Versions of relevant libraries:
[pip3] numpy==1.12.0
[conda] blas                      1.0                         mkl  
[conda] mkl                       2019.3                      199  
[conda] mkl-service               1.1.2            py37he904b0f_5  
[conda] mkl_fft                   1.0.10           py37ha843d7b_0  
[conda] mkl_random                1.0.2            py37hd81dba3_0  
[conda] pytorch                   1.2.0           py3.7_cuda9.2.148_cudnn7.6.2_0    pytorch
[conda] torchvision               0.4.0                 py37_cu92    pytorch

## Additional context

[CTC-bug.zip](https://github.com/pytorch/pytorch/files/3532271/CTC-bug.zip)

<!-- Add any other context about the problem here. -->
Repository: pytorch
Issue: [FR][jit] torch.jit.script as a class decorator
Labels: oncall: jit,triaged,jit-backlog

If my module is supposed to be scripted, then it is natural to have the script wrapper close to the class definition, similar to scripting a function. Having to call `torch.jit.script` after instance creation is unintuitive, and often breaks abstraction.

So, I think `torch.jit.script` should also work as a class decorator, returning a wrapped module class that always gives the scripted module.

Some trickiness include:
+ need to correctly set `__module__`, `__name__` etc., similar to `functools.wraps`.
+ probably want to have `isinstance` check work.

cc @suo
Repository: pytorch
Issue: [FR] torch.(Generator|random).seed allows specifying the seed value
Labels: triaged,enhancement,module: random

Currently, our `torch.(Generator|random).manual_seed(seed)` seeds the generator to a specific value; `.seed()` seeds it from `std::random_device` or the current time. 

It is a bit inconsistent with other random libs where the usual `.seed(seed=None)` method seeds to specific value if `seed` is specified, and to some random value otherwise. 

Can we merge the two methods into a single `.seed(seed=None)`?
Repository: pytorch
Issue: Generator objects should not always use the same seed
Labels: triaged,module: random

I don't think that this is the intended behavior. This is most of the times what you don't want when you have multiple generators. 

The initial seed doesn't seem to come from the current RNG either. It breaks reproducibility. I suppose it also makes sense to grab from `std::random_device`, `urandom`, current time, or something. But currently it is just fixed.

```py
In [39]: torch.Generator().initial_seed()
Out[39]: 67280421310721

In [40]: torch.Generator().initial_seed()
Out[40]: 67280421310721

In [41]: torch.Generator().initial_seed()
Out[41]: 67280421310721

In [42]: torch.rand(2, 3, 4, generator=torch.Generator())
Out[42]:
tensor([[[0.2673, 0.8725, 0.3353, 0.4030],
         [0.7871, 0.4576, 0.0719, 0.9715],
         [0.7147, 0.4275, 0.0846, 0.4904]],

        [[0.1662, 0.1538, 0.3638, 0.5145],
         [0.7122, 0.8787, 0.8431, 0.9879],
         [0.5595, 0.4359, 0.1276, 0.2768]]])

In [43]: torch.rand(2, 3, 4, generator=torch.Generator())
Out[43]:
tensor([[[0.2673, 0.8725, 0.3353, 0.4030],
         [0.7871, 0.4576, 0.0719, 0.9715],
         [0.7147, 0.4275, 0.0846, 0.4904]],

        [[0.1662, 0.1538, 0.3638, 0.5145],
         [0.7122, 0.8787, 0.8431, 0.9879],
         [0.5595, 0.4359, 0.1276, 0.2768]]])

In [44]: torch.rand(2, 3, 4, generator=torch.Generator())
Out[44]:
tensor([[[0.2673, 0.8725, 0.3353, 0.4030],
         [0.7871, 0.4576, 0.0719, 0.9715],
         [0.7147, 0.4275, 0.0846, 0.4904]],

        [[0.1662, 0.1538, 0.3638, 0.5145],
         [0.7122, 0.8787, 0.8431, 0.9879],
         [0.5595, 0.4359, 0.1276, 0.2768]]])
```

```py
In [53]: torch.Generator().initial_seed()
Out[53]: 67280421310721

In [54]: torch.rand(2, 3, 4)
Out[54]:
tensor([[[0.2384, 0.0965, 0.9460, 0.3316],
         [0.5213, 0.7518, 0.1692, 0.3696],
         [0.6316, 0.8950, 0.2026, 0.6782]],

        [[0.9342, 0.9530, 0.8290, 0.5884],
         [0.4184, 0.0874, 0.5385, 0.2840],
         [0.1021, 0.2164, 0.3872, 0.6371]]])

In [55]:

In [55]: torch.Generator().initial_seed()
Out[55]: 67280421310721
```

Compared to numpy. where each RNG state has a different seed:
```py
In [48]: numpy.random.RandomState().rand()
Out[48]: 0.897157178998516

In [49]: numpy.random.RandomState().rand()
Out[49]: 0.9620486919176156

In [50]: numpy.random.RandomState().rand()
Out[50]: 0.9457612837975016

In [51]: numpy.random.RandomState().rand()
Out[51]: 0.3025858768725779
```

cc @syed-ahmed who probably has comments :)
Repository: flutter
Issue: [video_player] add Linux support
Labels: c: new feature,platform-linux,p: video_player,package,c: proposal,a: desktop,P2,team-linux,triaged-linux

Just tried Flutter 1.7 with video_player 0.10.1+6 on Ubuntu 18.04, but it doesn't seem there is a plugin support.

error message:
```
[ERROR:flutter/lib/ui/ui_dart_state.cc(148)] Unhandled Exception: MissingPluginException(No implementation found for method init on channel flutter.io/videoPlayer)
[        ] #0      MethodChannel.invokeMethod (package:flutter/src/services/platform_channel.dart:314:7)
```