sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: FastNoiseLite.GetImage(normalize: true) morphs on width and height gradual change
Labels: discussion,topic:core,documentation,needs testing

### Tested versions

Found in: v4.2.2.stable.mono.official [15073afe3]

### System information

Godot v4.2.2.stable.mono - Windows 10.0.19045 - GLES3 (Compatibility) - GeForce 210 () - Intel(R) Core(TM) i3-10100F CPU @ 3.60GHz (8 Threads)

### Issue description

`FastNoiseLite.GetImage(normalize: true)` resulting image always shifts and morphs while gradually changing width and height parameters of the function. Firstly noticed on C#, then tested on GDScript – the issue remains.

![2024-06-2715-33-02-ezgif com-video-to-gif-converter](https://github.com/godotengine/godot/assets/66130961/5f306a67-9076-49b8-b30a-b60d327d9ee9)

Setting `normalize = false` seems to fix the issue, but values are, obviously, not the same as if `normalize = true`. Drawing the noise by yourself via `GetNoise2D()` is also problems-free.

(`GetNoise2D()` with `DrawRect()` for each point on the left and `GetImage(normalize: true)` on the right)
![2024-06-2710-44-10-ezgif com-crop](https://github.com/godotengine/godot/assets/66130961/639e5448-5894-42fa-8afe-9e8ade56c39c)


### Steps to reproduce

For the more noticeable effect you should put 'Project Settings' > 'Rindering' > 'Textures' > 'Default Texture Filter' to 'Nearest'

1. Create `FastNoiseLite` with `NoiseType = FastNoiseLite.NoiseTypeEnum.Simplex`
2. Create an image using `FastNoiseLite.GetImage2D(normalize: true)`
3. Display resulting image in any way (I am using `TextureRect` with `.Texture = ImageTexture.CreateFromImage(<our_result_image>)`)
4. Gradually change the `width` and `height` of `GetImage()`
5. It moves, it's alive!!

For the MRP:
The GDScript is attached to Node2D with `Threshold: int` and `Normalize: bool` variables. You can check/uncheck `Normalize` to compare the results.

### Minimal reproduction project (MRP)

[FastNoiseLite_Demo.zip](https://github.com/user-attachments/files/16025371/FastNoiseLite_Demo.zip)
Repository: create-react-app
Issue: Usage override/workaround/hack with ESLint 9
Labels: needs triage

Anybody?

```
 WARN  Issues with peer dependencies found
.
├─┬ react-scripts 5.0.1
│ ├── ✕ unmet peer typescript@"^3.2.1 || ^4": found 5.4.2
│ ├─┬ eslint-config-react-app 7.0.1
│ │ ├── ✕ unmet peer eslint@^8.0.0: found 9.5.0
│ │ ├─┬ @typescript-eslint/parser 5.7.0
│ │ │ └── ✕ unmet peer eslint@"^6.0.0 || ^7.0.0 || ^8.0.0": found 9.5.0
│ │ ├─┬ @typescript-eslint/eslint-plugin 5.7.0
│ │ │ └── ✕ unmet peer eslint@"^6.0.0 || ^7.0.0 || ^8.0.0": found 9.5.0
│ │ ├─┬ @babel/eslint-parser 7.16.5
│ │ │ └── ✕ unmet peer eslint@"^7.5.0 || ^8.0.0": found 9.5.0
│ │ ├─┬ eslint-plugin-react 7.27.1
│ │ │ └── ✕ unmet peer eslint@"^3 || ^4 || ^5 || ^6 || ^7 || ^8": found 9.5.0
│ │ ├─┬ eslint-plugin-flowtype 8.0.3
│ │ │ └── ✕ unmet peer eslint@^8.1.0: found 9.5.0
│ │ ├─┬ eslint-plugin-import 2.25.3
│ │ │ └── ✕ unmet peer eslint@"^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8": found 9.5.0
│ │ ├─┬ eslint-plugin-jest 25.3.0
│ │ │ └── ✕ unmet peer eslint@"^6.0.0 || ^7.0.0 || ^8.0.0": found 9.5.0
│ │ ├─┬ eslint-plugin-react-hooks 4.3.0
│ │ │ └── ✕ unmet peer eslint@"^3.0.0 || ^4.0.0 || ^5.0.0 || ^6.0.0 || ^7.0.0 || ^8.0.0-0": found 9.5.0
│ │ ├─┬ eslint-plugin-jsx-a11y 6.5.1
│ │ │ └── ✕ unmet peer eslint@"^3 || ^4 || ^5 || ^6 || ^7 || ^8": found 9.5.0
│ │ └─┬ eslint-plugin-testing-library 5.0.1
│ │   └── ✕ unmet peer eslint@"^7.5.0 || ^8.0.0": found 9.5.0
│ └─┬ eslint-webpack-plugin 3.1.1
│   └── ✕ unmet peer eslint@"^7.0.0 || ^8.0.0": found 9.5.0
└─┬ @testing-library/jest-dom 6.4.6
  └── ✕ unmet peer jest@">= 28": found 27.4.5
 ```
 
```
Failed to compile.

Invalid Options:
- Unknown options: extensions, resolvePluginsRelativeTo
- 'extensions' has been removed.
- 'resolvePluginsRelativeTo' has been removed.
ERROR in Invalid Options:
- Unknown options: extensions, resolvePluginsRelativeTo
- 'extensions' has been removed.
- 'resolvePluginsRelativeTo' has been removed.

ERROR in   Error: Child compilation failed:
  Invalid Options:
  - Unknown options: extensions, resolvePluginsRelativeTo
  - 'extensions' has been removed.
  - 'resolvePluginsRelativeTo' has been removed.
  
  


1 ERROR in child compilations (Use 'stats.children: true' resp. '--stats-children' for more details)
webpack compiled with 3 errors
```
Repository: PowerToys
Issue: [Setting] "When multiple zones overlap" -> Activate the zone closest to dragged window center
Labels: Needs-Triage

### Description of the new feature / enhancement

Please add a new option to the FancyZones "When multiple zones overlap" pulldown "Activate the zone closest to the dragged window center"..


### Scenario when this would be used?

dragging windows onto fanzyzones configs with overlapping zones

### Supporting information

Currently the following choices are available for FancyZones ambiguating a zone drop target "When multiple zones overlap"..

* Activate the smallest zone by area
* Activate the largest zone by area
* Split the overlapped area into multiple activation targets
* Activate the zone whose center is closest to the cursor

I've used FanzyZones for over 6 years, using the only existing option that makes sense for my setup "Activate the zone whose center is closest to the cursor" and it's just never felt right. On my 3-monitor setup, my top monitor zone config has two "left and right" tall portrait zones that nearly touch, and one "almost the whole monitor" zone that spans over them.  This zone config makes the smallest/largest zone options useless, because the drop target between the overlap is too tiny, so I can't disambiguate between them.

The weird feel of using the mouse-cursor occurs because I can't just drop a window onto the zones by looking at the WINDOW i'm dragging, it matters *where* I grabbed the window. If I grab the window titlebar on the left side, then I have to drag the window way off to the right of my target, if I grab the window on the right side I have to drag it way off to the left of my target..

I just realized that this whole acwkward feeling would be gone if I could just drop on the overlapping zone that was closest to the dragged WINDOW CENTER.. Then fanzyzones would disambiguate in the way that *looks* and *feels* right, based on the window I'm dragging, instead of this weird method of using my mouse cursor location, which once I'm dragging a window is kind of irrelevant, because the window itself effectively becomes my cursor.

Thanks for considering.
Repository: PowerToys
Issue: When in preview mode of a Markdown file, enable navigation to another markdown file in a new Window.
Labels: Needs-Triage

### Description of the new feature / enhancement

In Markdown file you can define something like this:
open [AnotherFile.md](./doc/AnOtherFile.md). It would be nice that this link leads to a new preview Window (when opened in the same Window, we need a back button as well, so a new Window would already be fine) 

### Scenario when this would be used?

Navigation between different Markdown files 

### Supporting information

_No response_
Repository: neovim
Issue: Windows: E303 swap error paths starting with `\\?\`
Labels: bug,platform:windows,filesystem

### Problem

Running `nvim \\?\D:\hello.txt` or other paths starting with `\\?\` causes `E303: Unable to open swap file for "\\?\D:\hello.txt", recovery impossible`. Other paths are fine.

search terms: backslash, question mark

### Steps to reproduce

```
PS> nvim \\?\D:\hello.txt
E303: Unable to open swap file for "\\?\D:\hello.txt", recovery impossible
Press ENTER or type command to continue
```

### Expected behavior

The swap file is correctly read and written.

### Neovim version (nvim -v)

v0.10.0

### Vim (not Nvim) behaves the same?

No, 9.1. Vim simply does not recognise paths starting with `\\?\` and opens as if it were called without a path.

### Operating system/version

Windows 10 22H2

### Terminal name/version

Powershell

### $TERM environment variable

N/A

### Installation

https://github.com/neovim/neovim/releases/latest/download/nvim-win64.msi
Repository: bitcoin
Issue: RFC: Misused LogError and LogWarning macros
Labels: Brainstorming

As a programmer, when I see `LogError` and `LogWarning` macros, I assume `LogError` should be used to log information about a failure that happened, and `LogWarning` should be used to log information about an unusual condition which happened that might indicate a real problem depending on other factors and intent.

But [developer notes](https://github.com/bitcoin/bitcoin/blob/b27afb7fb774809c9c075d56e44657e0b607a00c/doc/developer-notes.md#logging) suggest very different meanings for these macros. They say `LogError` should be used for "severe problems that require the node (or a subsystem) to shut down entirely (e.g., insufficient storage space)" and that `LogWarning` should be used "for severe problems that the node admin should address, but are not severe enough to warrant shutting down the node (e.g., system time appears to be wrong, unknown soft fork appears to have activated)."

I think the distinction the developer notes makes and the levels it defines are useful, but the current names make it likely that the macros will be used incorrectly.

So while the macros are new, I think it would be good to give them clearer names and I would suggest:

- `LogFatal` for severe problems that require the node or a subsystem to shut down entirely, and
- `LogCritical` for severe problems that the node admin should address, but do not warrant shutting down

Looking at the code I found 58 cases where `LogError` and `Level::Error` appeared to be use correctly, in conditions that would lead to full or partial shutdowns, and 71 cases where it appeared to be used incorrectly to report errors that would not cause shutdowns and were potentially transient.

Current `LogWarning` and `Level::Warn` usages were better but more rare, with 8 correct uses and 4 incorrect ones.

I think before more code is written and ported to use `LogWarning` and `LogError` macros incorrectly, we should update documentation and/or code so macro names accurately reflect the way they are intended to be used.

If we don't care about log levels distinguishing between fatal and nonfatal errors, #30361 is the most direct fix for this issue and is just a documentation change. If we think using levels distinguish fatal errors from other errors is valuable, #30347 fixes this issue by clarifying documentation and introducing LogFatal and LogCritical levels suggested above.
Repository: tensorflow
Issue: C-API support for .keras models
Labels: stat:awaiting tensorflower,type:feature,comp:core

### Issue type

Feature Request

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

binary

### TensorFlow version

2.16

### Custom code

No

### OS platform and distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

TF_LoadSessionFromSavedModel() not able to load .keras files.
Is C-API support for Keras v3 .keras format planned?

### Standalone code to reproduce the issue

```shell
TF_LoadSessionFromSavedModel(..., "model.keras", ...)
```


### Relevant log output

_No response_
Repository: rust
Issue: Binary size creep on Fuchsia after commit 5ced3da
Labels: T-compiler,I-heavy,O-fuchsia,E-needs-mcve

After bors rolled [commit 5ced3da](https://github.com/rust-lang/rust/commit/5ced3dad5752cc9423a19e9a5aafad6e12ed3063), Fuchsia's canaries began failing their binary size creep checks. See attached screenshot. It's non-obvious why this change would impact codegen on Fuchsia, but I wanted to alert the rust-lang project and commit author that this has occurred.

<img width="1096" alt="Screenshot 2024-06-27 at 10 14 40 AM" src="https://github.com/rust-lang/rust/assets/10383218/f051c7f2-4d95-4174-abd8-1f24d1424940">


cc: @tesuji @erickt
Repository: electron
Issue: [Bug]: `fs.stat` blksize/blocks are `undefined` for `.asar` files
Labels: bug :beetle:,component/node-integration,status/confirmed,29-x-y,31-x-y,32-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

29.2.0

### What operating system are you using?

macOS

### Operating System Version

macOS Sonoma 14.5

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

n/a

### Expected Behavior

When `fs.stat`-ing an asar file from an Electron process, it's expected that one gets the same results as when `fs.stat`-ing the same file from a Nodejs process of the same version.

### Actual Behavior

The information for the same file is different, and the version returned by Electron violates the Node API (where blksize, for example, is `bigint | number`). The following results are statting the exact same path.

**Electron**

```js
{
  dev: 1,
  mode: 16804,
  nlink: 1,
  uid: 501,
  gid: 20,
  rdev: 0,
  blksize: undefined,
  ino: 1,
  size: 0,
  blocks: undefined,
  atimeMs: 1719497601434,
  mtimeMs: 1719497601434,
  ctimeMs: 1719497601434,
  birthtimeMs: 1719497601434,
  atime: 2024-06-27T14:13:21.434Z,
  mtime: 2024-06-27T14:13:21.434Z,
  ctime: 2024-06-27T14:13:21.434Z,
  birthtime: 2024-06-27T14:13:21.434Z
}
```

**Node**

```js
{
  dev: 16777233,
  mode: 33188,
  nlink: 1,
  uid: 501,
  gid: 20,
  rdev: 0,
  blksize: 4096,
  ino: 26518531,
  size: 108901,
  blocks: 216,
  atimeMs: 1719497300692.307,
  mtimeMs: 1719497300686.6824,
  ctimeMs: 1719497300686.6824,
  birthtimeMs: 1719497300686.2349,
  atime: 2024-06-27T14:08:20.692Z,
  mtime: 2024-06-27T14:08:20.687Z,
  ctime: 2024-06-27T14:08:20.687Z,
  birthtime: 2024-06-27T14:08:20.686Z
}
```

### Testcase Gist URL

https://gist.github.com/clavin/d9babddd2e5147ebea73b99d6fef1406

### Additional Information

_No response_
Repository: electron
Issue: [Bug]: crash electron app once using `disable-gpu`, `in-process-gpu`, and `disable-software-rasterizer` together
Labels: platform/windows,bug :beetle:,status/confirmed,has-repro-gist,30-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

30.1.2

### What operating system are you using?

Windows

### Operating System Version

Windows 11 Pro 23H2 22631.3737 

### What arch are you using?

x64

### Last Known Working Electron version

29.4.2

### Expected Behavior

Electron should not crash when using the below command lines with `mainWindow.loadURL`:

```
app.commandLine.appendSwitch("disable-gpu");
app.commandLine.appendSwitch("in-process-gpu");
app.commandLine.appendSwitch("disable-software-rasterizer");
```

### Actual Behavior

Electron main process crashed once the above command lines are used at the same time

```
[25152:0627/170654.221:FATAL:gles2_cmd_decoder.cc(2993)] Validating command decoder is not supported.
[15728:0627/170655.550:ERROR:command_buffer_proxy_impl.cc(131)] ContextResult::kTransientFailure: Failed to send GpuControl.CreateCommandBuffer.

```

### Testcase Gist URL

https://gist.github.com/e55b49644a24e9df957fc2d5237b7915

### Additional Information

_No response_
Repository: go
Issue: x/tools/internal/gcimporter: TestStdlib failures
Labels: NeedsInvestigation,Tools

```
#!watchflakes
default <- pkg == "golang.org/x/tools/internal/gcimporter" && test == "TestStdlib"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8747798082951528577)):

    === RUN   TestStdlib
    /Users/swarming/.swarming/w/ir/x/w/gopath/pkg/mod/golang.org/x/telemetry@v0.0.0-20240228155512-f48c80bd79b2/internal/crashmonitor/crash_go123.go:13:19: cannot use debug.SetCrashOutput (value of type func(f *os.File, opts ...debug.CrashOptions) error) as func(*os.File) error value in assignment
        stdlib_test.go:52: there were errors during loading
    --- FAIL: TestStdlib (2.65s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: pytorch
Issue: [TensorDict - compile] cuda.is_initialized compatibility
Labels: triaged,oncall: pt2

### 🐛 Describe the bug

This [block](https://github.com/pytorch/tensordict/blob/b5cb40aaeb824ac632c0a2f178430105513525d1/tensordict/tensorclass.py#L7720-L7726) doesn't work because dynamo does not want to hear about cuda.is_initialized.



### Versions

PyTorch version: 2.5.0.dev20240627
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 14.5 (arm64)
GCC version: Could not collect
Clang version: 15.0.0 (clang-1500.3.9.4)
CMake version: version 3.29.3
Libc version: N/A

Python version: 3.11.7 (v3.11.7:fa7a6f2303, Dec 4 2023, 15:22:56) [Clang 13.0.0 (clang-1300.0.29.30)] (64-bit runtime)
Python platform: macOS-14.5-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M3 Max

Versions of relevant libraries:
[pip3] mujoco-torch==0.1.0
[pip3] numpy==1.26.4
[pip3] optree==0.11.0
[pip3] torch==2.5.0.dev20240627
[pip3] torchao==0.1
[pip3] torchaudio==2.4.0.dev20240627
[pip3] torchrl==0.4.0+7c0a7c8
[pip3] torchtext==0.18.0
[pip3] torchvision==0.20.0.dev20240627
[conda] Could not collect



cc @ezyang @anijain2305 @chauhang @penguinwu
Repository: vscode
Issue: Option to automatically change the debug toolbar's selected active session when launching a new debug session
Labels: bug,debug

<!-- ⚠️⚠️ 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. -->
When a debug session is active (running) and a new debug session is started, it would we nice if there was an option to automatically change the selected session dropdown in the debug toolbar to the newly launched session so it can be paused, restarted, stopped, etc.

Right now, if I have session A running and launch a new session B, if I want to stop B, I have to first go to the toolbar and change the session dropdown from A to B, and then I can stop B. If B has gone awry, it would be nice if the debug toolbar was automatically set to B so it can be immediately paused/stopped/etc (without having to manually change the active session in the debug toolbar dropdown)

Thanks
Repository: neovim
Issue: Detect FAT filesystem explicitly in `time_differs`
Labels: bug,filesystem

### Problem

In `time_differs` on Linux mtimes with nanosecond precision are not respected out of concern for behavior on FAT filesystems. The filesystem should be detected and in the case where it's not a FAT filesystem nanosecond precision should be used.
https://github.com/neovim/neovim/blob/724d1110b1e4699a34f489e9cdb2d25098746499/src/nvim/fileio.c#L2180-L2194

### Neovim version (nvim -v)

0.10.0

### Vim (not Nvim) behaves the same?

Yes
Repository: godot
Issue: Inconsistent Control node `gui_input` detection
Labels: needs testing,topic:input,topic:gui

### Tested versions

- Reproducible in: 4.2.2.stable

### System information

Godot v4.2.2.stable - Windows 10.0.22631 - GLES3 (Compatibility) - NVIDIA GeForce RTX 2070 SUPER (NVIDIA; 32.0.15.5599) - AMD Ryzen 5 3600 6-Core Processor (12 Threads)

### Issue description

Control node `gui_input` detection does not behave consistently with the documentation. The [docs](https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-private-method-gui-input) state this function won't trigger for various reasons, though two of these reasons are of note:

* clicking outside the control (see [_has_point](https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-private-method-has-point));
* control is obstructed by another Control on top of it, which doesn't have [mouse_filter](https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-mouse-filter) set to [MOUSE_FILTER_IGNORE](https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-constant-mouse-filter-ignore);

I made a test project to test this:

[Example](https://i.imgur.com/ZolhGSI.mp4)

This example works as follows:
* The "draggable" element outputs its current `mouse_filter` state (STOP/PASS/IGNORE)
* The "drop here" element outputs the most recently detected input event, and the elapsed time since it was detected
* A label briefly displays "Click" and "Release" to visually show mouse clicks and releases

This example shows the following unexpected behavior:

1. When the mouse clicks outside the "drop" element, moves onto the element, and then releases the button on the element, the mouse release is not detected. Note that mouse motion is detected in this case, which I expected, but is inconsistent with the button release not being detected.
2. (Not shown in video) When the mouse clicks on the "drop" element, moves off the element, and then releases the button outside the element, the mouse is release is detected. Additionally, mouse motion is detected outside the element while the mouse button is pressed, which I did not expect, but is consistent with the button release being detected.
3. When the "draggable" element is clicked and its `mouse_filter` is set to IGNORE, the "drop" element no longer detects the mouse motion mentioned in (1).

### Steps to reproduce

Run the MRP and perform the steps described above.

### Minimal reproduction project (MRP)

[Test.zip](https://github.com/user-attachments/files/16016428/Test.zip)