sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Language Service: TypeParameter.constraint is lazily calculated, but does not have an accessor function
Labels: Bug,Help Wanted,API

Because of this, I have to go through this awkward motion every time:

``` typescript
function getConstraint( type: ts.TypeParameter ) {
  // This call will cause the typechecker to resolve properties, as well as a bunch of other information
  // about the type (such as generic constraints), but we don't actually need its result right now.
  type.getProperties(); 

  return type.constraint;
}
```

For some members (such as "properties" - above), there is an accessor function, which I can use to be sure the data is up to date. Another category of members don't need an accessor function, because they are calculated eagerly, and so are "always there".

But there is this third category of members, which fall through the gap. One example is `TypeParameter.constraint`. Another is `InterfaceTypeWithDeclaredMembers.declaredProperties`. There are probably more, but I haven't come across them yet.
Repository: go
Issue: net: validate DNSSEC in Go's DNS resolver
Labels: NeedsInvestigation

DNSSEC is being deployed.

We should support it eventually.
Repository: kubernetes
Issue: v2 API proposal "desired vs actual"
Labels: priority/important-soon,area/api,area/app-lifecycle,sig/api-machinery,kind/feature,sig/cli,sig/architecture,lifecycle/frozen,wg/api-expression

This has come up a bunch in a lot of small ways, and my mind keeps coming back to this idea, so I want to write it down.

In early early kube API we had `desired` and `actual` (or something like that) structs.  Since they were the same struct there were a bunch of things in the struct that were things we didn't want users to set (which eventually became status) and other problems.  As we changed to `spec`+`status`, we lost the concept of "actual" and just folded it into `spec`.

This conflates a couple of ideas and makes it hard to distinguish what the user actually asked for from what was assigned to them.  I am proposing we reinstate that distinction.

I propose that every top-level object (all of them, not just the ones that make sense RIGHT NOW) holds 4 fields (plus ObjectMeta):
- `metadata` - same meaning as today
- `spec` - what the user asked for, with API-defined defaults applied AND NOTHING ELSE.  Every field is available to users.
- `actual` - the exact same structure as `spec`, but with other fields populated  by the system (e.g. nodeName when scheduled, clusterIP when auto-assigned, and so on)
- `status` - same meaning as today

If a user wants to save a pod and move it to another cluster, `spec` is what they want.  If a piece of software wants to know how a pod is operating, `actual` and `status` are what they want.

I chose this layout (which changes the meaning of `spec` because I figured it makes it easier on users to change over, while making it harder for system components (change to `actual`).  This may be wrong, but it's not obvious.  An alternative would be that `spec` means "actual" and `request` means "what the user asked for"; users write `request` and the system writes `spec`.  This has the advantage of software that observes state being easier to change over, but means that users have more pain.  But it is perhaps better to break users, who actually SEE error messages.  Sometimes bigger changes are better because the need to something is obvious (see the bugs people hit with some really subtle v1beta1 -> v1 changes).

It would be nice to make one field writable ONLY by users (create/update) and one field writable only by the system.  We've used binding for scheduling, but there are other things (like clusterIP) that are written directly in-process.  

We could make this round-trippable by embedding `request` under `status` in v1 or even as a new top-level object + sub-resources.

Lastly, there's some question about preserving exactly what the user asked for WITHOUT defaults applied, but I am less sure that is needed or particularly useful.

@bgrant0607 @smarterclayton @lavalamp
Repository: tensorflow
Issue: Make TensorFlow compatible with PyPy
Labels: stat:contribution welcome,type:feature

I know it's not a priority and will be a long way to get there; but making TF compatible with PyPy woud be super cool.

Thoughts?
Repository: go
Issue: net: more complete DNS stub resolver tests for uncommon scenarios
Labels: NeedsInvestigation

In working on #12778 I found there is not an easy way to test more uncommon DNS scenarios where tight control of responses and errors is needed.

For the pure Go stub resolver consider restructuring things to make this easier, such as with the ability to swap out real TCP/UDP connections for a stub so tight control is possible while still exercising the bulk of  code.

@mdempsky mentioned considering possibly related restructuring for #13281.
Repository: flutter
Issue: Matrix lerp
Labels: c: new feature,framework,a: animation,P3,team-framework,triaged-framework

If we had a true Matrix lerp(), then we could do things like support Hero animations regardless of how transformed the hero was (instead of now, where the Hero and the Navigator have to be axis-aligned for it to work).
Repository: opencv
Issue: Bug in stitching module when applying composePanorama multiple times
Labels: bug,priority: normal,category: stitching

Attempting to use composePanorama multiple times from the stitching module, yields very strange results. First time composePanorama is used, the resulting panorama is perfect, however the next time composePanorama, from the same stitch object is used, the resulting panorama is very strange.

The code that triggers the bug, can be boiled down to:

``` cpp
Stitcher stitcher = Stitcher::createDefault(try_use_gpu);
Mat pano; stitcher.composePanorama(pano);
Mat pano2; stitcher.composePanorama(imgs, pano2);
```

this blog post describes and illustrates the problem very well: http://www.scriptscoop.net/t/8d0bf668c48b/opencv-stitcher-class-with-overlapping-stationary-cameras.html
Repository: go
Issue: x/term: ReadKey() interface
Labels: NeedsInvestigation

Now that there is x/term (#13104) there should be some user stories.

The story here is that in LXC we have console client and server separated by websocket channel. Client uses os.Stdin to read the input from user. Server interprets what is being sent to it (passes it to pty?) Client most likely uses Read function from https://golang.org/pkg/io/#Reader, for which os.Stdin.Read() returns nothing on Windows.

This interface on Linux is flawed in the first place, because I personally don't understand what it should return on read from os.Stdin if I hit arrow key. What cryptic code it returns/expects on Linux part is a separate mystery to me. 

So perhaps there should be a better interface - synchronous ReadKey() and that will return keys in a sequence, and combinations of keys are also tracked.

And if we catch keys, it is better to returns values that are serializable in some cross-platform formats to avoid dependency on certain import and receive ability to switch packages who provide ReadKey() interface easily. I'd use strings like Ctrl-Q etc.

Hopefully that's clear. And I want to use Ctrl-Q in golang programs and Ctrl-V for my own purposes. And I also don't want Linux terminal to hang if I kill go process somewhere in the middle after go already switched terminal to some non-friendly state for its own purpose.
Repository: vscode
Issue: Provide option to opt out of line ending normalisation for files
Labels: feature-request,editor-textbuffer

Upon saving a file edited with VS Code, it appears to perform line ending normalisation automatically and without user notification of any sort. Because of this, I've found myself bitten by large diffs in Git (I'm aware you can circumvent this using the `-w` flag) where a trivial fix to a single line of source code appears to affect a significant proportion of the file, which makes pull requests and reviews for such changes on GitHub a pain to sift through. Then again, I guess one could argue why a source file with mixed line endings should stay in version control like that anyway!

Visual Studio Community displays a prompt upon opening a file if it has mixed line endings and lets a user decide whether or not to have it fixed.

![](http://i.imgur.com/bp9voln.png)

**Version:** 0.10.1

(By the way, great work on open sourcing VS Code too, thanks!)
Repository: go
Issue: net: TestDialerDualStack fails with "i/o timeout" or "got 5.81849453s; want <= 95ms"
Labels: Testing,OS-OpenBSD,OS-Windows,NeedsInvestigation

TestDialerDualStack is commonly flaking on OpenBSD and Windows, albeit with different error messages:

https://www.google.com/search?q=TestDialerDualStack+openbsd+site%3Abuild.golang.org

```
--- FAIL: TestDialerDualStack (14.78s)
    dial_test.go:633: got 5.81849453s; want <= 95ms
```

https://www.google.com/search?q=TestDialerDualStack+windows+site%3Abuild.golang.org

```
--- FAIL: TestDialerDualStack (5.30s)
    dial_test.go:664: dial tcp 127.0.0.1:2651: i/o timeout
```
Repository: vscode
Issue: Better drag and drop / clipboard integration of files across applications
Labels: help wanted,feature-request,upstream,workbench-os-integration,workbench-dnd,upstream-issue-linked

This includes being able to drag files and folders from VS Code into other applications as well as to being able to copy a file or folder to the native clipboard.

**Specifically:**
* [ ] copy files/folders from VS Code file explorer to clipboard and paste into native OS explorer
* [x] copy files/folders from native OS explorer and paste into VS Code file explorer (https://github.com/microsoft/vscode/issues/130036)
* [ ] support the native file data transfer when doing drag and drop (https://github.com/atom/electron/issues/2853)
* [ ] support 3rd party tools such as WinRAR to open files from an archive (https://github.com/microsoft/vscode/issues/90196)
* [x] drop files to the desktop to copy them there (https://github.com/microsoft/vscode/issues/128975)
Repository: vscode
Issue: [grammars] provide alternative to TextMate grammars
Labels: feature-request,api,languages-basic

TextMate isn't sufficient for many languages.

We have been integrating in to the lower level, in the src/vs/languages directory and using Modes.IState and supports.TokenisationSupport. There needs to be a way of writing an extension that can do this, which at least currently there doesn't seem to be,

Thanks.
Repository: vscode
Issue: Support workspace extensions
Labels: feature-request,plan-item,extensions

It would be interesting for people working on different projects to have a way to : 
1: Set up extensions for the all team to have an uniform configuration
2: Have different extensions on different projects

I think that having a list of extensions in the Workspace configuration could solve this. 
Otherwise i'll just have to write an extension for it :-)
Repository: go
Issue: x/exp/shiny: no API to change a window size
Labels: NeedsInvestigation

it seems there is no way to programmatically change a `screen.Window` size.

currently, a `screen.Window` size can only be changed from outside the program (_e.g._ using the mouse).

I'd propose to extend `screen.Window` as such:

``` go
type Window interface {
  // ...

    // Resize resizes the window.
    Resize(size image.Point)

    // Size returns the size of the window.
    Size() image.Point
}
```
Repository: opencv
Issue: Unexpected result in matchTemplate for TM_CCOEFF_NORMED
Labels: bug,priority: normal,category: imgproc

When the template is flat (all pixels have same value) the result of TM_CCOEFF_NORMED is 0/0 but matchTemplate returns 1.
Looking at [the formula](http://docs.opencv.org/3.0.0/df/dfb/group__imgproc__object.html#ga3a7850640f1fe1f58fe91a2d7583695d), `T` is the template:
`T'(x,y) = T(x,y) - mean(T)`

If T(x,y)=C for each x,y than mean(T)=C and you will have 
`T'(x,y) = C - C = 0` for each x,y

the formula will be:
`R = 0 * I / sqrt(0 * I^2)` that is 0/0 !=1 

This is true even if the Image patch under running template is constant.

In this case matchTemplate should returns undefined even if 0 has more sense

here is [the issue](https://github.com/opencv/opencv/blob/3.1.0/modules/imgproc/src/templmatch.cpp#L931)
here is simple test code:

``` cpp
Mat img,templ;
Scalar C = Scalar::all(64); //some rand number
img = imread("some_image.png");
templ = C + Mat::zeros(10,10,img.type());  // flat template
int result_cols = img.cols - templ.cols + 1;
int result_rows = img.rows - templ.rows + 1;
resultMatching.create(result_rows, result_cols, CV_32FC1);
// TM_CCOEFF returns all 0 as expected
matchTemplate(img, templ, resultMatching, TM_CCOEFF);
// TM_CCOEFF returns all 1 despite of it has sam numerator as TM_CCOEFF
matchTemplate(img, templ, resultMatching, TM_CCOEFF_NORMED);
```
Repository: vscode
Issue: [html] intellisense should be more context aware
Labels: feature-request,html

Currently HTML intellisense will present special attributes that are only related to tags but that's about as smart as it gets. Here are some improvements that could be made:
- Don't suggest attributes that aren't valid on a particular tag (eg. aria widget attributes on a non-widget element)
- Don't suggest tags that are not valid within the parent tag (eg. `<li>` is the only tag valid within `<ol>` and `<ul>`)
Repository: go
Issue: x/mobile: Permissions are needed in AndroidManifest.xml file
Labels: mobile

Many native Golang features are not usable without specifying permissions in AndroidManifest.xml. Suggest to put permissions by the time each package is imported, for example:

add the following permission when package "os"  is imported:
< uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" / >

and add the following permission when package "net" is imported:
< uses-permission android:name="android.permission.INTERNET" / >
Repository: rust
Issue: rustc should warn when a (library) crate's name doesn't match its filename
Labels: A-frontend,T-compiler,C-feature-request

Staring at `libfoo.rlib` while having rustc insist that it can't find crate `foo` is really confusing.

```
$ cat lib.rs 
#![crate_type = "rlib"]

pub fn foo() {}
$ cat main.rs 
extern crate foo;

fn main() { foo::foo(); }
$ rustc lib.rs -o libfoo.rlib
$ rustc -L. main.rs
main.rs:1:1: 1:18 error: can't find crate for `foo` [E0463]
main.rs:1 extern crate foo;
          ^~~~~~~~~~~~~~~~~
error: aborting due to previous error
$ ls
lib.rs  libfoo.rlib  main.rs
$ 
```
Repository: opencv
Issue: program crash in cv::gpu::device::hog::set_up_constants
Labels: bug,priority: normal,affected: 2.4,category: gpu/cuda (contrib)

I'm using hog of the gpu module. I have NVIDA GTX660 and NVIDA GTX550 and my OpenCV version is 2.4.11.
I got an error when I reboot my computer(Centos6.4, Centos 7, Ubuntu14.4) _every time_. The more detail is as follows:
<br/p>
`OpenCV Error: Gpu API call (unknown error) in set_up_constants, file /home/setup/opencv-2.4.11/modules/gpu/src/cuda/hog.cu, line 93
terminate called after throwing an instance of 'terminate called after throwing an instance of 'cv::Exception'  what():  /home/setup/opencv-2.4.11/modules/gpu/src/cuda/hog.cu:93: error: (-217) unknown error in function set_up_constants
`
<br/p>
My temporary solution is reinstall OpenCV by make install. 
But if I make install before starting the program and making it crash, it won't help.
so the "right" steps may be:
        1.     ﻿reboot my computer
        2.     ﻿start my program and get a crash.
        3.     ﻿make install opencv
        4.     ﻿start my program again.
Why does this happen? It makes me crazy!
Repository: three.js
Issue: Allow post effects to request access to depth and normal passes
Labels: Enhancement,Post-processing

Many post effects request specific special passes, normal and depth mostly, to create their effect.  Specifically:

DOF: depth
SSAO: depth, normal
SAO: depth, normal
MB: motion, depth?

While it is possible to set up the creation of a normal and depth pass and then coordinate passing that result into another effect, it quickly becomes hard to manage if you can turn on or off the various effects, you may unnecessarily be computing a depth pass when you do not need it.

One alternative solution would be for each pass to state explicitly what passes it requires, so a DOF pass would state it needs a depth buffer.  And a SAO pass would state that it needs a depth and a normal buffer.

It would then be the renderer's responsibility to create the buffers that the enabled post effects require.  This would simplify creating post effects and it would make it more efficient to use post effects.

Focusing on a request model and encapsulating in the renderer how these buffers are generated would allow us to change how these buffers are generated.  So that on Desktop we could use the WebGL DrawBuffers extension to create them in a single pass, while on mobile we can do multiple passes.

This also integrates well into AA systems where the normal or the depth buffer needs to be preprocessed with the same AA system that the beauty pass used for consistent sake -- this is the case with algorithms such as TAA.

(I would love to implement this but I've got other commitments for the next month.  I am also not sure of the right design, even though I think the above is a good outline of a general direction to go in.)

/ping @benaadams @erichlof  @MasterJames
Repository: opencv
Issue: FlannBasedMatcher throws exception on large inputs
Labels: bug,priority: normal,affected: 3.4,category: t-api

I'm getting the following exception from the call to knnMatch (see code given below):
`opencv/modules/core/src/ocl.cpp:4585: error: (-215) u->origdata == data in function deallocate`

The exception is only thrown when the descriptor sets are very large (i.e. dense features for two images).

The exception is thrown when the scope of FlannBasedMatcher::add is exited (features2d/src/matchers.cpp), I'm guessing during deallocation of `std::vector<UMat> descriptors`, although not sure.

``` C++
#include <opencv2/core.hpp>
#include <opencv2/highgui.hpp>
#include <opencv2/xfeatures2d.hpp>
#include <opencv2/flann.hpp>
#include <opencv2/imgcodecs.hpp>

int main(int argc, char* argv[]){

    cv::Mat im_l = cv::imread("im_left.png");
    cv::Mat im_r = cv::imread("im_right.png");

    cv::Ptr<cv::xfeatures2d::DAISY> daisy = cv::xfeatures2d::DAISY::create(30,6);

    std::vector<cv::KeyPoint> keypoints_l;
    std::vector<cv::KeyPoint> keypoints_r;
    cv::Mat descriptors_l;
    cv::Mat descriptors_r;

    daisy->compute(im_l,descriptors_l);
    daisy->compute(im_r,descriptors_r);


    std::vector<cv::DMatch> good_matches;
    cv::Ptr<cv::flann::KDTreeIndexParams> kdIndParams(new cv::flann::KDTreeIndexParams(5));
    cv::Ptr<cv::flann::SearchParams> searchParams(new cv::flann::SearchParams(50));
    cv::FlannBasedMatcher matcher( kdIndParams, searchParams);

    std::vector<std::vector<cv::DMatch>> matches;
    matcher.knnMatch( //OpenCV exception here
                descriptors_l,
                descriptors_r, matches, 2);
    filter_good_matches(matches,good_matches,0.75);

    return 0;
}
```
Repository: rust
Issue: thread_local macro stability precludes safe async signal handling
Labels: P-low,I-needs-decision,T-lang,C-bug

The `thread_local!` macro accepts arbitrary (non-Sync) objects to be put into thread local storage. It is not hard to construct a case where this causes signal handlers to observe inconsistent state:

``` rust
extern {
    fn signal(num: i32, handler: extern fn(i32)) -> extern fn(i32);
}

use std::cell::{RefCell};

/// First and second value always the same.
thread_local!(static X: RefCell<(usize,usize)> = RefCell::new((0,0)));

extern fn handler(_: i32) {
    X.with(|x| {
        let x = x.borrow();
        println!("{:?}", *x);
    });
}

fn main() {
    unsafe { signal(2, handler); }
    X.with(|x| {
        let mut x = x.borrow_mut();
        x.0 += 1;
        // raise(2)
        x.1 += 1;
    });
}
```

`RefCell` is not signal safe. A mutable borrow will not mark the `RefCell` as being borrowed in this case. This can be simulated as follows:
- Compile with `-O -C lto`
- In gdb, step to the instruction that stores the second value.
- `signal 2`

Expected result: panic/abort/segfault or similar. Actual result: `(1, 0)` is printed.

Fixing RefCell by adding a memory barrier does not fix the problem since there might be many other non-Sync types that were not written with signal handling in mind and that use unsafe constructs. For correctness, TLS would have to be restricted to types that are async safe via a new marker trait. With such a trait, signal handling would be safe by default in all rust code and all signals handlers could call arbitrary rust functions (as long as said functions don't call non-rust code which might not be async safe.)

---

This concerns me because adding a signal handler is a safe operation in lrs and all `#[thread_local]` objects that require mutation are wrapped in a single threaded mutex implementation with interior mutability. And if it is decided that async signal handling is never safe in rust, then `#[thread_local]` might be stabilized and might also start to accept arbitrary objects which would practically force me to create a full compiler fork for the sake of safety. The current implementation in lrs is already unsafe because the single threaded mutex implementation has to be marked `Sync` to be placed in a `#[thread_local]`. For correctness, there would have to be the above mentioned marker trait that restricts what can be put in a `#[thread_local]`.
Repository: opencv
Issue: HoughLine results not ordered when using OpenCL
Labels: priority: normal,feature,category: imgproc,category: t-api

I have been using HoughLine function with UMat parameters on GPU. When I transfer back the results, they are not ordered according to their accumulator values, as advertised in the documentation.

It works well on CPU.

OpenCV version is 3.0.0
Repository: vscode
Issue: Allow to change the font size and font of the workbench
Labels: feature-request,workbench-fonts

At the moment, we can only change the font size / font of the editor. If we want to change the font size, we need to use a roundabout method of "zooming in / out". It would be nice if this could be adjusted through the preferences.
Repository: go
Issue: cmd/internal/obj: implement auto-nosplit for arm64, ppc64
Labels: compiler/runtime

See #11482 and CL 17165. The fix was to add nosplit tags, but the implication is that arm64 and ppc64 do not have the same "auto-nosplit" optimization that the other architectures do for leaf functions with tiny frames. They should.
Repository: TypeScript
Issue: decorators in object literals not working
Labels: Suggestion,Committed,Domain: Decorators

_From @pascalopitz on November 19, 2015 11:43_

I am getting a parsing error for decorators on object literal properties. My jsconfig.json looks like this:

```
{
    "compilerOptions": {
        "target": "ES6",
        "module": "commonjs",
        "experimentalDecorators": true
    }
}
```

This code compiles okay in babel 5.8.12 using the "es7.decorators" extension.
Can I somehow make this work?

![image](https://cloud.githubusercontent.com/assets/271740/11269888/3f0a1f3a-8f0a-11e5-86e8-578b7a24d60d.png)

_Copied from original issue: Microsoft/vscode#201_
Repository: go
Issue: crypto/tls: Disable CBC Ciphers by default
Labels: Security

Per @agl on Twitter, the only way to be safe with Go and TLS if you are worried about Lucky13-style attacks is to disable CBC mode ciphers:

https://twitter.com/agl__/status/669182140244824064

Currently none of the CBC ciphers are marked with `suiteDefaultOff`: https://github.com/golang/go/blob/master/src/crypto/tls/cipher_suites.go#L75-L95

```
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
```

It seems wrong for Go to have insecure defaults for a class of attacks that is becoming more well documented. If there is no willingness to implement countermeasures, shouldn't the vulnerable class of ciphers be disabled by default?