sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: CUDA topk is slow for some input sizes
Labels: module: performance,module: cuda,triaged,module: sorting and selection

Hi,
I was able to reproduce a configuration in which I have what I believe is a GPU synchronization issue :
```python
import torch
from torch.autograd import Variable


def accuracy_2d(output, target, topk=(1,)):
    """
    Computes the precision@k for the specified values of k
    Considers output is : NxCxHxW and target is : NxHxW
    """
    maxk = max(topk)
    total_nelem = target.size(0) * target.size(1) * target.size(2)
    _, pred = output.topk(maxk, 1, True, True)
    correct = target.unsqueeze(1).expand(pred.size())
    correct = pred.eq(correct)

    res = []
    for k in topk:
        correct_k = correct[:, :k].contiguous().view(-1).float().sum(0)
        res.append(correct_k.mul_(100.0 / total_nelem))

    return res


class AverageMeter(object):
    """Computes and stores the average and current value"""
    def __init__(self):
        self.reset()

    def reset(self):
        self.val = 0
        self.avg = 0
        self.sum = 0
        self.count = 0

    def update(self, val, n=1):
        self.val = val
        self.sum += val * n
        self.count += n
        self.avg = self.sum / self.count


top1 = AverageMeter()
top3 = AverageMeter()

target = torch.LongTensor(16, 172, 172).cuda()
target_var = Variable(target)
pred = Variable(torch.FloatTensor(16, 135, 172, 172).cuda())

prec1, prec3 = accuracy_2d(pred.data, target, topk=(1, 3))
top1.update(prec1[0], 16)
top3.update(prec3[0], 16)
```

I noticed that removing the last two lines of code does not produce the expected behaviour, I suggest this is where the synchronization happens. Also, I think this is related to how `.topk` handles large kernels (cf  @soumith).

cc @ngimel @VitalyFedyunin
Repository: react
Issue: Treat value={null} as empty string
Labels: Component: DOM,Type: Discussion

Per @gaearon's request, I'm opening up a new issue based on https://github.com/facebook/react/issues/5013#issuecomment-340898727.

Currently, if you create an input like `<input value={null} onChange={this.handleChange} />`, the null value is a flag for React to treat this as an uncontrolled input, and a console warning is generated. However, this is often a valid condition. For example, when creating a new object (initialized w/ default values from the server then passed to the component as props) in a form that requires address, Address Line 2 is often optional. As such, passing null as value to this controlled component is a very reasonable thing to do.

One can do a workaround, i.e. `<input value={foo || ''} onChange={this.handleChange} />`, but this is an error-prone approach and quite awkward.

Per issue referenced above, the React team has planned on treating null as an empty string, but that hasn't yet occurred. I'd like to propose tackling this problem in the near future.

Please let me know if I can help further.
Repository: go
Issue: encoding/json: JSON tags don't handle empty properties, non-standard characters
Labels: NeedsDecision

#### What did you do?

https://play.golang.org/p/RRB1VFNufW

Trying to unmarshal with tags like this:

```
type Data struct {
	Foo    string `json:"Foo"`
	Empty  string `json:""`
	Quote  string "json:\"\\\""
	Smiley string "json:\"\U0001F610\""
}
```

#### What did you expect to see?

```
{"Foo": "bla", "": "nothing", "\"": "quux", "😐": ":-|"}
{"Foo":"bla","":"nothing","\"":"quux","😐":":-|"}
```

#### What did you see instead?

```
{"Foo": "bla", "": "nothing", "\"": "quux", "😐": ":-|"}
{"Foo":"bla","Empty":"","Quote":"","Smiley":""}
```

#### System details

```
go version go1.9.2 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/schani/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/1h/7ghts1ys53xdk8y1czrjzdmw0000gn/T/go-build770874315=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOROOT/bin/go version: go version go1.9.2 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.9.2
uname -v: Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.12.6
BuildVersion:	16G29
lldb --version: lldb-900.0.50.1
  Swift-4.0
gdb --version: GNU gdb (GDB) 7.12.1
```
Repository: flutter
Issue: flutter_driver finders should allow accessing descendants, first, and last
Labels: c: new feature,framework,t: flutter driver,P3,team-framework,triaged-framework

The [flutter_driver finders](https://docs.flutter.io/flutter/flutter_driver/CommonFinders-class.html) are very limited making it difficult to find a single instance of any repeated widget. If the finders supported descendant, first, and last (as they do in [flutter_test](https://docs.flutter.io/flutter/flutter_test/CommonFinders-class.html)) this would become much easier.

As is, the only way to find one of a set of repeated elements is to assign a predictable unique key to the first element in the list. This often requires some hackery - we usually don't generate lists based on indices - happens in a callback that takes some renderable data type.
Repository: TypeScript
Issue: TS auto import should support configuring whether a star or a qualified import is used.
Labels: Suggestion,Awaiting More Feedback,VS Code Tracked

_From @dbaeumer on October 31, 2017 11:29_

Testing: #37177

- vscode source code opened in VS Code
- open a file that doesn't import `'vs/base/common/types'`
- type isStringArray
- select the entry from code complete list
- the following import is inserted:

```ts
import { isStringArray } from 'vs/base/common/types';
```

However what I want in this case is

```ts
import * as Types from 'vs/base/common/types';
```

and the code should become `Types.isStringArray`

Would be cool if I can control this via a setting.


_Copied from original issue: Microsoft/vscode#37258_
Repository: go
Issue: archive/zip: FileHeader.Extra API is problematic
Labels: NeedsFix

The `FileHeader.Extra` field is used by the `Writer` to write the "extra" field for the local file header and the central-directory file header. This is problematic because the Go implementation assumes that the extra bytes used in the two headers are the same. While is this is often the case, it is not always true.

See http://mdfs.net/Docs/Comp/Archiving/Zip/ExtraField and you will notice that it frequently describes a "Local-header version" and a "Central-header version", where the formats sometimes differ.

The `Reader` does not have this problem because it entirely ignores the local headers.

I haven't thought much about what the right action is moving forward, whether to deprecate this field or add new API. I just want to file this issue, so I remember to address it later.
Repository: TypeScript
Issue: Fix setTimeout/setInterval/setImmediate functions
Labels: Bug,Help Wanted,Domain: lib.d.ts

Fix too lax typings.

**TypeScript Version:**  master

**Expected behavior:**

```ts
declare function setTimeout(handler: (...args: any[]) => void, timeout?: number, ...args: any[]): number;
```

**Actual behavior:**

```ts
declare function setTimeout(handler: (...args: any[]) => void, timeout: number): number;
declare function setTimeout(handler: any, timeout?: any, ...args: any[]): number;
```
Repository: kubernetes
Issue: Support disk io requests and limits
Labels: sig/node,kind/feature,lifecycle/frozen,needs-triage

<!-- This form is for bug reports and feature requests ONLY! 

If you're looking for help check [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) and the [troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/).
-->

**Is this a BUG REPORT or FEATURE REQUEST?**:
/kind feature

Kubernetes should support disk io requests and limits.


/cc @kubernetes/sig-node-feature-requests
Repository: TypeScript
Issue: Error "'this' implicitly has type 'any'" when used .bind()
Labels: Suggestion,Awaiting More Feedback,Domain: JavaScript

```sh
› tsc --version
Version 2.7.0-dev.20171020
```

**Code**

tsconfig.json:
```json
{
    "compilerOptions": {
        "allowJs": true,
        "checkJs": true,
        "noEmit": true,
        "strict": true
    },
    "files": [
        "index.d.ts",
        "index.js"
    ]
}
```

index.js:
```js
/** @type {MyObj} */
const o = {
    foo: function() {
        (function() {
            console.log(this); // <- Unexpected error here.
        }.bind(this))();
    }
};
```

index.d.ts:
```ts
interface MyObj {
    foo(this: { a: number }): void;
}
```

**How it looks in the editor:**

Context of `foo()` is defined:
![1](https://user-images.githubusercontent.com/1322855/32268670-16e5df5c-bf01-11e7-9d74-96ce9f4b9afa.png)

But context passed to the nested function is lost:
![4](https://user-images.githubusercontent.com/1322855/32268937-fb1041b8-bf01-11e7-80b5-2ffce7bcc1d5.png)

**Expected behavior:**

There should not be error, because `this` explicitly specified by `.bind()`.

**Actual behavior:**

```sh
› tsc
index.js(5,25): error TS2683: 'this' implicitly has type 'any' because it does not have a type annotation.
```
Repository: rust
Issue: Lint for undesirable, implicit copies
Labels: A-lints,T-lang,C-tracking-issue,S-tracking-design-concerns

As part of https://github.com/rust-lang/rust/issues/44619, one topic that keeps coming up is that we have to find some way to mitigate the risk of large, implicit copies. Indeed, this risk exists today even without any changes to the language:

```rust
let x = [0; 1024 * 10];
let y = x; // maybe you meant to copy 10K words, but maybe you didn't.
```

In addition to performance hazards, implicit copies can have surprising semantics. For example, there are several iterator types that *would* implement `Copy`, but we were afraid that people would be surprised. Another, clearer example is a type like `Cell<i32>`, which could certainly be copy, but for this interaction:

```rust
let x = Cell::new(22);
let y = x;
x.set(23);
println!("{}", y.get()); // prints 22
```

For a time before 1.0, we briefly considered introducing a new `Pod` trait that acted like `Copy` (memcpy is safe) but without the implicit copy semantics. At the time, @eddyb argued persuasively against this, basically saying (and rightly so) that this is more of a linting concern than anything else -- the implicit copies in the example above, after all, don't lead to any sort of unsoundness, they just may not be the semantics you expected.

Since then, a number of use cases have arisen where having some kind of warning against implicit, unexpected copies would be useful:

- Iterators implementing `Copy`
- Copy/clone closures (closures that are copy can be surprising just as iterators can be)
- `Cell`, ~~`RefCell`, and other types with interior mutability implementing `Copy`~~
- Behavior of `#[derive(PartiallEq)]` and friends with packed structs
- A coercion from `&T` to `T` (i.e., it'd be nice to be able to do `foo(x)` where `foo: fn(u32)` and `x: &u32`)

I will writeup a more specific proposal in the thread below.
Repository: go
Issue: proposal: encoding/json: preserve unknown fields
Labels: Proposal,Proposal-Hold

Yesterday I've implemented https://github.com/golang/go/issues/15314, which allows to optionally fail JSON decoding if an object has a key which cannot be mapped to a field in the destination struct.

In the discussion of that proposal, a few people floated the idea of having a mechanism to collect such keys/values instead of silently ignoring them or failing to parse.

The main use case I can think of is allowing for JSON to be decoded into structs, modified, and serialized back while preserving unknown keys (modulo the order in which they appeared, and potentially "duplicate" keys that are dropped due to uppercase/lowercase collisions, etc.). This behavior is supported by many languages / libraries and other serialization systems such as protocol buffers.

I propose to add this type to the JSON package:

```go
type UnknownFields map[string]interface{}
```

Users of the JSON package can then embed this type in structs for which they'd like to use the feature:

```go
type Data struct {
  json.UnknownFields
  FirstField int
  SecondField string
}
```

On decoding, any object key/value which cannot be mapped to a field in the destination struct would be decoded and stored in UnknownFields. On encoding, any key present UnknownFields would be added to the serialized object.

I can think of a couple edge cases which are tricky, and I propose to resolve them as follows:

##### Nested structs

It's possible for nested structs to also declare UnknownFields. In such cases any UnknownFields in nested structs should be ignored, both when decoding and encoding. Pros: it is consistent with how we already flatten fields, and it's the only way to ensure decoding is unambiguous. Cons: keys that somehow were set to UnknownFields in a child struct would be ignored on encoding.

##### Key collisions

When encoding it's possible that a key in UnknownFields would collide with another field on the struct. In such cases the key in UnknownFields should be ignored. Pros: it is consistent with the behavior in absence of UnknownFields, seems generally less error prone, it cannot happen in a plain decode/edit/encode cycle, it's unambiguous. Cons: it can possibly lead to silently dropping some values.

PS: I'm happy to do the implementation should the proposal or some variation of it be approved.
Repository: go
Issue: image: support LJPEG
Labels: help wanted,NeedsFix

Please consider adding support for Lossless JPEG (SOF3, aka LJPEG). This format is used in medical imaging (DICOM) and RAW files of digital cameras (DNG). An argument for this to be in standard library is that most of the required parts are already in place (JPEG parser, Huffman coding), whereas an external library would need to replicate those private methods.
Repository: kubernetes
Issue: Create guidelines, documentation and tooling about apiextension PKI
Labels: priority/important-soon,kind/documentation,sig/api-machinery,sig/auth,lifecycle/frozen

* how do I deploy extensions securely?
* how do I implement rotation?
* can I use the kubernetes certificates API?
* is there any way to improve automation of this?
Repository: youtube-dl
Issue: YT-DL dont downloading from new page of IPRIMA TV 
Labels: geo-restricted,account-needed

youtube-dl -u ******@seznam.cz --verbose  http://play.iprima.cz/filmy/bitva-o-sevastopol
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-u', u'PRIVATE', u'--verbose', u'-F', u'http://play.iprima.cz/filmy/bitva-o-sevastopol']
Type account password and press [Return]: 
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2017.10.29
[debug] Python version 2.7.13 - Linux-4.9.0-4-amd64-x86_64-with-debian-9.2
[debug] exe versions: avconv 3.2.8-1, avprobe 3.2.8-1, ffmpeg 3.2.8-1, ffprobe 3.2.8-1
[debug] Proxy map: {}
[IPrima] bitva-o-sevastopol: Downloading webpage
[IPrima] p396592: Downloading player
ERROR: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 784, in extract_info
    ie_result = ie.extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 434, in extract
    ie_result = self._real_extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/iprima.py", line 93, in _real_extract
    self._sort_formats(formats)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 1072, in _sort_formats
    raise ExtractorError('No video formats found')
ExtractorError: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Repository: go
Issue: net/http: Transport: add a ConnectionManager interface to separate the connection management from http.Transport
Labels: NeedsInvestigation,FeatureRequest

`http.Transport` gives us a real solid HTTP client functionality and a faithful protocol implementation. The connection pooling/management is also bundled into `http.Transport`. `http.Transport` connection management takes a stance on a few areas. For example,

- it does not limit the number of *active* connections
- it reuses available connections in a LIFO manner

There are real needs and use cases where we need a different behavior there. We may want to limit the number of active connections. We may want to have a different connection pooling policy (e.g. FIFO). But today it is not possible if you use `http.Transport`. The only option is to implement the HTTP client, but we like the protocol implementation that exists in `http.Transport`.

There are several issues filed because of the inability to override or modify the connection management behavior of `http.Transport`:
- #14984
- #6785
- #17775
- #17776

among others.

It would be great if the connection management aspect of `http.Transport` is separated from the protocol aspect of `http.Transport` and becomes pluggable (e.g. a `ConnectionManager` interface). Then we could choose to provide a different connection management implementation and mix it with the protocol support of `http.Transport`.

The `http.Transport` API would add this new optional field:
```go
type Transport struct {
    ...
    // ConnMgr provides the connection management behavior
    // if nil, a default connection manager is used (yet to be named)
    ConnMgr ConnectionManager
}
```
The connection manager should have a fairly simple API while encapsulating the complex behavior in the implementation. An incomplete API might look like:
```go
type ConnectionManager interface {
    Get() (net.Conn, error)
    Put(conn net.Conn)
}
```
It would be a pretty straightforward pool-like API. The only wrinkle might be that it should allow for the possibility that `Get` may be blocking (with a timeout) for certain implementations that want to allow timed waits for obtaining a connection from the connection manager.

It'd be great if the current "connection manager" is available publicly so some implementations can start with the base implementation and configure/customize it or override some methods as needed.
Repository: kubernetes
Issue: All etcd3 watches close after 10m or so
Labels: kind/bug,priority/backlog,sig/scalability,sig/api-machinery,lifecycle/frozen

It appears that we are not properly handling the watch expired error by continuing the watch from the most recent RV seen on a watch.  When compaction occurs watches appear to terminate (the RV we started the watch on no longer exists).  We should be able to restart the watch at the last RV we received on the watch at the storage level and continue.

```
E0607 17:45:11.447234 367 watcher.go:188] watch chan error: etcdserver: mvcc: required revision has been compacted
```
Repository: flutter
Issue: DefaultTextStyle docs are lacking
Labels: framework,d: api docs,a: typography,has reproducible steps,P2,found in release: 3.3,found in release: 3.7,team-framework,triaged-framework

https://api.flutter.dev/flutter/widgets/DefaultTextStyle-class.html

Doesn't say much.  Topics it might explain are things like "when would you use one of these" or "what widgets set one of these for you", etc.

My understanding is MaterialApp sets a crazy default text style, might be useful to note that here (and how you're expected to interact with that default).
Repository: rust
Issue: private_in_public lint triggered for pub associated type computed using non-pub trait
Labels: C-enhancement,A-visibility,T-compiler

I was surprised to get a private_in_public deprecation warning for using a private trait to _compute_ an associated type that's itself pub.

De-macro'd, shortened example of what I was doing:
```rust
#![feature(try_from)]

trait Bar {
    type Inner;
}

pub struct B16(u16);
pub struct B32(u32);

impl Bar for B16 {
    type Inner = u16;
}
impl Bar for B32 {
    type Inner = u32;
}

use std::convert::{TryFrom, TryInto};
impl TryFrom<B32> for B16 {
    type Error = <<B16 as Bar>::Inner as TryFrom<<B32 as Bar>::Inner>>::Error;
//  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
//  warning: private type `<B16 as Bar>::Inner` in public interface (error E0446)
//  (Despite the fact that that actual type is core::num::TryFromIntError)
    fn try_from(x: B32) -> Result<Self, Self::Error> {
       Ok(B16(x.0.try_into()?))
    }
}

fn main() {}
```
Repro: https://play.rust-lang.org/?gist=1f84c630e07ddd54d2bf208aa85ed8bb&version=nightly

I don't understand how that type is part of the public interface, since I can't get to it using TryFrom.

(Do close if this is known and covered by things like https://github.com/rust-lang/rfcs/pull/1671#issuecomment-268422405, but I couldn't find any issues talking about this part at least.)
Repository: flutter
Issue: Make it less confusing to use Cupertino with text under MaterialApp
Labels: framework,f: material design,f: cupertino,a: quality,a: typography,P2,team-design,triaged-design

Avoid user confusing wrt the default error text style from MaterialApp when using Cupertino widgets.
Repository: go
Issue: cmd/cover: inconsistent treatment of comments
Labels: help wanted,NeedsInvestigation,compiler/runtime

Run coverage on the following program using these commands:

```
$ cd $GOROOT/src/test
$ cat test.go
package test

func f() {
        if true {
                println("A")
        }
        // comment
        if true {
                // comment
                if false {
                        println("B")
                }
        } else {
                // comment
                println("D")
        }
}
$ cat test_test.go 
package test

import "testing"

func Test(t *testing.T) { f() }
$ go test -coverprofile=c.out test
ok      test    0.015s  coverage: 66.7% of statements
$ command go tool cover -html=c.out
```

This is the rendered HTML output:

![coverage](https://user-images.githubusercontent.com/8433140/32339357-fac47eaa-bfcd-11e7-9d90-c07be51c153c.png)

Observe that the first comment is grey, not green, even though it was covered. Is this a simple bookkeeping error, or is there a design reason why we shouldn't consider the entire span from `func f() {` up to `if false` as covered, and render it green?

(This is Google internal issue 68650370.)
Repository: rust
Issue: Literate doctests
Labels: T-rustdoc,C-feature-request,A-doctests

This might be RFC-worthy.

What if you could tie several sequential doctests together so that they operate as a single code block, but you can still write narrative comments in between in a literal style? This could cut down on `ignore`/`no_run` code blocks as well as hidden lines at the same time.

### Example

    Here is an example of using mutable variables. First, let's make some bindings.
    
    ```rust
    let a = 1;
    let mut b = 2;
    ```
    
    `a` can't be modified, but `b` can!
    
    ```rust,cont
    // a += 1; // this would be an error!
    b += 1;
    ```

Clicking the run button on either code block would open a playpen with all the code. Syntax up for debate.

cc @QuietMisdreavus