sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: Multiple DNN models under multi-threading will cause the program to freeze
Labels: incomplete,needs reproducer

### System Information

// example for c++ user
OpenCV version: 4.5.5, 4.6.0, 4.7.0
Operating System / Platform: Windows 10
Compiler & compiler version: VS 2019



### Detailed description

In order to run the new feature extraction algorithm for face recognition, I tried to compile the latest version of OpenCV 4.7 based on CUDA. On OpenCV4.5 compiled with GPU, I can run up to 6 DNN models in multithreading simultaneously. However, on the convenient OpenCV version above 4.5.4, when there are more than 2 models, there will be a very serious freeze, which will cause the program to fail to run.

### Steps to reproduce

The code does not report an error, but the operation freezes.

### 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
- [ ] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: PowerToys
Issue: add "turn off screen" system command 
Labels: Needs-Triage,Needs-Team-Response

### Description of the new feature / enhancement

I like the system commands from power toys run. it would be a nice addition to be able to turn off the screen with a command

### Scenario when this would be used?

when I have to leave my laptop on over night to do some heavy calculations/simulations/renderings it would be nice to just type this command and be able to turn off the screen without having to change the turn off time in the settings.

### Supporting information

_No response_
Repository: pytorch
Issue: Proposal: `@capture`: Unified API for capturing functions across `{fx, proxy_tensor, dynamo}`
Labels: feature,triaged,months,oncall: pt2,module: functorch,module: dynamo,module: pt2-dispatcher

> ```python
> # replaces `@fx.wrap`
> @fx.capture 
> def my_traced_op(x):
>   pass
> 
> # new API, similar to `@fx.wrap`. `make_fx` will capture this function.
> @proxy_tensor.capture 
> def my_traced_op(x):
>   pass
> 
> # replaces `dynamo.allow_in_graph`
> @dynamo.capture 
> def my_traced_op(x):
>   pass
> ```
> 
> Can we break backwards compatibility on `wrap`? It is a terrible API due to its name. 
> `capture` could be the preferred new API, and `wrap` will simply alias it, then we can deprecate `wrap` slowly.

_Originally posted by @jon-chuang in https://github.com/pytorch/pytorch/issues/94461#issuecomment-1435530121_
            
Examples of user demand for custom op tracing:
1. https://github.com/pytorch/pytorch/issues/95021
2.  https://github.com/pytorch/pytorch/pull/94867

Question: is there overlap between `@dynamo.capture` and `@proxy_tensor.capture`? Whether the fx graph traced by dynamo is traced again by `make_fx` depends on the backend (e.g. `aot_eager`, `inductor`). So I suppose that to trace an op through `torch.compile` and into a backend like aot_eager which uses `make_fx`, one should wrap with both, correct? @jansel 

cc @ezyang @chauhang @penguinwu @zou3519 @Chillee @samdow @kshitij12345 @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames @rec @bdhirsh @msaroufim @wconstab @anijain2305 @janeyx99 @aakhundov @soumith @ngimel @yanboliang @Xia-Weiwen @desertfire
Repository: rust
Issue: Const equality disagrees when using in match and if
Labels: A-const-eval,A-patterns

Consider following code:

```rust
#[derive(Debug, PartialEq, Eq)]
struct Foo([u32; 4]);

const fn bar() {
    const ONE: Foo = Foo([1, 0, 0, 0]);
    match Foo([0, 0, 0, 0]) {
        ONE => unreachable!(),
        _ => {},
    }

    if ONE == Foo([0, 0, 0, 0]) {
        unreachable!()
    }
}
```

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=f2b2c2421583fbb47472f8e8746b394f
It fails with "the trait `PartialEq<_>` is implemented for `Foo`, but that implementation is not `const`". 

But if we do add a const implementation:

```rust
#![feature(const_trait_impl)]

#[derive(Debug, Eq)]
struct Foo([u32; 4]);

impl const PartialEq for Foo {
    fn eq(&self, other: &Self) -> bool {
        self.0[0] == other.0[0]
        && self.0[1] == other.0[1]
        && self.0[2] == other.0[2]
        && self.0[3] == other.0[3]
    }
}


const fn bar() {
    const ONE: Foo = Foo([1, 0, 0, 0]);
    match Foo([0, 0, 0, 0]) {
        ONE => unreachable!(),
        _ => {},
    }

    if ONE == Foo([0, 0, 0, 0]) {
        unreachable!()
    }
}

```
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=a980e3ab7d72b9545886de5547cf4963
then it fails with "to use a constant of type `Foo` in a pattern, `Foo` must be annotated with `#[derive]"

So we found ourselves between rock and hard place where we have to choose between using pattern matching and equality.
Repository: transformers
Issue: kros_test
Labels: New model

### Model description

1st test model trained by 100 pages

### Open source status

- [X] The model implementation is available
- [X] The model weights are available

### Provide useful links for the implementation

_No response_
Repository: next.js
Issue: next dev listens on IPv6 but next start does not
Labels: bug

### Verify canary release

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

### Provide environment information

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:39:35 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T8103
    Binaries:
      Node: 18.14.0
      npm: 9.4.1
      Yarn: N/A
      pnpm: 7.27.0
    Relevant packages:
      next: 13.1.7-canary.20
      eslint-config-next: 13.1.6
      react: 18.2.0
      react-dom: 18.2.0

### Which area(s) of Next.js are affected? (leave empty if unsure)

_No response_

### Link to the code that reproduces this issue

Any project generated by create-next-app

### To Reproduce

Initialise a new project with `create-next-app`:
```
npx create-next-app@latest ipv6-test
```
(Accept all defaults.)

Start the dev server:
```
% npx next dev
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
```
Check on which interfaces it's listening on:
```
% netstat -ant |grep 3000
tcp46      0      0  *.3000                 *.*                    LISTEN
```
Start the prod server:
```
% npx next build
% npx next start
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
```
Check on which interfaces it's listening on:
```
% netstat -ant |grep 3000
tcp4       0      0  *.3000                 *.*                    LISTEN
```




### Describe the Bug

`next start` does not listen on IPv6 by default, while `next dev` does.

This resulted in a weird situation where another Node.js app could not connect to the Next.js server on `localhost` but only when running in production mode.

### Expected Behavior

`next dev` and `next start` should listen on the same interfaces by default.

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

_No response_

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

_No response_
Repository: next.js
Issue: [NEXT-705] API routes returning 404 when adding RSC header
Labels: bug,linear: next

### Verify canary release

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

### Provide environment information

```
npx next info

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:43 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T8112
    Binaries:
      Node: 16.18.1
      npm: 8.19.2
      Yarn: N/A
      pnpm: 7.26.3
    Relevant packages:
      next: 13.1.7-canary.20
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
```

### Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Middleware / Edge (API routes, runtime)

### Link to the code that reproduces this issue

https://github.com/rijk/repro-issue-api-rsc-routing

### To Reproduce

1. Go to https://repro-issue-api-rsc-routing.vercel.app/
2. Observe in Network console prefetch call to /api/get-next-lesson returning a 404
3. Click on [Continue learning](https://repro-issue-api-rsc-routing.vercel.app/api/get-next-lesson) link
4. Observe no 404, but redirecting as intended

Alternative reproduction:

1. Do a GET request to https://repro-issue-api-rsc-routing.vercel.app/api/get-next-lesson from Postman
2. Observe lesson page returned
3. Add `RSC: 1` header
4. Observe 404 returned

### Describe the Bug

In my course app, there are "Continue" buttons that take take you to the next uncompleted lesson in the course. This is implemented with an API route, that fetches your progress and then redirects you to the next lesson.

This works fine when clicking the link, however when the router prefetches it, Vercel returns a 404. I believe this is because the `RSC` header forces the routing into the app directory, even though this is an API route. I think this header should be ignored for API routes (and maybe for all routes that have a filesystem match in the `pages` directory, but not sure about that).

### Expected Behavior

I would expect the server to return the same thing for a GET request to https://repro-issue-api-rsc-routing.vercel.app/api/get-next-lesson with or without the `RSC` header: the redirect. This is how it works when running the code locally through `npm dev`, and allows the client to prefetch so it already knows what to redirect to and the user does not have to wait when clicking the Continue button.

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

_No response_

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

Vercel

<sub>[NEXT-705](https://linear.app/vercel/issue/NEXT-705/api-routes-returning-404-when-adding-rsc-header)</sub>
Repository: node
Issue: Using `for await...of` with `break` to read from a stream
Labels: stream

### Version

v18.14.1

### Platform

Microsoft Windows NT 10.0.19045.0 x64"Microsoft Windows NT 10.0.19045.0 x64

### Subsystem

streams

### What steps will reproduce the bug?

I'm trying to read from `process.stdin` by using `for await` until I get `\n` (as you can see in the code snippet blow):

```js
const readLine = async () => {
  process.stdin.on('error', err => {
    console.log('stdin error:', err);
  });
  let str = '';
  for await (const chunk of process.stdin) {
    str += chunk.toString();
    if (str.includes('\n'))
      break;
  }
  return str.split('\n')[0];
};
```

But when it reaches to `break`, it will throw an error in the stream.

The output of my log:

```
stdin error: AbortError: The operation was aborted
    at Object.destroyer (node:internal/streams/destroy:305:11)
    at createAsyncIterator (node:internal/streams/readable:1141:19) {
  code: 'ABORT_ERR'
}
````

I've also tried to read from a file stream like this and got the same error.

I got the same error on a Mac machine as well.


### How often does it reproduce? Is there a required condition?

Always

### What is the expected behavior?

I don't know what exactly the expected behavior should be here, but throwing an error doesn't make sense to me

### What do you see instead?

-

### Additional information

_No response_
Repository: stable-diffusion-webui
Issue: [Feature Request]: processing multiple images at once using the img2img batch mode.
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

So for example, lets say im processing a folder of images using the img2img batch mode, but i want to process the first 3 images at once, and then once they are done move on to the next 3 images, and so on, like a larger batch size without processing the same images multiple times. Currently if i increase the batch size in the img2img batch mode, it processes the same image multiple times, and then moves on to the next one.

### Proposed workflow

Im not sure.

### Additional information

_No response_
Repository: godot
Issue: `Input.parse_input_event(event)` do not work on headless mode
Labels: discussion,documentation,topic:input

### Godot version

v4.0.rc2.official [d2699dc7a]

### System information

Windows 10

### Issue description

I need to run my tests on a CI with `--headless` option because of no render output is available.

The propagated input events are never emitted when Godot is run in headless mode.

This part is working when run Godot normaly and not when run with `--headless` option
```gdscript
func _handle_input_event(event :InputEvent):
	if event is InputEventMouse:
		Input.warp_mouse(event.position)
	Input.parse_input_event(event)
	Input.flush_buffered_events()
```
This blocks me now to run my UI tests in headless mode ;(


### Steps to reproduce


run the attached script
```
%GODOT_BIN% --path . -s res://test.gd

Vulkan API 1.3.224 - Forward+ - Using Vulkan Device #0: NVIDIA -

-> fire input event
Enter
Mouse motion at position ((96, 463)) with velocity ((0, 0))
```



and with `--headless`
```
%GODOT_BIN% --path . -s res://test.gd --headless

-> fire input event
```


### Minimal reproduction project

[input_event.zip](https://github.com/godotengine/godot/files/10774626/input_event.zip)
Repository: rust
Issue: `Command::status` method doesn't say when it will return an `Err(...)`
Labels: T-libs-api,A-docs,A-process

### Location

rustdocs for std

### Summary

I think the following methods:

[Command::spawn(&mut self)](https://doc.rust-lang.org/std/process/struct.Command.html#method.spawn)
[Command::output(&mut self)](https://doc.rust-lang.org/std/process/struct.Command.html#method.output)
[Command::status(&mut self)](https://doc.rust-lang.org/std/process/struct.Command.html#method.status)
[Child::wait(&mut self)](https://doc.rust-lang.org/std/process/struct.Child.html#method.wait)
[Child::try_wait(&mut self)](https://doc.rust-lang.org/std/process/struct.Child.html#method.try_wait)
[Child::wait_with_output(self)](https://doc.rust-lang.org/std/process/struct.Child.html#method.wait_with_output)

ought to mention when they will exit with an `Err(_)`. From a discussion in the community Discord:

"nils, supposedly one of the many: they will error when the command is not found
nils, supposedly one of the many: well
nils, supposedly one of the many: there are probably other conditions than "command not found"
nils, supposedly one of the many: just in general when it failed to spawn it
nils, supposedly one of the many: which can happen for all kinds of issues"

Maybe it should be a module level doc to avoid duplication.
Repository: godot
Issue: Animation Tree preview conflicts with Animation Player preview (property combination or override)
Labels: enhancement,discussion,topic:editor,topic:animation

### Godot version

v4.0.rc2.official [d2699dc7a]

### System information

Linux Ubuntu 20.04 with Unity desktop

### Issue description

When AnimationTree is Active, it previews tree animations and transitions in the editor.

In the AnimationPlayer Animation panel, we can press play to preview a single animation.

Do both results in cumulation of the single animation and the current tree animation, either combining or overriding properties. This is rarely desired and can lead to odd animations.

Giving priority to one of the two (the last one triggered by user input, or always tree, or always player) would make things clearer.

Alternatively, distinguishing AnimationTree being Active for runtime, and AnimationTree preview in editor, with an extra toggle, could at least reduce the risk of conflict as the developer wouldn't constantly keep tree animations playing (by fear of forgetting to re-activate the tree before hitting Play).

I don't know what the desired behavior was, so it may be a suggestion, but for the confusion it causes I reported it as a bug first.

### Steps to reproduce

1. Open repro project. Note that Animation Tree is already Active and previewing
2. Select AnimationPlayer, select animation3 (rotation) and preview-play it
3. Observe a weird combination of translation (animation1 & 2 from tree) + rotation (animation3)

You can also try to play animations 1 & 2, they will override translation animations in the tree (sometimes playing at the same time as themselves).

### Minimal reproduction project

[v4.0.rc2 - Animation player vs tree preview conflict.zip](https://github.com/godotengine/godot/files/10774745/v4.0.rc2.-.Animation.player.vs.tree.preview.conflict.zip)

v4.2.2
[v4.2.2 - Animation Tree preview prevents Animated Sprite animation preview.zip](https://github.com/user-attachments/files/15741778/v4.2.2.-.Animation.Tree.preview.prevents.Animated.Sprite.animation.preview.zip)
(slightly different as it was made for another issue, animations are named "default" and "eyes" and there is no rotation, so may be harder to see how things merge, but basically when previewing both tree and player, sprites will jump unexpectedly)
Repository: pytorch
Issue: cuda 12 support request.
Labels: module: cuda,triaged

### 🚀 The feature, motivation and pitch

graphical card is 4070ti (which is released 2023.1.4)
cuda version 12.

can't find correct version on https://pytorch.org/get-started/locally/ 

### Alternatives

_No response_

### Additional context

_No response_

cc @ngimel
Repository: pytorch
Issue: CosineAnnealingWarmRestarts but restarts are becoming more frequent
Labels: triaged,module: LrScheduler

I'm training a model on a large dataset (1 epoch is more than 3000 iterations). An ideal learning rate scheduler is CosineAnnealingWarmRestarts in my case but it would be better if it would make restarts more frequently as training goes further. I tried to pass 0.5 for `T_mult` but it didn't work. I got this error `ValueError: Expected integer T_mult >= 1, but got 0.5`. I think it can be implemented safely with integer division `T_0 // T_mult`. Is there any special reason not to implement this functionality?
Repository: tauri
Issue: Cannot have focus on Ubuntu GNOME
Labels: type: bug,platform: Linux,status: needs triage

### Describe the bug

I am on Ubuntu 22.04, with GNOME on Xorg (because Tauri doesn’t support global shortcuts on wayland)

My app launches as a tray app.

I registered a global shortcut to show my window, and it works well. Though : the window does not have any focus. When the shortcut is triggered, i get my window, i make it .show(), and I make it .set_focus()… but it won’t. I must click on it to get my focus.
Same with a tray item as a trigger.

### Reproduction

1. Crrate a Tauri app
2. Main window is hidden by default
3. App is a tray app
4. Register a global shortcut : when triggered, get the main window and make it visible. No focus
5. You can make a set_focus too : no focus on the app

### Expected behavior

With a show(), the window is supposed to get the focus.

### Platform and versions

```
Environment
  › OS: Ubuntu 22.04 X64
  › Node.js: 18.13.0
  › npm: 8.19.3
  › pnpm: 7.25.1
  › yarn: Not installed!
  › rustup: 1.25.2
  › rustc: 1.67.0
  › cargo: 1.67.0
  › Rust toolchain: stable-x86_64-unknown-linux-gnu 

Packages
  › @tauri-apps/cli [NPM]: 1.2.3
  › @tauri-apps/api [NPM]: 1.2.0
  › tauri [RUST]: 1.2.4,
  › tauri-build [RUST]: 1.2.1,
  › tao [RUST]: 0.15.8,
  › wry [RUST]: 0.23.4,

App
  › build-type: bundle
  › CSP: unset
  › distDir: ../build
  › devPath: http://localhost:5173/
  › framework: Svelte
  › bundler: Vite

App directory structure
  ├─ src
  ├─ .idea
  ├─ build
  ├─ .svelte-kit
  ├─ static
  ├─ .git
  ├─ node_modules
  └─ src-tauri

```

### Stack trace

No errors

### Additional context

_No response_
Repository: rust
Issue: miscompilation with incremental + unpacked debug + macos 
Labels: O-macos,P-high,T-compiler,regression-from-stable-to-stable,I-unsound,A-incr-comp,C-bug

The following script illustrates a miscompilation on macOS when using incremental and unpacked debug:

I tried this code:

```bash
#!/bin/bash 

rm -rf *.o incremental foo

echo "fn main() { let a: i64 = 1 << 64; }" > foo1.rs
echo "fn main() { let a: i64 = 1 << 63; }" > foo2.rs

ARGS="--crate-name foo -C split-debuginfo=unpacked -C debuginfo=2 -C incremental=incremental"

for i in {1..20}
do
    rustc foo1.rs $ARGS && { echo "ERROR: first build should have failed"; exit 1; }
    rustc foo2.rs $ARGS || { echo "ERROR: second build should have passed"; exit 1; }
    ./foo || { echo "ERROR: executing should have passed"; exit 1; }
done
```

The first compilation should fail due to the overflow error:

```
error: this arithmetic operation will overflow
 --> src/main.rs:1:26
  |
1 | fn main() { let a: i64 = 1 << 64; }
  |                          ^^^^^^^ attempt to shift left by `64_i32`, which would overflow
  |
  = note: `#[deny(arithmetic_overflow)]` on by default
```

The second compilation should succeed since the overflow has been removed.
Then executing the binary should pass, since there is no overflow.

Instead, this happened:

Sometimes executing the binary will fail, as-if it compiled with the incorrect constant value:

```
thread 'main' panicked at 'attempt to shift left with overflow', foo1.rs:1:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
ERROR: executing should have passed
```

This doesn't happen *always*, although it usually happens right away (thus the reason for the loop in the script).

Testing on macOS 13.2 aarch64 and macOS 12.6.3 x86_64 with either Xcode 14 or 13.

I couldn't get it to fail on Linux.

## Bisection

This appears to be a regression introduced in #87337. Presumably because before that it wouldn't write any `.o` files (or write anything to the incremental db) due to the error. Strangely, I cannot get it to fail with `#![allow(arithmetic_overflow)]`, and I don't really have a theory as to why.
Repository: godot
Issue: Localization POT Generation does not recognize `tres` files
Labels: enhancement,topic:editor

### Godot version

v4.0.rc.custom_build [f84479fe5]

### System information

Ubuntu

### Issue description

the probably single most common location for translatable strings - `tres` files - seems to be the only file type not recognized by the POT generation tool. when changing the filter to "All Files" and selecting a `tres` nonetheless, we get an error message: 
```
editor/pot_generator.cpp:78 - Unrecognized file extension tres in generate_pot()
```

### Steps to reproduce

1. in any project, navigate to Project > Project Settings > Localization > POT Generation
2. Click `Add...`, change the filter to `All Files (*)`, and select any `tres` file
3. note that no POT has been generated and that an error message appears

### Minimal reproduction project

n/a