sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: net: can {Conn,PacketConn}.Close block?
Labels: Documentation,NeedsFix

The documentation for `net.Conn.Close` is:
> Close closes the connection. Any blocked Read or Write operations will be unblocked and return errors.

However, it does not mention anything about whether `Close` itself can block.

Some `net.Conn` implementations have an implicit write buffer. Thus, when `Close` is called, it still needs to flush the buffer before returning. This means that `Close` is effectively an operation that involves IO. Since it involves IO, this means that `Close` may have to wait until the recipient acknowledges the incoming data (which could potentially be forever if the receiver's read buffer is full).

If we extend the documentation for `net.Conn.Close`, would the following be reasonable?
> Close closes the connection. Any blocked Read or Write operations will be unblocked and return errors. Close itself may block while it is flushing any internal write buffers, but must return an error and terminate the connection  when a previously set write deadline is exceeded.

\cc @bradfitz @mikioh
Repository: youtube-dl
Issue: NoneType is not callable in utils.py
Labels: external-bugs

```
Error Type: <type 'exceptions.TypeError'>
    Error Contents: attribute of type 'NoneType' is not callable
    Traceback (most recent call last):
      File "ytdl_test.py", line 588, in <module>
        yt_download()
      File "ytdl_test.py", line 393, in yt_download
        result = ydl.extract_info(url, download=False)
      File "/usr/local/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py", line 694, in extract_info
        ie_result = ie.extract(url)
      File "/usr/local/lib/python2.7/dist-packages/youtube_dl/extractor/common.py", line 357, in extract
        return self._real_extract(url)
      File "/usr/local/lib/python2.7/dist-packages/youtube_dl/extractor/youtube.py", line 1436, in _real_extract
        upload_date = unified_strdate(upload_date)
      File "/usr/local/lib/python2.7/dist-packages/youtube_dl/utils.py", line 1118, in unified_strdate
        upload_date = datetime.datetime.strptime(date_str, expression).strftime('%Y%m%d')
    TypeError: attribute of type 'NoneType' is not callable

```
    
quick fix:

utils.py
---------
```
1116    for expression in date_formats(day_first):
1117        try:
1118            upload_date = datetime.datetime.strptime(date_str, expression).strftime('%Y%m%d')
1119        except ValueError:
1120            pass
1121        except:     # added case for generic exception
1122            pass
```
Repository: TypeScript
Issue: WebWorker and dom lib does not support transfers in the type for postMessage
Labels: Bug,Help Wanted,Domain: lib.d.ts

<!-- BUGS: Please use this template. -->
<!-- QUESTIONS: This is not a general support forum! Ask Qs at http://stackoverflow.com/questions/tagged/typescript -->
<!-- SUGGESTIONS: See https://github.com/Microsoft/TypeScript-wiki/blob/master/Writing-Good-Design-Proposals.md -->

**TypeScript Version:**  2.0.10

**Code**

```ts
// Create a 32MB "file" and fill it.
var uInt8Array = new Uint8Array(1024 * 1024 * 32); // 32MB
for (var i = 0; i < uInt8Array.length; ++i) {
    uInt8Array[i] = i;
}

self.postMessage(uInt8Array.buffer, [uInt8Array.buffer]);

```

**Expected behavior:**

Compiled with `tsc --lib "es6, webworker, scripthost" worker.ts` a JavaScript file should be generated.

**Actual behavior:**

```
[14:04:55] ➜  Desktop tsc --lib "es6, webworker, scripthost" worker.ts
worker.ts(7,1): error TS2346: Supplied parameters do not match any signature of call target.
```

As documented in the [WhatWG Living Standard](https://html.spec.whatwg.org/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface:dom-dedicatedworkerglobalscope-postmessage), postMessage on DedicatedWorkerGlobalScope should accept a list of objects to be transferred rather than cloned, but the current lib.webworker.d.ts defines postMessage with only a single parameter. postMessage on a MessagePort should also accept a list of transfers, which is not the case in either dom.generated.d.ts or in webworker.generated.d.ts. The postMessage in dom on the window object, however, does currently support transfers.
Repository: neovim
Issue: word-wrap ("gq" or "gw") is not idempotent
Labels: bug-vim

- `nvim --version`:
```
NVIM 0.1.7
Build type: None
Compilation: /usr/bin/cc -g -O2 -fdebug-prefix-map=/build/neovim-Rms3o8/neovim-0.1.7=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DDISABLE_LOG -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1  -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -DHAVE_CONFIG_H -D_GNU_SOURCE -I/build/neovim-Rms3o8/neovim-0.1.7/build/config -I/build/neovim-Rms3o8/neovim-0.1.7/src -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/build/neovim-Rms3o8/neovim-0.1.7/build/src/nvim/auto -I/build/neovim-Rms3o8/neovim-0.1.7/build/include
Compiled by pkg-vim-maintainers@lists.alioth.debian.org

Optional features included (+) or not (-): +acl   +iconv    +jemalloc +tui      
For differences from Vim, see :help vim-differences

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

```

- Vim (version: 8.0 with patches 1-95) behaves differently?  No, vim has the same bug.

- Operating system/version: Debian GNU/Linux sid
- Terminal name/version: GNOME Terminal 3.22.1 Using VTE version 0.46.1
- `$TERM`: xterm-256color

Given a file containing the following text (exact amount of whitespace significant, in particular the two spaces before `I'd`):

```
(1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 123456.)  I'd
like to test wrapping
```

Pressing gqap moves the `I'd` to the next line.  Pressing gqap again moves the `I'd` back to the end of the first line, but with a single space between it and the close paren.

Leaving aside what seems like incorrect wrapping (should have two spaces after the `.)`), it seems wrong for word-wrapping to not produce the final result after one word-wrap, and to change again with a second word-wrap.
Repository: TypeScript
Issue: Incorrect type definition for "ErrorEvent" in "lib.es6.d.ts"
Labels: Bug,Help Wanted,Domain: lib.d.ts

**TypeScript Version:**  2.0.10

**Code**

This issue was first mention in Stackoverflow:

http://stackoverflow.com/questions/40935259/how-to-create-an-errorevent-in-typescript/

The question:

> According to this post
> 
> http://stackoverflow.com/questions/26554607/how-to-properly-initialize-en-errorevent-in-javascript
> 
> You should be able to create an `EventError` with this code:
> 
>     var error = new ErrorEvent('oh nose', {
>         error : new Error('AAAHHHH'),
>         message : 'A monkey is throwing bananas at me!',
>         lineno : 402,
>         filename : 'closet.html'
>     });
> 
> However, if you try this in the TypeScript playground:
> 
> [https://www.typescriptlang.org/play/#src=var%20error%20%3D%20new%20ErrorEvent('oh%20nose'%2C%20%7B%0A%20%20%20%20error%20%3A%20new%20Error('AAAHHHH')%2C%0A%20%20%20%20message%20%3A%20'A%20monkey%20is%20throwing%20bananas%20at%20me!'%2C%0A%20%20%20%20lineno%20%3A%20402%2C%0A%20%20%20%20filename%20%3A%20'closet.html'%0A%7D)%3B][1]
> 
> It says `Supplied parameters do not match any signature of call target.`
> 
> Even this simple example does not compile:
> 
>     var error = new ErrorEvent('oh nose');
> 
> I have tried to figure it out by looking at the Type Definition
> 
> https://github.com/Microsoft/TypeScript/blob/master/lib/lib.es6.d.ts#L9612
> 
> But can't figure it out.
> 
> What is missing to create a perfectly legal `EventError` in TypeScript?

The answer:

>*lib.es6.d.ts* is not completely aligned with the [spec](https://www.w3.org/TR/html5/webappapis.html#the-errorevent-interface).
>
>You should log an issue on [TypeScript's github](https://github.com/Microsoft/TypeScript/issues), >but for the time being you can edit *lib.es6.d.ts* to include the fix:
>
>     // add this interface
>     interface ErrorEventInit {
>          // ...put the properties here...
>     }
>    
>     // edit this declare var's new signature
>     declare var ErrorEvent: {
>          new(type: string, eventInitDict?: ErrorEventInit): ErrorEvent;
>          prototype: ErrorEvent;
>     }


  [1]: https://www.typescriptlang.org/play/#src=var%20error%20%3D%20new%20ErrorEvent('oh%20nose'%2C%20%7B%0A%20%20%20%20error%20%3A%20new%20Error('AAAHHHH')%2C%0A%20%20%20%20message%20%3A%20'A%20monkey%20is%20throwing%20bananas%20at%20me!'%2C%0A%20%20%20%20lineno%20%3A%20402%2C%0A%20%20%20%20filename%20%3A%20'closet.html'%0A%7D)%3B

**Expected behavior:**

`lib.es6.d.ts` should be updated

**Actual behavior:**

TSC `Supplied parameters do not match any signature of call target`.
Repository: angular
Issue: Binding on input [type] is broken
Labels: feature,state: blocked,freq2: medium,area: forms,feature: under consideration

**I'm submitting a ...** 
```
[x] bug report => search github for a similar issue or PR before submitting
```

**Current behavior**
Try to bind the `type` attribute of input:

```js
// in Class
inputType="number"

// in html
<input [type]="inputType" formControlName="integerB" />
```
Initially, the value is presented as number when doing `form.value`:

```js
{"integerB": 5}
```
Now, try to change the input's value.

**Its type has changed to string:**

```js
{"integerB": "5"}
```

while it seems the html attributes haven't changed:
```html
// chrome dev console
<input formcontrolname="integerB" ng-reflect-name="integerB" ng-reflect-type="number" type="number" class="ng-valid ng-dirty ng-touched">
```

**Expected behavior**
If we *are* able to bind to [type], the input type should have stayed "number", so does the value.

**Minimal reproduction of the problem with instructions**
http://plnkr.co/edit/kp0xoDbZmJnD5orOTZUj?p=preview

**What is the motivation / use case for changing the behavior?**
I'm dynamiclly generating forms from given JSON, so binding to [type] can save a lot of copy-paste code.

**Please tell us about your environment:**
Not sure this is relevant as it is reproducible in plnkr.

Thanks.

**Edit**: same goes if binding [type] to `inputType="checkbox"`.
**Edit2**: this is also broken in the Dynamic Forms demo if you change "email" type to number (for example)
Repository: TypeScript
Issue: Support @class in JSDoc
Labels: Suggestion,Help Wanted,VS Code Tracked,Domain: JSDoc,Domain: JavaScript,Has Repro

From https://github.com/Microsoft/vscode/issues/15168

For the following JavaScript code:

```js
/**
 * @class
 * 
 * @param {number} x
 */
function Foo(x) {
    this.x = x
}

/**
 * @param {Foo} foo
 */
const request = function(foo) {

}
```

The `@class` jsdoc annotation for `Foo` does not seem to be recognized, so the type of `foo` in `request` is `any`:

![screen shot 2016-12-05 at 3 25 07 pm](https://cloud.githubusercontent.com/assets/12821956/20906854/143c3e9c-baff-11e6-891e-b7a577816fbc.png)

Changing the code to use `class` fixes the issue (you don't actually need the `@class` in this case):

![screen shot 2016-12-05 at 3 26 45 pm](https://cloud.githubusercontent.com/assets/12821956/20906900/560e733a-baff-11e6-86e7-53362db8be7e.png)
Repository: opencv
Issue: VS2017: CMake files are put outside the build directory
Labels: bug,category: build/install

##### System information (version)
- OpenCV => GitHub master from today
- Operating System / Platform => Win 8.1
- Compiler => VS2015-U3
- CMake => 3.7.1

##### Detailed description & Steps to reproduce

If you do an out-of-source build and have the following directory layout:

```
opencv    # sources
build
install
```

You do the usual `cd build` and `cmake-gui ..\opencv`, so "c:/...../build/" is the build dir and you set "c:/...../install/" as `CMAKE_INSTALL_PREFIX`, as well as "c:/...../install/bin" as `EXECUTABLE_OUTPUT_PATH`. Then generate the Visual Studio solution, start compiling. Suddenly a folder appears, completely outside the build directory (this should never happen!) with the following subfolders/content:

```
opencv    # sources
build
install
x64/Release/ZERO_CHECK/ZERO_CHECK.log
```

This issue wasn't there a few months ago, and it really shouldn't happen. CMake has no business writing into that folder.
Repository: opencv
Issue: ORB OpenCL in opencv 3.1-dev is different with opencv3.1 release, and something is wrong there.
Labels: wontfix,category: features2d,platform: ios/osx,category: ocl


<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => 3.1.0-1843-g37cbcf0-dirty
- Operating System / Platform => macos sierra 10.12.1 Darwin 16.1.0 x86_64
- Compiler => clang++  (ver 8.0.0.8000042)

##### Detailed description

<!-- your description -->

compare with opencv 3.1 release version's ORB:
the detected keypoint info has no difference with 3.1, both has same x, y, angle, and size,
but the extracted descriptor is different.
if I compile the latest 3.1.0-dev without opencl support, the extracted descriptor is same with 3.1 version's descriptor.

##### Steps to reproduce
the ORB feature can be test by this: 
https://github.com/BloodAxe/OpenCV-Features-Comparison.
If I use the 3.1.0-dev with opencl support, the orb's precision and recall are very low:
Average Recall
ORB	Brightness change	0.527154
ORB	Gaussian blur	0.333556
ORB	Rotation	0.0643926
ORB	Scaling	0.101222
Average Precision
ORB	Brightness change	0.672338
ORB	Gaussian blur	0.490562
ORB	Rotation	0.0712741
ORB	Scaling	0.174263

If I use the 3.1.0-dev WITHOUT opencl support, the orb's precision and recall are much higher:
Average Recall
ORB	Brightness change	0.622231
ORB	Gaussian blur	0.419333
ORB	Rotation	0.487047
ORB	Scaling	0.393111
Average Precision
ORB	Brightness change	0.802267
ORB	Gaussian blur	0.608733
ORB	Rotation	0.649895
ORB	Scaling	0.63038

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
Repository: youtube-dl
Issue: Site support request for 9jumpin.com.au
Labels: geo-restricted

While trying to download a video, using the latest version of youtube-dl, it says that the url is unsopported. So this is a site support request for the website 9jumpin.com.au

This is a url example:  http://www.9jumpin.com.au/show/today/today-takeaway/2016/december/is-benedict-cumberbatch-headed-for-australia/

From what I was able to make out this website uses brightcove which has in the past usually worked with youtube-dl. I was unable to obtain the direct brightcove url to the video though but usually youtube-dl obtains it iself.

[x] I've **verified** and **I assure** that I'm running youtube-dl **2016.12.01**

```
D:\ytdl>youtube-dl.exe -v http://www.9jumpin.com.au/show/today/today-tak
eaway/2016/december/is-benedict-cumberbatch-headed-for-australia/
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['-v', 'http://www.9jumpin.com.au/show/today/today-ta
keaway/2016/december/is-benedict-cumberbatch-headed-for-australia/']
[debug] Encodings: locale cp1252, fs mbcs, out cp850, pref cp1252
[debug] youtube-dl version 2016.12.01
[debug] Python version 3.4.4 - Windows-7-6.1.7600-SP0
[debug] exe versions: ffmpeg N-73696-g8250943, ffprobe N-73696-g8250943, rtmpdum
p 2.4
[debug] Proxy map: {}
[generic] is-benedict-cumberbatch-headed-for-australia: Requesting header
WARNING: Falling back on generic information extractor.
[generic] is-benedict-cumberbatch-headed-for-australia: Downloading webpage
[generic] is-benedict-cumberbatch-headed-for-australia: Extracting information
ERROR: Unsupported URL: http://www.9jumpin.com.au/show/today/today-takeaway/2016
/december/is-benedict-cumberbatch-headed-for-australia/
Traceback (most recent call last):
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmp6j6yd3lp\build\youtube_dl\YoutubeDL.py", line 694, in extract_info
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmp6j6yd3lp\build\youtube_dl\extractor\common.py", line 357, in extract
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmp6j6yd3lp\build\youtube_dl\extractor\generic.py", line 2433, in _real_extract
youtube_dl.utils.UnsupportedError: Unsupported URL: http://www.9jumpin.com.au/show/today/today-takeaway/2016/december/is-benedict-cumberbatch-headed-for-austral
ia/
<end of log>
```
Repository: opencv
Issue: INSTALL target can't be re-run in VS2017RC
Labels: bug,priority: low,category: build/install

##### System information (version)
- OpenCV => GitHub master from today
- Operating System / Platform => Win 8.1, 64bit, CMake 3.7.1
- Compiler => VS2017RC

##### Detailed description

The `INSTALL` target is somehow broken in VS2017. You can run it once, it installs all files, but then when you run the target again, nothing happens, you just get this build output:

`========== Build: 0 succeeded, 0 failed, 11 up-to-date, 0 skipped ==========`

Even when you delete files in the install directory, or recompile your solution again, you can't make the `INSTALL` target re-run.

To reproduce, just build OpenCV in standard (or minimal) configuration, open with VS2017RC, build, run INSTALL, (optionally delete some files from the install-dir), re-run INSTALL again, it won't do anything.
Repository: kubernetes
Issue: Expose enough information to resolve object references and label selectors generically
Labels: area/app-lifecycle,area/extensibility,sig/api-machinery,lifecycle/frozen

The API has a number of references to other resources that don't specify full details needed to construct API calls (e.g., `secretName`) without specific, detailed knowledge of the API. Clients need to be able to resolve dependencies generically. 

There are a few possible approaches. One could be to augment the OpenAPI spec. Another could be to provide a subresource or alternative representation (#33900) to enumerate fully qualified dependencies.

See also #3676.
Repository: opencv
Issue: YUV/YCbCr conversions only support imagery using the SD colorspace
Labels: feature,category: imgproc

##### System information (version)
- OpenCV => 3.1
- Operating System / Platform => All
- Compiler => All

##### Detailed description

Color conversions in OpenCV between YUV/YCbCr and color models like RGB only use the colorspace coefficients for SD/Rec.601. Therefore if you use imagery in the HD/Rec.709 or UHD/Rec.2020 colorspaces then the conversions will not produce correct colors. 

##### Steps to reproduce

Easy! Do a code-wide search for 601, and in those same files you will not be able to find alternative coefficients for 709 or 2020

Examples:
https://github.com/opencv/opencv/blob/3.1.0/modules/imgproc/src/color.cpp
https://github.com/opencv/opencv/blob/3.1.0/modules/imgproc/src/opencl/cvtcolor.cl
Repository: go
Issue: test: doesn't use GO_GCFLAGS for tests
Labels: help wanted,Builders,NeedsFix

GO_GCFLAGS only affects the compiler that is invoked directly by the `dist` tool (I think).
The compiler invoked by test/run.go doesn't have its command line modified by GO_GCFLAGS.
So all of the tests in test/ aren't actually testing what we think they are testing on the modified builders like noopt and ssacheck.

Maybe this is unfixable as a some of the tests in test/ provide their own flags to the compiler.  But it surprised me that the ssacheck checks weren't actually running on the ssacheck builder in the test directory.

Maybe there's some way to propagate GO_GCFLAGS that makes sense.

See https://go-review.googlesource.com/c/33909/ for a hack I needed to make this work for randomized value order testing.

@bradfitz @cherrymui @dr2chase
Repository: rust
Issue: `rustc -v` should print out linker output
Labels: A-frontend,A-linkage,T-compiler,C-feature-request

If I compile something with `rustc -v`, it doesn't show the linker invocations or anything else:

```
$ echo "fn main() {}" > t.rs
$ rustc -v --crate-type bin t.rs
$ ls -l t
-rwxr-xr-x. 1 jsgf users 2052670 Dec  6 17:15 t
```

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"yanok"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: react
Issue: Undo behavior in controlled textareas works differently from the default behaviour in chrome
Labels: Type: Bug,Component: DOM

If you control a textarea with **value**, it behaves differently when you use undo. When the textarea is controlled, you can only undo one letter at a time. This is not how undo works normally with an uncontrolled component. Undo seems to work as expected with input components.

With a controlled textarea component, you can only undo one letter at a time. The normal undo works with some kind of algorithm for how much is going to be un- or redone.

You can try the difference in this codepen:

https://codepen.io/fabsor/pen/LbmBOv

Tested with React 15.3.1 and Chrome 54 and Chrome Canary. Works as expected in Firefox and Safari. It might be a Chrome bug?
Repository: rust
Issue: Consider different way of inheriting handles in child processes on Windows
Labels: O-windows,T-libs-api,C-feature-request,A-process

Currently to avoid handles being inherited incorrectly by child processes due to race conditions, Rust wraps the whole blob of code in a mutex to synchronize it. However, it will still accidentally inherit any handles created elsewhere that are inheritable, can cause race conditions with people creating processes using libraries other than std, and isn't very efficient.

By switching from `STARTUPINFO` to `STARTUPINFOEX`, we can pass a value for `lpAttributeList` and that attribute list can specify an explicit list of handles to inherit. For more information on this, see https://blogs.msdn.microsoft.com/oldnewthing/20111216-00/?p=8873

Unfortunately this does require vista, so XP users will lose out.
Repository: go
Issue: runtime: frequent blocking syscalls cause high sysmon overhead
Labels: Performance,NeedsInvestigation,compiler/runtime

The hard-coded 20us `sysmon` tick in the runtime appears to be far too aggressive for minority architectures.

Our storage controllers run a single-core 800MHz arm cpu, which runs single-threaded workloads between 10 and 20 times slower than my desktop Intel machine.

![](http://packetpushers.net/wp-content/uploads/2016/10/Igneousnano-serverwebJPG.jpg)

Most of our product-level benchmarks improved substantially (5-10%) when I manually adjusted the minimum tick to 2ms on our arm devices. (Our use-case benefits from particularly long syscall ticks, since we tend to make `read` and `write` syscalls with large buffers, and those can take a long time even if they never actually block in I/O. Also, as you might imagine, the relative cost of thread creation and destruction on this system is quite high.)

Perhaps the runtime should calibrate the sysmon tick based on the performance of a handful of trivial syscalls (`getpid()`, etc). Similarly, the tick could be adjusted upwards if an `m` wakes up within a millisecond (or so) of being kicked off its `p`. Perhaps someone with a better intuition for the runtime can suggest something heuristically less messy.

Thanks,
Phil