sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: angular
Issue: [feature] Enable/disable event listening on @HostListeners
Labels: feature,area: core,core: event listeners,core: host and host bindings,core: change detection,feature: under consideration

There are cases where `@HostListener` is the ideal API to use, however, for events like `touchmove`, `mousemove` or `scroll` we cannot use them for performance reasons. Far too many and often unnecessary change detections are happening. Additionally, there are many times we don't even need to listen in on `touchmove` events at all, unless a certain criteria happens. 

One example is when an input has focus, we want to know when the user begins to scroll it's parent, however, we don't need every input to listen to every scroll event. The other is for our pull-to-refresh and infinite scroll features, where users may or may not have them enabled. When they're not enabled at all, there's no need to still be listening in on every touchmove/scroll events.

The current work around is for us to manually add and remove touchmove or scroll listeners depending on our criteria. While this works, we need to be very careful about not adding memory leaks, but more importantly we're not using `@HostListener` at all which keeps code nice and clean.

Could a feature be added to enable/disable host listeners from listening to the actual native events? This isn't about not firing off events under a certain criteria, but completely removing native event listeners when they're not needed.

Discussed this with both @IgorMinar and @mhevery, and said this would also be related to work needed for https://github.com/angular/angular/issues/1773
Repository: rust
Issue: doc inclusion (reexport) changes order of impl blocks
Labels: T-rustdoc,C-enhancement

`std::vec::Vec` shows the inherent method `impl` blocks in a different order than `collection::vec::Vec`. The latter follows the order in the source.

Part of #24305
Repository: go
Issue: cmd/link: dead code elimination for side-effect free functions
Labels: NeedsInvestigation,binary-size,compiler/runtime

Currently if we compile a Go program like:

```
package main
type dead int
func newDead() *dead { return new(dead) }
var x = newDead()
func main() {}
```

the linker can't dead code eliminate `x` or `dead`.  This is because the "x = newDead()" initialization is compiled to an implicit init function, which causes the linker to pull in `x` and `newDead`.

(See https://golang.org/cl/20765 for a real world example.)

In general, just because `x` is otherwise unused, the linker can't get rid of the `newDead()` call because it might have side-effects.  However, it should be possible for the compiler to help identify functions that are side-effect free, which could in turn let the linker be more aggressive about dead code elimination.

We would probably also need to tweak how cmd/compile generates package initializer functions for the linker to be able to eliminate individual initializers.
Repository: react
Issue: Form input name='nodeName' breaks onSubmit event handling
Labels: Type: Bug,Component: DOM

It happened that I stumbled on following edge case. If you add `name='nodeName'` attribute to form's _input_, at some point of React event handling (`ChangeEventPlugin.js: shouldUseChangeEvent()`) it will call: `elem.nodeName && elem.nodeName.toLowerCase()`, but coincidentally `nodeName` property refers to _input_ and invocation fails.

Here's a [jsFiddle example](https://jsfiddle.net/tLd7xvwc/)
Repository: youtube-dl
Issue: site support request for www.pornjam.com
Labels: site-support-request,nsfw
Repository: opencv
Issue: Print stack trace with exception
Labels: feature,RFC

CNTK features a nice set of tools for printing [stack traces on thrown exceptions.](https://github.com/Microsoft/CNTK/blob/7c811de9e33d0184fdf340cd79f4f17faacf41cc/Source/Common/Include/ExceptionWithCallStack.h)
It would be rather simple to add something like this to opencv via the cv::redirectError.
We could also have a function like cv::errorPrintsCallstack(bool) which could be used to switch between the default behavior and the more verbose behavior.
This could improve remote debugging such as when running through ssh on a remote machine.

Is this something that the community would be interested in porting into OpenCV, or leave as something for the user to implement if desired?
Repository: opencv
Issue: opencv_perf_objdetect "OCL_Cascade_*" tests fail since commit ad70ab40
Labels: wontfix,category: ocl,category: 3rdparty

When running opencv_perf_objdetect all haarcascade tests fail with the exception below.
This was introduced in commit ad70ab40, if i checkout 1 commit before that the tests run fine.

```
Time compensation is 0
CTEST_FULL_OUTPUT
OpenCV version: 3.1.0-dev
OpenCV VCS version: 3.1.0-315-gecf65a0-dirty
Build type: release
Parallel framework: pthreads
CPU features: mmx sse sse2 sse3
OpenCL Platforms:
    Clover
        iGPU: AMD TAHITI (DRM 2.43.0, LLVM 3.7.1) (OpenCL 1.1 MESA 11.1.2)
Current OpenCL device:
    Type = iGPU
    Name = AMD TAHITI (DRM 2.43.0, LLVM 3.7.1)
    Version = OpenCL 1.1 MESA 11.1.2
    Compute units = 28
    Max work group size = 256
    Local memory size = 32 kB
    Max memory allocation size = 256 MB
    Double support = Yes
    Host unified memory = Yes
    Has AMD Blas = No
    Has AMD Fft = No
    Preferred vector width char = 16
    Preferred vector width short = 8
    Preferred vector width int = 4
    Preferred vector width long = 2
    Preferred vector width float = 4
    Preferred vector width double = 2
[==========] Running 28 tests from 2 test cases.
[----------] Global test environment set-up.


[ RUN      ] OCL_Cascade_Image_MinSize_CascadeClassifier.CascadeClassifier/3
OpenCV Error: Assertion failed (u->origdata == data) in deallocate, file /usr/src/opencv/modules/core/src/ocl.cpp, line 4584
/usr/src/opencv/modules/ts/src/ts_perf.cpp:1721: Failure
Failed
Expected: PerfTestBody() doesn't throw an exception.
  Actual: it throws cv::Exception:
  /usr/src/opencv/modules/core/src/ocl.cpp:4584: error: (-215) u->origdata == data in function deallocate

params    = ("cv/cascadeandhog/cascades/haarcascade_frontalface_alt.xml", "cv/cascadeandhog/images/bttf301.png", 30)
termination reason:  unhandled exception
bytesIn   =     240950
bytesOut  =          0
samples   =         10 of 100
outliers  =          0
frequency = 1000000000
min       =   16528436 = 16.53ms
median    =   16943004 = 16.94ms
gmean     =   16932285 = 16.93ms
gstddev   = 0.02050919 = 2.08ms for 97% dispersion interval
mean      =   16935514 = 16.94ms
stddev    =     351309 = 0.35ms
[  FAILED  ] OCL_Cascade_Image_MinSize_CascadeClassifier.CascadeClassifier/3, where GetParam() = ("cv/cascadeandhog/cascades/haarcascade_frontalface_alt.xml", "cv/cascadeandhog/images/bttf301.png", 30) (236 ms)
```
Repository: go
Issue: x/sys/unix: file type information from dirents inaccessible
Labels: compiler/runtime

golang.org/x/sys/unix.ReadDirent reads a Dirent that includes the filename and the file type. golang.org/x/sys/unix.ParseDirent parses out the filename.

Linux and OSX include the file type in the Dirent. Go should make this information accessible. This info would let programs skip stat'ing files of the wrong type.

It would not be feasible to change ParseDirent to do so because it would require a type signature change.

If we can agree on a plan, I can (try to) make the code change. 

Here's my proposal, but I've never made a change to Go so it may be off-base.

The package unix could offer a func like "ParseDirentFully" that returned a struct or interface that offered all dirent members available. ParseDirent could call ParseDirentFully to return just the name. (The naming could be better, e.g. ParseDirent and ParseNameFromDirent, but that would break existing code) The code in syscall_*.go already casts to the dirent type from the underlying FS, so it could access another member.

(I am using go 1.5.1 on darwin/amd64. I have inspected code on tip and believe this issue still applies)
Repository: neovim
Issue: Unhelpful 'Channel was closed by client'
Labels: provider,ux,channels-rpc

- Neovim version: v0.1.3-355-g6b22a74
- Operating system: ArchLinux x86_64
- Terminal emulator: gnome-terminal
### Actual behaviour

After quitting insert mode for first time in the session I get this error:

```
Error detected while processing function provider#python#Call:
line   18:
Channel was closed by the client
```

Subsequent times exiting insert mode throw a different error:

```
Error detected while processing function provider#python#Call:
line   18:
Invalid channel "1"
```
### Expected behaviour

Exiting insert mode should work just fine, or at least throw a more helpful error if there is an issue. Line 18 where? Not anywhere in my `.vim` directory.
### Steps to reproduce

I haven't been able to reproduce this with a minimal configuration yet.
Repository: go
Issue: cmd/compile: improve escape analysis understanding of tree structures
Labels: compiler/runtime

``` go
package x

type N struct {
    left *N
    t    string
}

func f(n *N) {
    n.t = n.left.t
}
```

``` bash
$ go tool compile -m -m e.go
e.go:8: leaking param content: n
e.go:8:     from n.left (dot of pointer) at e.go:9
e.go:8:     from n.left.t (dot of pointer) at e.go:9
e.go:8:     from n.t (star-dot-equals) at e.go:9
```

I believe that n should not escape here.

This arises in the compiler. It is one of the reasons that typecheck1's np argument escapes. (The new escape analysis explainer is very exciting.) 15% of the allocations in the compiler are `*gc.Node`, almost all of them due to moving `*gc.Node` parameters to the heap for calls to typecheck1. (After `*gc.Node` come `gc.Nodes` at 9%, `gc.Node` at 8.5%, `[]*gc.Node` at 5.5%, and `string` at 5%.)

This strikes me as hard to fix in the general case, but figured it was worth checking.

@dr2chase
Repository: go
Issue: runtime: x_cgo_init determines stacklo incorrectly for some Solaris versions
Labels: compiler/runtime

This is basically a continuation of issue #12210.

As @rsc guessed, Solaris grows the stack as faults happen.  This behavior is described in section 5.3.5, on page 136 of Mauro, J., & McDougall, R. (2001). Solaris internals: Core kernel components:

> The process stack is mapped into the address space with an initial allocation and then grows downward.  The stack, like the heap, grows on demand, but no library grows the stack; instead, a different mechanism triggers this growth.
> 
> Initially, a single page is allocated for the stack, and as the process executes and calls functions, it pushes the program counter, arguments, and local variables onto the stack. When the stack grows larger than one page, the process causes a page fault, and the kernel notices that this is a stack segment page fault and grows the stack segment.

Prior to Solaris 11 (e.g. OpenSolaris and derivatives), when the stack size was set to unlimited, libc_init() (which is responsible for the initialization of the main stack) would set ss_size = 0 and ss_sp = ul_stktop initially and would then update that as stack faults were encountered.

A simple (naive) test program on a pre-Solaris 11 system:

```
#include <ucontext.h>
#include <stdio.h>
#include <sys/resource.h>
#include <inttypes.h>

int main(int argc, char **argv) {
  ucontext_t uc;
  struct rlimit lim;
  stack_t ss;

  getcontext(&uc);
  printf("ss_sp = %p\n", uc.uc_stack.ss_sp);
  printf("ss_size = %" PRId64 "\n", uc.uc_stack.ss_size);

  getrlimit(RLIMIT_STACK, &lim);
  printf("RLIMIT_STACK = %" PRId64 "\n", lim.rlim_cur);
}
```

...produces these results:

```
$ gcc -m64 -o s main.c ; ./s
ss_sp = fffffd7fffdfb000
ss_size = 8192
RLIMIT_STACK = -3
```

There's nothing wrong with the results since posix doesn't require specific behaviors in regards to these values and in fact, getcontext(), et al. are considered obsolete (they were removed from the 2013 version of the posix standard: http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap03.html).

Now, on Solaris 11 and later, the same test program when executed produces different results:

```
ss_sp = ffff800000000000
ss_size = 1098437885952
RLIMIT_STACK = -3
```

As such, for Solaris 11+, the current code in gcc_solaris_amd64.c in `x_cgo_init()` should generally work fine for determining stacklo in the _unlimited_ stack size case.

However, for older releases the correct answer is to actually call getrlimit(RLIMIT_STACK, ...) and calculate the low address using rlim_cur (unless it returns -3, RLIM_INFINITY), in which case it can safely assume 2GB.
Repository: go
Issue: encoding/asn1: When slicing bytes specify capacity or allocate new slice
Labels: Documentation,NeedsInvestigation

`parseField` should use triple slice assignments (`[x:y:z]`) to specify the capacity of slices when dealing with `RawContent` and `RawValue` fields. Defining the capacity of these slices will prevent other fields in a struct that reference the same underlying byte slice from inadvertently being mutated by operations that attempt to expand the slice (i.e. `append`).
1. What version of Go are you using (`go version`)?
   `go1.6`
2. What operating system and processor architecture are you using (`go env`)?
   `Ubuntu 15.10 amd64`
3. What did you do?
   Basic example: https://play.golang.org/p/ibPZYcKNs5

```
package main

import "fmt"
import "encoding/asn1"

type outer struct {
    Raw     asn1.RawContent
    Version int `asn1:"optional,default:1,tag:0"`
    Inner   inner
    Other   asn1.RawValue

}

type inner struct {
    Raw     asn1.RawContent
    Version int `asn1:"optional,default:2,tag:2"`
}

func main() {
    a := outer{Version: 1, Inner: inner{Version:2}, Other: asn1.RawValue{1, 1, false, []byte{10}, []byte{1, 1, 10}}}
    out, _ := asn1.Marshal(a)
    var b outer
    asn1.Unmarshal(out, &b)

    fmt.Println(b.Raw)
    // Since b.Inner.Raw and b.Raw share the shame underlying slice when
    // append extends b.Inner.Raw (since it has no capacity) it is extending
    // into the part of the underlying slice which is referenced by b.Raw and in
    // doing so overwrites a section of that slice
    _ = append((&b).Inner.Raw, []byte{255, 255, 255}...)
    fmt.Println(b.Raw)
}
```
1. What did you expect to see?
   In above example `b.Raw` shouldn't be affected by using `append`
2. What did you see instead?
   The last three bytes of `b.Raw` are overwritten.
Repository: neovim
Issue: double-width character issue in Nerdtree and Netrw
Labels: bug,localization,ui,needs:design,encoding,has:plan

- Neovim version: 0.1.1 and 0.1.3-361-g5730ad9
- Operating system: OS X el capitan
- Terminal emulator: iTerm2.app and Terminal.app
- Shell : zsh and bash
### Actual behaviour

When I use Korean(double-width characters) in filename, (I think) NEOVIM cannot compute correct length of the filename. So NEOVIM draw horizontal bar incorrectly in Nerdtree.
![2016-03-20 5 33 56](https://cloud.githubusercontent.com/assets/4075389/13903516/ff21f34e-eec1-11e5-8a77-0b24c03cd736.png)

However, VIM works in this case.
![2016-03-20 5 31 27](https://cloud.githubusercontent.com/assets/4075389/13903510/d093a810-eec1-11e5-84fd-c5aa0e7c493c.png)

(first image is the NEOVIM case and second image is the VIM case)
### Steps to reproduce
1. make directory and files with double-width characters. I used 안녕, 테스트(means hello, test resp.)
2. In the directory, open NEOVIM and Nerdtree.
Repository: opencv
Issue: Discussion needed - Mat operator == 
Labels: wontfix,RFC

Hi folks,

I'd like to open a discussion regarding a fundamental issue using Matrices in all OpenCV versions all OS.
The Mat class instance is a shared pointer by himself. It overwrite the  == operator to check two matrices are equal comparing the content of 2 matrices and return a matrix.

This cause a lot of problems. You can not put the matrices into a std::list<Mat> slist or QList<Mat> qlist and perform standard list functions like ...
Mat a;
slist.indexOf(a)

Elementwise comparing is neccessary, but OpenCV should not overwrite the == operator and use a method instead like Mat c = a.compare(b)
I suggest to replace the == operator

and in modules/core/include/opencv2/core/mat.hpp

CV_EXPORTS MatExpr operator == (const Mat& a, const Mat& b);
+CV_EXPORTS bool operator == (const Mat& a, const Mat& b);

and in modules/core/src/matop.cpp

-MatExpr operator == (const Mat& a, const Mat& b)
+bool operator == (const Mat& a, const Mat& b)
 {
-    MatExpr e;
-    MatOp_Cmp::makeExpr(e, CV_CMP_EQ, a, b);
-    return e;
-   return a.data == b.data;
  }

I know, the backward compatibility will be broken and some programs has to be adjusted. But the compiler will find the issue quickly and one has to replace it by the function only.

Actually, I use a fork of OpenCV to be suiteable for my work. But I think this will benefit for all developers.

Any comments?

Best Madrich
Repository: TypeScript
Issue: refinement types
Labels: Suggestion,Needs Proposal

This is a further development of the idea of [tag types](https://github.com/Microsoft/TypeScript/issues/4895).

There are situations where being able to encode a certain predicate about a given value using its type is tremendously helpful.

Let's imagine that we have a number. In order to proceed with it we need to assert that it is greater than 0. This assertion doesn't come for free, because it takes some processor time to get evaluated. Since numbers are immutable this assertion only needs to be evaluated once and will hold true from then on without having to be reevaluated. But due to having no way to attach this knowledge to the number value we:
- either need to play safe and reevaluate it every time immediately before using 
- or take our chances trying to trace it through the code from the place where it was asserted keeping the result of the assertion in mind and hoping not to break things during the next refactoring

Being able to attach additional knowledge to the type of a value in form of predicate that is guaranteed to hold true as long as the value doesn't change is what is called **refinement types**.

@ahejlsberg, what are the chances of seeing the refinement types in TypeScript one day?

References: 
- Refinement types: https://en.wikipedia.org/wiki/Refinement_(computing)
- Pre/post conditions, Hoare logic: https://en.wikipedia.org/wiki/Hoare_logic
- Design by contract: https://en.wikipedia.org/wiki/Design_by_contract
Repository: go
Issue: cmd/api: remove contexts slice by parsing `go tool dist list -json` output
Labels: help wanted,NeedsFix

It's discovered in https://golang.org/cl/20935 that cmd/api contains
a copy of supported platforms along with their cgo support status.

We should remove those hardcoded values and use `go tool dist list -json`
instead.
Repository: vscode
Issue: Macro recording
Labels: feature-request,keybindings

It would be nice to be able to record a sequence of inputs and then reproduce it as in Notepad++ or Vim.
Repository: youtube-dl
Issue: [Youtube] HTTP Error 404: Not Found (caused by HTTPError()) on Python 2
Labels: cant-reproduce,external-bugs

``` bash
$ youtube-dl "https://www.youtube.com/watch?v=UdO7_GrRttM" --verbose

[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'https://www.youtube.com/watch?v=UdO7_GrRttM', u'--verbose']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2016.03.18
[debug] Python version 2.7.6 - Linux-3.16.0-60-generic-x86_64-with-Ubuntu-14.04-trusty
[debug] exe versions: avconv 9.18-6, avprobe 9.18-6, rtmpdump 2.4
[debug] Proxy map: {}
[youtube] UdO7_GrRttM: Downloading webpage
ERROR: Unable to download webpage: HTTP Error 404: Not Found (caused by HTTPError()); 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.
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 365, in _request_webpage
    return self._downloader.urlopen(url_or_request)
  File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 1929, in urlopen
    return self._opener.open(req, timeout=self._socket_timeout)
  File "/usr/lib/python2.7/urllib2.py", line 410, in open
    response = meth(req, response)
  File "/usr/lib/python2.7/urllib2.py", line 523, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.7/urllib2.py", line 448, in error
    return self._call_chain(*args)
  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 531, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
```

Anything else I should attach?
Repository: nvm
Issue: Fix startup files (.profile, .bashrc, .bash_profile, etc.)
Labels: installing nvm: profile detection,pull request wanted

Looking through the issues, it looks like there are a lot of people (myself included) that need the startup to be included in `~/.bash_profile` instead of `~/.bashrc`. I know that there's a plethora of startup profile dotfiles, operating systems, and shells to consider when installing a CLI tool like nvm. The number of [related issues already filed](https://github.com/creationix/nvm/labels/installing%3A%20profile%20detection) is strong evidence of the complexity.

After some research, I think the `rvm` project has a good idea. This project updates startup files to run an rvm startup script on login just like `nvm`. [Here's how they do it](https://github.com/rvm/rvm/blob/master/scripts/functions/installer#L1163-L1165):
1. [Compile a list of files where startup commands _may_ exist](https://github.com/rvm/rvm/blob/master/scripts/functions/installer#L1023-L1026).
2. [Pick _preferred_ locations for startup commands](https://github.com/rvm/rvm/blob/master/scripts/functions/installer#L1030-L1032).
3. [Build list of files _already containing_ startup command using list from step 1](https://github.com/rvm/rvm/blob/master/scripts/functions/installer#L1034-L1051) - ignore the `found_rc` (see note below).
4. [Remove startup commands from all files from step 3](https://github.com/rvm/rvm/blob/master/scripts/functions/installer#L1113-L1124).
5. [Add startup commands to all files from step 2](https://github.com/rvm/rvm/blob/master/scripts/functions/installer#L1125-L1148).

Note: The `rvm` installer also does steps 2-5 for files related to `$PATH`, but it doesn't look like that's necessary for `nvm`, so I've omitted those steps.

The result of this process is you may end up with extra dotfiles you never use (like `.mkshrc`), but everything should still work properly. We could print a list of new files at the end of installation so the user can delete ones that aren't relevant if they care.