sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: hello-algo
Issue: Chinese-to-English (Help Wanted)
Labels: translation

We are working on translating "Hello Algo" from Chinese to English with the following approach:

1. **AI translation**: Carry out an initial pass of translations using the machine learning translator.
2. **Human optimization**: Manually refine the machine-generated outputs to ensure authenticity and accuracy.
3. **Pull request review**: The optimized translation will be doubly checked by the reviewers through GitHub pull request workflow.
4. Repeat steps `2.` and `3.` for further improvements.

<img width="600" alt="image" src="https://github.com/user-attachments/assets/201930ef-723e-4179-b670-e5a084a8211e">

## Join us

We're seeking contributors who meet the following criteria.

- **Technical background**: Strong foundation in computer science, particularly in data structures and algorithms.
- **Language skills**: Native proficiency in Chinese with professional-level English, or native English.
- **Available time**: Dedicated to contributing to open-source projects with a willingness to engage in long-term translation efforts.

That is, our contributors are computer scientists, engineers, and students from different linguistic backgrounds, and their objectives have different focal points:

- **Native Chinese with professional working English**: Ensuring translation accuracy and consistency between CN and EN versions.
- **Native English**: Enhance the authenticity and fluency of the English content to flow naturally and to be engaging.

> [!tip]
> 
> - If you are interested in joining us, don't hesitate to comment on this issue or contact me via krahetx@gmail.com or WeChat `krahets-jyd`.
> - Please read the [contributing guidelines](https://github.com/krahets/hello-algo/blob/main/en/CONTRIBUTING.md) before submitting or reviewing pull requests.
> - We use this [Notion page](https://hello-algo.notion.site/chinese-to-english) to track progress and assign tasks. Please visit it for more details.
Repository: pytorch
Issue: async_compile.triton is unable to cache generated triton kernels due to meta containing kernel names
Labels: low priority,triaged,enhancement,oncall: pt2,module: inductor

### 🐛 Describe the bug

When inductor generates a kernel, it emits inside the async_compile.triton(...). The code inside this block is cached across different graphs.
However, a recent change introduced `'kernel_name'` field inside the meta in order to identify kernels. This field makes it so that the caching can no longer work as each blob is now unique.
Example:
```
@pointwise(
    size_hints=[8],
    filename=__file__,
    meta={'signature': {0: '*fp32', 1: '*fp32', 2: 'i32'}, 'device': 0, 'device_type': 'cuda', 'constants': {}, 'mutated_arg_names': ['out_ptr0'], 'autotune_hints': set(), 'kernel_name': 'triton_poi_fused_3', 'configs': [instance_descriptor(divi
sible_by_16=(0, 1), equal_to_1=(), ids_of_folded_args=(), divisible_by_8=())]},
    min_elem_per_thread=0
)
```

This does not affect caching for kernels in same graph as inductor has another layer of caching.

Two possible solutions @davidberard98 and I discussed are 1) emitting two wrappers in codegen one for profiling and one for regular execution where the profiling one records the name and 2) emitting a wrapper around cached async compile.

### Versions

origin/main

cc @ezyang @anijain2305 @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @msaroufim @wconstab @bdhirsh @zou3519 @yf225 @aakhundov
Repository: rust
Issue: Implement String and str conversion to Cow<OsStr>
Labels: T-libs-api,C-feature-request

It would be nice to have the following:

* `From<&'a str> for Cow<'a, OsStr>`
* `From<String> for Cow<'a, OsStr>`

Right now I have a bunch of `OsStr::new("true").into()` and `OsString::from(value).into()` sprinkled in my code.
Repository: godot
Issue: Casting not creating Safe Line for ConfigFile.get_value
Labels: topic:gdscript,needs testing

### Godot version

4.2.beta3

### System information

Windows 10

### Issue description

Apologies if this is a misunderstanding of the documentation, but in the [Safe lines](https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html#safe-lines) section of the documentation, it says that casting should enable a safe line if it would otherwise not be. However I'm not seeing this when casting `ConfigFile.get_value`.

### Steps to reproduce

Put this function in a script and note the safe lines on the left:

```gdscript
func no_safe_line(config: ConfigFile) -> int:
	var default := 0
	return (config.get_value("", "my_key", default) as int) # This is not a safe line
```

### Minimal reproduction project

See the "Steps to reproduce".
Repository: PowerToys
Issue: AltGr Combinations for keyboard layout stop working when PowerToys is installed
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.75.1

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

General

### Steps to reproduce

AltGr combinations for US INTL Keyboards on Windows 11 stopped working
and i can't do the German ö in any application since installing PowerToys

Specifically, all the following combinations stopped working on US INTL Keyboard Layout and probably all other keyboard layouts as they have a new action/shortcut action when pressed.

AltGr + E > application loses focus

AltGr + P > application loses focus

AltGr + F > application loses focus

AltGr + C > application loses focus

AltGr + M > Nothing happens

possibly some other altgr combos dont work

### ✔️ Expected Behavior

Expected inputs for US INTL:

![3b6d7937-6701-4a44-8047-31ecfb723cce](https://github.com/microsoft/PowerToys/assets/11999105/b3d94313-972e-45a6-823b-e6ef4d645dca)


### ❌ Actual Behavior

AltGr + E > application loses focus

AltGr + P > application loses focus

AltGr + F > application loses focus

AltGr + C > application loses focus

AltGr + M > Nothing happens



### Other Software

_No response_
Repository: flutter
Issue: [Impeller] RoundRect handling is incomplete and inconsistent
Labels: engine,P2,e: impeller,team-engine,triaged-engine

I've spotted a number of places in the Impeller code where round rects aren't handled consistently and sometimes produce bad outcomes for various types of radii. We should consolidate all validation code that attempts to make sense of a rectangle and a radius or group of radii and use it throughout the code. I'll leave a single example here (expressed as an Aiks playground test) as a placeholder for how these things can quickly get out of hand if not properly checked.

(Note that the same output would likely happen for `DrawRRect` because it uses the same Path construction)

<details>
<summary>Playground test</summary>

```
TEST_P(AiksTest, CanRenderDegenerateRRectClip) {
  Canvas canvas;
  Paint paint;
  paint.color = Color::Fuchsia();
  canvas.ClipRRect(Rect::MakeXYWH(100, 100, 300, 300), 400);
  canvas.DrawPaint(paint);
  ASSERT_TRUE(OpenPlaygroundHere(canvas.EndRecordingAsPicture()));
}
```
</details>
Repository: rust
Issue: `doctest` should not be `opt-in`
Labels: T-rustdoc,C-bug,A-doctests

## BUG

`compile_fail` should not be ignored on test function.

## Actual

`compile_fail` is ignored on test function.

```sh
$ cargo test && echo OK
...
OK
```

```rust
pub fn add(left: usize, right: usize) -> usize {
    left + right
}

#[cfg(test)]
mod tests {
    use super::*;

    /// ```compile_fail
    /// let mut x = 5;
    /// x += 2;
    /// ```
    #[test]
    fn it_works() {
        let result = add(2, 2);
        assert_eq!(result, 4);
    }
}
```

## Expected

`compile_fail` should not be ignored on test function.

Same as on non-test function.

```sh
$ cargo test
...
Test compiled successfully, but it's marked `compile_fail`.
...
```

```rust
/// ```compile_fail
/// let mut x = 5;
/// x += 2;
/// ```
pub fn add(left: usize, right: usize) -> usize {
    left + right
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_works() {
        let result = add(2, 2);
        assert_eq!(result, 4);
    }
}
```

### Version

- rustc 1.73.0 (cc66ad468 2023-10-03)

- cargo 1.73.0 (9c4383fb5 2023-08-26)
Repository: TypeScript
Issue: Option to report errors enabled by `useDefineForClassFields`, but still transpile using assignment semantics
Labels: Suggestion,Awaiting More Feedback

### 🔍 Search Terms

"useDefineForClassFields", "class fields errors"

### ✅ Viability Checklist

- [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [X] This wouldn't change the runtime behavior of existing JavaScript code
- [X] This could be implemented without emitting different JS based on the types of the expressions
- [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

Add an option to have TSC generate the same errors it currently generates for `useDefineForClassFields = True`, but while still continuing to transpile fields using the non-spec-compliant assignment semantics.

### 📃 Motivating Example

We must run TS with `useDefineForClassFields = false`, because we find the output code size of define semantics unacceptably large.

We want to be certain that our code continues to behave the same way when we are able to ship this code to environments that understand class fields without transpilation.

We want to eliminate from our code base all cases where field definitions behave differently between the 2 semantics, and then prevent them from ever returning.

To do this, it would be extremely helpful if TSC could report errors for code that would behave differently with define semantics, but also continue transpiling with assign semantics.



### 💻 Use Cases

1. What do you want to use this for?
2. What shortcomings exist with current approaches?
3. What workarounds are you using in the meantime?

For 1:

see the Motivating Example.

For 2  & 3:

The only workaround I know of is to run TSC twice with different options, once for the output we want and once for the errors we want. This is prohibitively expensive to do at scale.
Repository: godot
Issue: Mouse Input not detected in SubViewport when switching to MOUSE_MODE_CAPTURED while mouse is outside of the window
Labels: bug,needs testing,topic:input

### Godot version

4.1.1

### System information

Windows 10, NVIDIA GeForce GTX 1660 Ti, Forward Plus

### Issue description

When using a SubViewport and changing the mouse mode between MOUSE_MODE_CAPTURED and MOUSE_MODE_VISIBLE, it will not detect any mouse inputs unless a mouse button is held down. 

This also happens when alt-tabbing and the cursor is outside of the window, but only after the mouse modes have been switched at least once.

Video:
https://github.com/godotengine/godot/assets/95089122/5e2d76ad-9120-43b6-9fa4-bb4170833699
First the mouse is working fine, then I switch to MOUSE_MODE_VISIBLE, move the cursor outside of the window, switch back to MOUSE_MODE_CAPTURED, then mouse inputs are no longer working unless I hold down left click.

Might be related to #84258, but I'm not sure.

### Steps to reproduce

Create a new 3D project
Set the project to run in fullscreen
Add a SubViewportContainer and a SubViewport, set to fill the whole screen
Add a player character with basic mouse movement and a camera
Add a way to switch mouse modes between visible and captured
Add a box in front of the player for reference when moving the mouse
Run the project, change the mouse mode to visible, move the cursor outside of the window (bottom left), then change the mouse mode back to captured.

### Minimal reproduction project

[MRP.zip](https://github.com/godotengine/godot/files/13245754/MRP.zip)
Repository: godot
Issue: Using _ready to remove node added by `add_sibling` can cause crash
Labels: bug,topic:core,crash

### Godot version

v4.1.3.stable.official [f06b6836a]

### System information

Godot v4.1.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1080 (NVIDIA; 31.0.15.3734) - Intel(R) Core(TM) i5-10600KF CPU @ 4.10GHz (12 Threads)

### Issue description

If a Node is added to the scene tree by `add_sibling` and removed (either by reparenting or removing) from the scene tree during it's own `ready` callback, a crash can occur. The crash is caused by line 1430 in Node.cpp trying to set the index of the new Node, assuming it knows that it is (or where it is) in the scene tree.

https://github.com/godotengine/godot/blob/b733901e9e650fc2f1a43627be2379f5ba200f8d/scene/main/node.cpp#L1428-L1430

I opened a pull request (https://github.com/godotengine/godot/pull/78834) to fix this in the past, but consensus wasn't reached so I figured the issue should be tracked seperately

### Steps to reproduce

Attach the following script to a button and press it a few times:
```gdscript
extends Button

class MyNode extends Node:
	func _ready() -> void:
		get_parent().remove_child(self)

func _pressed() -> void:
	add_sibling(MyNode.new())
```

### Minimal reproduction project

N/A
Repository: pytorch
Issue: DISABLED test_trace_while_active (__main__.NCCLTraceTest)
Labels: oncall: distributed,module: rocm,triaged,module: flaky-tests,skipped

Platforms: rocm

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_trace_while_active&suite=NCCLTraceTest) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/18292774114).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 2 failures and 2 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_trace_while_active`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `distributed/test_c10d_nccl.py`

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
Repository: terminal
Issue: Color Error in Docker on WSL2
Labels: Area-Output,Issue-Bug,Product-Terminal,Priority-3

### Windows Terminal version

1.18.2822.0

### Windows build number

10.0.19045.0

### Other Software

Docker Desktop 4.24.1
Zsh 5.9
Python 3.11

### Steps to reproduce

Using `docker exec -it <container> /usr/local/bin/zsh` to attach to the running container.
Using python rich module to test color.


### Expected Behavior

Color palette should be full and smooth.

### Actual Behavior

![img_v3_024r_4db93ba3-c05d-476e-a3ef-573fd895ae8g](https://github.com/microsoft/terminal/assets/16175763/9973f40e-e502-4c4f-b682-9c7bc744b632)
Repository: next.js
Issue: Can't use server actions with default next babel setup
Labels: bug

### Link to the code that reproduces this issue

https://github.com/tmeasday/next-babel-server-actions-bug

### To Reproduce

1. Clone repro repo [tmeasday/next-babel-server-actions-bug](https://github.com/tmeasday/next-babel-server-actions-bug)
2. `yarn dev`
3. Visit http://localhost:3000/test
4. You'll see 

```
  × Server actions must be async functions
   ╭─[/Users/tom/GitHub/tmeasday/next-babel-server-actions-bug/app/test/action.ts:2:1]
 2 │
 3 │ import _asyncToGenerator from "/Users/tom/GitHub/tmeasday/next-babel-server-actions-bug/node_modules/next/dist/compiled/@babel/runtime/helpers/esm/asyncToGenerator.js";
 4 │ import _regeneratorRuntime from "/Users/tom/GitHub/tmeasday/next-babel-server-actions-bug/node_modules/@babel/runtime/regenerator/index.js";
 5 │ export function action() {
   ·                 ──────
 6 │   return _action.apply(this, arguments);
 7 │ }
 8 │ function _action() {
   ╰────
```

Workarounds (you'll need to delete `.next` before trying each):

1. Use SWC -- delete `.babelrc`
2. Target latest chrome -- change `.babelrc` to:

```json
{
  "presets": [
    [
      "next/babel",
      {
        "preset-env": {
          "targets": { "chrome": 117 }
        }
      }
    ]
  ]
}
```

### Current vs. Expected behavior

Server actions should work with Next's out-of-the-box babel config, ideally even if the browser targets were older too!

### 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.2
  npm: 9.8.1
  Yarn: 1.22.18
  pnpm: 8.6.2
Relevant Packages:
  next: 14.0.2-canary.9
  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)

App Router

### Additional context

_No response_
Repository: next.js
Issue: Next.js v14.0.0 server with socket.io client doesn't send messages with more than a few characters
Labels: bug

### Link to the code that reproduces this issue

https://github.com/mecabricks/debug-socketio

### To Reproduce

1. yarn dev-ws
2. yarn dev
3. Make a `GET` request to the page `http://localhost:3000/api/test`
4. See the logs in the socket.io server terminal window

### Current vs. Expected behavior

The socket.io server shall receive the 3 messages sent by the socket.io client (server side) however only two are received - The two with the same length. The longest is not sent over the network.

```js
socket.emit("partLibraryIconEvent", { test: "abc" });   // OK
socket.emit("partLibraryIconEvent", { test: "abcd" });  // NOT OK
socket.emit("partLibraryIconEvent", { test: "123" });   // OK
```

The message is serialized by socket.io to be sent and the `length` of the message seems to determine if the message is sent or not. Anything shorter goes through and anything longer doesn't.

**The issue appeared between Nextjs v.13.5.7-canary11 and v13.5.7-canary12.**

In debug mode, the message not going through yield a final line  -
`engine.io-client:websocket websocket closed before onclose event`

<img width="1300" alt="Capture d’écran 2023-11-03 à 14 25 54" src="https://github.com/vercel/next.js/assets/45501180/f08c726f-f314-407c-991c-95951fc95d6d">


### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Tested on macOS ARM and Ubuntu in development or production.
```


### Which area(s) are affected? (Select all that apply)

App Router

### Additional context

_No response_
Repository: godot
Issue: MeshInstance2D culling bounds in editor not updated until window changes
Labels: bug,topic:editor,topic:3d

### Godot version

v4.2.beta4.mono.official [93cdacbb0]

### System information

Godot v4.2.beta4.mono - Windows 10.0.19042 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2070 (NVIDIA; 31.0.15.2756) - Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (8 Threads)

### Issue description

When a MeshInstance2D is created in the editor, its culling bounds are initially treated as 1x1 (from -0.5 to +0.5). When the window is resized, the culling bounds are updated to be inline with whatever the mesh or custom AABB is. If the mesh or custom AABB changes, the changes are not reflected until the window changes again.

### Steps to reproduce

Create a MeshInstance2D. Set its mesh to be a new QuadMesh. Change mesh's size. Move viewport so the quad clips the edge of the screen. It will be frustum culled as if its bounds were 1x1 (the initial QuadMesh size)
Change window by maximizing, windowing, or resizing. Quad will now not be erroneously frustum culled.

(Example where the quad's custom culling AABB is set to be smaller than the quad itself)
![Untitled](https://github.com/godotengine/godot/assets/22027276/7f79bec3-05a9-4ee0-8ae6-237b657e2845)



### Minimal reproduction project

n/a
Repository: godot
Issue: C#, Changed event in a custom Resource with [Tool] does not reset properly on Build
Labels: bug,topic:dotnet

### Godot version

4.2beta4, 4.1.2

### System information

Godot v4.2.beta4.mono - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 (NVIDIA; 31.0.15.3667) - 13th Gen Intel(R) Core(TM) i5-13600KF (20 Threads)

### Issue description

C#, Changed event in a custom Resource with [Tool] does not reset properly on Build, and it throw some errors, and cause repeated event subscribe


![image](https://github.com/godotengine/godot/assets/25916527/fcbfc2dd-130a-414e-af7a-860386d791fc)


### Steps to reproduce

1. create a resource object with MyResource script attached
2. change code a bit, then Build the project
3. you will see errors after Build, and if you do step multiple times, when you change the X in the editor, you will notice that 
OnChanged method get invoked multiple times

### Minimal reproduction project

[BugReport.zip](https://github.com/godotengine/godot/files/13246300/BugReport.zip)