sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Describe function signature using an interface 
Labels: Suggestion,In Discussion

## Search Terms

function implements interface

## Suggestion

Allow functions to indicate interfaces that they implement, allowing usage of a function interface. 

Properties defined on an interface would not be possible unless they are defined as optional 

## Use Cases

When using function overloads, the return type is defined as `any`, this would allow the return type to be guarded and not use `any`. Referencing: https://www.typescriptlang.org/docs/handbook/functions.html#overloads 

It would also allow optional properties to be defined on a function without doing type gymnastics. 

## Examples

```
interface CoolFunction {
  (first: string, second: number): number;
  (first: number, second: string): string;
  property?: boolean;
}

// args will be of type   [string, number] | [number, string]
function coolFunction(...args) implements CoolFunction {
  if (typeof args[0] === "string") {
    // We're now reduced our type of args to [string, number]
    return args[1];
  } else {
    // args can only be [number, string]
    return args[1];
  }
}

// This property is known as it is defined on the interface
coolFunction.property = true;
```

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code 
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: terminal
Issue: Terminal startup location partially off Desktop
Labels: Help Wanted,Issue-Bug,Area-UserInterface,Product-Terminal,Priority-3

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

<!--
This bug tracker is monitored by Windows Terminal development team and other technical folks.

**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.

If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible.

-->

# Environment

```none
Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
 10.0.18362.418
Windows Terminal version (if applicable):
 0.5.2762.0

Any other software?
```

# Steps to reproduce

<!-- A description of how to trigger this bug. -->
1. change "initialRows": 44 in Settings
2. change "defaultProfile": "{c6eaf9f4-32a7-5fdc-b5cf-066e8a4b1e40}" # ubuntu-18.04
3. Start -> Windows Terminal (Preview)
# Expected behavior

<!-- A description of what you're expecting, possibly containing screenshots or reference material. -->
entire Terminal with default profile on screen in its entirety is expected to be seen on Desktop
# Actual behavior

<!-- What's actually happening? -->
Terminal appears to open with 14 lines off the bottom of the Desktop (behind and below the Taskbar). there does not seem to be "initialXpos" nor "initialYpos" in Settings to manually place Terminal in its entirety on the Desktop.
Repository: pytorch
Issue: Be able to build torch.distributed documentation easier
Labels: oncall: distributed,triaged,module: doc infra

## 📚Motivation

It is pretty hard to build pytorch documentation for releases right now. To make the releases easier, it would be great if we could build the documentation easier and on the platforms that devs use the most (linux and mac os). One of the trickier things to build is the torch.distributed documentation.

# Analysis

On Mac, distributed doesn't get built by default. I am not sure how easy it is to build distributed on mac.  However, when it is not built, then the APIs and their respective docstrings aren't exposed: https://github.com/pytorch/pytorch/blob/master/torch/distributed/__init__.py.

One possible solution is to push the `is_available()` into the APIs. For example, something like DistributedDataParallel https://github.com/pytorch/pytorch/blob/4bcedb66702a49c6c7e89f0a35321312bc5efcdb/torch/nn/parallel/distributed.py#L33 has its API and docstring exposed; the existence of the API and docstring don't depend on whether or not distributed was built.

Another possible solution is to make torch.distributed easier to build on mac os. I'm not sure how easy this is right now.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528 @ezyang @zou3519
Repository: rust
Issue: Replace most of rustc_metadata::schema with something based on queries.
Labels: C-cleanup,A-metadata,I-compiletime,T-compiler

Right now (cross-crate) "metadata" is encoded as an ad-hoc heterogeneous tree, described in [`rustc_metadata::schema`](https://github.com/rust-lang/rust/blob/d28a9c38fe14396e86ae274c7847e20ee0f78ca9/src/librustc_metadata/schema.rs), with `Lazy<T>` acting as indirection (as in "pointer to `T`", inside the "metadata" blob) and letting the user choose whether to decode of the `T` value.

There is also a random-access array (called "table" in #59953), which is currently only used for `Entry`.

This cross-crate system predates the on-demand/incremental query system, and we have accumulated a lot of data in the `schema` which is similar (but not always identical) to certain queries, and additional code to present that information through queries.

The disadvantages I see with the current approach are:
* a lot of `schema`/`encoder`/`decoder` boilerplate for everything
  * most of which isn't documented well, perpetuating the ad-hoc-ness
* somewhat inconsistent organization
  * e.g. `predicates` in `Entry` vs `super_predicates` in `TraitData`
* decoding more than is needed, even if mostly `Lazy` pointers 
  * `Entry`'s 15 fields are all decoded to read only 1, most of the time
  * arguably a significant performance issue (although we save some space)
  * #59953 is my attempt at solving this particular aspect

<hr/>

In #59953, the table of `Entry`s is replaced by a table for everything that used to be in an `Entry` field.
For example, the `predicates_of` query would then perform `predicates[i].decode()` instead of `entries[i].decode().predicates.decode()` (*irrelevant details elided*).

This is effectively a trade-off:
* using more space because most of those tables aren't 100% filled
  * @michaelwoerister has some ideas about that in https://github.com/rust-lang/rust/pull/59953#discussion_r331979338
* taking less time because there are less unused details being decoded
  * the query system dictates the granularity here, so matching it helps
  * losing (some) cache locality might limit this win

However, we can go further - #59953 doesn't touch `EntryKind`, which is still a sprawling `enum` with even two levels of `Lazy` indirection in places.

<hr/>

Ultimately, we could have "cross-crate metadata" be one table per query in most cases. This would accentuate the trade-off from #59953 further, but it would also allow simplifying `rustc_metadata` and unifying it further with incremental save&restore.

One of the queries that would benefit most from this is `def_kind`, which could be stored as a fully-populated table of bytes, much more compact and cheaper to decode than `EntryKind` today.
Repository: go
Issue: reflect: SetMapIndex does not permit adding nil values of interface type
Labels: Documentation,NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

I'm executing this on the Go playground (currently at 1.13.1). Sample provided.

### What did you do?
I tried to add an entry to a map of type map[string]interface{} using reflection. The behavior differs depending on if the actual value is an interface or a concrete value. There seem to be no way to actually add a nil value based on an interface type alone.  Example can be executed here: https://play.golang.org/p/yfQo-wyP0B9
```go
package main

import (
	"fmt"
	"reflect"
	"regexp"
)

func addAsHello(y interface{}) {
	m := map[string]interface{}{}

	// Add an entry for `hello` with the value nil value using reflection
	mr := reflect.ValueOf(m)
	mr.SetMapIndex(reflect.ValueOf(`hello`), reflect.ValueOf(y))
	fmt.Println(m)

	// Do the same without reflection
	m[`hello`] = y
	fmt.Println(m)
	fmt.Println()
}

func main() {
	addAsHello(nil)
	addAsHello(fmt.Stringer(nil))
	addAsHello((*regexp.Regexp)(nil))
}
```
### What did you expect to see?
```
map[hello:<nil>]
map[hello:<nil>]

map[hello:<nil>]
map[hello:<nil>]

map[hello:<nil>]
map[hello:<nil>]
```

### What did you see instead?
```
map[]
map[hello:<nil>]

map[]
map[hello:<nil>]

map[hello:<nil>]
map[hello:<nil>]
```
Repository: TypeScript
Issue: type for Function.prototype.bind wrongly preserves fields on a function
Labels: Suggestion,Awaiting More Feedback

When calling `bind` on a function Javascript does not copy the properties across that have been added to that function, however TS treats them as having been copied.

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.7-Beta

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** function bind

**Code**

```ts
const a = () => { }
a.hello = 'hi'

const b = a.bind({})

b.hello.split("") // Uncaught TypeError: Cannot read property 'split' of undefined
```

**Expected behavior:** `hello` field should not be present on `typeof b`.

**Actual behavior:** `hello` is deemed to exist on `typeof b` and the program crashes.

**Playground Link:** http://www.typescriptlang.org/play/?ts=3.7-Beta&ssl=1&ssc=1&pln=7&pc=1#code/MYewdgzgLgBAhjAvDAFASiQPhgbxgXwCg4A6ACwFMAbKkJGAcjIEsHDDRJYAje075mAAmKHPjTtu5arRIQADlWZQUAIlUYA9JpgBVMMDgBXAOZlYAFQCe8igFEATg5AOAXDADCcMGBCwHFHBCMPLOtg5QVowKSlAMMCAAZjBGwhSJghRChEA

**Related Issues:** https://github.com/Microsoft/TypeScript/issues/212 seems to be where this was discussed and finally implemented, although it's not directly related.
Repository: godot
Issue: Xbox 360 Controller not recognized in Firefox (Mac)
Labels: bug,platform:web,topic:input

**Godot version:** 3.1.1

**OS/device including version:** macOS 10.14.6; Firefox 69.0.3

**Issue description:** In Chrome and the Mac build, I'm able to use an Xbox 360 Controller, which presents to the engine as "Xbox 360 Wired Controller." However, this doesn't get recognized in Firefox, perhaps because the name shows up as "45e-28e-Xbox 360 Wired Controller." I'm not sure where that extra string at the beginning is coming from, but it seems like something Godot should maybe anticipate and be able to handle? This might only be an issue on the Mac, maybe something with the 360Controller.kext that most folks use to get it running; I don't have access to my Windows machine at the moment so can't confirm. 

**Steps to reproduce:**
1. Run on a Mac using the [360Controller](https://github.com/360Controller/360Controller/) kernel extension. (As I said, may be the case elsewhere; I just don't want to make overly broad claims.)
2. Load the linked project from below and export to HTML5. 
3. Start a server to run the exported HTML.
4. Load the page in Firefox, making sure the console is visible. 
5. Move a stick or press a button on an attached 360 Controller (since a webpage won't treat it as connected until it's interacted with.)
6. Note the console output: 
```
Joystick 0 connected
name: 45e-28e-Xbox 360 Wired Controller
Device not recognized.
```
7. Run the same project from the editor. 
8. Note the console output:
```
Joystick 0 connected
name: X360 Controller
Recognized joystick
X360 Controller connected
```
9. Load the page in Chrome, with console visible. Interact with the controller.
10. Note the console output:
```
Joystick 0 connected
name:  Default Mapping
Recognized joystick
Default Mapping connected
```

**Minimal reproduction project:**
[sjml/Godot-Firefox-ControllerBug](https://github.com/sjml/Godot-Firefox-ControllerBug)

[Exported web version](https://shaneliesegang.com/tmp/ControllerBug/)
Repository: flutter
Issue: invokeMethod on MockedMethodCallHandler should have an option to invoke the "real" handler and bypass the mock
Labels: a: tests,c: new feature,framework,c: proposal,P3,a: plugins,team-framework,triaged-framework

## Use case
I am mocking platform messages for Firebase. I have the option to setMockMethodCallHandler for the plugin to invoke code for tests to allow users to use sane defaults or provide their own custom responses. However, the internals of the plugin will respond to normal platform channel messages and allocate private types like FirebaseUser._(), trigger _onAuthChanged() callbacks, etc.. 

Because the MockMethodCallHandler is either in effect or not at any point in time, I can call setMockCallHandler(null) on the channel and trigger plugin code, but if that plugin code then sends any messages on the same channel, it will not reach the mocked handler, but instead throw an exception when running "flutter test".

## Proposal
If I could call invokeMethodOnHandler() instead of just invokeMethod(), where the call would be routed to the plugin code, just once, then the very next call would come back to my mocked tests and not require any tight coupling between user code or the test library. Just providing some mock overrides for platform channels would cover all cases.

A good example is triggering all of the onAuthStatusChanged callbacks in FirebaseAuth, but there are probably several other cases where there is more than a single-fire event to a platform channel on a call stack, and it would be preferable to explicitly tell the platform channel to call the registered handler once under test situations.
Repository: flutter
Issue: Provide visual feedback when the app is ready for the Dart Debug Extension
Labels: tool,platform-web,P3,team-web,triaged-web

### Current behavior

When I run a flutter web app using the following command:
```
flutter run -d chrome --no-web-browser-launch
```
The app would load but not render anything until the Dart Debug Extension is clicked.

### Problem
The problem is that the app takes sometime to be ready, and there's no way to know when it's ready (except by looking at the DevTools Network tab). So if the Dart Debug Extension is clicked before the app is ready, this is what happens:

![image](https://user-images.githubusercontent.com/1278212/66078791-8fbc4680-e517-11e9-85ae-462f3e97361f.png)

### Feature request
Show visual feedback when the app is ready to be started by the Dart Debug Extension.
Repository: flutter
Issue: AccessibilityBridge test on iOS
Labels: a: tests,platform-ios,a: accessibility,P2,team-ios,triaged-ios

We should have tests to test if the accessibility bridge builds the iOS accessibility tree correct based on the semantics tree provided by the framework. It would also require a dedicated iOS device that has voice over on to run the test. 

https://github.com/flutter/flutter/issues/42270
Repository: flutter
Issue: Wire up automated code coverage reporting for the engine.
Labels: a: tests,engine,P2,team-engine,triaged-engine

It is possible to generate total test coverage in the engine using `//flutter/build/generate_coverage.py`. However there is no automated reported of these numbers. This must be wired up on CI so engine developers don't have to run the script locally to figure out test coverage impact of their patches.
Repository: terminal
Issue: Tile mode for background image stretch
Labels: Help Wanted,Area-UserInterface,Product-Terminal,Issue-Task,Priority-3

# Description of the new feature/enhancement

I'm trying to use a patterned GIF as a background image, but didn't find an option to tile it. A new option for setting the stretch mode to tile the image would be great. It would be a nice option as images like these simply don't look good under other modes or require extra effort to make them work, such as editing them and tiling them manually.

Here's the GIF I'm trying to use:
![pmttyd](https://user-images.githubusercontent.com/12767988/66777197-891dbf80-ee85-11e9-9c19-63f7bb475656.gif)

# Proposed technical implementation details (optional)

Allow setting the `"backgroundImageStretchMode"` setting in the profiles to something like `"tile"`. This would display the image at its native resolution from the top-left corner, repeating the image across the background until it's entirely covered.
Repository: kubernetes
Issue: kubelet does not honor shortened grace period on already-deleting pod
Labels: kind/bug,priority/backlog,sig/node,lifecycle/frozen,triage/accepted

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!

If the matter is security related, please disclose it privately via https://kubernetes.io/security/
-->


**What happened**:

Delete a pod with a grace period of 120 seconds, then again with 60 seconds. It will still wait until the first 120 time elapses to delete the pod.

**What you expected to happen**:

For it to use the new grace period of 60 seconds

**How to reproduce it (as minimally and precisely as possible)**:

```
ben@shadowfax:~$ kubectl get pod -o yaml | egrep -i 'term|del'
      blockOwnerDeletion: true
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
    terminationGracePeriodSeconds: 900

ben@shadowfax:~$ kubectl delete pod $(kubectl get pods | grep python | grep Running | cut -f1 -d' ') --grace-period=60
pod "python-645896764c-f5p9k" deleted

ben@shadowfax:~$ kubectl get pod -o yaml | egrep -i 'term|del'
      blockOwnerDeletion: true
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
    terminationGracePeriodSeconds: 900
    deletionGracePeriodSeconds: 60
    deletionTimestamp: "2019-10-02T16:27:50Z"
      blockOwnerDeletion: true
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
    terminationGracePeriodSeconds: 900

ben@shadowfax:~$ kubectl delete pod $(kubectl get pods | grep python | grep Running | cut -f1 -d' ') --grace-period=10
pod "python-645896764c-cfsjz" deleted

ben@shadowfax:~$ kubectl get pod -o yaml | egrep -i 'term|del'
      blockOwnerDeletion: true
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
    terminationGracePeriodSeconds: 900
    deletionGracePeriodSeconds: 10
    deletionTimestamp: "2019-10-02T16:27:15Z"
      blockOwnerDeletion: true
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
    terminationGracePeriodSeconds: 900
    deletionGracePeriodSeconds: 60
    deletionTimestamp: "2019-10-02T16:27:50Z"
      blockOwnerDeletion: true
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
    terminationGracePeriodSeconds: 900
```

**Environment**:
- Kubernetes version (use `kubectl version`): 1.14
- Cloud provider or hardware configuration: Rancher/RKE/Hyperkube
- OS (e.g: `cat /etc/os-release`): Ubuntu 18.04
- Install tools: RKE/Rancher
Repository: pytorch
Issue: `num_batches_tracked` update in `_BatchNorm` forward should be a single scalar update on host regardless of the residence of the layer
Labels: module: performance,module: nn,module: cuda,triaged,enhancement

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->

`num_batches_tracked` is single scalar that increments by 1 every time `forward` is called on the `_BatchNorm` layer with both `training` & `track_running_states` set to true. Our current implementation stores it as a single-element buffer that resides on the same device as with the rest of its parameters/buffers.

We request the update & storage of `num_batches_tracked` to be moved to host, despite the residence of the rest of parameters/buffers.

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

When we have a BN layer on accelerators (GPUs), every forward call that updates `num_batches_tracked` triggers a single-element kernel launch, introducing unnecessary host overhead which could hurt our end-2-end perf in cpu bounded workload.

My last attempt to move `num_batches_tracked` to the host from the device gives 0%~11% performance gain across some common problem sizes. #26550

## Pitch

<!-- A clear and concise description of what you want to happen. -->
We need a way that `num_batches_tracked` would resides on device and be backward compatible for save/load modules. This involves relaxing some checks in python tests, which assumes that all values in `state_dict` are buffers/parameters passed by reference.

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

My implementation #26550 does not give full backward compatibility (failing tests and not loading `num_batches_tracked` by reference) and I don't know how to do that easily without a big hammer (rewriting `__setattr__` in `_BatchNorm` inherited from `nn.Module`).
But it does support save/load module, as well as allow assignment using tensor/scalar.
Repository: pytorch
Issue: Specifying `pos_weight` in F.binary_cross_entropy_with_logits leads to RuntimeError: class size not match
Labels: module: nn,module: error checking,triaged

The function `F.binary_cross_entropy_with_logits` should be able to handle arbitrary logits shapes, but the argument, `pos_weight` still assumes the size of the second channel be the number of classes.

Example:

```
import torch
import torch.nn.functional as F

inputs = torch.randn(4, 100, 100)
targets = torch.empty(4, 100, 100).random_(2)

pos_weight = torch.tensor([0.1, 0.9]) # for class 0 and class 1, when dataset is biased.
```

`F.binary_cross_entropy_with_logits(inputs, targets)` works fine, but `F.binary_cross_entropy_with_logits(inputs, targets, pos_weight=pos_weight)` would gives out error:

```
RuntimeError: The size of tensor a (2) must match the size of tensor b (100) at non-singleton dimension 2
```

Could you take a look at it? Or is there any quick hack that can handle it?

cc @albanD @mruberry