sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Custom hover is slightly off-screen on the right
Labels: polish,workbench-hover

See how part of `n` is eaten away

![Image](https://github.com/microsoft/vscode/assets/16353531/4ac5c82e-96e0-4c99-982e-ca210e25121d)

Happens on github.dev codespace

https://github.com/microsoft/vscode/assets/16353531/9adb06e3-1e7a-47d4-9b44-b205419e9a66


Version: 1.90.0-insider
Commit: 89de5a8d4d6205e5b11647eb6a74844ca23d2573
Date: 2024-06-04T01:34:49.767Z
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36
Repository: vscode
Issue: Add context menu item to relaunch terminals with extra environment info
Labels: feature-request,papercut :drop_of_blood:,terminal-tabs

Currently, when launching VS Code I often see terminals (including ones that just run tasks) have warnings that some terminal env contributions couldn't happen, so I need to relaunch the terminal. 

Since the orange warning is quite eye-catching and distracting, I relaunch those terminals, but it's quite tedious because it can be done either using a link within hover, which is easy to lose on inaccurate mouse move and also non-keyboard friendly, or by killing and relaunching the terminal.

To alleviate this problem, could we add right-click context menu items to

- relaunch a specific terminal
- relaunch all terminals (including tasks)

This has become quite a pain point for me when I very often get these warnings and have to kill all terminals one by one and relaunch them (this's necessary for terminals with tasks running)

https://github.com/microsoft/vscode/assets/16353531/00e5e155-d711-494a-a683-2f1a833f1280
Repository: vscode
Issue: Alt-L (Find in Selection) replaces block selection with multiline selection
Labels: bug,editor-find

Does this issue occur when all extensions are disabled?: Yes
    VS Code Version: 1.89.1
    OS Version: Ubuntu Linux 22.04

1. Close the find/replace window if it's open (click on the X in the upper-right) 
2. Use Alt-Shift-Leftclick to make a block selection
3. Press Ctrl-H to start search
4. Press Alt-L to enable "Find in Selection"

The block selection is replaced with a multi-line selection, but only the lines that had text under the block are part of the multiline.

Before pressing Alt-L:
![image](https://github.com/microsoft/vscode/assets/1065860/535b1071-daf2-4a85-af99-e74d202d0196)

After pressing Alt-L:
![image](https://github.com/microsoft/vscode/assets/1065860/9e4c49f5-173c-4511-a7c9-3e1a99f4a189)

Weirdly, it appears that the find/replace does still honor the original block selection (it only replaces text in the original block), but the block itself is no longer visible.

Basically, it just looks like the block selection features was added recently and not thoroughly tested with find/replace.
Repository: ollama
Issue: deepseek v2 lite and 236b gets crazy after some conversations
Labels: bug

### What is the issue?

Hi Ollama team:

I loaded the modes and keep them stay in memory. After some conversations, the models start to response with strange text and codes. After restarting ollama in ubuntu, the issue is gone.

### OS

Linux

### GPU

_No response_

### CPU

AMD

### Ollama version

0.1.40
Repository: pytorch
Issue: Document the torch.fx.experimental.proxy_tensor.make_fx function
Labels: module: docs,triaged,medium,docathon-h1-2024

Document the `torch.fx.experimental.proxy_tensor.make_fx` function located in [https://github.com/pytorch/pytorch/blob/main/torch/fx/experimental/proxy_tensor.py#L1147](https://github.com/pytorch/pytorch/blob/main/torch/fx/experimental/proxy_tensor.py#L1147).
Follow the [Docstring Guidelines](https://github.com/pytorch/pytorch/wiki/Docstring-Guidelines).

cc @brycebortree
Repository: pytorch
Issue: Document the torch.fx.experimental.proxy_tensor.track_tensor_tree function
Labels: module: docs,triaged,medium

Document the `torch.fx.experimental.proxy_tensor.track_tensor_tree` function located in [https://github.com/pytorch/pytorch/blob/main/torch/fx/experimental/proxy_tensor.py#L216](https://github.com/pytorch/pytorch/blob/main/torch/fx/experimental/proxy_tensor.py#L216).
Follow the [Docstring Guidelines](https://github.com/pytorch/pytorch/wiki/Docstring-Guidelines).

cc @brycebortree
Repository: pytorch
Issue: Document the torch.fx.experimental.proxy_tensor.disable_proxy_modes_tracing function
Labels: module: docs,triaged,medium

Document the `torch.fx.experimental.proxy_tensor.disable_proxy_modes_tracing` function located in [https://github.com/pytorch/pytorch/blob/main/torch/fx/experimental/proxy_tensor.py#L1290](https://github.com/pytorch/pytorch/blob/main/torch/fx/experimental/proxy_tensor.py#L1290).
Follow the [Docstring Guidelines](https://github.com/pytorch/pytorch/wiki/Docstring-Guidelines).

cc @brycebortree
Repository: pytorch
Issue: Document the torch.fx.traceback.preserve_node_meta function
Labels: module: docs,triaged,medium,docathon-h1-2024

Document the `torch.fx.traceback.preserve_node_meta` function located in [https://github.com/pytorch/pytorch/blob/main/torch/fx/traceback.py#L16](https://github.com/pytorch/pytorch/blob/main/torch/fx/traceback.py#L16).
Follow the [Docstring Guidelines](https://github.com/pytorch/pytorch/wiki/Docstring-Guidelines).

cc @brycebortree
Repository: pytorch
Issue: Document the torch.cuda.profiler.start function
Labels: module: docs,triaged,medium,docathon-h1-2024

Document the `torch.cuda.profiler.start` function located in [https://github.com/pytorch/pytorch/blob/main/torch/cuda/profiler.py#L47](https://github.com/pytorch/pytorch/blob/main/torch/cuda/profiler.py#L47).
Follow the [Docstring Guidelines](https://github.com/pytorch/pytorch/wiki/Docstring-Guidelines).

cc @brycebortree
Repository: godot
Issue: Input map: assigning input map with Key Label (Unicode, Case-Insensitive) mode may suddenly show a triple Label or Physical or Unicode
Labels: discussion,needs testing,topic:input

### Tested versions

- Reproducible in v4.2.1.stable.official [b09f793f5]

### System information

Godot v4.2.1.stable - Ubuntu 22.04.4 LTS 22.04 - X11 - Vulkan (Mobile) - dedicated NVIDIA GeForce GTX 860M (nvidia; 535.161.07) - Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (8 Threads)

### Issue description

The exact conditions to trigger this are unclear, but generally speaking, when working with input map in Key Label (Unicode, Case-Insensitive) mode, they may suddenly change from `input (Unicode)`

![image](https://github.com/godotengine/godot/assets/1067772/50b77df5-e412-44e5-9ff9-aec3fd916592)

to `input or input (Physical) or input (Unicode)`

![image](https://github.com/godotengine/godot/assets/1067772/3c345dde-419b-4692-89a4-d1d5c8f46370)

and it shows in git diff:

![image](https://github.com/godotengine/godot/assets/1067772/428dc24e-1782-4ab3-bf62-7595e45f1c16)

Sometimes I must change the input back and forth (changing the key or the mode) to force refresh to just "(Unicode)".

Sometimes adding an unrelated input suddenly modifies the existing one!

I wanted to record a GIF but of course, when I tried to repro I couldn't.

That said, the triplet *must* be coded somewhere so it should be easy to find what in the code can create it, and from there we can deduce the conditions triggering it. To me it seems that it would make sense for special keys like Space which are always in the same place, but it's weird for keys like Q which can definitely change place.

Note: in the real game the binding seems to behave like Unicode, it's not mapped to *both* physical and unicode (e.g. Q is not triggered on both A and Q when using Azerty). But I haven't tested it for a while as I now force refresh when I can to be clean.

### Steps to reproduce

1. Add a Key Label (Unicode) input
2. Add other inputs
3. Modify modifier keys...
4. And hope for the bug to appear

### Minimal reproduction project (MRP)

N/A
Repository: godot
Issue: GPUParticle2D With alpha or scale curve becomes completely invisible after export to Android
Labels: bug,platform:android,topic:rendering,topic:2d

### Tested versions

- Reproducible in v4.3beta1

### System information

Godot v4.3.beta1 - macOS 14.5.0 - GLES3 (Compatibility) - AMD Radeon Pro 560X OpenGL Engine - Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz (12 Threads)

### Issue description
Just what the title says.

### Steps to reproduce
Add alpha curve to a GPUParticle2D

### Minimal reproduction project (MRP)
I Initially thought this had to do with the new glow feature, so the MRP contains a little more than required.

[mrp.zip](https://github.com/user-attachments/files/15567434/mrp.zip)
Repository: opencv
Issue: Window freezes after 4 updates
Labels: bug,platform: win32

### System Information

OpenCV version: 4.9.0
Operating System / Platform: Windows 10 x64
Compiler & compiler version: MinGW GCC 7.3.0

OpenCV python version:  4.9.0.80
Operating System / Platform: Windows 10 x64
Python version: 3.9.6

### Detailed description
Before that I had #25676 issue and fixed it as described in my comment in this issue.
I try to show image/stream video to window using openCV but this window freezes after exactly 4 updates. No matter what language I use: cpp/python/go, result always is the same. This problem appears on 2 different windows machines.
Result of code execution:
![image](https://github.com/opencv/opencv/assets/81556924/bb58ce17-67e5-4fa5-84c3-2ddc3ea4ce63)


### Steps to reproduce

Cpp code:
```cpp
#include <opencv2/core.hpp>
#include <opencv2/imgcodecs.hpp>
#include <opencv2/highgui.hpp>
#include <iostream>

using namespace cv;
using namespace std;
int main()
{
    std::string image_path = samples::findFile("pic.png");
    cv::Mat image = cv::imread(image_path, cv::IMREAD_COLOR);

    for(;;) {
        cout << "x\n";
        cv::imshow("Output Window", image);
        cv::waitKey(1);
    }

    return 0;
}
```
Python code:
```python
import cv2

video = cv2.VideoCapture(0)
address = "https://192.168.0.23:8080/video"
video.open(address)

while(1):
    print("x\n")
    check, frame = video.read()
    cv2.imshow("zcx", frame)
    k = cv2.waitKey(1) & 0xFF
    if k == 27:
        break
```

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [x] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: go
Issue: net/http: move HTTP/2 into std
Labels: NeedsFix

The `net/http` package includes transparent support for HTTP/2. The source of truth for this implementation is the `golang.org/x/net/http2` package, which is vendored into `std` (using a rather complicated process to avoid import cycles). The `http2` package also exposes a number of configuration settings and features which are not directly accessible from `net/http`.

There were good reasons for starting development of the HTTP/2 implementation outside of `std`, but the current state of affairs is confusing and inconvenient. Backporting HTTP/2 fixes into minor releases is difficult. New versions of `net/http` need to support old versions of `x/net`. We can't make changes to the HTTP/1 and HTTP/2 implementations atomically. Users need to import an x/ package to configure HTTP/2 settings.

This issue is a tracking issue for moving HTTP/2 into `std`.

The desired end state is that the canonical HTTP/2 implementation used by `net/http` is located in the main Go repository and `golang.org/x/net/http2` is deprecated.

The `golang.org/x/net/http2` package has a substantial API surface. Some of that functionality (such as server and client configuration settings) will be made available via `net/http`, some will move into new packages, and some will be deprecated. The first stage of this project is to make every non-deprecated feature of `golang.org/x/net/http2` available elsewhere.

(Original discussion: https://github.com/golang/go/discussions/60746)

- [x] #61777 
- [x] #67812 
- [ ] #67813 
- [x] #67814
- [ ] #69649
- [x] #67816 
- [ ] #67817
- [ ] #67819
Repository: godot
Issue: GPU particles expensive when ACTIVE = false
Labels: discussion,needs testing,performance,topic:particles

### Tested versions

- Tested in 4.3 beta 1

### System information

Godot v4.3.beta1 - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 6GB (NVIDIA; 32.0.15.5599) - Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (8 Threads)

### Issue description

When a particle is set to inactive in the particle shader, it isn't rendered visible on screen, but it still has an impact on the rendering performance. Particle systems with high poly meshes and with all particles being inactive still increase the 'Render Depth Prepass' and 'Render Opaque Pass' a lot. On such a particle system, adding discard; to the start op the fragment shader improves performance, suggesting that the fragment shader is running. Another indication is that changing the amount of polygons in the mesh has an impact on performance, for example lowering the 'rings' count on the TorusMesh increases the performance. 

To me it seems like inactive particles shouldn't have a rendering cost (or at least really low), as they aren't being rendered. 

(Issue is related to #19507 and #92599)
### Steps to reproduce

1. Add GPUParticles3D
2. Set the amount to something fairly low, like 100. 
3. Add a custom particles shader with in start(): "ACTIVE = false;"
4. Set the mesh to a low poly mesh, like the cube. 
5. Note the really high fps and low primitives count.
6. Set the mesh to a really high poly mesh, like a torus with 1000 ring segments.
7. Note how the fps is a lot lower and the primitives count is a lot higher, even though all particles are disabled in the shader.



### Minimal reproduction project (MRP)

Very simple scene with fps counter and vsync disabled. The ACTIVE = false; is commented out by default.
Warning the scene has 12 million primitives. Open in 4.3 beta 1.
[Gpu_particles.zip](https://github.com/user-attachments/files/15567164/Gpu_particles.zip)
Repository: react
Issue: Refs merging/combining
Labels: Type: Enhancement

## Summary

I wanted to use `ref` from `props` while also creating a local `ref` as a fallback, but I got into this problem https://github.com/facebook/react/issues/17200.

I know this could be resolved with a little code, though I think this behavior should belong natively to React. There is even a package for that https://www.npmjs.com/package/react-merge-refs with ~1 million downloads/week, which confirms necessity of this for the React users.

I would propose something like
```tsx
function Component(props: { ref?: Ref<HTMLDivElement> }) {
  const fallbackRef = useRef<HTMLDivElement>(null)
  return <div ref={[props.ref, fallbackRef]} />
}
```
or at least this for fallback cases
```tsx
function Component(props: { ref?: Ref<HTMLDivElement> }) {
  const elementRef = useRef<HTMLDivElement>(props.ref)
  return <div ref={elementRef} />
}
```
or hook/helper to resolve `ref`s concurrency
```tsx
function Component(props: { ref?: Ref<HTMLDivElement> }) {
  const elementRef = useRef<HTMLDivElement>(null)
  const combinedRef = useCombinedRef([props.ref, elementRef])

  return <div ref={combinedRef} />
}
```
```tsx
function Component(props: { ref?: Ref<HTMLDivElement> }) {
  const elementRef = useRef<HTMLDivElement>(null)
  return <div ref={combineRefs([props.ref, elementRef])} />
}
```

What do you think? Am I going too far with it? 😅

<!--
  Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a
  repository on GitHub, or provide a minimal code example that reproduces the
  problem. You may provide a screenshot of the application if you think it is
  relevant to your bug report. Here are some tips for providing a minimal
  example: https://stackoverflow.com/help/mcve.
-->
Repository: flutter
Issue: Golden tests failed to run on the 3.23 beta release
Labels: P2,team-engine,triaged-engine

Previously [work was done](https://github.com/flutter/engine/tree/main/testing/skia_gold_client#release-testing) to make sure the golden tests run on the release branches.  It was verified to work in a mock run at https://github.com/flutter/flutter/issues/146078.  When the [3.23 beta branch was created golden images were not reaped](https://github.com/flutter/engine/pull/53148) like it did in the mock test.

This is likely a difference in the environment between the test and the real release workflow.  The code that added the ability for cocoon to run the skia gold on release branches was added in https://github.com/flutter/cocoon/pull/3659 and appears intact still.

The PR that disabled the golden image tests for the 3.23 beta branch was https://github.com/flutter/engine/pull/53163.  It appears that the release team ran into issues beyond just the failure of cocoon to reap the golden images too since there was a need to disable the tests.  I believe that is their GOLDCTL env var issue which should be resolved by adding skia gold as a dependency in the builder.

We need to identify the difference between the mock run and the real workflow to understand why cocoon did not reap the golden images.

cc @matanlurey
Repository: flutter
Issue: When running Web Renderer HTML chips label not disabled color
Labels: framework,engine,f: material design,platform-web,e: web_html,has reproducible steps,P3,team-web,triaged-web,found in release: 3.22,found in release: 3.23

### Steps to reproduce

1.
Create flutter app.
2.
Delete contents of main and replace with 
```dart
import 'package:flutter/material.dart';

void main() {
  runApp(
     MaterialApp(
      home: Material(
        child: Column(
          mainAxisSize: MainAxisSize.min,
          children: [
            const ActionChip(
              onPressed: null,
              label: Text('Disabled'),
            ),
            ActionChip(
              onPressed: () {},
              label: const Text('Active'),
            ),
          ],
        ),
      ),
    ),
  );
}
```
3.
flutter run using --web-render html

### Expected results

The text in disabled chip should be grey like so
![image](https://github.com/flutter/flutter/assets/95657952/7b5496bf-6627-4978-ba9b-73a9461ee1ba)


### Actual results

The text in the disabled chip is not grey
![image](https://github.com/flutter/flutter/assets/95657952/3fb82f2d-c2b7-49dd-bc1e-89e0098193c6)


### Code sample

<details open><summary>Code sample</summary>

```dart
import 'package:flutter/material.dart';

void main() {
  runApp(
     MaterialApp(
      home: Material(
        child: Column(
          mainAxisSize: MainAxisSize.min,
          children: [
            const ActionChip(
              onPressed: null,
              label: Text('Disabled'),
            ),
            ActionChip(
              onPressed: () {},
              label: const Text('Active'),
            ),
          ],
        ),
      ),
    ),
  );
}

```

</details>


### Screenshots or Video

Same code one running with --web-render html the other using the default
![image](https://github.com/flutter/flutter/assets/95657952/1e721e42-b57c-41df-a85e-2ec4d4e0f721)

### Logs

<details open><summary>Logs</summary>

```console
Launching lib/main.dart on Chrome in debug mode...
This app is linked to the debug service: ws://127.0.0.1:44657/ZmJ2IN9Yrac=/ws
Debug service listening on ws://127.0.0.1:44657/ZmJ2IN9Yrac=/ws
Connecting to VM Service at ws://127.0.0.1:44657/ZmJ2IN9Yrac=/ws
```

</details>


### Flutter Doctor output

<details open><summary>Doctor output</summary>

```console
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.22.1, on Linux Mint 20.2 5.4.0-182-generic, locale en_US.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
[✓] Chrome - develop for the web
[✓] Linux toolchain - develop for Linux desktop
[!] Android Studio (not installed)
[✓] VS Code (version 1.89.0)
[✓] Connected device (2 available)
[✓] Network resources

! Doctor found issues in 1 category.
```
</details>

(this also occured on my coworkers windows machine and on my others coworkers ubuntu machine)
Repository: go
Issue: proposal: x/net/http2: deprecate WriteScheduler
Labels: Proposal

This issue is part of a project to move `x/net/http2` into `std`: https://github.com/golang/go/issues/67810

The [`http2.WriteScheduler`](https://pkg.go.dev/golang.org/x/net/http2#WriteScheduler) interface type defines a scheduler used to select the order in which data is written to HTTP/2 streams. The [`Server.NewWriteScheduler`](https://pkg.go.dev/golang.org/x/net/http2#Server.NewWriteScheduler) configuration setting selects a write scheduler to use for server connections. Client connections do not permit configuring the write scheduler.

The package includes three implementations of this interface: Round robin (the default), random, and priority. The priority write scheduler is known to be buggy and the HTTP/2 stream prioritization scheme it implements is deprecated; see https://github.com/golang/go/issues/58804#issuecomment-1470330633.

Support for user-defined write schedulers is used seldom, if ever, and substantially constrains the HTTP/2 implementation.

Users should not need to configure the HTTP/2 implementation at this level. Of the current set of scheduler options, there is a clear correct choice: The round robin scheduler outperforms the random scheduler, and the priority scheduler is buggy and we have no plans to fix it. If we come up with a better scheduler, we should just make it the default. If we do discover a reason for users to configure this, we can and should provide a simpler configuration setting than what exists now.

I propose deprecating the write scheduler selection mechanism, consisting of the following types and functions:

- `FrameWriteRequest`
- `NewPriorityWriteScheduler`
- `NewRandomWriteScheduler`
- `OpenStreamOptions`
- `PriorityWriteSchedulerConfig`
- `Server.NewWriteScheduler`
- `WriteScheduler`

I propose that we add a deprecation notice to these types and functions today, and remove support for them in one year. After removing support, servers will ignore the value of the `NewWriteScheduler` field.
Repository: godot
Issue: Must reopen scene before Color Curve changes shows for GPUParticle2D
Labels: bug,topic:editor,topic:particles

### Tested versions

Godot 4.3 beta 1

### System information

Godot v4.3.beta1 - macOS 14.5.0 - GLES3 (Compatibility) - AMD Radeon Pro 560X OpenGL Engine - Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz (12 Threads)

### Issue description

Have to close and reopen the scene after adding a Color Ramp or Alpha Curve before it shows in the editor window.
Sometimes you have to close the entire project and reopen. Haven't been able to distinguish why.

### Steps to reproduce

Add GPUParticle2D, add a Color Ramp to it. Nothing happens.
Reopen the scene, it goes from black to white.

### Minimal reproduction project (MRP)

Sorry, I don't have time for this. I only happened to notice it when I was reporting another bug.