sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: Visual / Text reminder when PowerToys is elevated
Labels: Idea-Enhancement

From the twitters, two people have recommended we make it clear when we are elevated.

Issue we face is most stuff is extremely transient or works without UX (example FancyZones)

Ideas:
- Append to title like Command prompt and others do 
- Change systray icon to visually show we are elevated as well.
Repository: electron
Issue: Support BrowserWindow.maximizable on Linux
Labels: enhancement :sparkles:,platform/linux,component/BrowserWindow

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [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 a feature request that matches the one I want to file, without success.

### Problem Description
Setting `maximizable` to false when creating a `BrowserWindow` has no effect on Linux. 

For my specific scenario, I've created a borderless window with a maximum width and height. Resizing the window respects the maximum width and height correctly, but if I drag the window to the top of the screen, the window becomes maximized, making it larger than the maximum width and height. I'd like to prevent the window from being maximized.

### Proposed Solution
If `maximizable` is set to false, the `BrowserWindow` should not be maximizable. 

### Alternatives Considered
None.

### Additional Information
I originally created #21595 before I discovered this current behaviour is by design. 🤦‍♂ 

Adding this feature _might_ also fix #21508, but I'm not 100% confident of that.
Repository: neovim
Issue: `starstar` globbing searches through 'wildignore' paths
Labels: bug-vim,completion

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`: v0.4.3
- `vim -u DEFAULTS` (version:  8.1, patches 1-2268) behaves differently? No, same behaviour.
- Operating system/version: Arch Linux

If a path pattern for a directory is in `'wildignore'`, files under that directory won't be returned in the results of functions like `glob()`. However, the directory will still be searched for. This can be problematic when the ignored directory is very large: functions using path expansions (for example, autocompleting `:edit **<tab>`) could take a very long time to complete, even though none of the files from the ignored folder should be considered.

It would be nice if the glob expansion function (`ExpandOne` in `ex_getln.c` I think?) could consider `'wildignore'` before diving into sub-directories.

See also:
https://github.com/vim/vim/issues/2132
https://groups.google.com/forum/#!topic/vim_dev/SEPEM44lsl8


### Steps to reproduce using `nvim -u NORC`

In this example, `big` should be ignored (I use a symlink to `/usr/share` to easily get a folder large enough to trigger a delay for demonstration purposes.)

```
$ tree
.
└── src
    ├── apples
    │   ├── models.py
    │   └── views.py
    ├── big
    │   ├── data -> /usr/share
    │   ├── models.py
    │   └── views.py
    └── oranges
        ├── models.py
        └── views.py

$ nvim -u NONE -c 'set wildignore=**/big/*'
```

### Actual behaviour

Entering `:e **/m` on the command line and pressing `<tab>` for autocompletion, there will be a large delay before results are displayed in the `wildmenu` (and `src/big/models.py` is correctly not included in those results.)

Similar for `:echo glob('src/**/models.py')` (compare with `glob('src/*/models.py')`, which returns almost immediately.)

### Expected behaviour
No unnecessary delay.
Repository: flutter
Issue: Modify default Gradle file or "Build and release an Android app" document
Labels: c: new feature,tool,t: gradle,a: release,P3,team-tool,triaged-tool

I have an open source project (https://github.com/bernaferrari/color-studio) and I was setting up the signing keys to release in Play Store. The issue is, the [documentation](https://flutter.dev/docs/deployment/android) only covers how to add your own key (replacing `signingConfigs.debug` with `signingConfigs.release` and then setting it up). It doesn't cover how to keep both: the release keys if available, or the debug otherwise. I want people to download my project and call `flutter run --release` without trouble.

So, I got it by making the following modifications:

```groovy
def propertyExists = keystorePropertiesFile.exists() // new attribute added

if (propertyExists) {
    keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
}
signingConfigs {
        if (propertyExists) { // check if file exists
            release {
                keyAlias keystoreProperties['keyAlias']
                keyPassword keystoreProperties['keyPassword']
                storeFile file(keystoreProperties['storeFile'])
                storePassword keystoreProperties['storePassword']
            }
        }
    }

    buildTypes {
        release { // provide both
            signingConfig propertyExists ? signingConfigs.release : signingConfigs.debug
        }
    }
```

And I was thinking, there are three possibilites:

1. Modify the document with my instructions (5 lines of difference)
2. Detail in the document what should do if you want to have both signing configs available when release key is not present.
3. Just modify the Android sample when Flutter creates a project and include them with a fake key.properties file. That way, anyone releasing an Android app would only have to modify that file instead of creating that file, looking at documentation and modifying gradle.

I'm actually in favor of option 3, but option 1 and 2 are also good.
Repository: pytorch
Issue: broadcast randperm with dim specification
Labels: triaged,function request

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->

Currently randperm uses only int as input
It would be great to provide a tensor and specify a dimension to make a permutation on.

## Motivation

That would be an example of how to do right now
```
idx = torch.stack([torch.randperm(n) for _ in range(28*28)]).t().long() # permute pixel of an image
data_shuffled = torch.zeros(10, 784).scatter_(0, idx, data.view(10, -1)).view(10, 28, 28) # permute each  image independently but in a vectorized way.
```

It isn't neither nice nor optimized. 





<!-- 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 -->

## Pitch

<!-- A clear and concise description of what you want to happen. -->

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

## Additional context

<!-- Add any other context or screenshots about the feature request here. -->
Repository: flutter
Issue: Add Support for tvOS
Labels: c: new feature,tool,engine,c: proposal,P3,team-engine,triaged-engine

_Latest status: https://github.com/flutter/flutter/issues/47928#issuecomment-1366960093_

----

*@lesnitsky commented on Dec 24, 2019, 4:08 PM UTC:*

I'm trying to build `Flutter.framework` for tvOS and getting this error. Is there a way to workaround this issue?

*This issue was moved by [devoncarew](https://github.com/devoncarew) from [dart-lang/sdk#39918](https://github.com/dart-lang/sdk/issues/39918).*
Repository: TypeScript
Issue: Can't infer unique symbol types via another variable
Labels: Bug

Literals such as 0 can be inferred correctly but unique symbols are not.

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.7.x-dev.20191224

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
let revision: symbol;
const rev = revision = Symbol();
rev === revision;
```

**Expected behavior:**
Type rev is unique symbol.
**Actual behavior:**
Type rev is symbol. Can't even declare that rev is a unique symbol.
**Playground Link:** https://www.typescriptlang.org/play/index.html?ts=3.8.0-dev.20191224&ssl=1&ssc=1&pln=3&pc=18#code/DYUwLgBATiBuCWBneB7AdgLgogngWwCMVgBuAKAGN1FIZYIBeaOJVNRiAZXyOAAoAlOTqMGTOq3QkgA

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: rust
Issue: Remove `HirId` from MIR
Labels: C-cleanup,A-lints,T-compiler,A-HIR,A-MIR

The [`source_scopes`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Body.html#structfield.source_scopes) field of `mir::Body` contains a `lint_root` `HirId` for figuring out the correct lint levels when reporting lints in MIR processing. Not only does this break our abstractions between HIR and MIR, this makes inlining functions from other crates super weird, because right now we just outright stop reporting any lints on the code from the other crates, no matter who wrote any kind of lint level.

We should instead figure out a system that stores all the lint level information directly in the MIR. To prevent duplication between mir bodies, we should consider some interning scheme (e.g. a query taking a `DefId` and returning an interned lint level information struct that may have a `parent` field pointing to the parent lint level datastructure).

cc @spastorino @wesleywiser @eddyb
Repository: go
Issue: archive/zip: FileHeader.SetMode: character files encoded as regular files
Labels: NeedsInvestigation

```
package main

import (
        "archive/zip"
        "log"
        "os"
)

const charDeviceFile = "/dev/null"

func main() {
        fi, err := os.Stat(charDeviceFile)
        if err != nil {
                panic(err)
        }
        fh, err := zip.FileInfoHeader(fi)
        if err != nil {
                panic(err)
        }
        if isChar(fi) != isChar(fh.FileInfo()) {
                log.Printf("file mode inconsistent after zip.FileInfoHeader: got %q, want %q", fh.FileInfo().Mode(), fi.Mode())
        }
}

func isChar(fi os.FileInfo) bool { return fi.Mode() & os.ModeCharDevice != 0 }
```

This reproducer program [fails unexpectedly](https://play.golang.org/p/aS7W0qzdRPH) with the error:

    file mode inconsistent after zip.FileInfoHeader: got "-rw-rw-rw-", want "Dcrw-rw-rw-"

The data loss is due to a logically impossible bit match in `fileModeToUnixMode`. The fix:

```
--- src/archive/zip/struct.go   2019-12-29 02:26:54.000000000 +0100
+++ src/archive/zip/struct.go   2019-12-29 02:27:05.000000000 +0100
@@ -337,12 +337,10 @@
                m = s_IFIFO
        case os.ModeSocket:
                m = s_IFSOCK
+       case os.ModeDevice | os.ModeCharDevice:
+               m = s_IFCHR
        case os.ModeDevice:
-               if mode&os.ModeCharDevice != 0 {
-                       m = s_IFCHR
-               } else {
-                       m = s_IFBLK
-               }
+               m = s_IFBLK
        }
        if mode&os.ModeSetuid != 0 {
                m |= s_ISUID
```
Repository: rust
Issue: Remove uses of `_` in defaults
Labels: C-cleanup,C-enhancement,A-diagnostics,T-compiler

Quoting myself from the referenced thread:

I feel like the internal use of `_` as a default name for things is a bit undisciplined, and it's leaking into diagnostics in annoying ways. There is also this: https://github.com/rust-lang/rust/pull/66679

I feel like internally, we should keep a strong separation between names that we get from the source code being compiled and names being generated by the compiler...

_Originally posted by @mark-i-m in https://github.com/rust-lang/rust/issues/67565#issuecomment-569458176_

cc @Centril @matthewjasper @pnkfelix
Repository: opencv
Issue: Invalid parameters description in Java documentation for findContours 
Labels: category: documentation,category: java bindings,Hackathon

https://docs.opencv.org/master/javadoc/org/opencv/imgproc/Imgproc.html#findContours(org.opencv.core.Mat,java.util.List,org.opencv.core.Mat,int,int)

> hierarchy - Optional output vector (e.g. std::vector<cv::Vec4i>), containing information about the image topology. It has as many elements as the number of contours. For each i-th contour contours[i], the elements hierarchy[i][0] , hierarchy[i][1] , hierarchy[i][2] , and hierarchy[i][3] are set to 0-based indices in contours of the next and previous contours at the same hierarchical level, the first child contour and the parent contour, respectively. If for the contour i there are no next, previous, parent, or nested contours, the corresponding elements of hierarchy[i] will be negative.


This is not the case. The Java hierarchy output is a matrix with 1 row, and N columns (for N contours), where each element contains a 4-element double array. The double array holds the indices of the next, previous, child, and parent contours.


Eg: hierarchy.get(0, k) gives a double[4]  
hierarchy.get(1, k) throws "java.lang.NullPointerException: Attempt to read from null array"
Repository: pytorch
Issue: What is the significance of torchvision._is_tracing()? 
Labels: triaged,module: vision

## What is the significance of torchvision._is_tracing()? ❓ 

### Please note that this issue tracker is not a help form and this issue will be closed.

We have a set of [listed resources available on the website](https://pytorch.org/resources). Our primary means of support is our discussion forum:

- [Discussion Forum](https://discuss.pytorch.org/)


cc @fmassa
Repository: pytorch
Issue: Parallelization: more balanced work distribution among workers
Labels: module: cpp,feature,triaged,module: data parallel

## 🚀 Feature
Parallelization: more balanced work distribution among workers

## Motivation

I recently checked the code for `at::parallel_for` method and this is what I observed.
Suppose there are `N` indices and `T` workers, then worker `i (0 <= i < T)` receives
indices `[i * ceil(N/T), min(N, (i+1) * ceil(N/T)) )`.

Now, suppose `N=10, T=4`, then this scheme will have the following distribution : `3|3|3|1`.
Definitely, something like `3|3|2|2` looks better. The issues is that the current approach is biased against the last worker(s) - it (them) always receive(s) the least work, which **could be even zero**. To elaborate, the whole situation becomes even worse if, for example, `N=100, T=40`. Then work of size 3 is scheduled for each worker, meaning that only 34 workers are going to do something useful, while 6 workers do nothing. And, in general, the situation gets worse if the number of workers scales up with the size of an input.

## Pitch
What about a slightly different distribution? This one **uses all the workers**!
For a worker `i: 0 <= i < T` let
```
begin(i) = ceil(N*i/T),
end(i) = begin(i+1),
```
and the worker receives indices `[begin(i), end(i) )`

It can be shown that for any `N >= T >= 1`, any `i,j: 0 <= i,j < T`:
```
|(end(i) - begin(i)) - (end(j) - begin(j))| <= 1, 
end(i) - begin(i) >= 1, begin(i) < N,
```
so this new scheme is optimally balanced, and each worker will do at least something!

The only issue I see is a more likely chance of overflow in computing `begin`

cc @yf225 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528
Repository: pytorch
Issue: DataLoader does not consider default floating point type
Labels: module: dataloader,triaged

## 🐛 Bug

The default collate function used in `torch.utils.data.DataLoader` ignores the default floating point type set via `torch.set_default_dtype()`. The created type for a python `float` is always `torch.float64`. However, I am not sure if this is a deliberate design decision.

## To Reproduce

Steps to reproduce the behavior:

1. Set the dtype to float32 with torch.set_default_dtype(torch.float32)
2. Use DataLoader on a dataset which has python scalar floats

```
>>> torch.set_default_dtype(torch.float32)
>>> torch.utils.data._utils.collate.default_collate((1.0,)).dtype
torch.float64
```
<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior
The default collate function should create for python `float` types the dtype that is set with `torch.set_default_dtype()`.

## Environment
```
PyTorch version: 1.3.1
Is debug build: No
CUDA used to build PyTorch: 10.0.130

OS: Debian GNU/Linux bullseye/sid
GCC version: (Debian 8.3.0-26) 8.3.0
CMake version: Could not collect

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 10.1.168
GPU models and configuration: GPU 0: GeForce RTX 2070 SUPER
Nvidia driver version: 430.64
cuDNN version: Could not collect

Versions of relevant libraries:
[pip3] numpy==1.16.5
[conda] _pytorch_select           0.2                       gpu_0  
[conda] blas                      1.0                         mkl  
[conda] mkl                       2019.4                      243  
[conda] mkl-service               2.3.0            py37he904b0f_0  
[conda] mkl_fft                   1.0.15           py37ha843d7b_0  
[conda] mkl_random                1.1.0            py37hd6b4f25_0  
[conda] pytorch                   1.3.1           cuda100py37h53c1284_0  
[conda] torchvision               0.4.2           cuda100py37hecfc37a_0
```

cc @SsnL
Repository: TypeScript
Issue: [Compiler API] function which check if a class implements an interface
Labels: Suggestion,API,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

Compiler API, InterfaceDeclaration, ClassDeclaration, Checker

## Suggestion

<!-- A summary of what you'd like to see added or changed -->

A function to check whether a `ClassDeclaration` implements an `InterfaceDeclaration`

## Use Cases

Hello, I wanted to check whether a `ClassDeclaration` of `a.ts` file implements an `InterfaceDeclaration` from `b.ts` file using Compiler API.
But I couldn't find a method or a function for it.

## Examples

```ts
function isClassImplementInterface(
  ts.ClassDeclaration: classDeclaration,
  ts.InterfaceDeclaration: interfaceDeclaration
): boolean {
  // return true if classDeclaration implements interfaceDeclaration correctly
}
```

## 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: godot
Issue: Light2D is unreliable when reparenting it
Labels: bug,topic:rendering,confirmed,topic:2d

**Godot version:**
3.2 beta4

**Issue description:**
Soo I have a rather complicated light setup to workaround #26507 and recently (?) I noticed that it's unreliable. What I do is keep whole game in a ViewportContainer and reparent any Light2D that appears to the parent of this container and then draw the whole screen masked with lights. Yep, that's complicated.

My problem is that lights sometimes don't work. Completely randomly. Like, check this screenshot. The character has light around it.
![image](https://user-images.githubusercontent.com/2223172/71556314-553f4880-2a37-11ea-9da4-72205efacc4c.png)

But when I run the game multiple times, 70% of the time the light does not appear.
![image](https://user-images.githubusercontent.com/2223172/71556353-ec0c0500-2a37-11ea-8557-a4fd747b9756.png)

This happens after reparenting. I tried debugging it to see what's the difference when it works and when doesn't and there doesn't seem to be any. The light has same parent/position in parent in both cases, all properties have the same values in remote inspector. Disabling/enabling light or toggling visibility doesn't fix it. Here's a GIF of the bug in action.
![Ot9elJAW7g](https://user-images.githubusercontent.com/2223172/71556374-34c3be00-2a38-11ea-8a49-be3d0b52f992.gif)

So uh, I have no idea how to reproduce it outside my game, but it's clearly some problem with the engine.

**Minimal reproduction project:**
I haven't managed to create a minimal project :/ Simply reparenting doesn't seem to cause the bug, it's just a trigger.
Repository: TypeScript
Issue: Give better error when using private identifier in parameter property
Labels: Bug

<!-- 🚨 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 the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.8.0-dev.20191228

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** parameter property private

**Code**

```ts
class C {
    constructor(private #prop: number) {}
}
```

**Expected behavior:**

Maybe `Parameter properties cannot have a private name.`

**Actual behavior:**

```
A parameter property is only allowed in a constructor implementation.(2369)
Parameter '(Missing)' implicitly has an 'any' type.(7006)
Identifier expected.(1003)
';' expected.(1005)
Unexpected token. A constructor, method, accessor, or property was expected.(1068)
```

**Playground Link:** https://www.typescriptlang.org/play/?ts=3.8.0-dev.20191228&ssl=3&ssc=2&pln=1&pc=1#code/MYGwhgzhAEDC0G8BQ1XWAewHYQC4CcBXYXDfACgAd8BLANzFwFNoBiajSgLmi0IFsARk3wBKRAF8kEoA

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: vscode
Issue: Pseudoterminal handleInput does not catch Terminal.sendText
Labels: bug,api,confirmed,terminal-input

Info:

- VSCode Version: 1.41.1
- OS Version: Windows 10

Issue:

This code creates a pseudoterminal and tries to write a string to it:

```
const writeEmitter = new vscode.EventEmitter<string>();
const pty: vscode.Pseudoterminal = {
    onDidWrite: writeEmitter.event,
    open: () => writeEmitter.fire('Opening terminal!'),
    close: () => {},
    handleInput: data => writeEmitter.fire(data === '\r' ? '\r\n' : data)
};
let terminal = vscode.window.createTerminal({ name: "test", pty });
terminal.sendText("test");
```

However the handleInput does not catch the sendText command and no text is printed.
The docs do mention that it catches sendText():

>handleInput(data: string): void

>Implement to handle incoming keystrokes in the terminal or when an extension calls Terminal.sendText. data contains the keystrokes/text serialized into their corresponding VT sequence representation.

Typing in the pseudoterminal does trigger handleInput.