sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [local_auth] Support Linux
Labels: platform-linux,p: local_auth,package,a: desktop,P3,team-linux,triaged-linux

## Use case

The `local_auth` package is useful when handling sensitive data in Flutter applications. In my case, I am processing encrypted, sensitive messages which I would obviously like to protect. Especially on Desktop systems in the professional environment, lots of sensitive data is being processed. That is why I would like to propose to support native authentication on desktop systems too.

## Proposal

Especially on Linux, the implementation should be done using `pam`, the native Linux authentication manager, as pam itself supports various authentication types, security levels. Especially, password authentication, facial detection and fingerprint detection can be natively integrated into pam.

About Windows and macOS, I am unfortunately not in knowledge to propose a suiting method.
Repository: transformers
Issue: Add POINTER model
Labels: New model

# 🌟 New model addition

## Model description

[POINTER](https://github.com/dreasysnail/POINTER) is a progressive and non-autoregressive text generation pre-training approach, published on EMNLP 2020 by Microsoft Research. POINTER generates fluent text in a progressive and parallel manner. With empirical logarithmic time, POINTER outperforms existing non-autoregressive text generation approaches in hard-constrained text generation.

The model uses basically BERT-large architecture. However, an additional token is added to the vocab. The inference is performed by passing the input iteratively to the model. Since there is no existing model architecture in Huggingface that is compatible, I am not sure how to incorporate this into the model card. 

## Open source status

* [x] the model implementation is available: (https://github.com/dreasysnail/POINTER)
* [x] the model weights are available: [here](https://yizzhang.blob.core.windows.net/insertiont/ckpt.tar.gz?st=2020-08-18T20%3A49%3A02Z&se=2024-01-16T20%3A49%3A00Z&sp=rl&sv=2018-03-28&sr=b&sig=PKrSJt38cmY0P%2FBcZuyK%2Btm3bXyYzzfazaqTu1%2F%2FDtc%3D)
* [x] who are the authors: @dreasysnail
Repository: next.js
Issue: Ensure Next.js is correctly respecting `NODE_ENV`
Labels: bug,Webpack

Next.js should unconditionally use `NODE_ENV=development` and `NODE_ENV=production` for `next dev` and `next build` respectively in the following areas:

- [ ] `.env.*` loading
- [ ] Client-side bundle inlining
- [ ] Server-render time
- [x] `next/babel` plugin internal mode (#20679)
- [x] Webpack mode (#20679)

The only way to read a "misconfigured" `NODE_ENV` (e.g. `NODE_ENV=staging`) should be in `next.config.js`. This is only allowed for backwards compatibility.

I _believe_ we also have to allow it to override what Babel "env" is loaded. I don't feel strongly about this.

Next 11 should disallow all non-standard values for this and immediately exit. This behavior should be implemented by whatever PR closes this behind a `future` flag.

---

We also need to fix this message:
```
warn  - You are using a non-standard "NODE_ENV" value in your environment. This creates inconsistencies in the project and is strongly advised against. Read more: https://err.sh/next.js/non-standard-node-env
```
Repository: pytorch
Issue: Conda package should install libtorch in the standard location
Labels: module: binaries,module: build,triaged

`conda install pytorch=1.7 -c pytorch` has the header and libs under python dirs, for example `$CONDA_PREFIX/lib/python3.8/site-packages/torch/include/torch/script.h`.

It should install libtorch under `$CONDA_PREFIX/{include,lib}`.

Maybe we can have a separate `libtorch` conda package for users who do not need python version (e.g. prod server) and make the pytorch package depend on it.


cc @ezyang @seemethere @malfet @walterddr
Repository: ant-design
Issue: Cascader 支持onSearch事件，让用户可以自己处理搜索逻辑
Labels: help wanted,💡 Feature Request,Inactive

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### What problem does this feature solve?
在数据量大的时候Cascader组件中生成plattenOptions耗时严重（300ms/次），如果一个页面多个组件示例，且生成的plattenOptions一样，则会造成不必要的耗时. 所以需要将生成plattenOptions的逻辑由用户统一处理

### What does the proposed API look like?
新加onSearch事件
|参数	|说明|	类型|	默认值|
|-----|-----|-----|----|
|onSearch  | 文本框值变化时回调 | function(value: string)	|-|


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: Cudnn header files should be copied into build package as well 
Labels: module: windows,triaged,windows-triaged

## 🚀 Feature
Cudnn headers should be copied to build package as well.

## Motivation
Logically, we have copied the cudnn dlls to build package, the head files should be copied as well.
In reality, If the user is using C++ frontend, he/she might need to set CUDNN_INCLUDE_DIR in CMAKE, It'd better to keep the head files consistent with the dlls.





cc @peterjc123 @maxluk @nbcsm @guyang3532 @gunandrose4u @smartcat2010 @mszhanyi
Repository: go
Issue: cmd/go: add a flag to ignore build constraints when listing packages
Labels: NeedsFix,FeatureRequest,GoCommand,Tools

I realise that the point of `go list` is to list packages, and I realise that one must generally obey build constraints when loading packages. For example, it makes no sense to try to type-check all the Go files in a package while ignoring build constraints, because there will likely be duplicate definition errors if declarations are split by `GOOS` or `GOARCH`.

Having said that, it can be very useful to merely list or traverse a set of packages in a way that build constraints are completely ignored. The most common use case is: what packages are potentially imported by the current package, directly or indirectly, across all build configurations?

This question is valid, for example, if one wants to copy a package and all of its transitive package dependencies. `go list -deps <package>` does not work in general, because if I run the command on Linux, I would not be including imports which are only used on Windows.

The closest thing we have right now is `go mod vendor`, which copies all transitively imported packages by all the packages in the current module into the vendor folder, across all build constraints. So `cmd/go` already has the machinery to traverse a package dependency graph while ignoring build constraints, it seems.

--

Here ends the problem statement, and begins my initial suggestion for a solution: a `go list` flag to ignore build constraints. Here are some example use cases:

* List all the packages potentially depended on by a given package: `go list -deps -newflag <package>`

* List all the packages under the current directory tree, not just for the current platform: `go list -newflag ./...`

I'm not sure what this new flag could be called. Perhaps `-nobuild` or `-anybuild`.

The flag would also restrict what `go list` can do. For example, using `-newflag` along with `-export` or `-compiled` would be an error, because it does not make sense to load/build packages when we're ignoring build constraints. Similarly, `-newflag -json` would always omit some fields like `IgnoredGoFiles`, since they make sense only when following build constraints.

This idea has been discussed briefly before, but as far as I know no problem statement or solution has been raised as an issue yet. I'm not using a proposal title and label; as far as I know that's only necessary if we need the proposal review committee to intervene.

cc @bcmills @jayconrod @matloob @rsc for cmd/go
cc @ianthehat @dominikh @myitcv @rogpeppe @kardianos for golang-tools and some previous issues
Repository: go
Issue: runtime: Goexit doesn't crash the program
Labels: NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.15.4 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### 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="/Users/fxrlv/Library/Caches/go-build"
GOENV="/Users/fxrlv/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/fxrlv/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/fxrlv/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.15.4/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.15.4/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/3r/9dz2gvss1cq9j8y7_76cgs300000gn/T/go-build700045611=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

case 1
```
package main

import (
	"runtime"
)

func main() {
	runtime.Goexit()
}
```

case 2
```
package main

import (
	_ "net/http"
	"runtime"
)

func main() {
	runtime.Goexit()
}
```

### What did you expect to see?

two cases produce the same, should crash

### What did you see instead?

second case hangs forever
Repository: go
Issue: html/template: escapes + to &#43;
Labels: NeedsDecision

As far as I know, the `+` character has no special meaning when used as: `<p> This is a plus "+" sign</p>`. However html/template's escaping analysis thinks otherwise. What strikes me as odd is that `template.HTMLEscaper("+")` doesn't provide the same behaviour, even when skipping the [allocation optimisation check](https://golang.org/src/text/template/funcs.go#L631).

### What version of Go are you using (`go version`)?

<pre>
$ go version
go1.15.4 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?
It reproduces with 1.15.4, haven't tried _tip_.

### What did you do?
```go
package main

import (
	"html/template"
	"fmt"
	"strings"
)

func main() {
	var buf strings.Builder

	tpl := template.Must(template.New("foo").Parse(`{{ "+" }}`))
	tpl.Execute(&buf, nil)
	
	fmt.Printf("HTML Escaper's result %q\n", template.HTMLEscaper("+"))
	fmt.Printf("html/template         %q\n", buf.String())
}
```
Playground with the problem I'm having: https://play.golang.org/p/6rbaYLi9_Bt

(_I've also tried variations of html elements to create a different escaping context (e.g.: surround the action with e.g. `<li>` tags), which I thought would be the problem initially. That produced the same result however._)

### What did you expect to see?
The same output as if the value ran through `template.HTMLEscaper()`
```
HTML Escaper's result "+"
html/template         "+"
```

### What did you see instead?
```
HTML Escaper's result "+"
html/template         "&#43;"
```
Repository: ant-design
Issue: Tabs结合Popover会渲染两次Popover
Labels: 🐛 Bug,help wanted,Inactive

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[https://stackblitz.com/edit/react-ua4iau?file=index.js](https://stackblitz.com/edit/react-ua4iau?file=index.js)

### Steps to reproduce
Tabs中addIcon， 使用Popover ，通过 visible 属性控制浮层显示。会出现两个Popover

### What is expected?
只出现一个Popover 

### What is actually happening?
会出现两个Popover 

| Environment | Info |
|---|---|
| antd | 4.8.2 |
| React | 16.8.6 |
| System | window7 |
| Browser | Google |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: Astar2D Inconsistent with tie-breaking decision in path traversal
Labels: enhancement,topic:core,confirmed

**Godot version: 3.2.stable**


**OS/device including version: Ubuntu 18.04.4 LTS x86_64**

Astar2D path finding is not consistent due to the use of OAHashMap. The tie breaker for choosing points that are equivalent in distance from any current point is decided by which was first iterated in the [OAHashMap as seen here](https://github.com/godotengine/godot/blob/10fd10759978f01e9152278e905f32c1117d2841/core/math/a_star.h#L55)

I can understand the want for speed with the lookups, but having inconsistent results in pathfinding is not worth the cost in my opinion; I think we should consider adding the option for Astar to use an ordered set, such as the ordered_hash_map if not outright changing the graph to use it.

 

**Quick minimal setup to see the inconsistency.**

```
	var astar = AStar2D.new()
	astar.add_point(1, Vector2(0,0))
	astar.add_point(2, Vector2(0,1))
	astar.add_point(3, Vector2(0,2))
	astar.add_point(4, Vector2(1,0))
	astar.add_point(5, Vector2(1,1))
	astar.add_point(6, Vector2(1,2))
	astar.add_point(7, Vector2(2,0))
	astar.add_point(8, Vector2(2,1))
	astar.add_point(9, Vector2(2,2))
	
	astar.connect_points(1,2)
	astar.connect_points(2,3)
	astar.connect_points(4,5)
	astar.connect_points(5,6)
	astar.connect_points(7,8)
	astar.connect_points(8,9)
	astar.connect_points(1,4)
	astar.connect_points(4,7)
	astar.connect_points(2,5)
	astar.connect_points(5,8)
	astar.connect_points(3,6)
	astar.connect_points(6,9)
	
	print(astar.get_point_path(1, 9))
	print(astar.get_point_path(9,1))
	print(astar.get_id_path(1,9))
	print(astar.get_id_path(9,1))
	
	print(1, astar.get_point_connections(1))
	print(2, astar.get_point_connections(2))
	print(3, astar.get_point_connections(3))
	print(4, astar.get_point_connections(4))
	print(5, astar.get_point_connections(5))
	print(6, astar.get_point_connections(6))
	print(7, astar.get_point_connections(7))
	print(8, astar.get_point_connections(8))
	print(9, astar.get_point_connections(9))

//Printout on my machine is as follows

[(0, 0), (1, 0), (1, 1), (2, 1), (2, 2)]
[(2, 2), (2, 1), (1, 1), (0, 1), (0, 0)]
[1, 4, 5, 8, 9]
[9, 8, 5, 2, 1]
1[4, 2]
2[1, 5, 3]
3[2, 6]
4[5, 1, 7]
5[8, 2, 4, 6]
6[5, 9, 3]
7[8, 4]
8[9, 5, 7]
9[8, 6]
```
Visualizing this as a number pad, 1 on bottom left, 9 on the top right, 3 on the bottom right..
We get the first big standout result with the path from 9 to 1 breaking the ties at nodes 9 and 5 differently. On 9, it goes to 8 (left node), and on 5 it goes to 2 (bottom node), whereas on the path from 1 to 9, the ties broken are consistent. On 1 to 9, the ties are at 1 (going up to 4), and at 5 (again going up 8).

I'm not sure how much of a reproduction effect this has on say multiplayer games where 2 different clients need to recalculate the same path and ties are being handled on each machine, but this does have an affect on 2d grid games where the pathing just looks odd when it isn't consistent across diagonals.
Repository: go
Issue: encoding/json: Unmarshal inserts map keys when the value is not appropriate for the map type
Labels: NeedsFix

```go
package main

import (
	"fmt"
	"encoding/json"
)

func main() {
	var x map[string]int
	err := json.Unmarshal([]byte(`{"a":1,"b":"c"}`), &x)
	fmt.Printf("x = %#v, err = %s", x, err)
}
```

Output:
```
x = map[string]int{"a":1, "b":0}, err = json: cannot unmarshal string into Go value of type int
```

I think this violates the principle of least astonishment, "b" key shouldn't appear in the output `x` map.

The relevant part of the documentation for [`json.Unmarshal()`](https://golang.org/pkg/encoding/json/#Unmarshal) is:

> To unmarshal a JSON object into a map, Unmarshal first establishes a map to use. If the map is nil, Unmarshal allocates a new map. Otherwise Unmarshal reuses the existing map, keeping existing entries. Unmarshal then stores key-value pairs from the JSON object into the map. The map's key type must either be any string type, an integer, implement json.Unmarshaler, or implement encoding.TextUnmarshaler.
> 
> If a JSON value is not appropriate for a given target type, or if a JSON number overflows the target type, Unmarshal skips that field and completes the unmarshaling as best it can. If no more serious errors are encountered, Unmarshal returns an UnmarshalTypeError describing the earliest such error. In any case, it's not guaranteed that all the remaining fields following the problematic one will be unmarshaled into the target object.

It doesn't seem to me that it describes the above behaviour.
Repository: godot
Issue: Export variable not shown in Inspector after resolving script error by modifying parent script
Labels: bug,topic:gdscript,topic:editor

**Godot version:** 3.2.3


**OS/device including version:** not graphics-related


**Issue description & Steps to reproduce:**
I have a base scene and an inherit scene named `Base.tscn` and `Derived.tscn`. Each of them has a script that's named accordingly. And `Derived.gd` inherits from `Base.gd`.

```gdscript
# Base.gd
extends Node2D

var bar = 42


# Derived.gd
extends "res://Base.gd"

export var foo = 123

func _ready():
	print(bar)
```

1. In the beginning, `Derived.tscn` shows script variable "Foo" in Inspector.
2. Change the last line of `Derived.gd` to `print(foobar)`, so it references a nonexistent variable.
    * The script editor shows error about identifier "foobar" not declared.
    * The Inspector shows no script variable since there's an error in the script.
3. Change the `bar` in `Base.gd` to `foobar`.
    * `Derived.gd`'s error in the script editor is now gone.
    * But the Inspector still shows no script variable.

Reopening the scene alone won't bring the script variable back. To trigger the update in Inspector:

* Make some change in `Derived.gd` and save
* or, close `Derived.gd` in the script editor and then reopen `Derived.tscn`
* or, restart Godot

This can also be reproduced on the master branch, but seems more complicated. Its revert to default value button is also messed up in this case.

**Minimal reproduction project:** [ExportVar.zip](https://github.com/godotengine/godot/files/5523982/ExportVar.zip)
Repository: vscode
Issue: Reveal comments in diff editor when navigating with the keyboard
Labels: feature-request,comments

Microsoft/vscode#67509

Repro:

1. Turn on tab key moves focus mode
2. Focus the second comment in the document, with the first being out of the viewport:

   ![image](https://user-images.githubusercontent.com/2193314/51998059-cadc1680-246c-11e9-924f-2dfcb67ebcc0.png)

3. Press shift+tab a few times until the first comment is focused, it will still be out of the viewport
Repository: rust
Issue: Suggest using -- --nocapture if tests run for too long
Labels: C-enhancement,A-diagnostics,T-compiler,A-libtest

When tests ran via `cargo test` take too long, a message like the following shows on the console:

```
running 1 test
test foo ... test foo has been running for over 60 seconds
```

I would like it if this little note could be updated to say something like the following, to help discoverability of the `--nocapture` flag:

```
running 1 test
test foo ... test foo has been running for over 60 seconds (try using `cargo test -- --nocapture`)
```

Alternatively, perhaps `cargo` should stop capturing the outpuut if they take too long and dump it all on the console, so it would be like an implicit `--nocapture` if things go south. But I think mentioning the flag is enough, because it took me a bit to find about it when I needed it.
Repository: pytorch
Issue: Make libtorch modular
Labels: module: binaries,module: build,triaged,module: selective build

## 🚀 Feature
libtorch binaries have grown substantially over the last releases, to a point where this is a problem because we need to ship our software on DVD.

## Motivation

We are currently upgrading from libtorch 1.4 to 1.7 in order to support Ampere GPUs.
We noticed that torch.dll is larger, new CUDA dlls (e.g. cusolver) have been introduced and existing ones (e.g. cuDNN) are much larger.

We have analyzed which DLLs are actually called at runtime and it seems like only cudart and cuDNN (except adv) are used. We are only using CNNs (training and inference).

It looks most libtorch users work on specific problems in vision or other areas and don't need all functionality available at all times:
https://discuss.pytorch.org/t/survey-what-are-you-using-the-c-api-for/55163/10

## Pitch

It would be great if libtorch could be configured at compile-time so that only required functionality (e.g. CNNs) is enabled. As a workaround we could link the unused DLLs with delay loading and not deploy them, but we aren’t sure if this is safe.



cc @ezyang @seemethere @malfet @walterddr
Repository: terminal
Issue: Allow CUI apps to provide a WT profile through the registry
Labels: Issue-Feature,Area-Settings,Product-Terminal

I know the first reaction of the Windows Terminal team will be that JSON is much better than the registry, especially for WSL users, and in most cases I agree, but hear me out on this one.

Windows Terminal automatically detects and add profiles for Microsoft-provided shells and WSL distros, populating the new-tab menu without user intervention.
But 3rd party shells that are Win32 CUI apps need to explain to their users how to add a profile in settings.json manually, as there is no way for Windows Terminal to automatically detect and create the proper profiles entries for all 3rd party apps.
Such shells are regularly installed using MSI packages, which are designed to be declarative target states and really should avoid using MSI custom actions which make them less reliable and impossible to process by some automated deployment tools. Adding a DLL to their installer that goes and tinker with "%LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json" file at install time isn't a solution, and wouldn't work when Windows Terminal is installed after.

I believe the cleanest solution for MSI-deployed Win32 shells would be to provide their profile for WT through the registry, in a well-known registry key such as HKLM|HKCU\Software\Microsoft\Windows Terminal\Profiles\ (HKLM or HKCU depending on whether the shell is installed per-user or globally).
Each Win32 shell could simply add a subkey with its profile GUID in that registry key, without even checking if Windows Terminal is currently installed or not.
Each subkey would contain values that match the profile properties provided in settings.json. These should be individual registry values to allow the installer to provide the targets for commandline, icon, startingDirectory,... as MSI variables depending on the installation directory selected by the user without having to, again, provide some custom action DLL that can generate JSON. It would also make it easy for IT to customize the profile of specific shells in their custom deployment solutions after extracting the declarations from an MSI package.
Whenever WT gets used, even if it has been installed after the shell, it could check that location for 3rd party profiles to be added to the add-tab menu, making the experience so much easier for users. It could also automatically remove profiles for any shell that has been uninstalled.

This isn't a suggestion to replace the JSON file with the registry, but to complement the current system to let 3rd party Win32 shells provide the same level of integration as PowerShell and CMD, and the registry seems like the best solution for those apps as it is supported as part of the MSI declarative packaging system.