sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: OpenCV.js assigned Mat object memory isnt collected by garbage collection
Labels: RFC,category: javascript (js)

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

Please:

* Read the documentation to test with the latest developer build.
* Check if other person has already created the same issue to avoid duplicates. You can comment on it if there already is an issue.
* Try to be as detailed as possible in your report.
* Report only one problem per created issue.


This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => 4.1
- Operating System / Platform => MacOS
- Compiler => using opencv.js from the source of your website

##### Detailed description

<!-- your description -->
If I push the Mat objects to arrays, the objects hang in the array and aren't possible to clean with V8 garbage collection. This is unfortunate and causes memory overflow when using with larger objects. I've filled the issue concerning this to google team, which you can read about with examples to reproduce in here: https://bugs.chromium.org/p/chromium/issues/detail?id=982797

##### Steps to reproduce
https://bugs.chromium.org/p/chromium/issues/detail?id=982797

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
Repository: terminal
Issue: TitlebarControl should be a Template
Labels: Product-Terminal,Issue-Task,Area-CodeHealth

The `TitlebarControl` introduced in #1948 should be a XAML Template, so we can style it easier. Right not the control is just straight up defined in XAML, but it should do the thing most controls do, where they're a ResourceDictionary with a Template.
Repository: terminal
Issue: Stop rendering when the terminal has been minimized/control has been hidden
Labels: Help Wanted,Area-UserInterface,Product-Terminal,Issue-Task

Ported from MSFT:21315817

We shouldn't render the XAML island when we're minimized.

I don't remember any more of the context on this one. It _was_ assigned to @DHowett-MSFT, so he might remember.
Repository: rust
Issue: Type inference breaks down in recursive call
Labels: A-type-system,T-compiler,A-inference,C-bug,T-types

This is as simple as I could make it. There is an error when I try to call `do_stuff` recursively, without explicitly giving the type of `T`:

```rust
fn do_stuff<T>(t: T)
where
    u8: From<T>,
{
    // This is an error:
    do_stuff(1u8);

    // This is ok:
    do_stuff::<u8>(1u8);
}

fn main() {
    // This is ok:
    do_stuff(1u8);
}
```

```
error[E0308]: mismatched types
 --> src/main.rs:7:14
  |
7 |     do_stuff(1u8);
  |              ^^^ expected type parameter, found u8
  |
  = note: expected type `T`
             found type `u8`
```

Interestingly, when I switch around the `From` relationship, it works:

```rust
fn do_stuff<T>(t: T)
where
    T: Into<u8>,
{
    // This is ok now!:
    do_stuff(1u8);

    // This is ok:
    do_stuff::<u8>(1u8);
}

fn main() {
    // This is ok:
    do_stuff(1u8);
}
```
----

```
$ rustc --version
rustc 1.36.0 (a53f9df32 2019-07-03)
```
Repository: pytorch
Issue: JIT trace parameter sharing error if Module attributes happen to be the same
Labels: oncall: jit,triaged

## 🐛 Bug

You'll get an error if two attributes of a Module have the same values when using `torch.jit.trace`: 
```
~/miniconda3/lib/python3.6/site-packages/torch/jit/__init__.py in check_unique(param)
   1459         def check_unique(param):
   1460             if param in id_set:
-> 1461                 raise ValueError("TracedModules don't support parameter sharing between modules")
   1462             id_set.add(param)
   1463 

ValueError: TracedModules don't support parameter sharing between modules
```

## To Reproduce
```
class SimpleModule(nn.Module):

    def __init__(self, size=(784, 10)):
        super().__init__()
        self.weight = nn.Parameter(torch.Tensor(*size))
        self.logits = self.weight if size[0] == 784 else self.weight + 0.01
        nn.init.xavier_normal_(self.weight)

    def forward(self, x):
        x = self.weight @ x
        return x
```

```
# Works
mod = SimpleModule(size=(785,10))
torch.jit.trace(mod, torch.randn((10,10)))

# Doesn't work
mod = SimpleModule(size=(784,10))
torch.jit.trace(mod, torch.randn((10,10))) 
```

## Expected behavior

I would expect that it would be allowed to have complicated logic in a Module, in which a single case would be that two attributes happen to be the same.

## Environment
 - PyTorch Version (e.g., 1.0): 1.1.0
 - OS (e.g., Linux): Linux
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Python version: 3.6.8

## Additional context

The issue is that the values of the parameters are checked to be equal in order to indicate parameter sharing, however, that is not always the case.
See also the related issue to improve the error message: https://github.com/pytorch/pytorch/issues/22677
Repository: flutter
Issue: Can't swipe to dismiss scrollable Bottom Sheet
Labels: c: new feature,framework,f: material design,f: scrolling,f: gestures,customer: crowd,c: proposal,P2,team-design,triaged-design

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill our the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

Per @dnfield https://github.com/flutter/flutter/issues/31739#issuecomment-511459403

## Use case

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

See the [Crane](https://material.io/design/material-studies/crane.html#layout) Material sample and [Google I/O 2019](https://play.google.com/store/apps/details?id=com.google.samples.apps.iosched&hl=en_US)

These both feature a bottom sheet that slides up (in the case of I/O, you select "Events" and the hit the "Filter" FAB) and scrolls.

With the I/O app, if you continue to swipe down when scrolled to the top, it will start to drag and then dismiss when a threshold is reached.

If the threshold is not reached (or you swipe upwards) then the bottom sheet will not be dismissed and it'll rebound to the top of the screen.

## Proposal

<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching images showing what you are imagining.

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->

I'd think this should be a part of `DraggableScrollableSheet` as mentioned in #31739, but maybe it makes sense to bake the logic into the Bottom Sheet itself?

I've tried both modal and non-modal bottom sheets with and without the `DraggableScrollableSheet`, and can't seem to make this work as is.

The current issue with the `DraggableScrollableSheet` is that you can't have the sheet be maximized all the time.  (Since, as I mentioned in https://github.com/flutter/flutter/issues/31739#issuecomment-511241746, any swipe will immediately dismiss the `BottomSheet` rather than scroll the `CustomScrollView`)
Repository: go
Issue: x/oauth2/clientcredentials: context values are not passed to oauth2 requests that retrieve tokens
Labels: help wanted,NeedsFix

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13beta1 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
It does reproduce with the latest version of golang.org/x/oauth2. I guess this is an issue about this subrepository.


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/yann/.cache/go-build"
GOENV="/home/yann/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY="github.com/ulule/*"
GONOSUMDB="github.com/ulule/*"
GOOS="linux"
GOPATH="/home/yann/go"
GOPRIVATE="github.com/ulule/*"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/yann/sdk/go1.13beta1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/yann/sdk/go1.13beta1/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/yann/z/facebook/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build659375516=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
https://play.golang.org/p/iOdgycJZA4f

This example requires facebook credentials, but the bug does reproduce with any credential source.

### What did you expect to see?

There are two requests, one for retrieving an oauth2 token, and the other to get the actual URL.

I expected the two requests to see the same context values, which would generate an output like
```
context value
context value
```

### What did you see instead?

```
<nil>
context value
```
The context value is not passed to the first request.
Repository: TypeScript
Issue: Feature Request: Make ES module exports conform to an interface using triple slash directive
Labels: Suggestion,Awaiting More Feedback

## Search Terms
ESM, ES module, EcmaScript Module, Interface, Exports, triple slash directive, module

## Suggestion
I want to be able to enforce and ESM's exports to conform to an interface.

<details>
<summary>Here's an ESM that exports some values:</summary>

![carbon (45)](https://user-images.githubusercontent.com/3070389/61315883-080c4900-a800-11e9-98cc-aec84e78f8b7.png)

</details>

This ESM is going to be consumed by some system; __the ESM acts as configuration__ for that system.

<details>
<summary>The system could expose interfaces/types for all possible exports, and users apply them manually:</summary>

![carbon (47)](https://user-images.githubusercontent.com/3070389/61316349-15760300-a801-11e9-98a0-2f1579c14807.png)

</details>

But this is manual work, and thus error-prone.

**I propose to be able to do:**

![carbon (48)](https://user-images.githubusercontent.com/3070389/61316553-887f7980-a801-11e9-8c3c-9ce6d7522b9d.png)

*The exact syntax TBD.*

Adding
```
/// <exports name="ConfigInterface" from="system-that-needs-configuration" />
``` 
will tell typescript about which interface the ESM exports should adhere to and where to find it.

If this is implemented in a triple slash directive this can also work for non-ts files.

## Use Cases

I want users of [storybook](https://github.com/storybookjs/storybook) to be able to configure it with ease using modern code.
CommonJS isn't tree-shake-able, which is important to us. There's a pretty detailed RFC for this feature for storybook here: https://docs.google.com/document/d/15aAALZBl0GTBEKgJN219ebzJ8LUJf2TVJ3hQdkNdLvQ/edit#

Tools like babel, eslint & webpack currently are or can be configured using CommonJS modules; as the ecosystem for ESM is improving, being able to add an interface to an ESM becomes really useful.

Tools could start using ESM for configuration more, which has clear benefits over CommoNJS.

## Examples

Here's a config file that is annotated with the triple slash directive:
![carbon (49)](https://user-images.githubusercontent.com/3070389/61317985-558ab500-a804-11e9-95f3-47c64214e464.png)

Here's the interface that's being referred to:
![carbon (51)](https://user-images.githubusercontent.com/3070389/61318016-620f0d80-a804-11e9-8f75-108553e026c2.png)

This should warn the user that `logLevel = 'any'` is not a valid value.

## 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: go
Issue: cmd/doc: show documentation for explicitly-requested identifiers regardless of the `-u` flag
Labels: help wanted,NeedsFix

### What version of Go are you using (`go version`)?
```
~/go/src$ go version
go version devel +87bf0b5c51 Tue Jul 16 13:17:46 2019 -0400 linux/amd64
```

### What did you do?

```
~/go/src$ go doc go/build.getToolDir
```

### What did you expect to see?

```
~/go/src$ go doc go/build.getToolDir
package build // import "go/build"

func getToolDir() string
    getToolDir returns the default value of ToolDir.
```

### What did you see instead?
```
~/go/src$ go doc go/build.getToolDir
package build // import "go/build"

doc: no symbol getToolDir in package go/build
exit status 1

~/go/src$ go doc -u go/build.getToolDir
package build // import "go/build"

func getToolDir() string
    getToolDir returns the default value of ToolDir.
```

----

The `doc` command by default hides all unexported identifiers, _even those explicitly requested by the user._ To coax it to display the requested result, you have to pass the `-u` flag, which has the secondary (and often unwanted) effect of displaying unexported fields and methods on the requested identifier.

Moreover, that behavior is inconsistent with the behavior for `internal` packages, for which `go doc` will happily display documentation even without the `-u` flag.

Instead, the `-u` flag should control *only* the behavior for nested declarations — variables, constants, types, functions, fields, and/or methods _associated with_ the requested identifier — not the requested identifier itself.

CC @robpike @mvdan @ianthehat
Repository: go
Issue: cmd/doc: show types for constants and variables that have initializers
Labels: NeedsInvestigation,FeatureRequest

Currently, if you ask `go doc` for an exported identifier, and it happens to be declared as a `var` or `const` with the type inferred from the initializer, the type of the variable does not appear in the output.

It is doubly frustrating if the initializer happens to refer to unexported identifiers, since `go doc` requires an extra flag before it will document those (#33133).

### What version of Go are you using (`go version`)?
```
~/go/src$ go version
go version devel +87bf0b5c51 Tue Jul 16 13:17:46 2019 -0400 linux/amd64
```

### What did you do?

```
~/go/src$ go doc go/build.ToolDir
```

### What did you expect to see?

The documentation for *and type of* the `go/build.ToolDir` variable.


### What did you see instead?
```
~/go/src$ go doc go/build.ToolDir
package build // import "go/build"

var ToolDir = getToolDir()
    ToolDir is the directory containing build tools.
```

No indication of whether ToolDir is a `string`, a `[]byte`, or something else entirely. It isn't mentioned in the doc comment, and it shouldn't _need_ to be mentioned in the doc comment because the compiler already knows what it is.
Repository: pytorch
Issue: Unify tensor shape formatting in shape checks
Labels: module: error checking,module: convolution,triaged,enhancement

I made some mistake with tensor shape for nn.Conv1d and expectedly got an error:
```
  File "/miniconda/lib/python3.7/site-packages/torch/nn/modules/conv.py", line 198, in forward
    self.padding, self.dilation, self.groups)
RuntimeError: Expected 3-dimensional input for 3-dimensional weight 768 161 13 140185417077232, but got 4-dimensional input of size [40, 1, 161, 1923] instead
```

https://github.com/pytorch/pytorch/issues/19947 already reports overflown dimension of `140185417077232`

Another minor issues is mising square brackets and commas in the first weight tensor shape. Some unification would make it clearer for the user that it's tensor shape in question.

Torch version is `1.2.0.dev20190607`
Repository: flutter
Issue: Shell unit-tests that assert subprocess death don't seem to work on Windows.
Labels: engine,platform-windows,P2,team-engine,triaged-engine

These have been disabled in the test harness for now.
Repository: go
Issue: proposal: issues: distinguish "blocks beta/rc" from "blocks final release"
Labels: Proposal,Proposal-Hold

When we (@golang/osp-team) triage the issues labeled with [`release-blocker`](https://github.com/golang/go/labels/release-blocker) prior to a release, we often end up sorting them into a finer granularity:
* “blocking the next beta” (issues that will need broad testing before the release),
* “blocking the release candidate” (known regressions with limited impact and clear testing steps),
* “blocking the final release” (documentation, certain kinds of test flakiness).

We end up repeating that classification for each pre-release build, and we spend time discussing the classifications when they could often be made by smaller numbers of people ahead of time.

Furthermore, it's probably useful for folks in the community to be able to see that classification, so that they can set expectations appropriately (and so that they can point out issues that might need more testing than we thought).

----

I propose that we do one of the following:

a. Create milestones for each pre-release (`Go1.13-beta.1`, `Go1.13-rc.1`, and so on).
   * These pre-releases are conceptually before the main miletone (`Go1.13`), so a `release-blocker` on `Go1.13` would indicate the “blocking the final release” category. 

b. Or, create labels for each pre-release (`next-beta`, `next-rc`), with the expectation of zero `next-beta` issues open when we cut a beta release and zero `next-rc` issues open for a given milestone when we cut the corresponding pre-release for that milestone.
   * We would need to decide whether to have GopherBot ensure that `next-*` issues are also labeled `release-blocker`, or have GopherBot remove the `release-blocker` label as redundant.
Repository: flutter
Issue: Benchmark targets are not run on Windows.
Labels: engine,platform-windows,P2,team-engine,triaged-engine
Repository: pytorch
Issue: [data loader] Graceful data loader threads exit on KeyboardInterrupt
Labels: needs reproduction,module: dataloader,triaged

During training with PyTorch 1.2.0.dev20190607 I pressed Ctrl+C and got the following:
```
KeyboardInterrupt
Traceback (most recent call last):
  File "/miniconda/lib/python3.7/multiprocessing/queues.py", line 242, in _feed
    send_bytes(obj)
Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads

Thread 0x00007f49347f8700 (most recent call first):

Thread 0x00007f49357fa700 (most recent call first):

Thread 0x00007f4934ff9700 (most recent call first):

Thread 0x00007f494f7fe700 (most recent call first):
  File "/miniconda/lib/python3.7/traceback.py", line 105 in print_exception
  File "/miniconda/lib/python3.7/traceback.py", line 163 in print_exc
  File "/miniconda/lib/python3.7/multiprocessing/queues.py", line 273 in _on_queue_feeder_error
  File "/miniconda/lib/python3.7/multiprocessing/queues.py", line 264 in _feed
  File "/miniconda/lib/python3.7/threading.py", line 865 in run
  File "/miniconda/lib/python3.7/threading.py", line 917 in _bootstrap_inner
  File "/miniconda/lib/python3.7/threading.py", line 885 in _bootstrap

Thread 0x00007f49c70e5700 (most recent call first):
  File "/miniconda/lib/python3.7/threading.py", line 300 in wait
  File "/miniconda/lib/python3.7/queue.py", line 179 in get
  File "/miniconda/lib/python3.7/site-packages/tensorboard/summary/writer/event_file_writer.py", line 204 in run
  File "/miniconda/lib/python3.7/threading.py", line 917 in _bootstrap_inner
  File "/miniconda/lib/python3.7/threading.py", line 885 in _bootstrap

Current thread 0x00007f49df943700 (most recent call first):
train.sh: line 1:  4022 Aborted                 (core dumped) python3 train.py 
```

It would be great if data loader threads could die less verbosely (and mysteriously) on KeyboardInterrupt.
Repository: rust
Issue: Link errors when compiling for i386 with +soft-float
Labels: A-linkage,O-x86_64,T-compiler,C-bug,O-x86_32

It appears that since https://github.com/rust-lang/rust/pull/61408, rust now requires `fminf` and `fmaxf` functions to be present when compiling for i386 with +soft-float (using a custom target JSON). However, compiler-builtins [only expose those functions for some targets], which don't include x86.

Maybe compiler-builtins should include a `target-feature = "soft-float"` in the list of conditions to enable the math module?

[only expose those functions for some targets]: https://github.com/rust-lang-nursery/compiler-builtins/blob/master/src/lib.rs#L56
Repository: electron
Issue: Starting devtools with activate: false makes it so that clicking on the main window does not bring it to the front
Labels: platform/windows,bug :beetle:,5-0-x,7-1-x,10-x-y

### Preflight Checklist
* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

### Issue Details

* **Electron Version:** 5.0.6
* **Operating System:** Windows 10

### Expected Behavior
When I open devtools with `activate: false`, and the devtools appears in front of the main window, I expect that clicking on the main window will focus it and bring it to the front.

### Actual Behavior
When doing the above, the main window does not get sent to the front, but it does get focus.

### To Reproduce
main.js:
```
const { app, BrowserWindow } = require('electron')

function createWindow() {
  const mainWindow = new BrowserWindow();
  mainWindow.webContents.openDevTools({ mode: "detach", activate: false });
}

app.on('ready', createWindow)
```

Run `npm start`. Make sure that devtools is at least partially covering the main window. Notice that clicking on the main window that's in the back does not bring it to the front.

Observations:
1. The main window does get focus, and you can successfully open menu items
2. Clicking on the devtools and then back to the main window will bring the main window to the front
3. You can resize the main window and still observe the issue (resizing doesn't work around it)