sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: GPU Particles 2D/3D stop moving when colliding with a moving collider
Labels: bug,topic:particles

### Godot version

v4.1.2.stable; v4.2.beta2

### System information

Godot v4.2.beta2 - Windows 10.0.19045 - Vulkan (Forward+, Mobile) - GLES3 (Compatibility) - dedicated NVIDIA GeForce GTX 1650 (NVIDIA; 31.0.15.3742) - Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (8 Threads)

### Issue description

The GPU particles 2D and 3D seem to ignore collisions or freeze in place in the situations below:

1) Stationary particles don't move when colliding with a moving collider. Hide on Contact still works fine.
2) Particles stop moving when they hit a collider moving in the same or opposite direction. In 2D, this only happens above "Fixed FPS" 32.
3) Particles with friction above 0.55 stop moving after a few frames when they're being pushed in any direction by a moving collider. In 2D, this only happens above "Fixed FPS" 50.
4) In 3D, particles with a small size stop moving when collided against, while the same particles with a normal size are pushed normally.
4) (2nd MRP) Slow moving particles won't slide on colliders (moving or stationary). The issue seems to show on velocity values lower than 7.

I'm not sure if these are the same issues or different ones, but since they have the same symptoms, I decided to keep them together.

The expected behavior would be for those particles to be pushed away by the collider (like the white particle in the reproduction project)

_*Any references to a Collider means the LightOccluder2D or GPUParticlesCollisionBox3D_


### Steps to reproduce

The reproduction project has "main_2d" and "main_3d" scenes that show the issue, even in the editor.

### Minimal reproduction project

[GPUParticles Collisions.zip](https://github.com/godotengine/godot/files/13125842/GPUParticles.Collisions.zip)
[GPUParticles Collisions Slow.zip](https://github.com/godotengine/godot/files/13151577/GPUParticles.Collisions.Slow.zip)
Repository: flutter
Issue: Wonderous app doesn't launch with a local engine
Labels: platform-ios,tool,engine,P3,team-tool,triaged-tool

## description

Wonderous cannot launch on the iOS simulator with a local engine.  I tried both x64 and arm64 versions of the host engine, neither worked.

## steps to reproduce
1) Download https://github.com/gskinnerTeam/flutter-wonderous-app.git
1) Build a local engine
1) launch the ios simulator
1) Attempt to execute it with `flutter --local-engine=ios_debug_sim_unopt_arm64 --local-engine-host=host_debug_unopt --local-engine-src-path=/Users/aaclarke/dev/engine/src/ run`

## error
```
$ ~/bin/flutter-ios-debug-sim-unopt-arm64 run
Resolving dependencies... 
  cross_file 0.3.3+5 (0.3.3+6 available)
  file 6.1.4 (7.0.0 available)
  flutter_animate 1.0.0 (4.2.0+1 available)
  flutter_lints 2.0.3 (3.0.0 available)
  flutter_native_splash 2.3.3 (2.3.4 available)
  go_router 6.5.9 (12.0.0 available)
  lints 2.1.1 (3.0.0 available)
  package_info_plus 5.0.0 (retracted)
  petitparser 5.4.0 (6.0.1 available)
  share_plus 8.0.0 (retracted)
  share_plus_platform_interface 3.3.0 (3.3.1 available)
  shared_preferences_linux 2.3.1 (2.3.2 available)
  shared_preferences_windows 2.3.1 (2.3.2 available)
  uuid 3.0.7 (4.1.0 available)
  vector_graphics 1.1.7 (1.1.9 available)
  vector_graphics_codec 1.1.7 (1.1.9 available)
  vector_graphics_compiler 1.1.7 (1.1.9 available)
  xml 6.3.0 (6.4.2 available)
Got dependencies!
16 packages have newer versions incompatible with dependency constraints.
Try `flutter pub outdated` for more information.
Exception: Attempted to generate localizations code without having the flutter: generate flag turned on.
Check pubspec.yaml and ensure that flutter: generate: true has been added and rebuild the project. Otherwise, the localizations source code will not be importable.
Launching lib/main.dart on iPad Air (5th generation) in debug mode...
Running Xcode build...                                                  
Xcode build done.                                            4.2s
Failed to build iOS app
Error (Xcode): Target native_assets failed: Exception: Unsupported MacOS arch name ""


Could not build the application for the simulator.
Error launching application on iPad Air (5th generation).
```

cc @LouiseHsu
Repository: godot
Issue: GPU Particles 2D/3D move in the opposite direction after being pushed
Labels: bug,topic:rendering,topic:particles

### Godot version

v4.1.2.stable; v4.2.beta2

### System information

Godot v4.2.beta2 - Windows 10.0.19045 - Vulkan (Forward+, Mobile) - GLES3 (Compatibility) - dedicated NVIDIA GeForce GTX 1650 (NVIDIA; 31.0.15.3742) - Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (8 Threads)

### Issue description

GPU Particles sometimes move in the opposite direction after being pushed by the side of their velocity.

This seems to happen after they get dragged away by a moving collider, and only in a specific side, as other particles actually keep moving in the direction they were dragged.

The expected behavior would be for those particles to keep their momentum and continue moving in the same direction even after the collider moves away.

_*Any references to a Collider means the LightOccluder2D or GPUParticlesCollisionBox3D_

### Steps to reproduce

The reproduction project has "main_2d" and "main_3d" scenes that show the issue, even in the editor.

### Minimal reproduction project

[GPUParticles Collision Direction.zip](https://github.com/godotengine/godot/files/13061353/GPUParticles.Collision.Direction.zip)
Repository: rust
Issue: `improper_ctypes` is many clippy lints in 1~2 rustc lints
Labels: C-cleanup,A-lints,A-diagnostics,A-FFI,T-lang,T-compiler,C-bug,A-clippy,L-improper_ctypes

In general, rustc lints are held to a standard of "low false positives". Sometimes they may be opinionated (e.g. all the style lints), but they should generally at least be correct about what they are linting on. Unfortunately, the `improper_ctypes` lint is a grab-bag of opinions, but few of them necessarily reflect the actuality of what safe FFI looks like, partly [because](https://github.com/rust-lang/rust/issues/43894) [Rust's](https://github.com/rust-lang/rust/issues/54341) [in-compiler ](https://github.com/rust-lang/rust/issues/58487)[understanding](https://github.com/rust-lang/rust/issues/102174) [of](https://github.com/rust-lang/rust/issues/110505) [C](https://github.com/rust-lang/rust/issues/115336) [ABIs](https://github.com/rust-lang/rust/issues/115404) [is](https://github.com/rust-lang/rust/issues/115609) [actually](https://github.com/rust-lang/rust/issues/116344) [fairly](https://github.com/rust-lang/rust/issues/115666) [lacking](https://github.com/rust-lang/rust/issues/116558). They are over-conservative approximations, which must often be responded to with liberal usage of `allow(improper_ctypes)`.

In other words, it's a clippy lint. Probably multiple (it's already split into `improper_ctypes_definitions`, for instance).

This is not a new concern, considering:
- https://github.com/rust-lang/rust/issues/116831
- https://github.com/rust-lang/rust/issues/115457
- https://github.com/rust-lang/rust/issues/116959
- https://github.com/rust-lang/rust/issues/94000
- https://github.com/rust-lang/rust/issues/95683
- https://github.com/rust-lang/rust/issues/87438
- https://github.com/rust-lang/rust/issues/60757

I'm not the only one who has suggested extensively refactoring it:
- https://github.com/rust-lang/rust/issues/72774

Perhaps the more niche cases that it warns on should be moved to clippy and allowed to bake for... a while. This, admittedly, would be the first case that I know of for casting a lint down instead of lifting it up, but it may be justified.
Repository: pytorch
Issue: maximum Python version supported is not indicated
Labels: module: docs,triaged

### 📚 The doc issue

https://pytorch.org/get-started/locally/

Python 3.12 has been released, but it's not supported by the PyTorch wheels. This is not indicated on the page. Only the minimum Python version is indicated 

### Suggest a potential alternative/fix

Indicate both min and max Python versions supported when installing via pip.

cc @svekars @carljparker
Repository: godot
Issue: `signed_angle_to` affected by axes other than the axis given
Labels: enhancement,topic:core,documentation,topic:3d

### Godot version

4.2-beta1

### System information

MacOS 12.3

### Issue description

I've noticed while using [`signed_angle_to`](https://docs.godotengine.org/en/stable/classes/class_vector3.html#class-vector3-method-signed-angle-to) that it behaves strangely if the `to` vector is not on the same plane as the parent vector relative to the given `axis`.

Video [here](https://youtube.com/watch?v=D-qd-zJBZfY).

### Steps to reproduce

Clone the repro project, run it, and move the green target sphere on the Y plane, and then move it on the Y axis.

### Minimal reproduction project

https://github.com/wjagodfrey/godot_4_2_beta1_signed_angle_to
Repository: next.js
Issue: eslint-plugin-next/no-html-link-for-pages - Support for `pageExtensions`
Labels: bug

### Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/restless-river-xwfg2j?file=%2F.eslintrc.json%3A4%2C1

### To Reproduce

1. Open the terminal and run `yarn eslint .`
2. No warnings are showing up

### Current vs. Expected behavior

- No warnings are showing up / Warning are showing up 

### 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: arm64
      Version: Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.18.0
      npm: 9.8.1
      Yarn: 3.2.1
      pnpm: N/A
    Relevant packages:
      next: 12.3.1
      eslint-config-next: 12.3.4
      react: 17.0.2
      react-dom: 17.0.2
```


### Which area(s) are affected? (Select all that apply)

ESLint (eslint-config-next)

### Additional context

_No response_
Repository: pytorch
Issue: Missing `ignored_param` when calling wrapper_cls (FSDP) recursively
Labels: oncall: distributed,triaged

https://github.com/pytorch/pytorch/blob/935f6977542affc0d16c66333a13d60dae6aa5fa/torch/distributed/fsdp/wrap.py#L561

When calling FSDP class recursively, `ignored_param` (which is supposed to be passed by `ignored_states`) seems to be missing. When I pass parameters to ignore to FSDP, this information is lost at this interface when calling FSDP class recursively. 

I think `ignored_states` should be re-defined here and should be part of `kwargs`.

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu
Repository: opencv
Issue: Your platform doesn't suppport hardware accelerated AV1 decoding. Failed to get pixel format.
Labels: question (invalid tracker),category: videoio,incomplete

### System Information

Hello, I have a problem when using opencv-python:
System information (version)：

python: 3.8
opencv-python: 4.8.1.78
ffmpeg: ffmpeg version 6.0-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2023 the FFmpeg developers




### Detailed description

I just want to extract frame, but it got an unexpected error：
![image](https://github.com/opencv/opencv/assets/44286354/c266990f-79e3-4dab-8b18-d45a6cfc378a)


### Steps to reproduce

Here is my demo code:
```
import cv2

video_path = "/home/marden/source/video/sample.mp4"
cap = cv2.VideoCapture(video_path)

if not cap.isOpened():
print("Error: Could not open video file.")
exit()

ret, frame = cap.read()

if not ret:
print("Error: Could not read frame.")
exit()

cv2.imwrite("frame.jpg", frame)

cap.release()
```

### Issue submission checklist

- [X] I report the issue, it's not a question
- [ ] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [ ] 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: vscode
Issue: Add way to "Go to offset", ideally accessible from the "Go to" command
Labels: feature-request,quick-open

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
It sometimes useful to be able to go a certain offset of a file (e.g. when a tool reports "error xxx at position 599").

This has been implemented for [vscode-hexeditor](https://github.com/microsoft/vscode-hexeditor/pull/203) and it would be nice to have this mainstream and built-in (rather than having to depend on some extensions ... that might be buggy).

A nice way to access it would be from Go-to (<kbd>Ctrl</kbd> + <kbd>G</kbd>) as it is the case in Notepad++ for example, maybe like:
* `:n` would go to line n
* `:n:c` would go to character  c of line n
* `::c` would go to the character c of the whole file (i.e. offset)

The first two being already implemented, that would be the logical continuation
Repository: ant-design
Issue: 【DatePicker.RangePicker】在手动选择时间后切换 picker 类型并设置value，Pannel里的时间范围没有跟设置的 value关联
Labels: 🐛 Bug,Inactive

### Reproduction link

[https://stackblitz.com/edit/react-lzgfut-5kzuwd?file=demo.tsx,index.tsx](https://stackblitz.com/edit/react-lzgfut-5kzuwd?file=demo.tsx,index.tsx)

### Steps to reproduce

1. 点击“显示年”，此时设置的时间范围是 `[2021, 2023]`，手动选择时间范围至`[2024, 2027]`
2. 点击“显示月”，此时程序设置显示的时间范围是 `[2023/05, 2023/08]`，观察此时 Input 框里的时间为正确时间范围
3. 点击控件，观察 RangePicker 的 Pannel 里的时间

### What is expected?

Pannel 里显示设置的时间范围：`[2023/05, 2023/08]`

### What is actually happening?

Pannel 里的时间范围是 `[2024, 2025]`，而不是2023年

| Environment | Info |
| --- | --- |
| antd | 5.10.0 |
| React | 18.2.0 |
| System | Mac 13.2.1 |
| Browser |  118.0.5993.70（正式版本） (arm64) |

---
Pannel里的时间范围没有跟设置的 value关联，观察下来用了之前的缓存值

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: stable-diffusion-webui
Issue: [Feature Request]: Command line support without web server
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 ?

Currently, although an API interface is provided, there is a certain probability of failure when starting the SD webUI. Therefore, it is desired to provide a command-line execution form to improve execution efficiency. For example, when testing Lora performance, relevant code can be directly called to avoid executing test tasks serially on a webUI. This can also reduce the load on the web server.

### Proposed workflow

Just like 
```
python script.py --basemodel="XXX" --cfg="XXXX"  --step="XXXXXX"
```


### Additional information

_No response_
Repository: next.js
Issue: Bundle size increased by ~5% after 13.4.19
Labels: bug

### Link to the code that reproduces this issue

https://github.com/LoiLock/nextjs-bundle-size

### To Reproduce

Recently I found that after only updating nextjs, the bundle size has increased quite a bit for what is only a minor version bump.

The following screenshots were after a fresh install

Not sure where to go from here, would like to find out what causes the increase in size.


### Current vs. Expected behavior

13.4.19:
<img width="500" alt="Screenshot 2023-10-20 at 10 03 18" src="https://github.com/vercel/next.js/assets/33485182/d8a8b708-9491-41d7-9a3d-0df78471fd75">

13.5.7-canary.11:
<img width="480" alt="Screenshot 2023-10-20 at 10 03 49" src="https://github.com/vercel/next.js/assets/33485182/8833493e-6833-452d-b576-d6efd44c7b70">


### 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: arm64
  Version: Darwin Kernel Version 23.0.0: Thu Aug 17 21:23:05 PDT 2023; root:xnu-10002.1.11~3/RELEASE_ARM64_T6000
Binaries:
  Node: 20.1.0
  npm: 9.6.4
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 13.5.7-canary.11
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Additional context

_No response_
Repository: next.js
Issue: next.js renders another template on <Link> click
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://codesandbox.io/s/routing-fail-v2-n2kylw

### To Reproduce

I've noticed that my next.js application renders a different template when I call a page by clicking on a component than when I call the page directly.

This is my folder structure (pages-Folder):

```
[posttype]
    index.js
[...uri].js
index.js
```

Since I'm working with the SSG, I generate the paths at build time:

```
// [...uri].js

export async function getStaticPaths() {
    const paths = [
        {params: {uri: ["about"]}},
        {params: {uri: ["projects"]}},
    ]

    return {
        paths: paths,
        fallback: false
    }
}

// [posttype]/index.js

export async function getStaticPaths() {
    const paths = [
        {params: {posttype: "posts"}},
        {params: {posttype: "articles"}},
    ]

    return {
        paths: paths,
        fallback: false
    }
}
```

If I now call the page `/about/` directly (via the address bar of the browser), the template `[...uri].js` is rendered. However, when I call the page via a link component, the template `[posttype]/index.js` is rendered, which is not correct.

### Current vs. Expected behavior

The correct template should be rendered when clicking on the <Link>-Component.

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro
Binaries:
  Node: 17.8.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 13.5.6
  eslint-config-next: 13.5.6
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Routing (next/router, next/navigation, next/link)

### Additional context

_No response_
Repository: next.js
Issue: Failed to find the font overide value for font Nanum Pen Script
Labels: bug,Font (next/font)

### Link to the code that reproduces this issue

https://github.com/Ayush-v/Ayush-Development/tree/portfolio-refactor

### To Reproduce

1. pnpm i
2. pnpm dev

![Screenshot 2023-10-20 at 2 20 08 PM](https://github.com/vercel/next.js/assets/62958067/3a7ede6c-1a6b-4399-8118-6275a4f081ac)


### Current vs. Expected behavior

the font is being used in src/components/header.tsx file

The error is also there when run next build as well.

### 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: arm64
  Version: Darwin Kernel Version 23.0.0: Fri Sep 15 14:41:34 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T8103
Binaries:
  Node: 18.18.2
  npm: 9.8.1
  Yarn: 3.6.3
  pnpm: 8.9.2
Relevant Packages:
  next: 13.5.7-canary.11
  eslint-config-next: 13.5.2
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router

### Additional context

_No response_
Repository: go
Issue: runtime: mallocgc does not seem to need to call publicationBarrier when allocating noscan objects
Labels: NeedsInvestigation,compiler/runtime

I'm doing some performance analysis of `go1.20` on `arm64` platform, and I found that the DMB instruction in mallocgc consumes a lot of time. 

I found some CLs：

- [CL11083](https://go-review.googlesource.com/c/go/+/11083):  In `go1.5`, `publicationBarrier` was added when allocating scan objects. 
- [CL23043](https://go-review.googlesource.com/c/go/+/23043):  In `go1.7`, `publicationBarrier` is was added when allocating noscan objects because of the `heapBitsSetTypeNoScan`. 
- [CL41253](https://go-review.googlesource.com/c/go/+/41253):  However, `publicationBarrier` is still called when allocating  noscan objects after `heapBitsSetTypeNoScan` is deleted.

I tried to find the reason why `publicationBarrier` was called when allocating noscan objects, but I couldn't find it.


Knowing from the comments of source code, `publicationBarrier` in `mallocgc` ensure that the stores above that initialize x to type-safe memory and set the heap bits occur before the caller can make x observable to the GC. `publicationBarrier` in `allocSpan` make sure the newly allocated span will be observed by the GC before pointers into the span are published.


My question is, GC don't scan noscan object, why is `publicationBarrier` required when allocating noscan objects in `mallocgc`?

Thank you in advance for your help.
Repository: godot
Issue: Godot 3D's performance seems to get worse as time passes.
Labels: needs testing,performance

### Godot version

4.1.2-stable-mono

### System information

Godot v4.1.2.stable.mono - Windows 10.0.22621 - Vulkan (Forward+) - dedicated AMD Radeon RX 6800 XT (Advanced Micro Devices, Inc.; 31.0.22017.1011) - 13th Gen Intel(R) Core(TM) i9-13900K (32 Threads)

### Issue description

Basically what happens is, Godot will tend to slow down and degrade on performance ALOT. Restarting Godot doesn't fix this, only a full PC restart will fix the issue briefly for around 2 - 4 hours.

### Steps to reproduce

Just keep Godot running in the background, regardless of where you use it or not. It should start slowing down.

### Minimal reproduction project

N/A
Repository: flutter
Issue: [tech-debt] Environment.defines default value behavior
Labels: tool,P2,c: tech-debt,team-tool,triaged-tool

The environment defines could benefit from wrapping for dealing with default/required values.

https://github.com/flutter/flutter/blob/8b2c643c96782db810d05f252353849e8475e478/packages/flutter_tools/lib/src/build_system/build_system.dart#L490-L494

For example the defines contain

https://github.com/flutter/flutter/blob/8b2c643c96782db810d05f252353849e8475e478/packages/flutter_tools/lib/src/build_info.dart#L914-L926

There is a doc-comment on these what the default values are if they are missing. But doc-comments are not followed in the code:

This code follows the doc-comment:

https://github.com/flutter/flutter/blob/8b2c643c96782db810d05f252353849e8475e478/packages/flutter_tools/lib/src/build_system/targets/ios.dart#L65-L69

This code doesn't:

https://github.com/flutter/flutter/blob/8b2c643c96782db810d05f252353849e8475e478/packages/flutter_tools/lib/src/build_system/targets/ios.dart#L286-L289

Discovered in:

* https://github.com/flutter/flutter/pull/136948

Regarding the DarwinArchs and IosArchs, they should be maybe required everywhere instead of defaulting to a default value.