sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/go: be more forgiving with matching names for help
Labels: NeedsInvestigation,GoCommand

The go help output for topics is mostly good, but guessing how to spell the name of a particular topic can be difficult due to a combination of inconsistencies in the names matched, rigidity in the matching, and little assistance except asking for the full list. For example, is it singular (`go help testflag`) or plural (`go help modules`)? Is it hyphenated (`go help module-get` (not `modules-get`!)) or not (`go help buildmode`)?

The output for commands is less troubled, as it is quicker to access the list and the rules just match the commands, which are short and a little bit consistent already. But even here, I had to look at the list again today, as the command is called "work" but the feature is always called "workspaces".

I suggest the matching algorithm be  relaxed. I don't have a particular preference about the mechanism, but it could be as simple as having multiple names for a given command or topic (work, workspace, workspaces), using a prefix-driven algorithm, or some edit distance thing. In practice I find the last form steps too far from the goal, so the one of first two approaches would be my choice, but really anything less rigid would be an improvement.

This sort of thing is a common courtesy honored by many programs in the world. The go command could strive to be more accommodating.
Repository: pytorch
Issue: `torch.pow` errors out on specific input
Labels: module: cuda,triaged

### 🐛 Describe the bug

running into the issue with the scripts below:

```
import torch

x = torch.tensor(0, device="cuda", dtype=torch.int32)
y = torch.tensor(-1)
o = torch.pow(x, y)

---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-10-bc9daa4bd4d3> in <module>
----> 1 o = torch.pow(x, y)

RuntimeError: "reciprocal_cuda" not implemented for 'Long'
```


### Versions

running into this on latest ToT branch.

```
commit 9f541aa3aca768e7fbfa4a9d648b554f22b261f7 (HEAD -> master, origin/master, origin/HEAD)
Author: Taylor Robie <taylorrobie@fb.com>
Date:   Sun Feb 20 14:32:29 2022 -0800

    [Profiler] Optimize `reportMemoryUsage` (#71538)
    
    Summary:
    Pull Request resolved: https://github.com/pytorch/pytorch/pull/71538
    
    `reportMemoryUsage` is kind of awful. It does a bunch of string writes and such that makes it VERY expensive. Just moving that work off the hot path reduces the overhead for `profile_memory` from ~6.5 us to ~1.2 us. (85% reduction in the kineto contribution to profiling overhead.)
    
    Test Plan: Ran ubenchmark with `--op empty --stressTestKineto --kinetoProfileMemory`
    
    Reviewed By: swolchok
    
    Differential Revision: D32730167
    
    fbshipit-source-id: fe18e8fa3881967cad8fa1c26c71c805e9b034e5
    (cherry picked from commit 0d394cb252e6eac78626b467e0bb497d6d6ae86c)

```

cc @ngimel
Repository: godot
Issue: Pausing deletes Particles2D particles early
Labels: bug,topic:rendering

### Godot version

v3.4.2.stable.official [45eaa2daf]
v3.4.3.rc2.official [0ea54d07f]
v3.5.beta1.official [b9b23d222]

### System information

Windows 10

### Issue description

When pausing with `get_tree().paused = true` any Particles2D particles that have existed for some seemingly arbitrarily short time disappear even if they have a longer lifetime.

This does not affect CPUParticles2D and doesn't affect Particles2D with `pause_mode` process. I'm not sure if it happens with 3D Particles.

https://user-images.githubusercontent.com/3820082/155030394-32994825-1fd3-4775-bba5-fae71a2e237f.mp4

### Steps to reproduce

Play the default scene in the attached MRP and pause at different times. No particles should be disappearing at all, but specifically Particles2D particles do.

### Minimal reproduction project

[pause-particles-mrp.zip](https://github.com/godotengine/godot/files/8112248/pause-particles-mrp.zip)
Repository: rust
Issue: failed to get bitcode from object file for LTO (Bitcode section not found in object file)
Labels: I-ICE,T-compiler,C-bug,E-needs-mcve

````
git clone https://github.com/rust-lang/rust-clippy
cd rust-clippy
git checkout 9e605ef80f05fbaec22677e633971096675f2650
echo "[profile.release]
codegen-units = 1
lto = true" >> Cargo.toml

cargo test --release
````
fails to build without any interesting details unfortunately
````
.....
   Compiling clippy v0.1.60 (/home/matthias/vcs/github/rust-clippy)
error: failed to get bitcode from object file for LTO (Bitcode section not found in object file)

error: could not compile `clippy` due to previous error
warning: build failed, waiting for other jobs to finish...
````

with `nightly-2022-02-10`

Seems to happen while compiling tests:
`    Building [=======================> ] 140/141: compile-test(test)`
Repository: go
Issue: make.bash: clarify that CGO_ENABLED=0 sets default into resulting compiler
Labels: Documentation,help wanted,NeedsFix

### What version of Go are you using (`go version`)?

<pre>
$ go version
1.17.7
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What did you do?

Ran `CGO_ENABLED=0 ./make.bash`.

### What did you expect to see?

I expected it to produce a compiler (without using cgo) that abides by the documented behavior for cgo. Namely, host builds have cgo enabled by default.

### What did you see instead?

The resulting compiler defaults to cgo disabled even for the host, as confirmed by `go env`.
Repository: kubernetes
Issue: Kubernetes controller manager may fail to manage deployment rollout with minReadySeconds and pod restarts
Labels: kind/bug,sig/apps,priority/important-longterm,triage/accepted

### What happened?

```
kubectl rollout restart deployment alpine ; kubectl rollout status deployment alpine
``` 

may exceed the deployment rollout progress deadlines if the deployment sets `minReadySeconds` and a new pod restarts during the rollout before the minimum ready seconds.

### What did you expect to happen?

Deployment rollout is successful.

### How can we reproduce it (as minimally and precisely as possible)?

Apply the following deployment on a 3 node cluster.  We are using 3 nodes here to simulate a multi zone cluster that spreads pods across zones.


```
kind: Deployment
apiVersion: apps/v1
metadata:
  labels:
    app: alpine
  name: alpine
spec:
  minReadySeconds: 30
  replicas: 3
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: alpine
  strategy:
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: alpine
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values: ["alpine"]
            topologyKey: kubernetes.io/hostname
      containers:
      - image: alpine:latest
        imagePullPolicy: IfNotPresent
        name: alpine
        command: ["sh", "-c", "if [[ ! -e /tmp/okay ]]; then touch /tmp/okay; sleep 15; exit; else sleep 100000; fi"]
        volumeMounts:
        - mountPath: /tmp
          name: tmp
      volumes:
      - name: tmp
        emptyDir: {}
```

then run `kubectl rollout restart deployment alpine ; kubectl rollout status deployment alpine`.


### Anything else we need to know?

Removing `minReadySeconds` from the example deployment will yield a successful rollout.  In addition, finding the Kubernetes controller manager leader via `kubectl get leases -n kube-system` and killing the leader will also allow the rollout to be successful.  The rollout will also succeed if the old replicaset is scaled down to zero replicas.

### Kubernetes version

Failure occurs on Kubernetes versions 1.20, 1.21, 1.22, 1.23 and 1.24.

### Cloud provider

N/A

### OS version

N/A


### Install tools

IBM Cloud Kubernetes Service

### Container runtime (CRI) and and version (if applicable)

N/A

### Related plugins (CNI, CSI, ...) and versions (if applicable)

N/A
Repository: godot
Issue: [Bullet] _integrate_forces(state) not reporting contacts, normals
Labels: bug,topic:physics

### Godot version

3.4.2

### System information

Debian 11 (Linux)

### Issue description

Hello,

When using the Bullet Physics Engine (currently the default for Godot 3.4), sometimes the _integrate_forces method fails to return a value other than 0 for get_contact_count or get_contact_local_normal, for a RigidBody. This appears to be similar to issue [43806](https://github.com/godotengine/godot/issues/43806).




### Steps to reproduce

Putting the following in a RigidBody's script displays the problem for me:

```
func _integrate_forces(state):
	print(state.get_contact_count())
	print(state.get_contact_local_normal(0))

```
I am including a project that should reproduce this problem below. Simply Run full speed toward the green ramp in the middle, and pay attention to the printout in the output window. The script in question is Lee.gd located in the assets folder. You should notice that the other two ramps work fine, as do most objects in the game. This problem seems to be frequently mitigated by using a trimesh collision sibling. However these do not always compensate for more complex meshes, such as the insides of cylinders.

### Minimal reproduction project

[gammaball.zip](https://github.com/godotengine/godot/files/8112490/gammaball.zip)
Repository: rust
Issue: rustc linker = aarch64-linux-gnu-ld, aarch64-linux-gnu-ld: cannot find -lgcc_s
Labels: A-linkage,S-needs-repro

the simple code

fn main() {
    println!("Hello, world!");
}


rustc 1.57.0-nightly (5ecc8ad84 2021-09-19)
binary: rustc
commit-hash: 5ecc8ad8462574354a55162a0c16b10eb95e3e70
commit-date: 2021-09-19
host: x86_64-unknown-linux-gnu
release: 1.57.0-nightly
LLVM version: 13.0.0

error:
= note: aarch64-linux-gnu-ld: cannot find -lgcc_s
Repository: flutter
Issue: [Android] jvm target compatibility should be set to the same Java version.
Labels: platform-android,tool,a: build,P2,team-android,triaged-android

```
[   +1 ms] 'compileDebugJavaWithJavac' task (current target is 1.7) and 'compileDebugKotlin' task (current
target is 1.8) jvm target compatibility should be set to the same Java version.
[ +706 ms] e:
C:\Users\sksso\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\webcontent_converter-0.0.7+1\android\src\main
\kotlin\app\mylekha\webcontent_converter\FLNativeViewFactory.kt: (10, 1): Class 'FLNativeViewFactory' is not
abstract and does not implement abstract base class member public abstract fun create(p0: Context?, p1: Int,
p2: Any?): PlatformView defined in io.flutter.plugin.platform.PlatformViewFactory
[   +7 ms] e:
C:\Users\sksso\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\webcontent_converter-0.0.7+1\android\src\main
\kotlin\app\mylekha\webcontent_converter\FLNativeViewFactory.kt: (11, 5): 'create' overrides nothing        
[ +374 ms] > Task :webcontent_converter:compileDebugKotlin FAILED
------------------

[   +1 ms] 'compileDebugJavaWithJavac' task (current target is 1.7) and 'compileDebugKotlin' task (current
target is 1.8) jvm target compatibility should be set to the same Java version.
[ +706 ms] e:
C:\Users\sksso\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\webcontent_converter-0.0.7+1\android\src\main
\kotlin\app\mylekha\webcontent_converter\FLNativeViewFactory.kt: (10, 1): Class 'FLNativeViewFactory' is not
abstract and does not implement abstract base class member public abstract fun create(p0: Context?, p1: Int,
p2: Any?): PlatformView defined in io.flutter.plugin.platform.PlatformViewFactory
[   +7 ms] e:
C:\Users\sksso\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\webcontent_converter-0.0.7+1\android\src\main
\kotlin\app\mylekha\webcontent_converter\FLNativeViewFactory.kt: (11, 5): 'create' overrides nothing        
[ +374 ms] > Task :webcontent_converter:compileDebugKotlin FAILED

```
Repository: PowerToys
Issue: FancyZones editor gracefully crashes while editing layout on secondary monitor.
Labels: Issue-Bug,FancyZones-Editor,Product-FancyZones,Severity-High,Needs-Team-Response

### Microsoft PowerToys version

0.55.2

### Running as admin

- [ ] Yes

### Area(s) with issue?

FancyZones Editor

### Steps to reproduce

Create a new layout for secondary monitor.
Add additional zones.

### ✔️ Expected Behavior

I should be able to add additional zones, resize and reposition them, and save.

### ❌ Actual Behavior

A window pops up asking me to report bug.
The layout editor closes without saving.

### Other Software

Edition	Windows 10 Home
Version	21H1
Installed on	‎22/‎06/‎2020
OS build	19043.1566
Experience	Windows Feature Experience Pack 120.2212.4170.0

It may possibly be worth mentioning my secondary monitor uses my i5 8400's iGPU, whereas my primary monitor uses my discrete AMD Radeon RX 570 card. And this issue is only happening when I try to create or edit a layout and add additional zones, for my secondary monitor.
Repository: transformers
Issue: Add TUNet
Labels: New model

# 🌟 New model addition

The TUNet model for audio superresolution

## Model description

[TUNet: A Block-online Bandwidth Extension Model based on Transformers and Self-supervised Pretraining](https://arxiv.org/abs/2110.13492v3) is a paper by Viet-Anh Nguyen, Anh H. T. Nguyen, and Andy W. H. Khong, introducing a model for audio superresolution based on transformers.

Audio superresolution allows for the upsampling of audio with minimal loss of quality. This is very useful for ASR tasks that require audio to be resampled during preprocessing, which has a big impact on transcriptions depending on the native sample rate.

## Open source status

* [x] the model implementation is available: [The official repo](https://github.com/NXTProduct/TUNet)
* [x] the model weights are available: [ONNX weights](https://github.com/NXTProduct/TUNet/tree/master/lightning_logs)
* [x] who are the authors: Viet-Anh Nguyen, Anh H. T. Nguyen, and Andy W. H. Khong
Repository: opencv
Issue: Why is uchar defined in the global namespace?
Labels: category: core,RFC

In opencv/modules/core/include/opencv2/core/hal/interface.h, data types, including uchar, ushort and uint, are defined in the global namespace, which is different from other variables defined in cv namespace. What is the purpose? When opencv is used with other library, there may be a name conflict.
Repository: excalidraw
Issue: Export (save) dialog doesn't respect iOS safe area
Labels: good first issue,UX/UI

Note how the `Export` string is hidden under the notch. Worse: the back button `<` is hidden under the `Carrier`, which becomes the `Back to previous app` button, so if you came to Excalidraw from another app (or launched it via search), you can effectively never go back and leave the dialog. 

![excalidraw com_(iPhone X)](https://user-images.githubusercontent.com/145676/155087006-bff301b6-9c12-49f2-bb77-2846dc9364e2.png)
Repository: PowerToys
Issue: more than one key do the same action in PowerToys Run
Labels: Idea-Enhancement,Product-PowerToys Run,Run-Plugin Manager

### Description of the new feature / enhancement

to search installed program  only  in PowerToys Run the default key is `.` , but in Chinese input method the period t is `。`. I hope using the `。` do the same thing instead of switch input method type `.`. 
So could PowerToys allow more than one key do same thing, or add a localization support to ignore  difference between half width and full width forms

### Scenario when this would be used?

I'm using PowerToys and Chinese keyboard, but use key to search in PowerToys Run, switch keyboard frequently.
Ｉｔ＇ｓ　ｔｅｒｒｉｂｌｅ．


### Supporting information

_No response_
Repository: electron
Issue: [Feature Request]: Rounded window corners on linux.
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Are there any plans for implementing rounded window corners on linux, just like in mac os and windows 11. Specially after given the fact that recently the Gnome desktop has started pushing towards rounded window corners in their own toolkit (GTK), and KDE is to follow suit with their KDE 6 Desktop, if I am not mistaken

I Would like to know if this has been in the project's roadmap at some point. If not, then why, and would also like to know what obstructions posed by the linux platform(s) is currently preventing this or has been preventing this feature till now.

### Proposed Solution

.

### Alternatives Considered

.

### Additional Information

_No response_
Repository: next.js
Issue: ERR_VM_DYNAMIC_IMPORT_CALLBACK_MISSING when running a custom server with esm
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in Next.js canary release

### Provide environment information

    Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 19.2.0: Sat Nov  9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64
    Binaries:
      Node: 16.13.0
      npm: 8.1.0
      Yarn: 1.22.0
      pnpm: N/A
    Relevant packages:
      next: 12.1.1-canary.1
      react: 17.0.2
      react-dom: 17.0.2


### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

### Describe the Bug

Not entirely sure if it's a problem on Next side or just a missing functionality on [esm](https://github.com/standard-things/esm) but using a custom nextJS 12 server with`-r esm` results in:

```
TypeError [ERR_VM_DYNAMIC_IMPORT_CALLBACK_MISSING]: A dynamic import callback was not specified.
    at new NodeError (node:internal/errors:371:5)
    at importModuleDynamicallyCallback (node:internal/process/esm_loader:39:9)
    at Object.loadConfig [as default] (/Users/danielzlotnik/dev/source/next-12-esm-issue/node_modules/next/dist/server/config.js:448:78)
    at async NextServer.loadConfig (/Users/danielzlotnik/dev/source/next-12-esm-issue/node_modules/next/dist/server/next.js:116:22)
    at async NextServer.prepare (/Users/danielzlotnik/dev/source/next-12-esm-issue/node_modules/next/dist/server/next.js:98:24) {
``` 



### Expected Behavior

`esm` should support dynamic imports so not entirely sure what's the specific issue here.

Either-way would be great if Next 12 played along with `esm`.

### To Reproduce

https://github.com/danielzlotnik/next-12-esm-issue

**A basic custom server**
```
// server.js
const { createServer } = require('http');
const { parse } = require('url');
const next = require('next');

const dev = process.env.NODE_ENV !== 'production';
const hostname = 'localhost';
const port = 3000;

const app = next({ dev, hostname, port });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  createServer(async (req, res) => {
    try {
      const parsedUrl = parse(req.url, true);
      await handle(req, res, parsedUrl);
    } catch (err) {
      console.error('Error occurred handling', req.url, err);
      res.statusCode = 500;
      res.end('internal server error');
    }
  }).listen(port, err => {
    if (err) throw err;
    console.log(`> Ready on http://${hostname}:${port}`);
  });
});
```

**Run with -r esm**
```
{
  "scripts": {
    "dev": "node -r esm server.js", // right here
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },
  "dependencies": {
    "esm": "^3.2.25",
    "next": "12.1.1-canary.1",
    "react": "17.0.2",
    "react-dom": "17.0.2"
  },
  "devDependencies": {
    "eslint": "8.9.0",
    "eslint-config-next": "12.1.0"
  }
}
```
Repository: godot
Issue: Godot 4 does not respect OS power settings, always selects high performance GPU.
Labels: bug,topic:rendering,topic:porting,confirmed,regression

### Godot version

v4.0.alpha3.official [256069eaf]

### System information

Windows 10, Vulkan, Hybrid Laptop - AMD iGPU(Ryzen 7 4800HS) + GTX 1660 Ti Max-Q

### Issue description

Godot 3 always picks the correct GPU to use based on which power profile/settings are active in Windows, (Integrated low power GPU when on power saving, high performance dedicated GPU when on AC power).
Godot 4 currently always fails to do this on my system, it always picks the high performance GPU regardless of whatever power profile is active.
This makes testing on different GPU's on multi GPU systems a tedious process, I understand you can use --gpu-index to manually select which GPU to use, but this launch option does not persist correctly in the editor.

When I run the editor like this:
.\godot.exe --gpu-index 1 --path "path\to\project" -e
(gpu-index 1 being my integrated GPU, and 0 the high powered one.)

The editor opens up fine with the chosen GPU, but when I run the game for testing (F5 or F6) in the editor afterwards, it just opens up with the high performance GPU again, ignoring everything else.

Not sure if this happens on Linux, I don't have a multi-GPU device running Linux at the moment, so I can't test.
Perhaps someone else with a multi-GPU setup running Linux could test this.

### Steps to reproduce

Put your system on a power saving profile or force the Godot4 executable to use the Power Saving setting in Windows, which you can set in the "Graphics Settings" pane.
![image](https://user-images.githubusercontent.com/781121/155158927-2821562a-1559-4f8a-8f5c-69cd1be8c0f8.png)

Then run Godot 4 in a terminal window to see which GPU its using.

### Minimal reproduction project

Not Applicable
Repository: rust
Issue: Compiler bootstrap infrastructure and tests should be exercising `-g` more aggressively
Labels: A-testsuite,A-debuginfo,T-compiler

On https://github.com/rust-lang/rust/pull/93006 a change landed that broke `rustc -g` for unsized tuples, in a manner that ICE'd the compiler.

We didn't notice that it happened until nearly two weeks later, when  #93866  and  #93871 were filed.

The reason I'm filing a bug is that we have tests of unsized tuples; even the libcore test suite itself uses them. (I.e., this bug broke my attempts to bootstrap Rust itself with `debuginfo-level = 2` in the `config.toml`. But the test suite itself is not exercising `-g` enough to observe that combination.

At the very least, PR's that are making changes to debuginfo should be going through the process of bootstrapping with `debuginfo-level = 2`, as a sanity check.