sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [cleanup] Remove port unforwarding logic in flutter attach 
Labels: team,tool,P3,team-tool,triaged-tool

Once https://github.com/flutter/flutter/pull/46006 is merged, the resident runner's `cleanupAtFinish` method takes care of unforwarding the port used for remote debugging.
Repository: pytorch
Issue: `TestDocCoverage.test_torch` error messages could be clearer
Labels: module: docs,triaged

## 🐛 Bug

When someone writes a new torch operator and forgets to add an entry to https://github.com/pytorch/pytorch/blob/master/docs/source/torch.rst, the `test/test_doc_coverage.py` gives the following error:

```
Dec 04 22:30:21 ======================================================================
Dec 04 22:30:21 FAIL: test_torch (__main__.TestDocCoverage)
Dec 04 22:30:21 ----------------------------------------------------------------------
Dec 04 22:30:21 Traceback (most recent call last):
Dec 04 22:30:21   File "test_docs_coverage.py", line 77, in test_torch
Dec 04 22:30:21     don't want to document?''')
Dec 04 22:30:21 AssertionError: 
Dec 04 22:30:21 The lists of functions documented in torch.rst and in python are different.
Dec 04 22:30:21 Did you forget to add a new thing to torch.rst, or whitelist things you
Dec 04 22:30:21 don't want to document?
```

This is not the clearest thing in the world. I see the following two improvements we could make:
1) List out what functions are different.
2) Explicitly state what torch.rst is. Something like "For the documentation of an operator to appear in <insert_link_to_docs>, it needs an entry in torch.rst <link to torch.rst>. Please add one"

We got pretty confused over in https://github.com/pytorch/pytorch/pull/30493 about this.
Repository: pytorch
Issue: Page for `torch.__config__` 404s
Labels: module: docs,triaged

Going to https://pytorch.org/docs/stable/__config__.html or https://pytorch.org/docs/master/__config__.html hits the 404 page

![image](https://user-images.githubusercontent.com/9407960/70189001-f93b0b80-16a6-11ea-8f20-47d058eb2fee.png)

Weirdly it does work fine on a local docs build

![image](https://user-images.githubusercontent.com/9407960/70189029-0952eb00-16a7-11ea-974b-738e6c5c8150.png)
Repository: pytorch
Issue: Natively Declarable Fast-path Functions 
Labels: high priority,module: internals,triaged,module: dispatch

## 🚀 Feature

Fast-path functions such as `numel` are not natively registered to avoid dispatch overhead. Example PR here https://github.com/pytorch/pytorch/pull/27294 removed `numel` and added it in python, potentitally breaking BC for JIT-models that included the op.  In order for this function to be accessible in JIT we would have to duplicate it. 

It would be nice to have these functions declarable natively and shared across JIT / Pytorch eager.
  
Functions which fall under this category:
- `numel`
- `get_device`
- `is_contiguous`
- `storage_offset`
- `ndimension` 
- `dim`
- `is_cuda, is_sparse, is_mkldnn, is_quantized` 

cc @ezyang @gchanan @zou3519 @bhosmer @smessmer @ljk53 @bdhirsh @ailzhang
Repository: pytorch
Issue: Remove Ops bound in Python Layer for Legacy Reasons
Labels: module: internals,triaged,module: pybind

## 🐛 Ops Bound in the Python Layer Introduce Errors Between Python/JIT/C++

Many ops are bound in the python layer for legacy reasons. These ops may not be natively declared, or they might have additional error handling or logic that occurs only in the python layer. The result is silently different semantics between the Python api & C++/JIT, or ops which are only supported in python. Example issues: https://github.com/pytorch/pytorch/issues/17662, https://github.com/pytorch/pytorch/issues/30638.

Most of these ops can be found by searching `THPVariable_{op_name}`. 

List of ops which should be removed, and an explainer.

**natively registered** These ops are exposed to C++, JIT, and python. All functions in native_functions.yaml are natively registered, as well as those in Declarations.cwrap. Some of the functions in native_functions have additional python binding logic that introduces discrepancies between python api and C++/JIT. All of the natively registered ops end up in : **register_aten_ops_{1, 2, 3}.cpp**

**Python Layer** these are functions registered in in files like `python_variable_methods.cpp` that are bound only in python. Find these methods by searching THPVariable_{method_name}

**JIT**- registered by JIT in register_prim_ops.cpp. these are only exposed to the JIT and are usually re-implementations of ops exposed in the python layer.


     - range - error checking in python layer
     - randint - type inference in python layer
     - arange - feature-equivalent, but should be removed from python layer, natively registered
     - nonzero - device guard potentially wrong for non-python invocations, natively registered
     - sparse_coo_tensor - not natively registered nor in JIT
     - get_device - only python
     - _is_view - not in JIT
     - conversion functions: bfloat16, byte, char , bool, long, int, short, half, double, float- not in JIT
     - copy_ - natively registered
     - contiguous - natively registered
     - cpu, cuda -  in JIT, not natively registered
     - _data_ptr - not in JIT nor natively registered
     - item - natively registered
     - new - only python layer
     - new_ones - only python layer
     - new_tensor only python layer
     - nonzero - natively registered
     - requires_grad_ - natively registered and also (incorrectly) registered in JIT
     - size - natively registered
     - stride - natively registered
     - to - also in JIT 
     - type - only in python layer, maybe deprecated api
Repository: youtube-dl
Issue: Motor Trend on Demand
Labels: site-support-request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2019.11.28. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Make sure that all provided video/audio/playlist URLs (if any) are alive and playable in a browser.
- Make sure that site you are requesting is not dedicated to copyright infringement, see https://yt-dl.org/copyright-infringement. youtube-dl does not support such sites. In order for site support request to be accepted all provided example URLs should not violate any copyrights.
- Search the bugtracker for similar site support requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a new site support request
- [x] I've verified that I'm running youtube-dl version **2019.11.28**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that none of provided URLs violate any copyrights
- [x] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs

<!--
Provide all kinds of example URLs support for which should be included. Replace following example URLs by yours.
-->

- Single video: https://www.motortrendondemand.com/detail/the-story-of-ford-vs-ferrari/0_1j1evbz7/
- Single video: https://www.motortrendondemand.com/detail/the-breakdown-tesla-cybertruck-range-batteries-and-towing/0_cxw05fsl/
- Playlist: N/A


## Description

<!--
Provide any additional information.
If work on your issue requires account credentials please provide them or explain how one can obtain them.
-->

This is Motor Trend's premium site but the above videos are free to watch.  You can also join free for 14 days to watch TV shows from their network.  This is not the same as their watch.motortrend.com site for which support is currently broken (same problem that seems to be affecting other Discovery Network channels), and I do not think the Discovery extractor would work on this site even if it were working, but my suspicion is it is completely different from the other site.  In any case the site's URL is not currently recognized.
Repository: flutter
Issue: Trace portable (across embedders) performance metrics.
Labels: customer: fuchsia,engine,c: performance,e: embedder,P2,team-engine,triaged-engine

Originating issue is b/145540780

The tracing mechanism has mainly been used to identify specific pathologies in the engine. Any use of this mechanism for the determination of high level performance considerations has been by relying on not fully accurate but useful approximations. However, these approximations are barely portable across the mobile shells and much less across shells that use different client rendering APIs and interact with system compositors in a highly customized ways (primarily Fuchsia). So I would be highly cautious about making “X performs worse than Y” type generalizations (where X & Y are different embedder implementations on the same platform) by using just intelligence from gathered traces. Such assertions don’t identify specific pathologies we can direct our investigative efforts towards and may be inaccurate to boot. To the casual onlooker, assertions like this may look like statements of fact.

Now that cross embedder performance comparisons are becoming necessary, I suggest we expose portable (across embedders) performance metrics in traces. These would be traces for:
1.  Frame pipeline depth: Affects frame latency.
2.  Frame pipeline depth changes: Affects jank (any change causes jank).
3.  Framework workload times: Affects latency (actually may reduce it as the pipeline depth may be lowered as a result) and jank (causes it if frame intervals are exceeded).
4.  Render workload times: Affects both latency and jank for the similar reasons as framework workload times (except pipeline depths can only go up as a result of work done here).
5.  Time between render thread workload commit and signalling of fences.
6.  Voluntary frame de-scheduling due to frame pipeline back-pressure.
7.  Vsync scheduling overhead.
8.  Platform Vsync interval drifts.
9.  Aggregated input latency.
10. Raster cache population counts (affects device memory).
11. Surface pool population counts (affects device memory).

I can say with confidence that these metrics will be portable across all embedders will lead to more useful comparative analysis between embedders. Sadly these metrics on their own will not be sufficient to answer “Is X more performant than Y?” type questions. But since we are already working our way back from such assertions, I suggest we trace these metrics ASAP.

I say these metrics on their own are not sufficient because they only detail the instrumentation that the engine can gather on its own and trace. Frame generation in the engine is highly pipelined. This is also part of a larger pipeline on the system. Also, there are metrics like CPU usage should be considered that the engine cannot gather on its own but matter a lot.

Hopefully this helps color the conversation on performance comparison via tracing as the discussion so far has primarily centered on (4) and (5) in the list above when they are only one piece of a larger puzzle.
Repository: pytorch
Issue: C++ / JIT Parity for ops in `torch/functional.py` and `torch/tensor.py`
Labels: oncall: jit,triaged,TSUsability,TSRootCause:PyTorchParityGap

## 🚀 Feature  /   🐛 Bug

Ops which are bound in at `torch/functional.py` and `torch/tensor.py` are only exposed to the python api and not JIT / C++. Example issues https://github.com/pytorch/pytorch/issues/20113 and https://github.com/pytorch/pytorch/issues/29340. 

An example PR fix is here: https://github.com/pytorch/pytorch/pull/28918. Another fix may be fixing resolution for JIT so that it tries to compile these functions.

Edit: the stack in https://github.com/pytorch/pytorch/pull/33737 fixed the functions in `torch/functional.py` with an exception or two

Ops bound in `torch/functional.py`: 

    - lu_unpack
    - isinf
    - stft
    - unique
    - unique_consecutive
    - tensordot
    - cdist
    - norm
    - lu

Ops bound in `torch/tensor.py`: 

- norm - 
- register_hook - not currently possible, first class functions
- retain_grad 
- is_shared
- share_memory_
- `__reversed__`
- lu
- stft 
- split 
- unique 
- unique_consecutive 
- refine_names 
- align_to
- unflatten
- rename_
- update_names_
- `__contains__`

Another set of ops not supported is in `torch.nn.init`. The full list can be seen here: https://pytorch.org/docs/master/jit_unsupported.html

cc @gmagogsfm @suo
Repository: pytorch
Issue: Master Task: JIT/C++ Parity With Pytorch Python API
Labels: oncall: jit,triaged

## 🚀 JIT/C++ Parity With Pytorch Python API

There are a number of reasons why pytorch ops might work in python but not in JIT / C++. 

Tracking issues:

- [Ops bound in Python Layer for Legacy Reasons](https://github.com/pytorch/pytorch/issues/30780)
- [Tensor Properties are not natively declarable](https://github.com/pytorch/pytorch/issues/30775)
- [Fast path functions are not natively declarable](https://github.com/pytorch/pytorch/issues/30774)
- [Tensor Options create Schema Mismatch for Ops With dtype, layout, device tuple](https://github.com/pytorch/pytorch/issues/30763)
- [Requires_grad argument is implicitly added to schema of factory functions](https://github.com/pytorch/pytorch/issues/30761)
- [Ops bound in torch/tensor.py and torch/functional.py are python-only](https://github.com/pytorch/pytorch/issues/30786)
- [[jit] Python arg parser / TorchScript incompatibilities](https://github.com/pytorch/pytorch/issues/33887)


cc @suo
Repository: rust
Issue: rustdoc should versionsort types in trait implementations
Labels: T-rustdoc,C-enhancement,A-docs

In reading the [documentation for `std::num::Wrapping`](https://doc.rust-lang.org/std/num/struct.Wrapping.html), I noticed (in the left sidebar) a list of trait implementations for `Wrapping` of various numeric types, which appeared in this order:

- `Wrapping<i128>`
- `Wrapping<i16>`
- `Wrapping<i32>`
- `Wrapping<i64>`
- `Wrapping<i8>`
- `Wrapping<isize>`

This seems to sort numbers as strings, rather than by numeric value.

I would propose that everywhere rustdoc sorts identifiers of any kind, it should always use the versionsort algorithm, which sorts numbers by numeric value rather than as strings.

The commit at https://github.com/rust-lang/rustfmt/pull/3764 contains an implementation of the versionsort comparison algorithm. I would suggest putting that (and its tests) into a common implementation for rustdoc and other future callers like rustfmt.
Repository: pytorch
Issue: Sending sparse tensors over RPC not yet supported
Labels: module: serialization,triaged,module: rpc

## 🐛 Bug

## To Reproduce

Add the following test in `dist_autograd_test.py`

```
    @dist_init
    def test_sparse_tensors(self):
        t1 = torch.rand((3, 3), requires_grad=True).to_sparse()
        t2 = torch.rand((3, 3), requires_grad=True).to_sparse()
        rpc.rpc_sync("worker{}".format(self._next_rank()), torch.add, args=(t1, t2))

```

This fails with the following stack trace (need to catch exceptions in ProcessGroupAgent::enqueueSend to see this):

```
sparse tensors do not have storage (storage at caffe2/aten/src/ATen/SparseTensorImpl.cpp:87)
> frame #0: <unknown function> 
> frame #1: <unknown function> 
> frame #2: std::function<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > ()>::operator()() const
> frame #3: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
> frame #4: at::SparseTensorImpl::storage() const
> frame #5: <unknown function>
> frame #6: torch::jit::Pickler::pushStorageOfTensor(at::Tensor const&) 
> frame #7: torch::jit::Pickler::pushLiteralTensor(c10::IValue const&)
> frame #8: torch::jit::Pickler::pushTensor(c10::IValue const&)
> frame #9: torch::jit::Pickler::pushIValueImpl(c10::IValue const&) 
> frame #10: torch::jit::Pickler::pushIValue(c10::IValue const&)
> frame #11: <unknown function>
> frame #12: <unknown function>
> frame #13: std::function<void (c10::IValue const&)>::operator()(c10::IValue const&) const
> frame #14: torch::jit::Pickler::pushSpecializedList(c10::IValue const&, torch::jit::PicklerClass, std::function<void (c10::IValue const&)> const&)
> frame #15: torch::jit::Pickler::pushIValueImpl(c10::IValue const&)
> frame #16: torch::jit::Pickler::pushIValue(c10::IValue const&)
> frame #17: torch::distributed::rpc::wireSerialize[abi:cxx11](std::vector<char, std::allocator<char> > const&, std::vector<at::Tensor, std::allocator<at::Tensor> > const&)
> frame #18: <unknown function> 
> frame #19: <unknown function>
> frame #20: <unknown function>
> frame #21: <unknown function> 
> frame #22: <unknown function> 
> frame #23: <unknown function>
> frame #24: std::function<void ()>::operator()() const 
> frame #25: c10::ThreadPool::main_loop(unsigned long) 
> frame #26: <unknown function> 
> frame #27: <unknown function> 
> frame #28: <unknown function> 
> frame #29: <unknown function> 
> frame #30: <unknown function> 
> frame #31: <unknown function> 
> frame #32: <unknown function> 
> frame #33: <unknown function> 
> frame #34: clone 
```

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528
Repository: pytorch
Issue: Tensorboard graph failing to nest modules
Labels: oncall: visualization

## 🐛 Bug

See [this discussion](https://discuss.pytorch.org/t/tensorboard-graph-failing-to-nest-modules/62993). Basically tensorboard logging no longer works as expected for me (since version version 1.2 I think, as function `graph` changed a lot at this point). It doesn't nest modules anymore and just puts all leaf parameters directly under the main module. For torchvision's resnet34, it looks like that:
![Screenshot_2019-12-04 TensorBoard(1)](https://user-images.githubusercontent.com/22182892/70224089-f135a700-174c-11ea-836c-a9695ac0b63e.png)

## To Reproduce

Steps to reproduce the behavior:

1. Install pytorch 1.3 with tensorboard 2.0 (though I don't think tensorboard version matters much)
1. `writer = SumarryWriter()`
1. `writer.add_graph(resnet34(), torch.rand(8, 3, 224, 224))`

## Expected behavior

Graph is successfully added and looks like that (obtained from an environment with pytorch 1.1):
![Screenshot_2019-12-05 TensorBoard](https://user-images.githubusercontent.com/22182892/70224165-12969300-174d-11ea-96c6-a46d493dcba9.png)

## Environment

```bash
PyTorch version: 1.3.1
Is debug build: No
CUDA used to build PyTorch: 10.0.130

OS: CentOS Linux 7 (Core)
GCC version: (GCC) 7.3.0
CMake version: Could not collect

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: Tesla P100-PCIE-16GB
GPU 1: Tesla P100-PCIE-16GB

Nvidia driver version: 410.48
cuDNN version: Probably one of the following:
/usr/local/cuda-8.0/targets/x86_64-linux/lib/libcudnn.so.6
/usr/local/cuda-8.0/targets/x86_64-linux/lib/libcudnn.so.7
/usr/local/cuda-9.0/targets/x86_64-linux/lib/libcudnn.so.7

Versions of relevant libraries:
[pip3] numpy==1.16.1
[conda] captum                    0.1.0                         0    pytorch
[conda] cuda100                   1.0                           0    pytorch
[conda] mkl                       2019.4                      243  
[conda] mkl-service               2.3.0            py37he904b0f_0  
[conda] mkl_fft                   1.0.14           py37h516909a_1    conda-forge
[conda] mkl_random                1.1.0            py37hb3f55d8_0    conda-forge
[conda] pytorch                   1.3.1           py3.7_cuda10.0.130_cudnn7.6.3_0    pytorch
[conda] pytorch-lightning         0.5.3.2                  pypi_0    pypi
[conda] torchsummary              1.5.1                    pypi_0    pypi
[conda] torchvision               0.4.2                    pypi_0    pypi
```
Repository: angular
Issue: FormGroup not dirty when a nested FormControl changes from disabled to enabled, or vice versa.
Labels: area: forms,P3

<!--🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅

Oh hi there! 😄

To expedite issue processing please search open and closed issues before submitting a new one.
Existing issues often contain information about workarounds, resolution, or progress updates.

🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅-->


# 🐞 bug report

### Affected Package
@angular/forms

### Is this a regression?
No

### Description
A [FormGroup](https://angular.io/api/forms/FormGroup) is not considered [dirty](https://angular.io/api/forms/AbstractControl#dirty) when a nested [FormControl](https://angular.io/api/forms/FormControl) is changed from disabled to enabled, or vice versa. The [pristine](https://angular.io/api/forms/AbstractControl#pristine), [dirty](https://angular.io/api/forms/AbstractControl#dirty), [touched](https://angular.io/api/forms/AbstractControl#touched), and [untouched](https://angular.io/api/forms/AbstractControl#untouched) properties remain unchanged when a control changes from [enabled](https://angular.io/api/forms/AbstractControl#enable) to [disabled](https://angular.io/api/forms/AbstractControl#disable), or vice versa.

## 🔬 Minimal Reproduction
https://stackblitz.com/edit/formbuilder-6cjren

## 🌍  Your Environment

**Angular Version:**
<pre><code>8.0.0</code></pre>

**Anything else relevant?**
Posted more detail on StackOverflow: https://stackoverflow.com/questions/59184512/get-all-angular-form-controls-that-have-changed-from-enabled-to-disabled-or-vic
Repository: scrcpy
Issue: Put a small "Donate" badge at the top of README.MD
Labels: donation

https://blog.rom1v.com/2018/03/introducing-scrcpy/#comment-65
Repository: rust
Issue: thread_local vs __thread: implementation and docs
Labels: I-slow,T-libs-api,A-docs,A-thread-locals,C-bug

The docs for [localkey say](https://doc.rust-lang.org/std/thread/struct.LocalKey.html):

> This key uses the fastest possible implementation available to it for the target platform. It is instantiated with the thread_local! macro and the primary method is the with method.

This is sort of true, but sort of not at the same time. I'm not sure if this means the docs should be clarified, or if this is an implementation bug.

Consider this, for example: https://godbolt.org/z/WEvrPn

simply accessing a value in TLS is much, much heavier in Rust than in C.
Repository: rust
Issue: Tracking issue for the `convert::FloatToInt` trait
Labels: T-libs-api,B-unstable,C-tracking-issue,A-floating-point,Libs-Tracked,S-tracking-perma-unstable

PR https://github.com/rust-lang/rust/pull/66841 adds this supporting trait for the `{f32,f64}::approx_unchecked_to` method (tracking issue: https://github.com/rust-lang/rust/issues/67058) to the `core::convert` and `std::convert` modules:

```rust
mod private {
    pub trait Sealed {}
}
pub trait FloatToInt<Int>: private::Sealed + Sized {
    #[doc(hidden)]
    unsafe fn approx_unchecked(self) -> Int;
}

// Macro-generated for all combinations of primitive integer
// and primitive floating point types:
impl FloatToInt<$Int> for $Float {…}
```

The name and location (and usage of the sealed-trait pattern) are chosen to allow later adding additional methods with different conversion semantics between those types, as proposed in https://internals.rust-lang.org/t/pre-rfc-add-explicitly-named-numeric-conversion-apis/11395