sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Mouse enter an mouse leave events not working when opening a project on 4.2.1 from 4.1.2
Labels: discussion,topic:input

### Tested versions

Reproducible in:
Godot_v4.2.1-stable_win64
Godot_v4.1.2-stable_win64

### System information

Windows 10 , 4.2.1-stable 

### Issue description

I have made a testing project for some grid puzzles, i am using the mouse_entered and mouse_exited signal to see if the mouse is under a piece. When working on Godot 4.1.2, everything works as intended but if i open the project with Godot 4.2.1 the mouse signals are not fired anymore.

### Steps to reproduce

This is the link to the project if you want to try it out. https://github.com/irafunesta/grid-puzzle.git

### Minimal reproduction project (MRP)

https://github.com/irafunesta/grid-puzzle.git
Repository: godot
Issue: Wierd particle state after reset the process material in GPUParticle2D
Labels: bug,topic:rendering,topic:2d,topic:particles

### Tested versions

Godot v4.3.dev (89cc635c0)

### System information

 Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (NVIDIA; 31.0.15.4601) - 12th Gen Intel(R) Core(TM) i7-12700F (20 Threads)

### Issue description

When trying to debug https://github.com/godotengine/godot/issues/87123, I sometimes notice that after reset the process material, the particle will go crazy like below:

![image](https://github.com/godotengine/godot/assets/8315986/d60dd018-472c-4044-ae1b-d7721723149a)

give it the shader for the first time might looks like this:

![image](https://github.com/godotengine/godot/assets/8315986/347c790a-7448-4727-83cc-0b0ae212248d)

I admit the shader here is not that valid, but it does look like that some state is not inited well. And even the shader is not good, reset it is supposed to give the correct ( normal )  result.

```
shader_type particles;

void start() {
	// Called when a particle is spawned.
	USERDATA1 = vec4(1.0f,1.0,1.0f,1.0);
}

void process() {
	// Called every frame on existing particles (according to the Fixed FPS property).
	//TRANSFORM[3] = USERDATA1;
}
```

See the video below, sometimes I can get the wierd result at the first try:

https://github.com/godotengine/godot/assets/8315986/1c501e0a-329d-4fb3-88c8-bc6ca434c210



### Steps to reproduce

1. Make a GPUParticle2D
2. Give it a texture
3. Give it a Shader material and the related shader
4. reset and re-assign serveral times, observe

### Minimal reproduction project (MRP)

[GPUParticle2D.zip](https://github.com/godotengine/godot/files/13932158/GPUParticle2D.zip)
Repository: vscode
Issue: Screen of the app randomly blanking while using the Wayland Window Manager
Labels: bug,upstream,linux,electron,wayland

Type: <b>Bug</b>

In Fedora 39 with the Gnome desktop environment, launch in the Wayland-enabled Gnome version and open VS Code. The app will randomly black screen when both in fullscreen and windowed mode.

VS Code version: Code 1.85.1 (0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2, 2023-12-13T09:47:11.635Z)
OS version: Linux x64 6.6.9-200.fc39.x86_64
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz (12 x 3999)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>video_decode: enabled<br>video_encode: disabled_software<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: disabled_off|
|Load (avg)|0, 0, 0|
|Memory (System)|15.48GB (13.16GB free)|
|Process Argv|--unity-launch --crash-reporter-id 2aae8724-177c-441b-82c5-c728066ca684|
|Screen Reader|no|
|VM|0%|
|DESKTOP_SESSION|gnome|
|XDG_CURRENT_DESKTOP|GNOME|
|XDG_SESSION_DESKTOP|gnome|
|XDG_SESSION_TYPE|wayland|
</details><details><summary>Extensions (2)</summary>

Extension|Author (truncated)|Version
---|---|---
python|ms-|2023.22.1
vscode-pylance|ms-|2023.12.1

(1 theme extensions excluded)

</details>
<!-- generated by issue reporter -->
Repository: pytorch
Issue: Is this an expected memory profile?
Labels: module: multiprocessing,module: memory usage,triaged

### 🐛 Describe the bug

I've been working with `torch.multiprocessing` for a while now, and I've been trying to understand where a memory leak for some hogwild training code comes from. I managed to narrow down to an MRE here. I'm not sure if this is expected behavior or if my mental models are wrong (in which case, happy to help document my errors in thinking!)

I've attached a code snippet and a memory profile - I'm not sure if this is expected. I also did a few ablations and saw a lot of the same behavior

```python
import torch
import torch.distributed as dist

import time
import os

from torch.multiprocessing import Pipe, Process

_WORLD_SIZE = 2
_RANGE = 1000000

def ping_it(rank, pipe, device, XX):
    os.environ['MASTER_ADDR'] = 'localhost'
    os.environ['MASTER_PORT'] = '7044'
    
    # dist.init_process_group("gloo", rank=rank, world_size=_WORLD_SIZE)
    
    for i in range(_RANGE):
        print(rank, i)
        if i > 0:
            X = pipe.recv()
            X = X.to('cuda:{}'.format(device))
        else:
            XX = XX.to('cuda:{}'.format(device))
        
        pipe.send(XX)


if __name__ == "__main__":
    c1, c2 = Pipe()
    X1 = torch.randn(10000, 10000)
    X2 = torch.randn(10000, 10000)
    p1 = Process(target=ping_it, args=(0, c1, 1, X1))
    p2 = Process(target=ping_it, args=(1, c2, 2, X2))
    p1.start()
    p2.start()
    
    time.sleep(30)
    
    p1.join()
    p2.join()
 ```
 
 I log memory with:
 
 ```python
 import os
import time
import argparse

parser = argparse.ArgumentParser()
parser.add_argument("--file", type=str, default="check.log")
parser.add_argument("--interval", type=int, default=60)
args = parser.parse_args()

def get_memory():
    tim = time.time()
    ram =  os.popen('free -m').readlines()[1].split()[2]
    return tim, ram

if __name__ == "__main__":
    with open(args.file, 'a') as f:
        f.write("Time, RAM\n")
        while True:
            tim, ram = get_memory()
            print(tim, ram)
            f.write("{}, {}\n".format(tim, ram))
            time.sleep(args.interval)
```

Here is the memory profile I got: 
![memprof](https://github.com/pytorch/pytorch/assets/7892382/92c7a542-4ac9-42c4-90bb-ebe80cacc786)

(Running for longer or with different sizes didn't materially change the outcome)

### Versions

Pytorch 2.1.2cu121
Ubuntu 20.04
Python 3.10

cc @VitalyFedyunin
Repository: tauri
Issue: [bug] UI does not  fit properly when scale factor is higher than 100%
Labels: type: bug,status: needs triage

### Describe the bug

First two screenshots are of the app I'm working on with the display set to 125% and 100% on a Linux Mint (Ubuntu derivative) VM on VirtualBox. Notice that the UI is blown up.

125%
![image](https://github.com/tauri-apps/tauri/assets/21298211/8de9335e-7afd-44d3-89c6-77403da620e5)
100%
![image](https://github.com/tauri-apps/tauri/assets/21298211/b003128f-dccd-4cd2-b672-3a47b5777288)

Native Linux Mint App (100%)
![image](https://github.com/tauri-apps/tauri/assets/21298211/59fe9e35-3710-4950-a93a-73877d030250)
Native Linux Mint App (125%)
![image](https://github.com/tauri-apps/tauri/assets/21298211/b0e4029a-221e-417c-86f2-ceb36e8770cc)



### Reproduction

_No response_

### Expected behavior

The UI should not be scaling. I'm not sure if this is CSS issue or if this is a Tauri issue, but writing a ticket here just in case.

### Full `tauri info` output

```text
yarn run v1.22.21
$ tauri info
WARNING: Only one package manager should be used, but found yarn and bun.
         Please remove unused package manager lock files, will use yarn for now!

[✔] Environment
    - OS: Linux Mint 21.2 X64
    ✔ webkit2gtk-4.0: 2.42.3
    ✔ rsvg2: 2.52.5
    ✔ rustc: 1.75.0 (82e1608df 2023-12-21)
    ✔ cargo: 1.75.0 (1d8b05cdd 2023-11-20)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: 1.75.0-x86_64-unknown-linux-gnu (overridden by '/home/elijah/Documents/CodeRepos/obscuravpn-app/rust-toolchain.toml')
    - node: 20.9.0
    - pnpm: 8.14.1
    - yarn: 1.22.21
    - npm: 10.1.0

[-] Packages
    - tauri [RUST]: 1.5.2
    - tauri-build [RUST]: 1.5.0
    - wry [RUST]: 0.24.6
    - tao [RUST]: 0.16.5
    - @tauri-apps/api [NPM]: 1.4.0
    - @tauri-apps/cli [NPM]: 1.5.6

[-] App
Done in 18.39s.
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: PowerToys
Issue: Gaelic is not the same as Scotch Gaelic
Labels: Issue-Bug,Needs-Triage,Product-Quick Accent

### Microsoft PowerToys version

0.77.0

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Quick Accent

### Steps to reproduce

Accent a vowel and notice the direction of the accent mark—it's pointing the wrong way! Don't know if this is once in a while or always, but it was there and annoying! 

### ✔️ Expected Behavior

Scotch Gaelic accent should point(thin end) to the left.

### ❌ Actual Behavior

The accent pointed(thin end) to the right.

### Other Software

_No response_
Repository: node
Issue: SIGINT is not handled when a short-lived process is run in watch-mode
Labels: watch-mode

### Version

v20.11.0

### Platform

Linux hostname 6.5.7-arch1-1 \#\1 SMP PREEMPT_DYNAMIC Tue, 10 Oct 2023 21:10:21 +0000 x86_64 GNU/Linux

### Subsystem

_No response_

### What steps will reproduce the bug?


1. Write some short-lived script and save it to `index.js`.

````js
console.log("short-lived!");
````

2. Run this script in watch-mode.

```console
$ node --watch index.js
(node:1191877) ExperimentalWarning: Watch mode is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
short-lived!
Completed running 'index.js'
````

After following the above steps, you will no longer be able to terminate the Node.js process in watch-mode with `SIGINT` or `SIGTERM`.

### How often does it reproduce? Is there a required condition?

If you follow the steps, it will always reproduce.

### What is the expected behavior? Why is that the expected behavior?

A Node.js process in watch-mode will be terminated if we send `SIGINT` or `SIGTERM` to the process, such as with `Ctrl + C`.

### What do you see instead?

```console
$ vim index.js
$ cat index.js
console.log("short-lived!");
$ node test.js
short-lived!
$ node --watch index.js
(node:1191877) ExperimentalWarning: Watch mode is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
short-lived!
Completed running 'index.js'
^C^C^C^C^C^C
```

I input Ctrl + C but the input is ignored.

### Additional information

#### Mechanism of this behavior

The cause of this behavior is the `killAndWait` function located in `/lib/internal/main/watch_mode.js:69`.

Node.js process in watch-mode triggers a signal handler when it receives SIGINT or SIGTERM. In this signal handler, the `killAndWait` function is called as shown below.

https://github.com/nodejs/node/blob/c25878d370c6d96abb382d9ee10d1838da4ec29d/lib/internal/main/watch_mode.js#L134

At this time, since the argument `force` of the `killAndWait` function is set to `true`, processing continues without satisfying the condition in the code path below of the `killAndWait` function.

https://github.com/nodejs/node/blob/c25878d370c6d96abb382d9ee10d1838da4ec29d/lib/internal/main/watch_mode.js#L74-L76

As a result, the `killAndWait` function will wait for a process that has already terminated to terminate. In other words, the wait never ends.

https://github.com/nodejs/node/blob/c25878d370c6d96abb382d9ee10d1838da4ec29d/lib/internal/main/watch_mode.js#L77-L79

#### My proposed modifications

Modify the `killAndWait` function so that if `exited` is `true`, return the `killAndWait` function regardless of the value of the argument `force`.
If you accept this modification, I can create a PR!

Thank you!
Repository: flutter
Issue: generate_gradle_lockfiles.dart doesn't support .kts Gradle scripts
Labels: platform-android,tool,t: gradle,c: proposal,P2,team-android,triaged-android

The `generate_gradle_lockfiles.dart` script was added in #83067.

As of now, it supports only `settings.gradle` and `build.gradle`:

https://github.com/flutter/flutter/blob/1a2c3151fef25e88cfde49110f40a2c3d76cb114/dev/tools/bin/generate_gradle_lockfiles.dart#L31-L35

It should be adapted to support `settings.gradle.kts` and `build.gradle.kts` as well.
Repository: rust
Issue: `thread 'main' panicked. failed printing to stdout: Broken pipe (os error 32)`
Labels: C-feature-request,T-libs

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this command:

```sh
cargo run | echo
```

I expected to see this happen: ignore.

Instead, this happened: `thread 'main' panicked. failed printing to stdout: Broken pipe (os error 32)`

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
1.74.1 (a28077b28 2023-12-04)
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
thread 'main' panicked at library/std/src/io/stdio.rs:1019:9:
failed printing to stdout: Broken pipe (os error 32)
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:597:5
   1: core::panicking::panic_fmt
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/panicking.rs:72:14
   2: std::io::stdio::print_to
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/io/stdio.rs:1019:9
   3: std::io::stdio::_print
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/io/stdio.rs:1095:5
   4: data_type::compound_type
             at ./src/main.rs:3:5
   5: data_type::main
             at ./src/main.rs:100:5
   6: core::ops::function::FnOnce::call_once
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/ops/function.rs:250:5
```

</p>
</details>
Repository: material-ui
Issue: [docs] Isolate error messages, e.g. MUI -> Material UI
Labels: docs,dx,enhancement

### Steps to reproduce

We prefix all the errors with `MUI: ` but we shouldn't, we should use the project name instead.

### Current behavior

This error is about MUI System, it's not about MUI

https://github.com/mui/material-ui/blob/9e0af1b4ed040bd1917c99b64a6da4f72cc65fc7/packages/zero-runtime/src/utils/cssFunctionTransformerPlugin.ts#L54-L57

### Expected behavior

```jsx
 if (!themeValue) { 
   console.warn( 
     `MUI System: Value for key: ${val} does not exist in "theme.${propertyThemeKey}" or "theme.vars.${propertyThemeKey}"`, 
   ); 
```

### Context

This is a continuation of https://github.com/mui/mui-x/pull/11645. 

For the back story, we are moving toward forcing developers to import from @mui/base, @mui/system, and @mui/material directly (no longer reexporting anything from @mui/material). This is a strategic move to:

- better isolate the responsibilities, to educate developers that each of these 3 modules solves different problems
- better isolate the bundle size, removing the perception of bloat
- better support the progressive adoption of the MUI stack
Repository: material-ui
Issue: [docs-infra] Report component size in the docs
Labels: performance,enhancement,scope: docs-infra

### Steps to reproduce

Open https://mui.com/base-ui/react-autocomplete/

### Current behavior

No information about bundle size.

### Expected behavior

By order of how great the solution would be:

- [ ] 1. Bundle size information is available for each docs page
- [ ] 2. Bundle size information is available for each docs page automatically
- [ ] 3. A direct link to a trusted third-party is available (Requiring to fix https://github.com/pastelsky/bundlephobia/issues/389)

### Context

I have been dreaming of this since 2019  https://trello.com/c/iLsZLqL3/1978-improve-docs-header. It's an important feature IMHO. When I decide to adopt a new npm package, I would systematically check:

- npm downloads stats
- **bundle size**
- contribution history
- issues history

Previous conversation: https://github.com/mui/material-ui/pull/33156/files#r897983362

### Benchmark

- https://www.radix-ui.com/docs/primitives/components/switch, this is amazing, I feel like this helps gain trust from frontend engineers. It makes us accountable for all the crap bloat features you add to our modules.
    
<img src="https://github.com/mui/material-ui/assets/3165635/610af10d-a44b-47c0-9dfa-7ab97adae09b" width="138">
Repository: material-ui
Issue: [RFC] Remove @mui/material default theme and @mui/system, @pigment-css/react reexports
Labels: performance,breaking change,RFC,enhancement

### Pros

The motivation is similar to https://github.com/mui/material-ui/issues/40590: isolation of purposes. What if we were forcing developers to import from `@mui/system`, and `@mui/material` directly, no longer reexporting anything from @mui/material. This is a strategic move to:

1. **Brand education**. Better isolate the responsibilities, to educate developers that each of these 3 modules solves different problems. It forces people to use the right docs.

When you use Shadcn UI, Tailwind CSS is not reexported of it.

2. **Performance marketing**. better isolate the bundle size, removing the perception of bloat.

This would for instance better communicate the real cost of adding new Material UI components. When you look at https://bundlephobia.com/package/@mui/material@5.15.4 you see a huge bloat:

<img src="https://github.com/mui/material-ui/assets/3165635/a6e950e4-7a28-4541-9752-366e8a8450ce" width="710">

but the actual cost is much 90% lower, once you have all the shared dependencies. This can also look frightening from the IDE when using this popular VS Code extension: https://marketplace.visualstudio.com/items?itemName=wix.vscode-import-cost

<img src="https://github.com/mui/material-ui/assets/3165635/a7fce8af-ce25-4bb1-bb2d-e81cfe19d693" width="641">

3. **Customization** This better supports the strategic direction of having `@mui/material` only about the CSS logic of the components (you can have it in npm or in your sources, your choice). For this to work, the source needs to be written in a way that everything exported from `@mui/material` can end-up in someone's codebase. For example, it would be insane to keep: https://github.com/mui/material-ui/blob/029eb3b1f4837591e729779da9a82f0a66187770/packages/mui-material/src/utils/isHostComponent.ts#L6 in this location.

4. **Multi-theme support**. These reexports made a big mess with Joy UI. We have a lot of duplication in the codebase, but it's wrong, we should have used MUI System properly to support multi-theme.

### Neutral

CSS Variables support makes a theme provider required. For a long time not having the theme provider requirement was a differentiator of Material UI against https://github.com/react-toolbox/react-toolbox. React Toolbox was harder to configure, creating friction to adoption. Today, Tailwind CSS too doesn't have drop-in support for components, you have to configure it first.
Repository: rust
Issue: E0596 explanation points to return type, not the argument type of called function
Labels: A-diagnostics,T-compiler

### Code

```Rust
struct MyVec<T>(T);

impl<T> MyVec<T> {
    fn replace_with<U>(&self, mut f: impl FnMut() -> U) -> MyVec<U> {
        // reports correct error E0596,
        // but with odd explanation in the rustc output:   -------- ""change this to return `FnMut` instead of `Fn`""
        self.map(|_| f())
    }
    fn map<U>(&self, _: impl Fn(&T) -> U) -> MyVec<U> {
        todo!()
    }
}
```


### Current output

```Shell
error[E0596]: cannot borrow `f` as mutable, as it is a captured variable in a `Fn` closure
 --> src/lib.rs:7:22
  |
4 |     fn replace_with<U>(&self, mut f: impl FnMut() -> U) -> MyVec<U> {
  |        ------------                                        -------- change this to return `FnMut` instead of `Fn`
...
7 |         self.map(|_| f())
  |                  --- ^ cannot borrow as mutable
  |                  |
  |                  in this closure

For more information about this error, try `rustc --explain E0596`.
```


### Desired output

```Shell
error[E0596]: cannot borrow `f` as mutable, as it is a captured variable in a `Fn` closure
 --> src/lib.rs:7:22
  |
7 |         self.map(|_| f())
  |         -------- --- ^ cannot borrow as mutable
  |         |        |
  |         |        in this closure
  |         expects `Fn` instead of `FnMut`
8 |     }
9 |     fn map<U>(&self, _: impl Fn(&T) -> U) -> MyVec<U> {
  |                         ---------------- change this to accept `FnMut` instead of `Fn`

For more information about this error, try `rustc --explain E0596`.
```


### Rationale and extra context

Affected [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c19c261cfcae764bdba9e7d6f2c249c3), with correct error but misleading explanation.

Removing `impl` block and `self` parameters shows the correct/expected diagnostic explanation,
demonstrated in this [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6d7d3f34d6cd56d183311a097d961174)

### Other cases

_No response_

### Rust Version

Duplicated on playground with both "Stable 1.75.0", and on playground selecting nightly:

```
Build using the Nightly version: 1.77.0-nightly
(2024-01-13 d78329b92e8d141d1950)
```


### Anything else?

Overall, not a huge issue - the actual error indication is correct.
The small oddity is where it points to the function return type as the location of the `Fn`. This took me a bit to identify the mismatched `Fn`/`FnMut` :slightly_smiling_face: 

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"mu001999"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: No `mouse_{entered,exited}` signal if only the control moves
Labels: bug,topic:input,topic:gui

### Tested versions

Reproduced in 4.2.1.stable. No an regression as it's also reproduciable in older versions.

### System information

Godot v4.2.1.stable unknown - Arch Linux #1 SMP PREEMPT_DYNAMIC Sat, 13 Jan 2024 14:37:14 +0000 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (nvidia; 545.29.06) - 13th Gen Intel(R) Core(TM) i5-13400F (16 Threads)

### Issue description

`mouse_entered` and `mouse_exited` can only be triggered by moving the mouse into/out of a Control.

If the Control is moving, these signals won't be emitted if the mouse does not move.


https://github.com/godotengine/godot/assets/372476/5b18ee46-f317-43c0-b526-095d992d9102



### Steps to reproduce

Run the MRP.

### Minimal reproduction project (MRP)

[test-4.zip](https://github.com/godotengine/godot/files/13934747/test-4.zip)
Repository: go
Issue: proposal: go.dev: remove cookie banners
Labels: Proposal

### Proposal Details

This issue is the equivalant of https://github.com/golang/go/issues/65080 for go.dev. That is, I propose the removal of the reasons for having cookie banners on all of https://go.dev and of course the banners themselves.