sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: kubernetes
Issue: Make it clear why a namespace is still in Terminating
Labels: sig/api-machinery,kind/feature,lifecycle/frozen

Users need to know why a namespace is not being deleted when it has been in the Terminating state for a sufficiently long amount of time (see #64002). We should have a status condition or set of events that make it clear which objects the namespace deleter is trying / failing to delete.

<!-- DO NOT EDIT BELOW THIS LINE -->
/kind feature
/sig api-machinery
Repository: pytorch
Issue: test_spectral_norm: Backward is not reentrant
Labels: module: autograd,triaged,module: data parallel,module: norms and normalization

I got this on a run:

```
Nov 09 21:56:23 ======================================================================
Nov 09 21:56:23 ERROR: test_spectral_norm (__main__.TestNN)
Nov 09 21:56:23 ----------------------------------------------------------------------
Nov 09 21:56:23 Traceback (most recent call last):
Nov 09 21:56:23   File "/var/lib/jenkins/workspace/test/common_utils.py", line 116, in wrapper
Nov 09 21:56:23     fn(*args, **kwargs)
Nov 09 21:56:23   File "test_nn.py", line 1864, in test_spectral_norm
Nov 09 21:56:23     torch.autograd.gradcheck(fn, (input.clone().requires_grad_(),))
Nov 09 21:56:23   File "/opt/conda/lib/python3.6/site-packages/torch/autograd/gradcheck.py", line 208, in gradcheck
Nov 09 21:56:23     return fail_test('Backward is not reentrant, i.e., running backward with same '
Nov 09 21:56:23   File "/opt/conda/lib/python3.6/site-packages/torch/autograd/gradcheck.py", line 185, in fail_test
Nov 09 21:56:23     raise RuntimeError(msg)
Nov 09 21:56:23 RuntimeError: Backward is not reentrant, i.e., running backward with same input and grad_output multiple times gives different values, although analytical gradient matches numerical gradient
Nov 09 21:56:23 
```

https://circleci.com/gh/pytorch/pytorch/215442?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano
Repository: vscode
Issue: emmet.includeLanguages for one to many mapping
Labels: help wanted,feature-request,emmet

How can I enable several languages for a given file extension please?

For example

```json
"emmet.includeLanguages": {
        "tt": ["html", "css", "javascript"],
    }
```

Except this doesn't work. I tried with multiple references to the key 

```json
"emmet.includeLanguages": {
        "tt": "html",
        "tt": "css",
        "tt": "javascript",
    }
```

and also with an embedded object

```json
"emmet.includeLanguages": {
        "tt": {
        "html":"html",
        "css": "css",
        "javascript": "javascript",
    }
```

no joy :-(


-------------------------------------------------
```json
"emmet.includeLanguages": {
        "erb": "html"
    }
```

_Originally posted by @abnersajr in https://github.com/Microsoft/vscode/issues/9500#issuecomment-339634819_
Repository: opencv
Issue: Arm Mali/OpenCL - OpenCL error CL_OUT_OF_RESOURCES
Labels: category: ocl,RFC,platform: arm

**_update: this bug is specific to Mali Midgard(T8xx\T7xx\T6xx) GPU only. More resent Mali Bifrost(Gxx) series not affected**
##### System information (version)
- OpenCV => 4.0beta
- Operating System / Platform => Ubuntu 18.04/arm64
- Compiler => Ubuntu/Linaro 7.3.0-27
- OpenCL => OpenCL 1.2 v1.r14p0-01rel0-git(966ed26)
- GPU => ARM Mali T860(Midgard 4gen)
##### Detailed description

It is specific bug to arm\mali hardware in OpenCL, which related to limited resources on this mobile device. 
`OpenCL error CL_OUT_OF_RESOURCES (-5) during call: clEnqueueNDRangeKernel('stage1_with_sobel', dims=2, globalsize=4096x4096x1, localsize=32x8x1) sync=false`

reducing `maxWorkGoupSize_` value of `cl::Device` from default `256` to `128` (to give more resources to kernel) remove that particular bug in `cv::GausianBlur` with size `3x3`(and may be many more), but bigger parameters, like size '5x5' or other kernel, like described in #11503 issue, still lead to `CL_OUT_OF_RESOURCES`   

I am continue to evaluate another CL-acceletared methods on Arm Mali-t860 to figure out another reasons of  `CL_OUT_OF_RESOURCES`.

##### Steps to reproduce

```.cpp
#include "opencv2/opencv.hpp"
using namespace cv;
 
int main(int argc, char** argv)
{
    UMat img, gray;
    imread("lena.jpg", IMREAD_COLOR).copyTo(img); //use lena.jpg from CV examples
    cvtColor(img, gray, COLOR_BGR2GRAY);
    GaussianBlur(gray, gray,Size(3, 3), 1.5);
    Canny(gray, gray, 0, 50);   
    return 0;
}
 ```
Repository: opencv
Issue: the location of tutorial(cuda module) is not appropriate
Labels: category: documentation,category: contrib,category: gpu/cuda (contrib)

##### System information (version)
- OpenCV => 4.0.0-beta
- Operating System / Platform => All Platform
- Compiler => All Compiler

##### Detailed description
In PR https://github.com/opencv/opencv/pull/12585, cuda module was moved to opencv_contrib.  
But, the tutorial(cuda module) remains in the [main repository](https://github.com/opencv/opencv/tree/4.0.0-beta/doc/tutorials/gpu).  
I think that this tutorial should move to opencv_contrib, too.

##### Steps to reproduce
```shell
$ cmake -D BUILD_DOCS=ON -D WITH_CUDA=ON -D OPENCV_EXTRA_MODULES_PATH=<opencv_contrib>/modules <opencv_source_directory>
$ make doxygen
```
Repository: TypeScript
Issue: intellisense suggests inferred type parameter in else branch of conditional type
Labels: Bug,Domain: Completion Lists

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.2.0-dev.20181101

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
type T<U> = U extends Array<infer V> ? V : Array</**/>;
```

**Expected behavior:**

Intellisense does not suggest `V` in the else branch as it will result in an error.

**Actual behavior:**

Suggests `V`, using `V` there is an error

**Playground Link:** https://agentcooper.github.io/typescript-play/#code/C4TwDgpgBAKgPAVQHxQLxQVCAPYEB2AJgM5QCCAThQIYhwCW+AZhBVAGooD8HUAXOSq04SANxA

**Related Issues:**
This is likely caused by `TypeChecker.getSymbolsInScope`, which doesn't use the same rules as the actual symbol lookup
Repository: TypeScript
Issue: intellisense in static method suggests TypeParameter of outer class
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.2.0-dev.20181101

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
class Outer<T> {
    doStuff() {
        class Inner<T> {
            static doStuff(param: /**/) {}
        }
    }
}
```

**Expected behavior:**

Intellisense does not suggest `T` as it will result in an error.
OR
`T` of `Inner` doesn't shadow the outer `T` in static members, which is therefore accessible.

**Actual behavior:**

Suggests `T` from `Outer`.

**Playground Link:** https://agentcooper.github.io/typescript-play/#code/MYGwhgzhAEDyCuAXApgJwDwBUB80DeAUNMdACYD2AyovAGa0AUAlPkSe6JDAJIB2vaLLkLtRJCIjCIAlsDJUa9BgAcwqMAFsAXNAD0AKn26WeAL5sx59udNA

**Related Issues:**
#28471 

`TypeChecker.getSymbolsInScope` correctly excludes TypeParameters of the containing class for its static members. Because of that an outer scope can add a symbol with the same name.
Repository: TypeScript
Issue: Should intellisense suggest block scoped values before they are declared?
Labels: Suggestion,Domain: Completion Lists,Experience Enhancement

Currently intellisense suggests every block scoped declaration in scope, even if the suggestion is located within the TDZ. When accepting that suggestion, TypeScript issue an `used before its declaration` error:

```ts
new /**/; // suggests 'Clazz', which results in an error
class Clazz {}

function test(
  foo = /**/, // suggests `foo`, `bar` and `baz`, all of them result in an error
  bar = /**/, // suggests `bar` and `baz`, both result in an error
) {
  let baz = 1;
}
```

Should intellisense filter out suggestions that would result in an error? If so, it should probably use the same condition as the checker.

Related: #28472 #28471
Repository: flutter
Issue: Dismissible widgets disable Tabview drag detection
Labels: framework,f: material design,f: gestures,has reproducible steps,P2,found in release: 3.3,found in release: 3.7,team-design,triaged-design

I have two tabs, the left tab having a list of tiles and the right tab having nothing.  The user can drag the screen from right-to-left or left-to-right to get from one tab to the other.
The left tab has a list of dismissible tiles that only have `direction: DismissDirection.startToEnd` (from left-to-right) enabled so that the user can still _theoretically_ drag (from right-to-left) to go to the right tab.  
However, I believe the `Dismissible` widget still receives the right-to-left drag information which is disabling the `TabView` drag to change tabs.  

In essence, how do I allow the right-to-left drag to be detected by only the `TabView` and not the `Dismissible` item?

If an **explicit** solution/example with code snippets can be given, I would very very much appreciate the help!

UPDATE: 
I'm thinking we could change a copy of the `dismissible.dart` file to change the `TabController`, but I'm not sure how I might do that.

In the `dismissible.dart` file:
```dart
...
  void _handleDragUpdate(DragUpdateDetails details) {
    if (!_isActive || _moveController.isAnimating)
      return;

    final double delta = details.primaryDelta;

    if (delta < 0) print(delta);  // thinking of doing something here
...
```
Repository: opencv
Issue: Suggestion: use opencv:: namespace for cmake imported targets
Labels: priority: low,category: build/install,future

While the syntax `::` seems to be more modern and conventional in cmake, it has a obvious benefit.

The following won't get any error until the linking time with a undefined reference error to `cv::imshow`.
```cmake
find_package(OpenCV 3.3 REQUIRED COMPONENTS core)
target_link_libraries(myExe opencv_core opencv_highgui)
```

But if using `opencv::highgui`, we get a configuration error from cmake:
```cmake
Target "myExe" links to target "opencv::highgui" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?
```
Repository: vue
Issue: Unexpected component destroyed trigger by sibling component
Labels: improvement,has workaround

### Version
2.5.17

### Reproduction link
[https://jsfiddle.net/teddy_scmp/2m6kv3rn/](https://jsfiddle.net/teddy_scmp/2m6kv3rn/)





### Steps to reproduce
1. Open console
2. click the TOGGLE bottom

### What is expected?
It is weird that the component between the two v-if will destroy and mount again

### What is actually happening?
1. AComponent is destroyed which is unexpected
2. BComponent will keep, which I only added a class there.

---
In addition, I find that DIV will cause this issue, if I added a class / change it to a tag / button, it won't destroy.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: opencv
Issue: Stitching: failed test: ParallelFeaturesFinder.IsSameWithSerial (master branch)
Labels: bug,test,category: stitching

[Nightly build](http://pullrequest.opencv.org/buildbot/builders/master-win64-vc14/builds/10634) (sporadic failures on Windows):

```
[ RUN      ] ParallelFeaturesFinder.IsSameWithSerial
C:\build\master-win64-vc14\opencv\modules\stitching\test\test_matchers.cpp(103): error: Expected equality of these values:
  countNonZero(diff_descriptors)
    Which is: 12691
  0
C:\build\master-win64-vc14\opencv\modules\stitching\test\test_matchers.cpp(103): error: Expected equality of these values:
  countNonZero(diff_descriptors)
    Which is: 12691
  0
...
```

---

Problem is related to ORB descriptors (not bit-exact between runs for some reasons)
Repository: opencv
Issue: cv::cvtColor does not properly take transparency into account
Labels: wontfix,category: imgproc

##### System information (version)
- OpenCV => 3.2
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2013

##### Detailed description

``cv::cvtColor(image, outImage, cv::COLOR_BGRA2GRAY`);`` and ``cv::cvtColor(image, outImage, cv::COLOR_BGRA2BGR);`` don't handle transparency well: RGB pixel values determine the output even if alpha value is zero.

One could indeed argue that its because of a "wrong" image but this seems to be what many standard editing tools / conversion tools produce

##### Steps to reproduce

Use this test image at ``path``: [PngWithTransparency.png](https://user-images.githubusercontent.com/1710255/48357036-e3bc0380-e697-11e8-8e7a-6d67a3a6ed85.png)

```
cv::Mat image= cv::imread(path, cv::IMREAD_UNCHANGED);
cv::Mat noAlpha, noAlphaGray;
cv::cvtColor(image, noAlpha, cv::COLOR_BGRA2BGR);
cv::cvtColor(image, noAlphaGray, cv::COLOR_BGRA2GRAY);
```

This is what is inside the images, a black "bounding box" and then fully white border around. Expected would be a full black background.

![image](https://user-images.githubusercontent.com/1710255/48357188-43b2aa00-e698-11e8-90c8-e2b9b1ef8f4c.png)

BTW: ``cv::imshow("image", image)`` would produce the same result as ``noAlpha``
Repository: go
Issue: x/tools/go/packages: include directness information to ParseFile callback
Labels: Tools

Wire [recently switched to go/packages](https://github.com/google/go-cloud/pull/623) after using `golang.org/x/tools/go/loader`. As noted in google/go-cloud#663, we observed a ~4x slowdown. Since not all of the time is spent inside the Wire process, profiling has been difficult. However, for a baseline Wire run that took 2.26s (originally 0.3s), half the time is spent in `go list`, the other half is spent in `go/types.dependencyGraph` and map assignments.

This indicates to me that at least part of the problem still is having too much input being sent to the typechecker. One of the tricks Wire employed in the `loader`-based code was to skip function bodies for dependency packages (Wire needs function body type-checking for the root packages). However, the `ParseFile` callback does not give enough information to make this determination. I would like for the arguments to `ParseFile` to include whether the file is being parsed for the root packages or imported packages. Something like:

```go
package packages

type Config struct {
  // ...
  ParseFile func(fset *token.FileSet, filename string, src []byte, isRoot bool) (*ast.File, error)
}
```

It does seem quite possible that more information could be added over time, so a more future-friendly change could be along the lines of:

```go
package packages

type ParseFileRequest struct {
  Fset *token.FileSet
  Filename string
  Src []byte
  IsRoot bool
}

type Config struct {
  // ...
  ParseFile func(*ParseFileRequest) (*ast.File, error)
}
```
Repository: go
Issue: x/build/maintner: GitHubIssue.ClosedBy field is never populated
Labels: help wanted,Builders,NeedsFix

There exists a [`GitHubIssue.ClosedBy`](https://godoc.org/golang.org/x/build/maintner#GitHubIssue.ClosedBy) field in `maintner`:

```Go
type GitHubIssue struct {
    ...
    ClosedBy *GitHubUser
    ...
}
```

### What did you expect to see?

Accurate values.

### What did you see instead?

The field is never populated and always equals to `nil` for all GitHub issues.

This can be misleading for anyone looking to use that information.

## Cause

The `closed_by` JSON field is documented and shown in the sample response at https://developer.github.com/v3/issues/#get-a-single-issue.

However, `maintner` uses the https://developer.github.com/v3/issues/#list-issues-for-a-repository endpoint for getting information about many issues at once:

https://github.com/golang/build/blob/23803abc1638efbf100d69fe6d901b14a9ad55fd/maintner/github.go#L1605-L1613

But GitHub doesn't include all detailed fields when listing many issues rather than getting a single issue. The `closed_by` field is indeed missing:

<details><summary>Response from Get Single Issue Endpoint</summary><br>

```
  ...
  "comments": 1,
  "created_at": "2018-11-09T00:20:31Z",
  "updated_at": "2018-11-09T00:25:34Z",
  "closed_at": "2018-11-09T00:22:12Z",
  "author_association": "MEMBER",
  "body": "It exists in [...]",
  "closed_by": {
    "login": "gopherbot",
    ...
  }
}
```

</details><br>

<details><summary>Response from List Issues Endpoint</summary><br>

```
    ...
    "comments": 1,
    "created_at": "2018-11-09T00:20:31Z",
    "updated_at": "2018-11-09T00:25:34Z",
    "closed_at": "2018-11-09T00:22:12Z",
    "author_association": "MEMBER",
    "body": "It exists in [...]"
  },
```

</details>

## Possible Fixes

I see two possible solutions:

1. Populate the field.
2. Remove the field (or document it as broken and point to this issue).

Since this field isn't included in the existing endpoint queried by `maintner`, it would require making additional API calls per issue. That can be extremely expensive and simply not viable.

I'd suggest removing it or documenting, at least as an intermediate step. But open to ideas. /cc @bradfitz
Repository: pytorch
Issue: [c10d] Coordinated file truncation for FileStore
Labels: oncall: distributed,feature,triaged,distributed-backlog

Comment by @SsnL in https://github.com/pytorch/pytorch/issues/13750#issuecomment-437242684, and discussion following that comment.

The FileStore will delete the underlying file if all participating processes terminate gracefully. If they don't there will be a file hanging around. If you try to reuse that file, the process group that uses it will get to see old values, and likely hang or crash. The technique showed by @SsnL fixes this by ensuring that a file gets truncated when it is first opened.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528 @osalpekar @jiayisuse @agolynski
Repository: rust
Issue: proc_macro support for reading files/strings to spanned TokenStream
Labels: A-macros,A-proc-macros

Currently, as far as I am aware, there is no way to get spans for tokens parsed from a source other than the macro's callsite, and no good way to tell rustc & cargo a procedural macro depends on another file. It would be nice for macros which want to load other files to enable this.

It'd be nice to support some mechanism for loading a file as a `TokenStream`. Ideally this would take the form of a method in the crate directly parsing a file / string to a `TokenStream`. For example:

1. A function to load a file as a `TokenStream` with accurate span info etc, e.g.
   ```rust
   fn lex_file(path: &Path) -> io::Result<TokenStream>;
   ```

2. A function to parse a string with a given filename. This might need an additional mechanism to register the source file as a dependency, e.g.
   ```rust
   fn lex_str(src: &str, filename: &Path) -> Result<TokenStream, LexErr>;
   fn add_path_dependency(path: &Path) -> ...;
   ```

To make it generally useful & able to implement something like `include!()` we'd probably also want/need something like #54725 to get the file to load relative to.


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: flutter
Issue: Performance overlay is wrong when embedding UIViews on iOS
Labels: platform-ios,engine,a: platform-views,P2,team-ios,triaged-ios

With an embedded platform view we have multiple SurfaceFrames for a single frame, the stopwatch presented on performance overlay measures each of them separately.
Repository: godot
Issue: Using canvas world environment makes viewport render target ignore texture flip flag
Labels: bug,topic:rendering,confirmed

godot 3.1, Windows 10, gles3, commit hash:
caa141a1ac630144e441f89689baa1a74bb3bae5

When you use environment world in 2d (canvas mode) the viewport which is rendering to the texture in the scene, ignores the v flip flag. You can click this flag many times and nothing happens.
When you remove the world environment, the viewport uses the flag again.
Repository: electron
Issue: Support for the ppc64le architecture via existing patches
Labels: enhancement :sparkles:

**Is your feature request related to a problem? Please describe.**
Currently Electron does not support the ppc64le architecture and therefore can't be used on machines like the libre Talos II workstation from Raptor Computing Systems.

On this front, myself and others have recently ported Chromium to ppc64le. We are currently attempting to get them upstream in Chromium, but unfortunately Google has been slow in acknowledging them.

In the meantime, I have integrated the patches into Electron's patch hook which allows the project to be built and run on ppc64le systems[1]. Incorporating these changes would allow users on the ppc64le platform to benefit from Electron's broad ecosystem without needing to wait for Google.

**Describe the solution you'd like**
While the Chromium patches pend upstream, I would like for them to be incorporated into Electron's build system. I have already done this in a fork[1], and with the Electron team's guidance, I would like for them to be merged so that official Electron binaries can be provided and the existing ecosystem tooling can take advantage of them.

**Describe alternatives you've considered**
Ideally, the patches will be accepted into upstream Chromium and Electron will have automatic support as a downstream. As stated above, though, there are some delays on that front and I believe the ppc64 community would greatly benefit from Electron support in the meantime.

**Additional context**
The Chromium patchset is actively maintained by me to track upstream, so the Electron team would simply need to pull my changes on Chromium version bumps. Ideally, this would introduce as little maintenance overhead as possible.

I have also written build instructions for ppc64le machines[2].

On the unit test front, there is an issue when running the `npm i --nodedir=../../out/Debug/gen/node_headers` step as described in the Electron documentation. The issue does not appear to be directly related to electron, but rather an to npm dependency of the unit tests. I have attached the output of this command in hopes that someone more familiar with the ecosystem can provide some insight[3].

I believe introducing ppc64le support in Electron would greatly benefit the users and developers of the ppc64 community, as well as the libre software community as a whole.

[1] https://github.com/shawnanastasio/electron
[2] https://wiki.raptorcs.com/wiki/Porting/Chromium/Electron
[3] https://paste.fedoraproject.org/paste/cYjtZcqxlcV5RwLPsjAxWQ