sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: Implement more modern word-wise cursor navigations
Labels: Product-Conhost,Product-Terminal,Issue-Task,Needs-Tag-Fix,Area-CookedRead

# Description of the new feature/enhancement

Conhost and Windows Terminal currently use the classic Windows algorithm, which is also used by Notepad and Visual Studio. Given 3 classes of characters - whitespace, delimiters and regular text - it works something like this:
* Forward navigation:
  * Skip text until (after) you encounter a different character class
  * Skip whitespace
* Backward navigation:
  * Skip whitespace
  * Skip text until (before) you encounter a different character class

In comparison Visual Studio Code's navigation works like this:
* Forward navigation:
  * Skip whitespace
  * Skip 1 glyph
  * Skip text until (before) you encounter a different character class
* Backward navigation:
  * Skip whitespace
  * Skip 1 glyph
  * Skip text until (before) you encounter a different character class

Due to this symmetry navigating forward/backward will produce consistent and identical results. It'll feel more "intuitive" to new users.

# Risk

People can be _very_ picky about changes to our word selection algorithm. Double-clicking words needs to behave similar/identical to before. Cursor navigation needs to be at least so close that no one will feel bothered by it. There should be an opt-out if not at least via a registry key, just in case things go bad.
Repository: flutter
Issue: Investigated mergeable libraries for plugin builds
Labels: platform-ios,platform-mac,team-ecosystem,P2,a: plugins,triaged-ecosystem

Currently plugins are build via either dynamic or static libraries; we should investigate [mergeable libraries](https://developer.apple.com/documentation/xcode/configuring-your-project-to-use-mergeable-libraries) as an option. This is probably something that should wait until after https://github.com/flutter/flutter/issues/126005 so we're not duplicating work (assuming Cocoapods would even get support for them).
Repository: flutter
Issue: Tooltips should prefer to render up above items on mobile
Labels: c: new feature,framework,f: material design,P3,team-design,triaged-design

Flutter prefers to put tooltips below items on mobile, matching desktop placement.  On mobile this means placing the tooltip in a location that is obscured by the users finger.

## steps to reproduce
1) open the gallery app
1) go to Material -> Tooltips
1) Long press your finger on the magnifying glass button, notice that you cannot read the tooltip because it renders underneath your finger.
Repository: vscode
Issue: Persistent background terminals (`hideFromUser = true`, `isTransient = false`) are killed on window reload
Labels: bug,api,terminal-process

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
Does this issue occur when all extensions are disabled?: Yes

- VS Code Version: Version: 1.80.2 (Universal)
Commit: 2ccd690cbff1569e4a83d7c43d45101f817401dc
Date: 2023-07-27T21:05:41.366Z

- OS Version: Darwin arm64 22.5.0

Steps to Reproduce:

Via the extension API, create a background terminal with `hideFromUser = true`, and `isTransient = false`. For example:

```javascript
	vscode.window.createTerminal(<vscode.TerminalOptions>{
		name: "Background Terminal",
		"shellPath": "/bin/bash",
		shellArgs: ["-c", "sleep 2048"],
		hideFromUser: true,
		isTransient: false
	});
```

Reload the window (e.g. _Developer: Reload Window_ in the desktop version, or reload the tab in the web/server version) and note that the `sleep 2048` command is still running in the background.

Now, wait exactly 1 minute. VS Code will send a `SIGHUP` to the background terminal, killing the `sleep` process. 

My understanding is that non-transient terminals should keep running in the background even after a window reload, which is what they did prior to https://github.com/microsoft/vscode/pull/181365. If I am reading that PR correctly, it was intended to address transient terminals, but it also affects non-transient terminals.

The reason the behavior occurs is that detaching the terminal during reload starts a 60 second timer here:

https://github.com/microsoft/vscode/blob/ca5cfcca0601f18cc737811b3c1d86572629931d/src/vs/platform/terminal/node/ptyService.ts#L775-L781

However, because these terminals are hidden from the user, they aren't ever attached again (i.e. we never call `attach()` because that's downstream from the `TerminalGroupService`, and background terminal instances are not tracked by the service). So 60 seconds (`GraceTime`) after the terminal is detached, it is `kill()`'d with `SIGHUP`. 

I created an example extension which demonstrates the issue here: https://github.com/jmcphers/backgroundterminal

(If the new behavior is intentional, what is the recommended mechanism by which an extension should start a command that survives window reloads but doesn't show in the Terminal pane?)
Repository: youtube-dl
Issue: https://mediasetinfinity.mediaset.it
Labels: site-support-request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2021.12.17. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Make sure that all provided video/audio/playlist URLs (if any) are alive and playable in a browser.
- Make sure that site you are requesting is not dedicated to copyright infringement, see https://yt-dl.org/copyright-infringement. youtube-dl does not support such sites. In order for site support request to be accepted all provided example URLs should not violate any copyrights.
- Search the bugtracker for similar site support requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [ x] I'm reporting a new site support request
- [ ] I've verified that I'm running youtube-dl version **2021.12.17**
- [ ] I've checked that all provided URLs are alive and playable in a browser
- [ ] I've checked that none of provided URLs violate any copyrights
- [ ] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs

<!--
Provide all kinds of example URLs support for which should be included. Replace following example URLs by yours.
-->

- Single video: https://mediasetinfinity.mediaset.it


## Description

<!--
Provide any additional information.
If work on your issue requires account credentials please provide them or explain how one can obtain them.
-->

WRITE DESCRIPTION HERE
Repository: godot
Issue: PCSS not working for SpotLight3D: Vulkan (Forward+)
Labels: bug,topic:rendering,confirmed,topic:3d

### Godot version

Godot v4.1.stable

### System information

Godot v4.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (NVIDIA; 31.0.15.2824) - 11th Gen Intel(R) Core(TM) i5-11600K @ 3.90GHz (12 Threads)

### Issue description

Percentage-closer soft shadows (PCSS) don't seem to be working correctly with SpotLight3d's.

Image below shows an Omni Light and Spot Light with the same light_size value. The Omni Light shows correct PCSS with the shadow getting softer the furth the object (caster) is from the surface (reciever). The Spot Light shows uniform shadow hardness.

![image](https://github.com/godotengine/godot/assets/16860574/a66cde9b-3ea2-4f3a-bada-e5654a1317b0)

Increasing the light_size Value for a Spot Light uniformly blurs the shadow, but the blur doesn't seem impacted by the casters distance from the receiver.

![image](https://github.com/godotengine/godot/assets/16860574/5ba77d2c-05c9-4e52-82b3-dac9b5aab439)



### Steps to reproduce

1. Create a 3D Scene 
2. Add a SpotLight3D
3. Add a plane mesh instance, and a shadow caster mesh instance
4. Enable shadows on the SpotLight3D
5. Change the light_size to 0.1
6. Observe
7. Change SpotLight3D to OmniLight3D with the same light_size
8. Observe

### Minimal reproduction project

[PCSS_Shadow_Issue.zip](https://github.com/godotengine/godot/files/12233905/PCSS_Shadow_Issue.zip)
Repository: godot
Issue: Weird error messages when awaiting a custom signal
Labels: topic:core,topic:gdscript,needs testing

### Godot version

4.2-dev2 (and also previous 4.x)

### System information

Godot v4.2.dev2 - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 (NVIDIA; 31.0.15.2802) - Intel(R) Core(TM) i5-10400F CPU @ 2.90GHz (12 Threads)

### Issue description

When using a custom signal (await mysignal) to resume a coroutine, I get 2 weird error messages:

```
E 0:00:02:0071   Ball.gd:32 @ drop(): Condition "!function" is true. Returning: Variant()
  <Source C++>   modules/gdscript/gdscript_function.cpp:227 @ resume()
  <Pile des appels>Ball.gd:32 @ drop()
                 Player.gd:19 @ _ready()
                 Ball.gd:1397059936 @ take()
                 Ball.gd:32 @ drop()
                 Player.gd:19 @ _ready()
                 Ball.gd:1397059232 @ take()
                 Ball.gd:32 @ drop()
                 Player.gd:19 @ _ready()

E 0:00:02:0071   Ball.gd:32 @ drop(): Attempt to disconnect a nonexistent connection from 'Ball:<Node#26407339190>'. Signal: 'dropped', callable: 'GDScriptFunctionState::_signal_callback'.
  <Erreur C++>   Condition "!s->slot_map.has(*p_callable.get_base_comparator())" is true. Returning: false
  <Source C++>   core/object/object.cpp:1357 @ _disconnect()
  <Pile des appels>Ball.gd:32 @ drop()
                 Player.gd:19 @ _ready()
                 Ball.gd:1397059232 @ take()
                 Ball.gd:32 @ drop()
                 Player.gd:19 @ _ready()
```
 
Am I doing anything wrong here?

### Steps to reproduce

Open and run the attached project. Errors should show immediately in the debug panel.
The Ball.gd has a few comments.

### Minimal reproduction project

[coroutine_test.zip](https://github.com/godotengine/godot/files/12234000/coroutine_test.zip)
Repository: pytorch
Issue: PyTorchMPS not showing up in Instruments for `torch.mps.profiler`
Labels: triaged,module: mps

### 🐛 Describe the bug

Following these instructions: https://developer.apple.com/videos/play/wwdc2023/10050/?time=355, I'm not seeing the `PyTorchMPS` intervals showing up when trying to profile SDXL. I can see `events` in the `com.apple.Metal.AGXSignposts` but  I would expect to see PyTorchMPS here, with intervals breaking down each layer's latency.

<img width="618" alt="image" src="https://github.com/pytorch/pytorch/assets/1981179/6de491b4-5cbb-46eb-b614-96a7419cc85f">

Here's the code I'm using to profile:

```
from diffusers import DiffusionPipeline

pipe = DiffusionPipeline.from_pretrained("stabilityai/stable-diffusion-xl-base-1.0")
pipe.to("mps")

prompt = "test prompt"
negative_prompt = "test negative prompt"

torch.mps.profiler.start(mode='interval', wait_until_completed=True)
print(os.getpid())
image = pipe(prompt, negative_prompt=negative_prompt, num_inference_steps=1).images[0]
torch.mps.profiler.stop()

```

This may be related to macOS 14 beta? I'm calling this from a notebook being run via VSCode, but I tested just running it from a standalone python file via iTerm2 and similar issue.


### Versions

PyTorch version: 2.1.0.dev20230801
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 14.0 (arm64)
GCC version: Could not collect
Clang version: 14.0.3 (clang-1403.0.22.14.1)
CMake version: version 3.26.3
Libc version: N/A

Python version: 3.10.12 (main, Jun 20 2023, 19:43:52) [Clang 14.0.3 (clang-1403.0.22.14.1)] (64-bit runtime)
Python platform: macOS-14.0-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M2 Pro

Versions of relevant libraries:
[pip3] clip-anytorch==2.5.2
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.23.5
[pip3] open-clip-torch==2.20.0
[pip3] pytorch-lightning==1.7.7
[pip3] torch==2.1.0.dev20230801
[pip3] torchaudio==2.1.0.dev20230801
[pip3] torchdiffeq==0.2.3
[pip3] torchmetrics==0.11.4
[pip3] torchsde==0.2.5
[pip3] torchvision==0.16.0.dev20230801
[conda] numpy                     1.24.3          py311hd0e4f0d_0
[conda] numpy-base                1.24.3          py311h947b413_0
[conda] numpydoc                  1.5.0           py311hecd8cb5_0

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
Repository: flutter
Issue: Create a new issue whenever new translations get added
Labels: a: internationalization,P2,team-design,triaged-design

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

Oftentimes, new localized strings are added to Material or Cupertino widgets but the translations are not fetched internally until much later.

### Proposal

We should have a bot check for whenever a new string is added to `material_en.arb`, `cupertino_en.arb`, or `widgets_en.arb` and create a new issue and assign it to the person who created the PR so that there is always an issue for following up on the translations.
Repository: pytorch
Issue: `torch.nn.utils.clip_grad_norm_()` causes H2D sync with foreach ops.
Labels: module: nn,triaged,module: mta

`clip_grad_norm_()` has an optional `foreach` flag ([here](https://github.com/pytorch/pytorch/blob/ef0576f203bff957d7be976840244f45ff510d2c/torch/nn/utils/clip_grad.py#L14)), that specifies that a foreach kernel should be used.

Unfortunately, that foreach kernel (called [here](https://github.com/pytorch/pytorch/blob/ef0576f203bff957d7be976840244f45ff510d2c/torch/nn/utils/clip_grad.py#L76)) performs a H2D sync:

(1) `clip_coef_clamped` is a scalar-tensor

(2) `aten._foreach_mul_` has a `Scalar` overload and a `TensorList` overload, but not a `Tensor` overload.

(3) `torch._foreach_mul_` coerces the scalar-tensor into a tensor to call the Scalar overload, resulting in an `item()` call (causing a H2D sync).

I had a tentative patch up here to try to force `clip_grad_norm_()` to use the existing `_foreach_mul_.List` overload. It avoids the H2D sync, but ends up dispatching several smaller kernels, which is still not ideal for performance. Instead, we should add a dedicated `_foreach_mul_.Tensor` overload.

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @crcrpar @mcarilli
Repository: PowerToys
Issue: Mouse crosshair lags one update behind the actual position
Labels: Issue-Bug,Needs-Triage,Product-Mouse Utilities

### Microsoft PowerToys version

0.72.0 & before

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Mouse Utilities

### Steps to reproduce

activate mouse crosshairs and move the mouse

### ✔️ Expected Behavior

The crosshair is responsive to mouse movements.

### ❌ Actual Behavior

The crosshair is sometimes a step behind the actual mouse position.

For me, it’s
* always the case when using my physical mouse
* sometimes the case when using my trackpad (see also #24096)
* always the case when using Mouse Keys (Accessibility ➡ Mouse) [tested this *for science*]

### Other Software

* Contour mouse driver
Repository: pytorch
Issue: inconsistent dtype of scale and zero_point in observers
Labels: high priority,oncall: quantization,triaged

### 🐛 Describe the bug

in https://github.com/pytorch/pytorch/blob/main/torch/ao/quantization/observer.py#L323-L324 scale is float (32bit) and zero_point is long (64 bit), we should make sure both of them are 32 bit

### Versions

master

cc @ezyang @gchanan @zou3519 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel
Repository: next.js
Issue: `AsyncLocalStorage` and `res.locals` unexpected behavior starting in `13.4.3-canary.3`
Labels: bug,linear: next

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 20.6.0: Thu Mar  9 20:39:26 PST 2023; root:xnu-7195.141.49.700.6~1/RELEASE_X86_64
    Binaries:
      Node: 20.2.0
      npm: 9.6.6
      Yarn: 3.6.1
      pnpm: N/A
    Relevant Packages:
      next: 13.4.12
      eslint-config-next: 13.4.12
      react: 18.2.0
      react-dom: 18.2.0
      typescript: N/A
    Next.js Config:
      output: N/A
```

NOTE: `13.4.12` is the most recent version I could run, all `13.4.13` canaries are crashing with the following error:


```
Failed to proxy http://127.0.0.1:0/about Error: connect EADDRNOTAVAIL 127.0.0.1 - Local (0.0.0.0:57514)
```

### Which area(s) of Next.js are affected? (leave empty if unsure)

App Router

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/helloitsjoe/next-custom-server-repro

### To Reproduce

Please see the reproduction repo, it has a full example of the setup described here and a more detailed description in the README:

1. Create a custom server
2. Create an instance of `AsyncLocalStorage`, and call `.run()` in custom server middleware
3. Attach data to `res.locals` in custom server middleware
4. From a file in the `app` directory, try to access the store instance with `.getStore()`, see that it's undefined
5. From `getServerSideProps` in a file in the `pages` directory, try to access the store instance with `.getStore()`, see that it's undefined
6. From `getServerSideProps` in a file in the `pages` directory, try to access `res.locals`, see that it's also undefined 

### Describe the Bug

The `AsyncLocalStorage` store is undefined in application code in the `app` directory, and `res.locals` is undefined in the `pages` directory (in `getServerSideProps`), even though they are available in the custom server at request time. This behavior started in `next@13.4.3-canary.3`.

### Expected Behavior

I expect to have access to a globally defined `AsyncLocalStorage` store server-side in components in the `app` directory, and access to both the store and `res.locals` in `getServerSideProps` in the `pages` directory, without setting `customServer: false`. This is the behavior in `next@13.4.2`.

### Which browser are you using? (if relevant)

115.0.5790.114 (Official Build) (x86_64)

### How are you deploying your application? (if relevant)

_No response_

<sub>[NEXT-1489](https://linear.app/vercel/issue/NEXT-1489/asynclocalstorage-and-reslocals-unexpected-behavior-starting-in-1343)</sub>
Repository: godot
Issue: Can't connect to signals created with `Signal()` constructor
Labels: topic:core,documentation

### Godot version

v4.1.1.stable.official [bd6af8e0e]

### System information

Godot v4.1.1.stable - Windows 10.0.19044 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 2060 (NVIDIA; 31.0.15.3623) - AMD Ryzen 7 5700G with Radeon Graphics (16 Threads)

### Issue description

I'm trying to connect to a custom signal created with the `Signal()` constructor. However I got the following error:
```
E 0:00:01:0314   main.gd:5 @ _ready(): Condition "!obj" is true. Returning: ERR_UNCONFIGURED
  <C++ Source>   core/variant/callable.cpp:468 @ connect()
  <Stack Trace>  main.gd:5 @ _ready()
```
It's not possible to connect both to the `Signal()` and `Signal(object: Object, signal: StringName)` constructors variants but the `Signal(from: Signal)` works fine.

The documentation doesn't make clear if this is something I could do or if I can only use signals declared in scripts using the `signal` keyword.


### Steps to reproduce

Create an scene with the following script and run:
```
extends Node2D

func _ready():
	var custom_signal = Signal()
	custom_signal.connect(_signal_func)
	custom_signal.emit()
	
func _signal_func():
	print('success')
```



### Minimal reproduction project

[signal-bug.zip](https://github.com/godotengine/godot/files/12234764/signal-bug.zip)
Repository: PowerToys
Issue: Enhancement: Always on top 'Anchor / Sync'
Labels: Idea-Enhancement,Product-Always On Top,Needs-Triage

### Description of the new feature / enhancement

**Enhancement: Always on top**

The anchor feature would allow the user to "Anchor" one window to another. When activated the subject window will become locked in place relative to another. The user moved window 'A' 15 pixels, the window 'B' does the same. Minimise window 'A', window 'B' does the same. Transform one window to make it bigger and fill a particular space and the other window scales and does the same to match. Synchronised. This essential makes multiple windows behave as one to maximise pixel real estate when multi-tasking.

### Scenario when this would be used?

In my use case, I wanted to have a Chrome me window "Always on top" of OBS so I could monitor information on the Chrome window whilst being able to see and interact with OBS below. 'Alway on top" allows me to lock on OBS without it jumping in front of the Chrome window every time I click on it.

 However, the shortcoming is when I wanted to access a third unrelated window It would be sandwiched between the two layers, with Chrome on top, and OBS on the bottom. So now I have to either close the AoT tab or move it from out underneath before being able to use this 3rd window.

But If the chrome tabe to anchored or synced to OBS, then they essentially behave like a single window that allowers the use full control of both without extra busy work. The two windows remain anchored or synced relative to each other. Other windows can be used above or below the two subject windows as normal.


![chrome_cLDXCkrbnU](https://github.com/microsoft/PowerToys/assets/141192267/0f2a43c4-83ed-4999-8c73-f75b95c7ded9)
![Streamlabs_OBS_771OXtz1fc](https://github.com/microsoft/PowerToys/assets/141192267/07eb8de1-aacc-41d6-990f-0fb36c0b0b6d)


### Supporting information

N/A - Internal idea arising from need.
Repository: pytorch
Issue: [JIT] .item() dict keys cause `RuntimeError: Cannot create dict for key type 'Scalar', only int, float, complex, Tensor, device and string keys are supported`
Labels: oncall: jit

### 🐛 Describe the bug

**Tasks**:
* [ ] (maybe) fix this - seems hard because torchscript doesn't know whether a tensor is a FloatTensor or an IntTensor
* [ ] Improve source attribution: maybe this error should be a FrontendError(? is that what it's called?) that traces back to the source that had this issue.

Repro:

```python
import torch
from typing import List, Tuple, Dict

def fn(x: List[torch.Tensor]):
    return {x[i].item(): i for i in range(len(x))}

torch.jit.script(fn)
```

Error:
```
Traceback (most recent call last):
  File "/data/users/dberard/scripts/dict_comprehension.py", line 7, in <module>
    torch.jit.script(fn)
  File "/data/users/dberard/pytorch/torch/jit/_script.py", line 1377, in script
    fn = torch._C._jit_script_compile(
RuntimeError: Cannot create dict for key type 'Scalar', only int, float, complex, Tensor, device and string keys are supported
```

### Versions

main branch as of aug 1, 2023

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel