sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: transformers
Issue: Add support for prefix_allowed_tokens_fn to maintain a state throughout decoding
Labels: Feature request,Generation

### Feature request

Add an optional argument in `prefix_allow_tokens_fn` to allow for state to maintained throughout decoding or add a stateful alternative to `prefix_allowed_tokens_fn`.

### Motivation

`prefix_allowed_tokens_fn` is great but has one major downfall which is that you cannot maintain a state throughout decoding. This is inefficient because at each step you must go through your past `inputIds`, build up your current "state", and then figure out which tokens are allowed to appear next.

Instead, there should be a class we can subclass that gets passed the next token ID at each step of decoding (`Constraint` does not achieve this as `update` does not get every token ID). For example if you are trying to create a function to output json format (https://gist.github.com/BorisTheBrave/969f303a082c9da1916d04ee1eb04452), then you could track where you currently on in the json as each token ID is being received instead of going through everything on each new token.

### Your contribution

Unfortunately can't make a PR.
Repository: PowerToys
Issue: File Explorer add-ons: Turning off SVG "shows" the thumbnail preview. Turning on SVG preview "hides" the thumbnail preview.
Labels: Issue-Bug,Product-File Explorer,Needs-Triage

### Microsoft PowerToys version

0.78.0

### Installation method

Microsoft Store

### Running as admin

No

### Area(s) with issue?

File Explorer: Thumbnail preview

### Steps to reproduce

1. Download any .svg file from a browser.
2. Open File Explorer and navigate to that .svg file that you just downloaded.
3. Right click on the folder's empty space and choose View > (extra large icon, large icon, medium icon or small icon).

### ✔️ Expected Behavior

OFF = hide the svg preview.
ON = show the svg preview.

Here's something that can help.
![image](https://github.com/microsoft/PowerToys/assets/9446000/00a22c7f-aa14-4cc6-96e2-6ca7cf6babbd)


### ❌ Actual Behavior

OFF = shows svg preview.
ON = hides svg preview.

![image](https://github.com/microsoft/PowerToys/assets/9446000/6ad71984-e32b-4d05-9ad6-1c513a7753b3)

### Other Software

_No response_
Repository: godot
Issue: _CreateGizmo is invoked twice for gizmo plugins with their own gizmo subclasses
Labels: bug,topic:editor,topic:3d

### Tested versions

Only tested in 4.2 stable

### System information

Windows 10 - Godot_v4.2.1-stable_mono_win64

### Issue description

Attached is a minimal 3D gizmo plugin that simply draws a line from origin to (1,1,1). Print statements are present in the plugin to demonstrate that `_CreateGizmo` is being invoked twice for some nodes, seemingly at random. This leads to duplicate `EditorNode3DGizmo` instances (also as indicated by print statements), which, while not too big of a deal for lines, is a major problem for handles as only one handle can be grabbed at a time. I have only tested this with C#, as I do not use or know GDScript, but the example present is very nearly a direct translation of the example on the [docs page](https://docs.godotengine.org/en/stable/tutorials/plugins/editor/3d_gizmos.html) for 3D gizmo plugins. When following the first example on that page (not using a `EditorNode3DGizmo` subclass), everything behaves as expected.

Example of log output for demonstration:
![duplicate_call_output](https://github.com/godotengine/godot/assets/20629443/948ca7d7-899f-4d2c-9d57-da731f2d1bed)


### Steps to reproduce

1. Build project
2. Enable plugin "TestPlugin"
3. Create new 3D scene
4. Add an `ExampleNode`
5. See duplicated lines in output panel

### Minimal reproduction project (MRP)

[GizmoPluginTests.zip](https://github.com/godotengine/godot/files/14215404/GizmoPluginTests.zip)
Repository: PowerToys
Issue: Powertoys module Mouse Without Borders crashes when closing Remote Desktop connection
Labels: Issue-Bug,Needs-Triage,Product-Mouse Without Borders

### Microsoft PowerToys version

0.78.0

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Mouse Without Borders

### Steps to reproduce

1. Connect to the system using Remote Desktop. (During this time Mouse Without Borders operates, but is not needed as you are remoting into the machine.)
2. Close connection to system using Remote Desktop
3. Try to control the system using Mouse Without Borders. 

### ✔️ Expected Behavior

Mouse Without Borders to allow controlling the machine. 

### ❌ Actual Behavior

Mouse Without Borders cannot be used. Must manually log into the machine and start the PowerToys.MWB.Service in order to use it. 

### Other Software

_No response_
Repository: vscode
Issue: The backdrop-filter applied to the UI elements resulted in changes to the entire VSCode text UI.
Labels: info-needed

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.86.1
- OS Version: Windows 11 Pro (22631.3085) & Ubuntu 23.10 (Gnome 45,44)

Steps to Reproduce:

1. Toggle Developer Tools and play with backdrop filters.
2. Added backdrop filters (blur, opacity, saturation... or any other) rule to context menu, widgets, or any other elements. The whole VSCode UI was changed, but only the text... this is very strange.
3. No extension installed, only one theme, but also I have try with default theme from VScode and same things is happened.

Here is an animated GIF where the backdrop is enabled and disabled in context menu; you can see what happened. Try to zoom and check the letters carefully

![ezgif-7-8a72302542](https://github.com/microsoft/vscode/assets/159203552/fae48953-67a3-4974-a254-889c4efe6c1e)



Also, here is a zoomed gif of the some text
![1165cfced7](https://github.com/microsoft/vscode/assets/159203552/17e4850b-a0c7-48b8-835e-c6bebd44ff43)


Why has the text in the editor and UI changed if I just added a backdrop-filter to the context menu, for example?
Repository: godot
Issue: Expression.parse() returns OK when the parsed expression is not okay
Labels: bug,topic:core

### Tested versions

- Reproducible in v4.2.1.stable.official [b09f793f5]

### System information

Godot v4.2.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 (NVIDIA; 31.0.15.3699) - 12th Gen Intel(R) Core(TM) i5-12600K (16 Threads)

### Issue description

`Expression.parse()` returns `OK` for nonsensical statements that would not parse in Godot's editor (e.g. `blah 7 = ! * blah blah`) and which will fail to execute. It also returns `OK` for statements that would work outside of `Expression`, but are unsupported and return different results when executed by `Expression` (e.g. ternary if)

Sorry if this is a duplicate - it's definitely related to issue #84131 but seems broader/earlier? The bug is not that `Expression.execute()` doesn't support the ternary operator, nor even that it returns an incorrect result instead of failing, but rather that `Expression.parse()` is returning `OK` when it shouldn't - we shouldn't have even gotten to `Expression.execute()`.

### Steps to reproduce

Code:
```
extends Control

func _init():
	# Nonsense that wouldn't parse in Godot's editor parses as OK then fails to execute
	print(exec("blah 7 = ! * blah blah"), " - expecting <Parse error>")
	
	# Unsupported ternary operator parses as OK then executes without "failing"
	#	but incorrectly always returns the true side
	print(exec("'T' if false else 'F'"), " - expecting ", 'T' if false else 'F')
	
	# @GDScript method parses as OK then fails to execute...
	print(exec("Color8(0, 255, 0)"), " - expecting ", Color8(0, 255, 0))
	
	# ...but @GDScript constant executes successfully
	print(exec("PI"), " - expecting ", PI)

func exec(command:String) -> Variant:
	print("Executing: ", command)
	var expression = Expression.new()
	var error = expression.parse(command)
	if error != OK:
		push_error(expression.get_error_text())
		return "<Parse error>"
	var result = expression.execute()
	if expression.has_execute_failed():
		push_error("Runtime error in executed string (see previous error)")
		return "<Execute error>"
	return result
```
Output:
```
Executing: blah 7 = ! * blah blah
<Execute error> - expecting <Parse error>
Executing: 'T' if false else 'F'
T - expecting F
Executing: Color8(0, 255, 0)
<Execute error> - expecting (0, 1, 0, 1)
Executing: PI
3.14159265358979 - expecting 3.14159265358979
```

### Minimal reproduction project (MRP)

[ExpressionTest.zip](https://github.com/godotengine/godot/files/14215823/ExpressionTest.zip)
Repository: flutter
Issue: [iOS] Platform View SurfaceFrame::Submit being slow due to `waitUntilScheduled` block
Labels: platform-ios,a: platform-views,P2,team-ios,triaged-ios

From profiling the example: https://github.com/lucalooz/flutter_ads_list_perf

I found 3-4 consecutive frames (selected in screenshot below) being more expensive due to being blocked on `waitUntilScheduled`. 
![Screenshot 2024-02-08 at 4 27 20 PM](https://github.com/flutter/flutter/assets/41930132/dcb280d7-02ee-48cb-9638-4bc7a1f61205)

Interestingly, this these 3 frames do not have a long time on committing CATransaction. 

CC @jonahwilliams @jmagman
Repository: flutter
Issue: [iOS] platform view slow frame due to block in AcquireFrame's `waitForNextDrawable`
Labels: platform-ios,a: platform-views,P2,team-ios,triaged-ios

### Use case

I did a profiling on https://github.com/lucalooz/flutter_ads_list_perf, and found 3-4 consecutive frames (selected below) being slow when acquiring the frame (blocked in `WaitForNextDrawable`). This happens less frequently than the SubmitFrame's block on `waitUntilScheduled`, but when it happens, it takes pretty large chunk of time. 

![Screenshot 2024-02-08 at 4 51 01 PM](https://github.com/flutter/flutter/assets/41930132/60dec071-4e6f-4740-965b-422b7ca7bb37)

CC @jonahwilliams @jmagman
Repository: godot
Issue: Incorrect display of OpenGL 3 shadows
Labels: bug,topic:rendering,topic:3d

### Tested versions

Building the engine v4.3 dev3 win64

### System information

win10 ,opengl3,GTX 560 ti

### Issue description

shadows are displayed incorrectly in opengl 3 mode, the problem occurs when importing a 3d model in glb format, there are no problems when using obj format.
![S](https://github.com/godotengine/godot/assets/48522040/ae993cd6-c483-421d-91be-17e5edfd0e64)
![r](https://github.com/godotengine/godot/assets/48522040/be9d5dfd-1370-426d-aac1-7938295ee07c)


### Steps to reproduce

Create a new project with the opengl 3 visualization system, and export the 3d model in the format.glb without a second UV channel, then generate a uv2 light map in the editor.
[Новый игровой проект.zip](https://github.com/godotengine/godot/files/14216171/default.zip)




### Minimal reproduction project (MRP)

N / A
Repository: pytorch
Issue: Persistent reduction runs slower than reduction with the same triton config
Labels: triaged,oncall: pt2,module: inductor

### 🐛 Describe the bug

As a follow up of the multi-kernel work, I'm looking thru the collected persistent reduction and the corresponding non persistent reduction and understand the source of the perf difference. One interesting pair is:

Persistent reduction: https://gist.github.com/shunting314/502dfed757cf594a07c9a37c36e127e5 
Reduction: https://gist.github.com/shunting314/92cb77db2d2d564fe3a1129e33041e70 

For out of the box perf, the latency is 0.055 v.s. 0.065 ms . 
With max-autotune + coordinate descent tuning, the latency is 0.053 v.s. 0.042 ms .

At the first glance, It's nice to see MA+CDT help the non-persistent reduction beat the persistent reduction. However, take a deeper look, I found the non-persistent reduction picks RBLOCK equals to rnumel. Then in theory the persistent reduction should not be slower in this case.

So I force both the persistent reduction and the non-persistent reduction to use the optimial triton config: XBLOCK: 32, RBLOCK: 128, num_warps: 4 . And the latency for them are 0.052ms v.s. 0.044ms . 

So I think there is some extra overhead for persistent reduction here. It's possible to be a triton bug. I'll dig more.

cc @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler @jansel @Chillee @eellison 

### Error logs

_No response_

### Minified repro

..

### Versions

..
Repository: pytorch
Issue: Consistency in using (mean, std) vs. (loc, scale) terminology in Normal distributions
Labels: module: distributions,triaged,enhancement

### 🐛 Describe the bug

There are 3 places where the Normal distribution can be called in PyTorch:
- `torch.normal(mean, std)` ([link](https://pytorch.org/docs/stable/generated/torch.normal.html))
- `torch.Tensor.normal_(mean, std)` ([link](https://pytorch.org/docs/stable/generated/torch.Tensor.normal_.html))
- `torch.distributions.Normal(loc, scale)` ([link](https://pytorch.org/docs/stable/distributions.html#torch.distributions.normal.Normal))

I hope that the API can be made more consistent between using the names (mean, std) vs. (loc, scale). In general, it seems that (loc, scale) is preferred by numpy and scipy:

- `numpy.random.normal(loc, scale)` ([link](https://numpy.org/doc/stable/reference/random/generated/numpy.random.normal.html))
- `numpy.random.Generator.normal(loc, scale)` ([link](https://numpy.org/doc/stable/reference/random/generated/numpy.random.Generator.normal.html))
- `scipy.stats.norm.rvs(loc, scale)` ([link](https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.norm.html))

However, other libraries also use other terminology:

- TensorFlow uses its own (mean, stddev) argument names, e.g., `tensorflow.random.normal(shape, mean, stddev)` ([link](https://www.tensorflow.org/api_docs/python/tf/random/normal))
- The random module in Python's standard library uses (mu, sigma) argument names, e.g., `random.normalvariate(mu, sigma)` ([link](https://docs.python.org/3/library/random.html#random.normalvariate))

### Versions

2.1.2

cc @fritzo @neerajprad @alicanb @nikitaved
Repository: flutter
Issue: [ios] platform view optimize for scrolling scenario when inserting/deleting views at front/back of list
Labels: platform-ios,a: platform-views,P2,team-ios,triaged-ios

We had [an optimization](https://github.com/flutter/engine/blob/main/shell/platform/darwin/ios/framework/Source/FlutterPlatformViews.mm#L802) that avoids unnecessary `addSubview` calls if the view hierarchy is unchanged. This improved the performance because `addSubview` operation is expensive. 
 
When we scroll the list, it's very common to add a new platform view or delete a platform view from beginning or end of the list. We can optimize for these special case as well: 

1. add platform view at the front
2. add platform view at the end
3. delete the first platform view
4. delete the last platform view

No need to handle the "shifting" case since we don't have similar logic to UITableView's cell reusing logic.
Repository: flutter
Issue: [ios]platform view avoid unnecessary `BringLayersIntoView` call
Labels: platform-ios,a: platform-views,P2,team-ios,triaged-ios

A while back I found that sometimes [BringLayersIntoView](https://github.com/flutter/engine/blob/main/shell/platform/darwin/ios/framework/Source/FlutterPlatformViews.mm#L775) was called unnecessarily. So I wrote [this TODO](https://github.com/flutter/engine/blob/bb4c58dcf7187949b928fed7ac350abcf932f6d6/shell/platform/darwin/ios/framework/Source/FlutterPlatformViews.mm#L816) but didn't get a chance to look into it. I realized that this could help with improving the platform view scrolling perf issue.
Repository: tauri
Issue: [bug] Version 0.1.4 breaks my end-to-end tests
Labels: type: bug,scope: webdriver,status: needs triage

### Describe the bug

My end-to-end tests on GitHub CI started breaking today:

```
[0-0] 2024-02-09T02:56:58.452Z ERROR webdriver: Request failed with status 500 due to session not created: Failed to match capabilities
[0-0] 2024-02-09T02:56:58.454Z ERROR webdriver: session not created: Failed to match capabilities
[0-0]     at getErrorFromResponseBody (file:///home/runner/work/zamm-ui/zamm-ui/node_modules/webdriverio/node_modules/webdriver/build/utils.js:195:12)
[0-0]     at NodeJSRequest._request (file:///home/runner/work/zamm-ui/zamm-ui/node_modules/webdriverio/node_modules/webdriver/build/request/index.js:193:23)
[0-0]     at processTicksAndRejections (node:internal/process/task_queues:95:5)
```

Pinning the installed version to 0.1.3 gets them to pass again.

I have not looked into why this is, I'm just reporting this phenomenon. My yarn.lock has these versions:

- `webdriverio` at 8.29.1
- `@wdio/local-runner` at 8.29.2

### Reproduction

I'm using an end-to-end test script based on https://github.com/chippers/hello_tauri

### Expected behavior

Patch versions should ideally not result in breaking changes to my CI setup

### Full `tauri info` output

```text
My local machine where the driver works fine on 0.1.3


cargo tauri info

[✔] Environment
    - OS: Ubuntu 22.04 X64
    ✔ webkit2gtk-4.0: 2.42.4
    ✔ rsvg2: 2.52.5
    ✔ rustc: 1.71.1 (eb26296b5 2023-08-03)
    ✔ Cargo: 1.71.1 (7f1d04c00 2023-07-29)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: 1.71.1-x86_64-unknown-linux-gnu (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.5.1
    - pnpm: 8.7.6
    - yarn: 1.22.19
    - npm: 9.8.0

[-] Packages
    - tauri [RUST]: 1.5.4
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.7
    - tao [RUST]: 0.16.5
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.4.0

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../src-svelte/build
    - devPath: http://localhost:1420/
    - framework: Svelte
    - bundler: Vite
```

I have yet to kick off a run on CI with this command, because I just want to be able to report it first in case anyone else runs into the same issue.
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: PowerToys
Issue: Always on top fails to pin powershell properly when another command line program is running, then finishes
Labels: Issue-Bug,Product-Always On Top,Area-App Compat

### Microsoft PowerToys version

0.78.0

### Installation method

GitHub

### Running as admin

No

### Area(s) with issue?

Always on Top

### Steps to reproduce

![image](https://github.com/microsoft/PowerToys/assets/73092546/38729fca-9455-413f-8a13-eb51e6c31a3e)
attempting to close powershell 7.4.1 with always on top enabled caused it to freeze, and had to be closed with task manager. The log file had `[2024-02-08 23:25:40.006516] [p-12468] [t-12472] [error] Failed to unpin window, Invalid window handle.` I believe this may be because it detects the other command line program and pins that instead, and when the command finishes, the console is the same, so it doesn't delatch from the original process before closing the app.
1. start powershell 7.4.1 normally from the start menu
2. run a custom script I created for downloading a stream, and enable always on top midway through operation. The command finished after cancelling with ctrl+c, and I closed powershell with the x in the corner. The console went away, and the window controls(?) stayed, as shown in the image.

### ✔️ Expected Behavior

The application to close properly without error

### ❌ Actual Behavior

The console disappeared, leaving the window controls

### Other Software

Powershell 7.4.1
custom powershell script ran with parameters `-time 00:00-15:00 -link https://www.twitch.tv/##### -number [any number] -topic cats`:
```ps
function turtlesong {
    param(
        [Parameter(Mandatory)]
        [string]$time,
        [Parameter(Mandatory)]
        [string]$link,
        [Parameter(Mandatory)]
        [string]$number,
        [string]$topic
    )
    if ("$topic" -ne "") {
        $topic = ".($topic)"
    }

    if ((Test-Path "C:\Users\#####\turtlesongs\song.$number$topic.mp4") -eq $false) {
        C:\Users\#####\.stacher/youtube-dl --embed-metadata --no-check-certificate --ffmpeg-location C:\Windows\ --download-sections "*$time" -o "C:\Users\#####\turtlesongs\song.$number$topic.mp4" $link 
        
        $choice = Read-Host "Use ffmpeg and convert to audio? (y/n)"
        if ($choice -eq "y") {
            ffmpeg -i "C:\Users\#####\turtlesongs\song.$number$topic.mp4" -vn -c:a copy "C:\Users\#####\turtlesongs\audio\song.$number$topic.m4a"
        } else {
            write-host "Not converting to audio."
        }
    } else {
        Write-Warning -Message "Song with number ""$number"" already downloaded."
    }
}
```
Repository: rust
Issue: rust libs are not reproducible from 1.75
Labels: A-metadata,E-needs-test,T-compiler,C-bug,A-reproducibility

Hello,

We're building rust in Yocto framework for a custom target, and there we are facing a reproducible issue with the libs generated during the build. When the rust is build in two different paths the generated libs are not identical, those are getting differed in .rustc section. This is observed from the rust 1.75.0 onwards.
(We've enabled _remap-debuginfo_ option  but still this issue is happening, this option was learned from issue discussion https://internals.rust-lang.org/t/librustc-driver-so-not-reproducible/19639 and this was working fine till 1.74.1)

I've analyzed the changes from 1.74.1 to 1.75.0, there are changes related to Cargo, llvm & some changes w.r.t to bolt feature/optimization are there. I've tried a few builds by reverting these changes but still the issue is reproducing.

There are a few commits in https://github.com/rust-lang/rust/commit/85c0ce24cc748f07ba3497948d26356ff2b02f6d for _src/bootstrap/src/core/builder.rs & src/bootstrap/src/bin/rustc.rs_ files which have changes related to remap-debuginfo option and I suspect this commit might causing the issue. I tried build by reverting the commit & with the latest changes in https://github.com/rust-lang/rust/commit/4b7e0a0b56aa2446e670dfd6558380a1039a86aa but still issue is reproduing. There is a new RUSTC_CARGO_REGISTRY_SRC_TO_REMAP is added in this commit. I added a few debug statements in here to see the build paths passed, I can see those are passed correctly to RUSTC_CARGO_REGISTRY_SRC_TO_REMAP.

Any hints on what might cause reproducible issues with this commit on rust 1.75? Let me know if any other info is needed.

Non-reproducible libs are here:
![libs](https://github.com/rust-lang/rust/assets/56015745/a2149de0-f3d2-4efa-9ac1-0fe24ec7377b)