sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/sys/windows: named pipes support on Windows
Labels: OS-Windows,compiler/runtime

1. What version of Go are you using (`go version`)?
   go version go1.7rc3 windows/amd64
2. What operating system and processor architecture are you using (`go env`)?
   set GOARCH=amd64
   set GOBIN=
   set GOEXE=.exe
   set GOHOSTARCH=amd64
   set GOHOSTOS=windows
   set GOOS=windows
   set GOPATH=d:\developing\go\xxx..\3td;d:\developing\go\meijing\
   set GORACE=
   set GOROOT=d:\tools\go_amd64
   set GOTOOLDIR=d:\tools\go_amd64\pkg\tool\windows_amd64
   set CC=gcc
   set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\xxx\go-build491836642=/tmp/go-build -gno-record-gcc-switches
   set CXX=g++
   set CGO_ENABLED=1

On *nix we have unix sockets - a standard way of doing IPC (interprocess communication).
On windows we can use TCP sockets for doing the IPC, but a natural way of doing so according to this page (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx) is named pipes. Very close analogy to unix sockets. Providing net.NamedPipeConn in the net package sounds like a good idea to me. I need run web app on the pipe.

I find this issues https://github.com/golang/go/issues/3599,  but is closed. It provide a alternative package  “gopkg.in/natefinch/npipe.v2”。 but it is unstable and low performance.  All thread will blocked at syscall.WaitForSingleObject while Use PipeListener on the server.
Repository: flutter
Issue: No good way to determine who is causing my RenderObject to paint (without markNeedsPaint being called)
Labels: c: new feature,framework,a: debugging,P3,team-framework,triaged-framework

```
debugPrintMarkNeedsPaintStacks = true;
```

The above gives a stack trace but it's not helpful in finding the culprit - it's all RenderObjects and RenderProxyBoxes usually.
Repository: flutter
Issue: Stack and other multi-child layout renderers should not call markNeedsPaint if they don't actually change their layout
Labels: framework,c: performance,P3,team-framework,triaged-framework

Example is a Stack with two children, one always changing and the other never changing.  The changing child shouldn't cause the non-changing child to repaint.
Repository: kubernetes
Issue: design and implement kubeconfig v2 api version
Labels: area/kubectl,sig/api-machinery,lifecycle/frozen

The kubeconfig v2 api is intended to address usability issues of the v1 api. Design is in progress but i'm hoping to use this issue aggregate some ideas and problems we would like to address in v2.

v2 kubeconfig should:
- be composable: adding new clusters or auth infos should not require modifying existing files. We should be able to drop new contexts into new files in the .kube directory and have kubectl pick these up.
- context should be configurable by the environment: I should be able to talk to a different cluster or use a different namespace in different terminal tabs.

cc @jlowdermilk @kubernetes/kubectl
Repository: nvm
Issue: Add `prune` support to nvm
Labels: feature requests

I was exploring setting up a machine that would continuously test against different versions of node. Seeing how `nvm` is very easy to use for installing (think nightly `nvm i 6` etc) my next concern was removing older versions of node. A `nvm prune` suggestively should remove all older versions of each major; for instance:

``` bash
$ nvm ls
        v0.12.7
         v6.3.0
->       v6.3.1
default -> 6.3 (-> v6.3.1)
node -> stable (-> v6.3.1) (default)
stable -> 6.3 (-> v6.3.1) (default)
iojs -> N/A (default)
lts/* -> lts/argon (-> N/A)
lts/argon -> v4.4.7 (-> N/A)

$ nvm prune
# Cleaning older versions of node:
# - Uninstalled node v6.3.0
# - did x.y.z
$ nvm ls
        v0.12.7
->       v6.3.1
default -> 6.3 (-> v6.3.1)
node -> stable (-> v6.3.1) (default)
stable -> 6.3 (-> v6.3.1) (default)
iojs -> N/A (default)
lts/* -> lts/argon (-> N/A)
lts/argon -> v4.4.7 (-> N/A)
```

If passed a major (6, 0.12, etc), only clean that major (6.3.0 && 6.3.1 -> 6.3.1)
Repository: java-design-patterns
Issue: Entity component system (ECS) pattern
Labels: epic: pattern,type: feature

Description:
The Entity Component System (ECS) design pattern is a robust architectural pattern used in game development and other performance-critical applications. This pattern provides a flexible and efficient way to manage entities and their behaviors by breaking them down into distinct components. The main elements of the ECS pattern include:

1. **Entity**: A general-purpose object that serves as a container for components. Entities are usually identified by a unique ID and do not contain any logic.
2. **Component**: A modular, reusable piece of data that describes a specific aspect of an entity, such as position, velocity, or health. Components are passive data holders.
3. **System**: Logic that operates on entities with specific components. Systems query entities that possess the necessary components and execute game logic, updating component data as needed.

Implementing the ECS pattern involves defining entities, components, and systems, and establishing a way to manage and process these elements efficiently.

References:
- [Entity Component System - Wikipedia](https://en.wikipedia.org/wiki/Entity_component_system)
- [Java Design Patterns - Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)
- [Entity Component System Is the Coolest Thing I Ever Met](https://artificials.ch/entity-component-system-are-crazy-cool/)

Acceptance Criteria:
1. Create an `Entity` class that uniquely identifies each entity.
2. Develop a variety of `Component` classes that can be associated with entities, such as PositionComponent, VelocityComponent, and HealthComponent.
3. Implement `System` classes that operate on entities with specific components, including methods for querying relevant entities and updating their components.
4. Provide unit tests that validate the correct behavior of entities, components, and systems.
5. Ensure the implementation adheres to the project's coding standards and contribution guidelines.
Repository: TypeScript
Issue: Scope of this is lost when passing a member function to setInterval
Labels: Suggestion,Help Wanted,Domain: lib.d.ts,Good First Issue

TypeScript Version: 1.8.10

When passing a member function to setInterval, the scope of 'this' is lost within the callback, though the structure of the code (given experience of any object orientated language) indicates it shouldn't be.

**Example code**

```
export class SetIntervalTest {
  private someNumber: number = 1;

  trigger() {
      setInterval(this.setIntervalCallback, 400);
  }

  private setIntervalCallback() {
      console.log(this.someNumber);
  }
}  
```

**Expected behavior**
When console.log(this.someNumber); is called, the scope of this is within the scope of the SetIntervalTest interval instance, printing '1'.

**Actual behavior:** 
The scope of this is pulled from global scope, resulting in this.someNumber being 'undefined'.  If that isn't possible, the compiler should indicate the expected behaviour is not what you're going to get.

To fix this i need to change 'setInterval(this.setIntervalCallback, 400);' to 'setInterval(() => this.setIntervalCallback(), 400);' so 'this' is correctly scoped in the callback.
Repository: TypeScript
Issue: This-function parameters must be specified in caller *and* callee, even for methods
Labels: Suggestion,Needs Proposal

This means that only very careful people will benefit from assignability checking (and therefore argument checking at call sites). (Due to contextual typing, code that uses a this-typed library will get improved body checking a lot of the time.)

Specifically, assignability checking only happens when `this` is explicitly declared by both sides. 

Instead, class methods should implicitly have `this: this` unless declared otherwise.

Given the declarations:

``` ts
declare let f: (this: string, x: number) => void;
declare class C {
  m(x: number): void;
  n(this: this, x: number): void;
}
declare let c: C;
```

**Expected behavior:**

``` ts
c.m = f // error, 'this: string' is not assignable to 'this: string'
f = c.m // error, 'this: C' is not assignable to 'this: string'
f = c.n // error, 'this: string' is not assignable to 'this: C'
c.n = f // error, 'this: C' is not assignable to 'this: string'
```

**Actual behavior:** 

``` ts
c.m = f // no error
f = c.m // no error
f = c.n // error, 'this: string' is not assignable to 'this: C'
c.n = f // error, 'this: C' is not assignable to 'this: string'
```
# Comments

The "this parameter" feature was designed this way to balance four concerns:
1. Backward compatibility with un-annotated code.
2. Compiler efficiency.
3. Consistency between class and interface `this`.
4. Quality of error checking.

As you can see, (4) took the biggest hit by requiring annotation on both the source and target of the assignment.
## Backward compatibility

The problem with unannotated code is that we can't tell whether a function is intended to be called with or without `this`. 
### Functions

`--noImplicitThis` helps address this problem by forcing annotation of this parameters for functions.

TODO: Work through some examples.
### Methods

Actually, for methods, we _do_ have a pretty good idea that a method is not supposed to be removed from its class. Even if the class implements an interface, we the class methods should still be able to refer to class-private implementation details.

TODO: Work through some examples.
## Interface consistency

The problem is that interfaces are frequently used to interact with objects instead of the class type itself. But interfaces are used in lots of other contexts as well. That means we can't infer intent with an interface, but if we don't add `this: this` to interface methods, we're left with a bad assignment problem:

``` ts
interface I {
  m(x: number): void;
}
class C implements I {
  y = 12;
  m(x: number) {
    return this.y + x;
  }
}
let c = new C();
f = c.m;
f(); // error, this must of type 'C'
let i: I = c;
f = i.m;
f(); // ok, this is not annotated
```

"Assignment escape hatches" like this exist throughout TypeScript, but adding more is not a good thing.
## Efficiency

Briefly, if every interface has a `this` type, then every interface will be generic, even in non-OO code. This causes the compiler to generate about double the number of types internally, which is slower and uses more memory than today.
Repository: rust
Issue: `self` and `super` behave inconsistently in `use` statements and as module names
Labels: C-enhancement,A-resolve,T-lang

Handling of `self` and `super` in `use` and `mod` statements is inconsistent.  [Playpen](https://is.gd/znBchD):

``` rust
use self;                        // error: `self` imports are only allowed within a { } list [E0429] (expected)
                                 // error: unresolved import `self`. There is no `self` in the crate root [E0432]

mod super {                      // error: expected identifier, found keyword `super`
    type Test = u32;
    mod submodule {
        use super;               // error: a module named `super` has already been imported in this module [E0252]
        use super::{self, Test}; // (^^^ apparently "already" means "on the next line"?)
    }
    use super;                  // (no error for this one?)
}
```

There are probably several (related) issues here.
- Inconsistent handling of keyword status for `self` and `super` as module names:  if we add a `mod self { }` to the above, we get the two "expected identifier, found keyword" errors we'd expect -- and no other output.  It appears that `mod self { }` causes an immediate "aborting due to previous error", while `mod super { }` does not.
- `use super::{self, ...};` doesn't special-case the `self` keyword as a keyword like `use foo::bar::{self, ...};` does.
- `use super;` doesn't special-case the `super` keyword as a keyword.
- `use self;` _does_ do some special-casing so it can produce "error: `self` imports are only allowed within a { } list [E0429]", but it then continues by attempting to resolve `self` as an ident.
Repository: youtube-dl
Issue: Seperate Exception for authentication error in an extractor
Labels: request

## Please follow the guide below
- You will be asked some questions and requested to provide some information, please read them **carefully** and answer honestly
- Put an `x` into all the boxes [ ] relevant to your _issue_ (like that [x])
- Use _Preview_ tab to see how your issue will actually look like

---
### Make sure you are using the _latest_ version: run `youtube-dl --version` and ensure your version is _2016.08.12_. If it's not read [this FAQ entry](https://github.com/rg3/youtube-dl/blob/master/README.md#how-do-i-update-youtube-dl) and update. Issues with outdated version will be rejected.
- [ x] I've **verified** and **I assure** that I'm running youtube-dl **2016.08.12**
### Before submitting an _issue_ make sure you have:
- [x] At least skimmed through [README](https://github.com/rg3/youtube-dl/blob/master/README.md) and **most notably** [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones
### What is the purpose of your _issue_?
- [ ] Bug report (encountered problems with youtube-dl)
- [ ] Site support request (request for adding support for a new site)
- [x] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

---
### The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your _issue_

---

Can we have a seperate exception for authentication errors in extractors so that while using it as a python module we can identify login errors.
Repository: vscode
Issue: Lift `setContext` from a command to proper API
Labels: feature-request,api,context-keys

This would be very useful to activate extension build feature per project type.
would help for [this issue](https://github.com/Microsoft/vscode/issues/9280)
Repository: You-Dont-Know-JS
Issue: ECMAScript editors: JS classes are not fake
Labels: for second edition

> But does that mean JavaScript actually has classes? Plain and simple: No. ... the classes you have in other languages are not like the "classes" you're faking in JS.

At least a couple ECMAScript editors, Brian Terlson and Allen Wirfs-Brock, have implied or explicitly stated that the notion that JS classes are "fake" is incorrect.

Terlson explicitly said as much on reddit:

"it is not at all helpful for beginners to constantly be exposed to the notion that JS classes are "fake". They are not, they have real syntax and real semantics" (https://www.reddit.com/r/javascript/comments/4bmiqj/using_classes_in_javascript_es6_best_practice/d1avktu)

"There is no gold standard for "class". From a developer's perspective, a "class" is an OO encapsulation mechanism that involves creating methods, defining fields, and producing instances and has some sort of inheritance scheme. Making the definition of "class" more constrained than this is not only incorrect but also not a useful distinction to make at all." (https://www.reddit.com/r/javascript/comments/4bmiqj/using_classes_in_javascript_es6_best_practice/d1atm1a)

And Wirfs-Brock implied the same on twitter:

"What word do you use for “an open set of objects that share a common interface and implementation”?" (https://twitter.com/awbjs/status/689506114807857152)

Wirfs-Brock also gave a talk showing how Smalltalk's class model and JavaScript's constructor pattern are "exactly the same, basically." (https://www.youtube.com/watch?v=EPHmm8JiGbg&t=37m28s)

Likewise, Python's and Ruby's class and inheritance models are strikingly similar as well. In both languages, a class is a memory consuming runtime object, and inheritance happens by delegation.

If we were to pick a definition of "class" that accommodates not just Java/C#/C++ but also Smalltalk/Python/Ruby, then it would probably have to be something very much like Wirfs-Brock's tweet: A class is a descriptor for an open set of objects that share a common interface and implementation.

And if we accept that as the definition of class, then we have to acknowledge that JS classes are not fake. JS has real classes just like Smalltalk/Python/Ruby have real classes.
Repository: godot
Issue: "Sync script changes" doesn't work for Visual Scripts
Labels: bug,topic:editor,topic:visualscript

I have "Sync script changes" enabled, but when I change and save the visual script nothing happens...

My project: [HelloTriangle.zip](https://github.com/godotengine/godot/files/416323/HelloTriangle.zip)

Try to enable "Sync script changes" under Debug options and change one of the position values while app is running...

![cpsncv4w8aaem7j](https://cloud.githubusercontent.com/assets/1072168/17640182/9e746e3c-6103-11e6-8082-025d8c078fd0.jpg)
Repository: TypeScript
Issue: 'innerText' should not be nullable in most of Node's derived types
Labels: Bug,Help Wanted,Domain: lib.d.ts

Compile the following with `--strictNullChecks` with the DOM available.

``` ts
const foo = document.createElement("div");
const s: string = foo.textContent;
```

Expected: No error
Actual: `Type 'string | null' is not assignable to type 'string'.`

From https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent:

> - `textContent` returns `null` if the element is a [document](https://developer.mozilla.org/en-US/docs/DOM/document), a document type, or a notation. [...]
> - If the node is a CDATA section, a comment, a processing instruction, or a text node, textContent returns the text inside this node (the [`nodeValue`](https://developer.mozilla.org/en-US/docs/DOM/Node.nodeValue)).
> - For other node types, `textContent` returns the concatenation of the `textContent` attribute value of every child node, excluding comments and processing instruction nodes. This is an empty string if the node has no children.

Proposed fix: `textContent will be defined as nullable in`Node`, but overridden as`string` in most of its descendants.
Repository: kubernetes
Issue: Setting a message when cordoning nodes
Labels: area/kubectl,sig/node,sig/cli,lifecycle/frozen

Hey,
when draining a node or cordon a node I think its important to be able to set a message why this node was cordoned.

e.g (two examples)

kubectl cordon K8S_NODENAME "disabled due to docker maintenance"
kubectl drain K8S_NODENAME --set-message "disabled due to docker maintenance"
Repository: three.js
Issue: Editor: Light targets are not editable.
Labels: Editor

``` json
{
            "uuid": "F7A1537F-0DA9-4FC2-9436-1BCC2A930EDA",
            "type": "SpotLight",
            "castShadow": true,
            "matrix": [1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 215.52757263183594, -383.2663269042969, 587.3773193359375, 1],
            "color": 255,
            "intensity": 2,
            "distance": 1300,
            "angle": 0.3490658503988659,
            "decay": 1,
            "penumbra": 0
        }
```

this is what I get for the spot light. importing it in 3js editor it looks at the origin.
Repository: TypeScript
Issue: Auto-indentation problem with promise blocks
Labels: Bug,Help Wanted,Domain: Formatter,VS Code Tracked

_From @lumaxis on August 12, 2016 0:7_
- VSCode Version: 1.5.0-insider (666ed83a2d465257201cdac215a553ddee3cccbe)
- OS Version: 10.11.6

Steps to Reproduce:
1. Create a Typescript file and start writing code using promises
2. Auto-indent file using ~~Shift+Alt+D~~ Shift+Alt-F

Expected Result:

``` typescript
return output
.then((result: ControllerResponse) => {
  return res
  .status(result.statusCode)
  .json(result.payload);
})
```

Actual Result:

``` typescript
return output
  .then((result: ControllerResponse) => {
    return res
    .status(result.statusCode)
    .json(result.payload);
  })
```

Description:

The problem with the current way is that it leads to a strange indentation on the closing braces:

``` typescript
    });
}
```

Here, the closing curly braces and parentheses for the `.then()` block are indented 4 spaces instead of 2 spaces as they should be.

_Copied from original issue: Microsoft/vscode#10453_
Repository: rust
Issue: [rustbuild] Support `exclude` in config.toml, not just as a flag
Labels: E-easy,T-bootstrap,C-feature-request

debuginfo-gdb tests fail on my system due to gdb not existing/gdb being misconfigured/gdb being not actually gdb/gdb being too new/gdb being too old/gdb outputting stuff to stderr/etc. There should be a way to disable selected collections of tests altogether in rustbuild.

I tried setting debuginfo-tests to false, but it only appears to tweak whether `-g` gets passed to the tests by default.


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"Aditya-PS-05"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: vscode
Issue: Execute functions during snippet expansion
Labels: feature-request,api,snippets

- VSCode Version: 1.4
- OS Version: any

There are several snippets that exist in Visual Studio today that I would like to introduce to the C# extension for VS Code, but require generating dynamic text are executing code to perform other actions during snippet expansion. For example:
- `ctor` -- generate a constructor declaration, automatically filling in the name of the constructor with the enclosing type name.
- `testclass` -- generate a test class and adds references to necessary test assemblies.
- `cw` -- generate `System.Console.WriteLine()` but simplify the type name with the current using directives. So, `System.` is removed if `using System;` is in scope.

From what I can tell, snippets only support text with placeholders today. Is it possible to generate text dynamically or execute commands with arguments during snippet expansion?
Repository: opencv
Issue: When creating a PR containing only doc changes
Labels: feature,category: infrastructure

Wouldn't it make sense to disable the buildbots for the source code if only files from doc folder are edited? This would speed up the build of the docs for verification.