sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: deno
Issue: tsc --generateTrace output
Labels: suggestion,tsc

I have written a deno library that appears to have a decently slow type compilation stage. I would like to be able to use microsoft's analysis tool https://github.com/microsoft/typescript-analyze-trace to determine where my compilation bottlenecks occur.

Currently, running `tsc --generateTrace .` at the root of my project fails with exit code `1`. The first reason it fails, is that it requires a tsconfig.json file to be present. Thus far, I havent had a need to write one since deno's defaults have been good enough this far. Once a tsconfig.json file is created though, there is a problem I do not believe I can solve userland.
```
lib/mod.ts:2:21 - error TS2691: An import path cannot end with a '.ts' extension. Consider importing 'https://deno.land/std@0.91.0/fs/mod' instead.
```

not to mention some other errors that I do not know how to solve:
```
lib/mod.ts:67:31 - error TS2304: Cannot find name 'Deno'.
```


I am proposing that deno add a new flag `--trace-types=<trace.json>` under `deno run`, `deno test` that maps the `tsc --generateTrace` output. Alternatively, another top level command like `deno analyze` or `deno trace` could work, but I dont know if this deserves its own top level command.
Repository: neovim
Issue: More informative message and stacktrace for errors from remote plugins or lua call
Labels: enhancement,logging

### Feature already in Vim?

N/A

### Feature description

This is something between (regression) bug or feature request. 

## python remote plugins

When remote (python) plugin throws an error or exception *during an execution of pynvim(neovim) API*, there is no much debugging information available.

For example,

```
python3-rplugin-host: Async request caused an error:
Invalid buffer id: 421
Press ENTER or type command to continue
```

without information about (i) such a neovim API (e.g., `vim.async_call`) is called by which remote plugin, nor (ii) stacktrace of the plugin.

Note that when a python exception is raised (from the python remote plugin), it correctly prints the stack trace:
```
error caught in async handler '.../vim/plugged/some-plugin/rplugin/python3/some_module:function:SomeCommand [args]'
Traceback (most recent call last):
  ...
```

## Lua plugins

When it comes to a lua plugin, sometimes the whole stacktrace are printed in a single line:

For example (this bug is not specific to fidget.nvim; it's just one example),

```
Error detected while processing function clever_f#find_with[44]..<SNR>175_getchar:                                                                     
line    2:
Error executing vim.schedule lua callback: /Users/wookayin/.vim/plugged/fidget.nvim/lua/fidget.lua:190: E523: Not allowed here^@stack traceback:^@^I[C]: in func
tion 'nvim_open_win'^@^I/Users/wookayin/.vim/plugged/fidget.nvim/lua/fidget.lua:190: in function 'show'^@^I/Users/wookayin/.vim/plugged/fidget.nvim/lua/fidget.l
ua:55: in function </Users/wookayin/.vim/plugged/fidget.nvim/lua/fidget.lua:51>
```

where the stacktrace message is printed without actual carriage return but a literal character `^@^I`. I remember this was not the case at some earlier neovim versions (like v0.5), but since some point neovim started to print the stacktrace in a difficult-to-read format.
Repository: pytorch
Issue: kthvalue 20x slower than sort 
Labels: module: performance,triaged,module: sorting and selection

### 🐛 Describe the bug

An example task: find 2nd smallest element in a huge tensor on a cuda-device. 

1) First approach via `torch.sort`:
```python
import torch
import time

elapsed = 0.0
runs = 100
for i in range(runs):
    tensor = torch.rand(100_000_000, device='cuda:0')

    torch.cuda.synchronize()
    start = time.time()

    sorted, _ = tensor.sort()
    second_smallest_el = sorted[1]

    torch.cuda.synchronize()
    end = time.time()
    elapsed += end - start

print(elapsed/runs)  # 0.03 sec
```
2) Second approach via `torch.kthvalue`:
```python
import torch
import time

elapsed = 0.0
runs = 100
for i in range(runs):
    tensor = torch.rand(100_000_000, device='cuda:0')

    torch.cuda.synchronize()
    start = time.time()

    val, _ = torch.kthvalue(tensor, 2)

    torch.cuda.synchronize()
    end = time.time()
    elapsed += end - start

print(elapsed/runs)  # 0.68 sec
```

I would expect much better running time of the `kthvalue`, especially when `k` is as small as `2`.

### Versions

Collecting environment information...
PyTorch version: 1.11.0
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 10 (buster) (x86_64)
GCC version: (Debian 8.3.0-6) 8.3.0
Clang version: Could not collect
CMake version: version 3.13.4
Libc version: glibc-2.28

Python version: 3.8.12 (default, Oct 12 2021, 13:49:34)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-4.19.0-19-amd64-x86_64-with-glibc2.17
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration:
GPU 0: GeForce RTX 3090

Nvidia driver version: 460.73.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[conda] blas                      1.0                         mkl
[conda] cudatoolkit               11.3.1               h2bc3f7f_2
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py38h7f8727e_0
[conda] mkl_fft                   1.3.1            py38hd3c417c_0
[conda] mkl_random                1.2.2            py38h51133e4_0
[conda] mypy-extensions           0.4.3                    pypi_0    pypi
[conda] numpy                     1.22.3                   pypi_0    pypi
[conda] numpy-base                1.21.2           py38h79a1101_0
[conda] pytorch                   1.11.0          py3.8_cuda11.3_cudnn8.2.0_0    pytorch
[conda] pytorch-mutex             1.0                        cuda    pytorch
[conda] torchvision               0.12.0               py38_cu113    pytorch

cc @VitalyFedyunin @ngimel
Repository: PowerToys
Issue: [Settings] Make a page for "About this App"
Labels: Idea-Enhancement,Product-Settings,Area-User Interface

### Description of the new feature / enhancement

My idea is to create a Page titled "About this App".

- We can move version info and the <kbd>Update</kbd> **button** here.
- We can write out tips and faq's - for example a **HyperlinkButton** to the repo for existing issues.
- We can add image and text explaining the bug-report-file; add a **button** "Create zip-file"
   - **button** "Give Feedback". (Why don't we use WIndows Feedback hub?)
   - **HyperlinkButton** for Github website
- We can move the **HyperlinkButton** to Release notes (OOBE or online?) here
- App information that isn't accessed very often, such as privacy policy, help, app version, or copyright info. Any "Terms of Use" and "Privacy Statement"

### Scenario when this would be used?

updating ux

### Supporting information

https://docs.microsoft.com/windows/apps/design/app-settings/guidelines-for-app-settings#about-section-and-feedback-button

Exerpts:

> If a setting directly links to the web instead of to a flyout, let the user know this with a visual clue [...]
[Hyperlinks](https://docs.microsoft.com/windows/apps/design/controls/hyperlinks): To take the user to another page within the app or to an external website.
Don't use buttons for navigation or to commit changes.

https://docs.microsoft.com/en-us/windows/apps/design/controls/hyperlinks#create-a-hyperlinkbutton

Related to #17611
Repository: rust
Issue: Give a better error when using an undeclared macro variable
Labels: A-diagnostics,E-mentor,A-macros,T-compiler,E-medium

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a17456ca7139db13e945cbde87ae6fbd

```rust
macro_rules! m {
    () => {
        $x;
    }
}

fn foo() {
    m!()
}
```

The current output is:

```
error: expected expression, found `$`
 --> src/lib.rs:3:9
  |
3 |         $x;
  |         ^^ expected expression
...
8 |     m!()
  |     ---- in this macro invocation
  |
  = note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info)
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error[E0425]: cannot find macro parameter `$x` in this scope
 --> src/lib.rs:8:5
  |
2 |    () => {
  |    ^^ in this macro matcher
3 |     $x;
  |     ^^ not found in this scope
...
8 |     m!()
  |     ---- in this macro invocation
  |
  = note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info)
```

@rustbot label +A-macros

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: terminal
Issue: Notice in UI on updating the Terminal app + Fix a Release Notes link to point to the actual release page and not generic releases page
Labels: Help Wanted,Area-UserInterface,Product-Terminal,Issue-Task,good first issue

I've just acquired a new laptop, it installed "Windows Terminal Version: 1.6.10571.0" with Win11, and this Terminal is quite old, it doesn't even include a Settings UI. It would be nice if Terminal app included a way to update itself or at least a notice on this in About window.

Ideally there should be an easy updating mechanism no matter how WT is installed (if via msix, it should offer to download the latest msix etc)

Also clicking on Release Notes there in About window redirects to generic repo's release notes, and not notes of the specific release.
Repository: rust
Issue: Compiler error fails to show unsatisfied bounds on trait implementation
Labels: A-diagnostics,T-compiler,E-needs-mcve,D-confusing


```rust
use pyo3::prelude::*;
use std::collections::HashMap;

fn foo(thing: &PyAny) {
    let arg0: HashMap<Py<PyAny>, u32> = FromPyObject::extract(thing).unwrap();
}

```

The current output is:

```
error[E0277]: the trait bound `HashMap<pyo3::Py<pyo3::PyAny>, u32>: pyo3::FromPyObject<'_>` is not satisfied
 --> src\lib.rs:5:41
  |
5 |     let arg0: HashMap<Py<PyAny>, u32> = FromPyObject::extract(thing).unwrap();
  |                                         ^^^^^^^^^^^^^^^^^^^^^ the trait `pyo3::FromPyObject<'_>` is
 not implemented for `HashMap<pyo3::Py<pyo3::PyAny>, u32>`
  |
  = help: the trait `pyo3::FromPyObject<'source>` is implemented for `HashMap<K, V, S>`

For more information about this error, try `rustc --explain E0277`.
```
In fact, this error is caused by `Py<PyAny>` not implementing `Hash` (and `Eq`). But this is not shown in the error message!

Somehow the unsatisfied bounds on the `FromPyObject` trait are lost. For reference, this is its [definition](https://github.com/PyO3/pyo3/blob/main/src/types/dict.rs#L342-L356):
```rust
impl<'source, K, V, S> FromPyObject<'source> for HashMap<K, V, S>
where
    K: FromPyObject<'source> + cmp::Eq + hash::Hash,
    V: FromPyObject<'source>,
    S: hash::BuildHasher + Default,
{
    fn extract(ob: &'source PyAny) -> Result<Self, PyErr> {
        // ...
    }
}
```

When trying to create a minimal example (by just shimming the trait in an empty crate), the lacking bounds are correctly shown. Unfortunately I can't figure out how to reproduce the error above.
```
error[E0277]: the trait bound `Py<PyAny>: Eq` is not satisfied
 --> src\main.rs:9:41
  |
9 |     let arg0: HashMap<Py<PyAny>, u32> = FromPyObject::extract(unwrapped).unwrap();
  |                                         ^^^^^^^^^^^^^^^^^^^^^ the trait `Eq` is not implemented for `Py<PyAny>`
  |
  = help: the trait `FromPyObject<'source>` is implemented for `HashMap<K, V, S>`
  = note: required because of the requirements on the impl of `FromPyObject<'_>` for `HashMap<Py<PyAny>, u32>`

error[E0277]: the trait bound `Py<PyAny>: Hash` is not satisfied
 --> src\main.rs:9:41
  |
9 |     let arg0: HashMap<Py<PyAny>, u32> = FromPyObject::extract(unwrapped).unwrap();
  |                                         ^^^^^^^^^^^^^^^^^^^^^ the trait `Hash` is not implemented for `Py<PyAny>`
  |
  = help: the trait `FromPyObject<'source>` is implemented for `HashMap<K, V, S>`
  = note: required because of the requirements on the impl of `FromPyObject<'_>` for `HashMap<Py<PyAny>, u32>`

For more information about this error, try `rustc --explain E0277`.
```
Repository: PowerToys
Issue: Image resizer extended functionality **AND** resized image location/output
Labels: Idea-Enhancement,Product-Image Resizer,Needs-Triage

### Description of the new feature / enhancement

1) the most best awesome thing that would help me would be to allow a user to set an alternate default functionality for image resizing. for instance... it would be nice to be able to set a certain size for the image resizer to be used as default. when a user selects pictures/images, and right clicks them, then selects "Resize pictures", the alternate functionality would be no popup displayed and instead it would just use whatever your default setting is that you select in settings in the powertoys app. this way no user intervention is needed after you create a size and options, then set it as default, then you just right click an image and it resizes it without any extra popups or intervention.

2) the second thing this needs is to allow a user to toggle some setting for "save resized pictures in a sub directory within the current working directory of image resizer. so if i had images in C:\images\an_image.jpeg and selected to resize it, then it would automatically create a subdirectory in C:\images called "Converted - %size" or "Resized - %size" like "C:\images\Resized - 1280x720\an_image.jpeg"

i think if these two things were added, this image resizer would be a complete and final product, atleast in my eyes. i remember the days where i had to use photoshop to do this and you had to do it one by one until i realized you could photoshop them in a batch through ps settings. but having a right click context menu use a default config (so no popups or extra intervention is needed) and then a new directory is made in CWD for any new, resized, images.

### Scenario when this would be used?

it would be used when a user needs to resize a plethora of photos or images and didnt want to have to sift through the same directory with multiple copies/sizes. maybe even make the newly created directories name something like "Resized - %size" or something. that way your photos are organized in their own respective folders for each size you needed.

hope it is not to confusing to understand. the main goal is to reduce clicks and any user intervention after it is setup in powertoys image resizer settings. if i need to elaborate then dont hesitate to ask

### Supporting information

i work a lot with building transmissions and working on game console and tv hardware/software and am constantly taking a plethora of pictures and send these out to clients to show them problems or certain procedures or whatever the moment calls for. having this added functionality would allow me to easily and seamlessly resize images down to a size that can transfer quickly and also keep everything organized. my computer is starting to look like a crazy person owns it <.< well i might be crazy but thats besides the point XD
Repository: PowerToys
Issue: add custom handlers for preview pane
Labels: Idea-Enhancement,Product-File Explorer,Needs-Triage

### Description of the new feature / enhancement

it would be nice to be able to create add a program to be used as a handler of sorts. like for when you are going through source code files, liek .c and .cpp .py .pl and much more... to be able to use notepad++. this would give you the benefit of having syntax highlighting and such. i am not to sure if this is possible or not but it would be a great addition.

### Scenario when this would be used?

when you are going through some files and see on old source code you worked on 13 years ago but got in a fight with your exe then forgot about it.... and upon clicking on it you see some spaghetti without the sauce :( being able to add programs like notepad++ or even HxD as custom preview handlers would be cool. then you could get syntax highlighting when selecting source code etc.

### Supporting information

_No response_
Repository: godot
Issue: Sending GetSystemTimeMsecs() over Enet multiplayer returns in 1 sec delay
Labels: bug,needs testing,topic:network,topic:dotnet,topic:multiplayer

### Godot version

3.4.4.stable.mono

### System information

Linux 5.16.18 Fedora 35, GLES3 

### Issue description

Trying to send server time in physics process unreliably to every client and client receives batches of the same time:
```
1649705657450
[about 20 same times]
1649705659451
[about 20 same times]
1649705660451
[about 20 same times]
```
I know some packets may duplicate or corrupt, but I expect some packets may be at least 0.1 different. I haven't tested GDscript, but it does not work on Mono.

Sending time code:
```
public override void _PhysicsProcess(float delta)
{
    if (_connectedCount > 0)
    {
        var time = OS.GetSystemTimeMsecs();
        RpcUnreliable("GetTime", time);
    }
}
```

Receiving time code:
```
[Remote]
private void GetTime(ulong time)
{
    GD.Print(time);
}
```

### Steps to reproduce

1. Create projects for client and server
2. On the servers physics process send unreliable rpc with OS.GetSystemTimeMsecs() as an argument
3. On the client create remote function which receives time, print it.

### Minimal reproduction project

[Issue.zip](https://github.com/godotengine/godot/files/8467247/Issue.zip)
[IssueClient.zip](https://github.com/godotengine/godot/files/8467249/IssueClient.zip)
Repository: vscode
Issue: Allow comment UI to be triggered via a clickable icon in the gutter
Labels: feature-request,comments

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

Following up on a conversation with @isidorn [here](https://github.com/TeamCodeStream/codestream/issues/908).

We've love to be able to use the comment API, though we have some concerns about the current mechanism for initialing a comment. For our use, having a clickable icon in the editor gutter to kick off that comment would be the ideal UX (see attached image below)

<img width="234" alt="Screen Shot 2022-04-11 at 3 49 06 PM" src="https://user-images.githubusercontent.com/834948/162818178-0a4d6411-9c55-4067-95de-5dc90b32501e.png">
Repository: go
Issue: gopls/internal/regtest: use a real file system notifier
Labels: Testing,gopls

It looks like several gopls testing flakes may be related to inaccurate file system notifications (e.g. #51930).

Historically, the gopls regtests had executed in the x/tools module, and so could not import cross platform libraries for filesystem notifications (e.g. https://github.com/fsnotify/fsnotify). To work around this, file watching is 'faked' via polling.

The regtests are now in x/tools/gopls, and we should consider replacing this polling with an actual notification library. This would theoretically reduce flakes and improve accuracy.
Repository: pytorch
Issue: [ONNX] Support unit tests in scripting that we already support in tracing
Labels: module: onnx,triaged,onnx-triaged

- [x] Enable scripting tests that are currently working due to recent changes in pytorch export https://github.com/pytorch/pytorch/pull/77254
- [ ] Non-scriptable operators (as_strided, transformer_encoder)
- [ ] Dict type (ONNX map) not supported https://github.com/pytorch/pytorch/issues/81482
- [ ] Shape/type inference issues
- [ ] Issues related to support for kwargs/args https://github.com/pytorch/pytorch/issues/81478
- [ ] args* issues post compilation
- [ ] Support for optional type inference
- [ ] Input/output shape issues
- [ ] Issues due to ONNX Spec Gaps
- [ ] Failures from jit_pass_lower_tuple
- [ ] Failures from jit_pass_mutation https://github.com/pytorch/pytorch/pull/79555
- [ ] User defined/custom class support
- [ ] Model code not scriptable
- [ ] Unscriptable modules
- [x] Support for Union Types https://github.com/pytorch/pytorch/pull/77254



Migrated from the work item:
<https://microsoft.sharepoint.com/:x:/r/teams/ONNX2/_layouts/15/Doc.aspx?sourcedoc=%7B2F53DDC4-54E9-488F-B5CB-C114937A3E90%7D&file=TorchScript%20Export%20Issues.xlsx&wdOrigin=OFFICECOM-WEB.MAIN.SEARCH&ct=1636674278879&action=default&mobileredirect=true&share=IQHE3VMv6VSPSLXLwRSTej6QAWZK7HjHmHw9xD4UMRwbV4U&cid=9094dc65-62dd-4898-86b4-84904add63f7>
Repository: youtube-dl
Issue: Option for path prefix for info-json file (e.g. save to subdirectory)
Labels: request

Option to for path prefix for info-json file (e.g. save to subdirectory)

## Checklist

- [x] I'm reporting a feature request
- [x] I've verified that I'm running youtube-dl version **2021.12.17**
- [x] I've searched the bugtracker for similar feature requests including closed ones


## Description

I like to use `--write-info-json`, and I also almost like how it uses the filename template from the `--output` option. However, it's just "almost" because I want it in a subdirectory.

Future me might want it in an entirely different path, or with a filename prefix in the same directory, so I prefer the more general option of a path prefix.

If the prefix causes the info json file path to contain directory information, I'd like yt-dl to make a weak attempt at creating that directory. Failure in this tshall be silent and shall be ignored. The thing I actually care about is whether the info json can be written, and on exotic file systems, that might be entirely independent from directory creation.

In case this feature exists already, the feature request is instead about adding a hint to `--help`'s description of `--write-info-json` on how to have it be written to a subdirectory.

Would maintainers like to merge this? Shall I try and implement it?
Repository: frp
Issue: [Feature Request] http请求时请求头添加一个proxy_name，然后通过proxy_name找到对应的frpc客户端代理
Labels: proposal

### Describe the feature request

想通frpc客户端主机做http代理，发送实际请求
* 使用tcp端口，大量设备，需要按端口绑定访问,不好端口和设备对应，
* 子域名无法实现

1. 用户http请求frps，在http请求头中加一个proxy_name,proxy_name为设备ID,方便直接找到对应设备
2. 通过请求头中的proxy_name,找到对应的frpc客户端连接，删除proxy_name,
3. 将用户的http请求转发到frpc客户端
4. frpc再将http请求转发给后端的http代理
5. http代理发送用户请求


### Describe alternatives you've considered

_No response_

### Affected area

- [ ] Docs
- [ ] Installation
- [ ] Performance and Scalability
- [ ] Security
- [ ] User Experience
- [ ] Test and Release
- [ ] Developer Infrastructure
- [ ] Client Plugin
- [ ] Server Plugin
- [ ] Extensions
- [ ] Others
Repository: go
Issue: x/build/cmd/golangbuild: TryBot fails with "no packages to test" if an x/ repo contains a module with only an OS-specific package
Labels: Builders,NeedsInvestigation

The non-Windows TryBots are failing on [CL 399834](https://go.dev/cl/399834) due to the `winfsnotify` package, which is build-constrained to only exist on Windows.

The package has always been build-constrained to only exist on WIndows, but up until that CL it was not the only package in its module. Once it is carved out, `go test ./...` within that module fails with the message `no packages to test` (added in [CL 5495055](https://go.dev/cl/5495055)).

Since the package and module are being deleted entirely in a subsequent CL, for now we can probably just accept and ignore one CL of builder failures. (It's not ideal, but I can filter out a single broken commit during builder triage pretty easily.)

In the longer term, this might be good to fix alongside #51455 (CC @golang/release).