sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: [FSDP2 Related]`torch.split_with_sizes_copy` of the GPU does not update the version counter of `out` correctly.
Labels: oncall: distributed,triaged,module: fsdp

### 🐛 Describe the bug

I'm reading the source code implementation of FSDP2. I noticed a detail that the unsharded param is obtained through split_with_sizes_copy when needed. Since this operation writes to the memory of the param, I expected it to cause an increase in the version counter, which would further lead to failure to pass the verification of the version counter during the backward pass. However, in fact, it works normally on the GPU.

This confuses me a lot. So I tested split_with_sizes_copy separately and found that its handling of the version counter is inconsistent on the CPU and GPU: on the GPU, the version counter of out is not updated correctly.

```python
import torch

x = torch.ones(4, 2)
y = torch.ones(4, 1)
z = torch.ones(4, 1)
torch.split_with_sizes_copy(x, [1, 1], dim=1, out=[y, z])
print(y._version, z._version)  # 1 1

x = torch.ones(4, 2).cuda()
y = torch.ones(4, 1).cuda()
z = torch.ones(4, 1).cuda()
torch.split_with_sizes_copy(x, [1, 1], dim=1, out=[y, z])
print(y._version, z._version)  # 0 0
```

### Versions

I tested the torch versions including the nightly(2.5.0.dev20240709+cu121) versions since release 2.3.1, and this problem exists in all of them.

cc @XilunWu @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o @zhaojuanmao @mrshenli @rohan-varma @chauhang
Repository: PowerToys
Issue: Powertoys Run issues with multiple monitors
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.82.1

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

1. Move the mouse cursor from the main monitor's desktop to the sub monitor's desktop.
2. Run Powertoys Run on the sub monitor's desktop.
3. The search box will be displayed off-screen at the top of the sub monitor's desktop and will not be visible.
4. If you start typing in this state, a list of search results will be displayed off-screen at the top.

[PowerToysReport_2024-07-29-03-54-01.zip](https://github.com/user-attachments/files/16407163/PowerToysReport_2024-07-29-03-54-01.zip)


### ✔️ Expected Behavior

The search box will also be displayed in the center of the screen on the secondary monitor's desktop.

### ❌ Actual Behavior

On the secondary monitor desktop, the search box appears off-screen at the top and cannot be seen.

### Other Software

_No response_
Repository: storybook
Issue: [Bug]: The html content inserted using the ejs variable in iframe.html is not minify
Labels: bug,needs triage

### Describe the bug

The html content inserted using the ejs variable in iframe.html is not minify

template file: `node_modules/@storybook/builder-webpack5/templates/preview.ejs`

unminify variable: `bodyHtmlSnippet`, `headHtmlSnippet`

> The html file itself is indeed compressed, but the variables are not

### Reproduction link

https://github.com/storybookjs/sandboxes/tree/next/react-webpack/18-ts/after-storybook

### Reproduction steps

1. `npm run build-storybook`
2. check `./storybook-static/iframe.html` and `./storybook-static/index.html`

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 14.4.1
    CPU: (8) arm64 Apple M2
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.14.0 - ~/.nvm/versions/node/v20.14.0/bin/node
    Yarn: 2.4.3 - ~/.nvm/versions/node/v20.14.0/bin/yarn
    npm: 10.7.0 - ~/.nvm/versions/node/v20.14.0/bin/npm
    pnpm: 9.2.0 - ~/.nvm/versions/node/v20.14.0/bin/pnpm <----- active
  npmPackages:
    @storybook/addon-essentials: ~8.1.1 => 8.1.11 
    @storybook/addon-interactions: ~8.1.1 => 8.1.11 
    @storybook/addon-links: ~8.1.1 => 8.1.11 
    @storybook/addon-storysource: ~8.1.1 => 8.1.1 
    @storybook/addon-viewport: ~8.1.1 => 8.1.11 
    @storybook/addon-webpack5-compiler-swc: ^1.0.4 => 1.0.4 
    @storybook/blocks: ~8.1.1 => 8.1.11 
    @storybook/manager-api: ~8.1.1 => 8.1.1 
    @storybook/react: ~8.1.1 => 8.1.11 
    @storybook/react-webpack5: ~8.1.11 => 8.1.11 
    @storybook/test: ~8.1.1 => 8.1.11 
    @storybook/theming: ~8.1.1 => 8.1.1 
    @storybook/types: ~8.1.1 => 8.1.11 
    eslint-plugin-storybook: ^0.8.0 => 0.8.0 
    storybook: ~8.1.1 => 8.1.11
```


### Additional context

_No response_
Repository: godot
Issue: Godot Not Response Error (Wait for Windows dwm)
Labels: platform:windows,needs testing

### Tested versions

- Reproducible in: v4.3.rc1.mono.official [e343dbbcc]

### System information

Godot v4.3.rc1.mono - Windows 10.0.19045 - Vulkan (Mobile) - dedicated Intel(R) Iris(R) Xe Graphics (Intel Corporation; 31.0.101.5592)

### Issue description

![image](https://github.com/user-attachments/assets/ce266971-c6bb-4580-a67e-8904b05719b9)
![image](https://github.com/user-attachments/assets/d575dcf1-42c1-4187-b2bf-5e580f2bf3fa)
Here are two screenshots when the editor is not responding. I noticed that godot is waiting for dwm.exe to respond. This may be windows related. And sometimes it's endlessly unresponsive, other times it'll fix itself in 10 seconds or so. I think it's a bug because all the other programs running at the same time as it work fine. And it's also not an important bug to fix, since restarting the editor is sufficient. But it's an annoying bug.

My English is not very good, so sometimes I use translation tools. Please let me know if I've said something wrong, or if I've expressed myself unclearly.

### Steps to reproduce

It is known that this error is not caused by every dwm trigger. But this is the only known way to cause it. And I've found that updating the graphics driver causes the program to wait for dwm which in turn leads to unresponsiveness.

### Minimal reproduction project (MRP)

N/A
Repository: electron
Issue: [Feature Request]: clarify `fullscreen` and `fullscreenable`
Labels: enhancement :sparkles:

### 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.x

### What operating system(s) are you using?

macOS

### Operating System Version

macOS 14.5

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

_No response_

### Expected Behavior

A `BrowserWindow` can have `fullscreen` and `fullscreenable` set. From the JSDoc:

`fullscreen`:
> Whether the window should show in fullscreen. When explicitly set to false the fullscreen button will be hidden or disabled on macOS. Default is false

A couple of things:
* the default is not `false` because by default windows can show in fullscreen
* when a window is opened from a fullscreen window on macOS that window will also open fullscreen (not sure about Windows and Linux)

`fullscreenable`:
> Whether the window can be put into fullscreen mode. On macOS, also whether the maximize/zoom button should toggle full screen mode or maximize window. Default is true

This one is more clear to me but I think there is functionality overlap between the two.

I think ideally `fullscreen` should only be about the window opening fullscreen or not and `fullscreenable` should decide on the capability and the button.

Also, you cannot prevent a window from opening fullscreen when the originating window is already fullscreen without disabling the fullscreen button.

//cc @codebytere 



### Actual Behavior

As above.

### Testcase Gist URL

_No response_

### Additional Information

_No response_
Repository: react-native
Issue: Flatlist onEndReached 
Labels: Component: FlatList,Needs: Repro,Needs: Attention

### Description

flatlist onEndReached doesn't work at the bottom of the list, but works at the start of the render

### Steps to reproduce

<img width="556" alt="Screenshot 2024-07-29 at 13 09 06" src="https://github.com/user-attachments/assets/97dc2473-182a-4952-a22c-c7c90481e909">


### React Native Version

0.72.15

### Affected Platforms

Runtime - Android, Runtime - iOS

### Output of `npx react-native info`

```text
System:
  OS: macOS 14.3
  CPU: (8) x64 Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
  Memory: 134.64 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 16.19.0
    path: ~/.nvm/versions/node/v16.19.0/bin/node
  Yarn:
    version: 1.22.22
    path: /usr/local/bin/yarn
  npm:
    version: 8.19.3
    path: ~/.nvm/versions/node/v16.19.0/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.15.2
    path: /usr/local/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.2
      - iOS 17.2
      - macOS 14.2
      - tvOS 17.2
      - visionOS 1.0
      - watchOS 10.2
  Android SDK:
    API Levels:
      - "23"
      - "26"
      - "27"
      - "28"
      - "29"
      - "30"
      - "31"
      - "33"
      - "34"
    Build Tools:
      - 28.0.3
      - 29.0.2
      - 30.0.2
      - 30.0.3
      - 31.0.0
      - 33.0.0
      - 33.0.2
      - 34.0.0
    System Images:
      - android-19 | Google APIs Intel x86 Atom
      - android-21 | Intel x86 Atom
      - android-21 | Google APIs Intel x86 Atom
      - android-21 | Google APIs Intel x86 Atom_64
      - android-27 | Google Play Intel x86 Atom
      - android-31 | Google APIs Intel x86 Atom_64
      - android-34 | Intel x86_64 Atom
      - android-34 | Google Play Intel x86_64 Atom
      - android-34 | Google APIs ATD Intel x86_64 Atom
    Android NDK: Not Found
IDEs:
  Android Studio: 2023.3 AI-233.14808.21.2331.11842104
  Xcode:
    version: 15.2/15C500b
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.10
    path: /usr/local/opt/openjdk@17/bin/javac
  Ruby:
    version: 3.3.3
    path: /usr/local/opt/ruby/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.72.15
    wanted: 0.72.15
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false
```


### Stacktrace or Logs

```text
-
```


### Reproducer

-

### Screenshots and Videos

_No response_
Repository: angular
Issue: [Doc] change `overflow` property value from `visible` to `scroll`
Labels: state: has PR,P3,area: docs

### Describe the problem that you experienced

content overflowed can not scroll

### Enter the URL of the topic with the problem

https://angular.dev/tutorials/learn-angular

### Describe what you were looking for in the documentation

Click the `console` tab in [this link](https://angular.dev/tutorials/learn-angular), and the content will overflow, caused by the following css defined in [_xterm.scss](https://github.com/angular/angular/blob/main/adev/src/styles/_xterm.scss#L39-L45):

```css
.xterm-screen {
  padding: 10px;
  box-sizing: border-box;
  overflow: visible !important;
  height: 100% !important;
  width: 100% !important;
}
```

and should be changed to:

```diff css
.xterm-screen {
  padding: 10px;
  box-sizing: border-box;
- overflow: visible !important;
+ overflow: scroll !important;
  height: 100% !important;
  width: 100% !important;
}
```

orelse maybe `oveflow-y: scroll !important;`

### Describe the actions that led you to experience the problem

_No response_

### Describe what you want to experience that would fix the problem

_No response_

### Add a screenshot if that helps illustrate the problem

_No response_

### If this problem caused an exception or error, please paste it here

_No response_

### If the problem is browser-specific, please specify the device, OS, browser, and version

_No response_

### Provide any additional information here in as much as detail as you can

_No response_
Repository: PowerToys
Issue: MWB Overriding keyboard layout between remote and local PC
Labels: Idea-Enhancement,Needs-Triage,Product-Mouse Without Borders

### Description of the new feature / enhancement

Hi, this is a feature request about MWB.

My local PC is set to US keyboard layout, but remote PC is different (Japanese) keyboard layout (because remote PC is laptop).
Currently, keyboard input send to remote PC with local PC's layout.
That is a little inconvenience.
So I propose adding a setting to override the local PC layout to the remote PC.
I don't have enough experience in Windows software development to understand how difficult this feature is...

I'm sorry if someone has already requested this feature or if I've missed a setting that already exists.

### Scenario when this would be used?

When someone using between 2 PC that have different keyboard layout.

### Supporting information

_No response_
Repository: storybook
Issue: [Bug]: upgrading from `8.1.2` to `8.2.6` breaks argTypes actions
Labels: bug,addon: actions,svelte,sev:S2,test utilities,upgrade:8.2

### Describe the bug

Using `argTypes` to create actions works in `8.1.2` but breaks in `8.2.6`.

```svelte
<script context="module" lang="ts">
	export const meta = {
		title: 'Bug',
	};
</script>

<script lang="ts">
	import { Story } from '@storybook/addon-svelte-csf';
	import { expect, userEvent, within, fn } from '@storybook/test';
</script>

<Story
	name="Default"
	let:args
	argTypes={{
		test: {
			action: 'inputRequired',
		},
	}}
	play={async ({ canvasElement, args }) => {
		const canvas = within(canvasElement);
		const button = canvas.getByRole('button');
		button.click();
		expect(args.test).toHaveBeenCalledTimes(1);
	}}
>
	<button on:click={() => args.test()}>Submit</button>
</Story>
```

the interaction test works flawlessly in `8.1.2` but throws `handler is not a spy` in `8.2.6`

### Reproduction link

https://stackblitz.com/edit/github-c8zg4s

### Reproduction steps

1. go to the above link
2. let the installation finish
3. run `pnpm storybook` and wait for storybook to show up in the preview
4. navigate to the interaction test and confirm that everything works
5. run `npx storybook@latest upgrade` and complete the upgrade process (or go [here](https://stackblitz.com/edit/github-c8zg4s-rsoldt) it's the same stackblitz where i run the command)
6. run `pnpm storybook` again
7. navigate to the interaction test and confirm that it's now broken 

### System

```bash
Storybook Environment Info:

  System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.20.3 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm <----- active
  npmPackages:
    @storybook/addon-essentials: 8.1.2 => 8.1.2 
    @storybook/addon-interactions: 8.1.2 => 8.1.2 
    @storybook/addon-links: 8.1.2 => 8.1.2 
    @storybook/addon-svelte-csf: ^4.1.4 => 4.1.4 
    @storybook/blocks: 8.1.2 => 8.1.2 
    @storybook/svelte: 8.1.2 => 8.1.2 
    @storybook/sveltekit: 8.1.2 => 8.1.2 
    @storybook/test: 8.1.2 => 8.1.2 
    storybook: 8.1.2 => 8.1.2
```


### Additional context

This also breaks when building storybook which means that if you are using it in chromatic it will fail the chromatic build.
Repository: ui
Issue: [bug]: When Dialog component  opended it expands elements below dialog-overlay
Labels: bug

### Describe the bug

When the Dialog component is opened, it causes unintended expansion or shifting of elements located beneath the dialog-overlay on the page. This issue results in elements being displaced or rendered incorrectly, affecting the overall layout and user experience.

![Screenshot 2024-07-29 121234](https://github.com/user-attachments/assets/33c39159-34ec-4079-8fed-5796aa14ffe6)
![Screenshot 2024-07-29 121324](https://github.com/user-attachments/assets/dfa9e457-6141-4a7c-91c6-3c4b089dec4e)


### Affected component/components

Dialog

### How to reproduce

1. Open the application or page where the Dialog component is implemented.
2. Trigger the action to open the Dialog component (e.g., clicking a button or link).
3. Observe the behavior of elements located beneath the dialog-overlay.

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
next.js 14
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: vscode
Issue: VSCode Crashes upon merging branches
Labels: freeze-slow-crash-leak

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.91.1 (Universal)
- OS Version: Darwin arm64 23.5.0 -- macOs Sonoma 14.5(23F79)

Steps to Reproduce:

1. Upon performing `git merge <branch> --no-commit --squash`

Problem:

Upon performing git merge, the commit toolbar loads for a bit and shows the no of changes. Lets say 7. Once I click the commit icon, the sidebar loads indefinitely and vscode crashes

VSCode version

```
Version: 1.91.1 (Universal)
Commit: f1e16e1e6214d7c44d078b1f0607b2388f29d729
Date: 2024-07-09T22:07:54.982Z
Electron: 29.4.0
ElectronBuildId: 9728852
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Darwin arm64 23.5.0

```

Images:

1. Loads indefintely
![image](https://github.com/user-attachments/assets/031eeaff-3f73-4600-a440-71086a709a87)

2. I then get
![image](https://github.com/user-attachments/assets/d7f40db3-7f80-41ff-b5fb-8f093440872d)


Steps I tried

1. Restarting the application
2. Killed and started vscode from activity monitor
3. Reinstalled an older version and tried(Still crashes)
4. Reinstalled the latest version and tried(Still crashes)


Thanks for the help
Repository: ollama
Issue: strange tool response
Labels: bug

### What is the issue?

The prompt was "call fibonacci function to determine 7 element of the sequence".

I wonder if there should be 2 tool calls.

```
{
    "model": "llama3.1:8b",
    "created_at": "2024-07-29T09:32:02.5425761Z",
    "message": {
        "role": "assistant",
        "content": "",
        "tool_calls": [
            {
                "function": {
                    "name": "fibonacci",
                    "arguments": {
                        "n": null
                    }
                }
            },
            {
                "function": {
                    "name": "fibonacci",
                    "arguments": {
                        "n": 7
                    }
                }
            }
        ]
    },
    "done_reason": "stop",
    "done": true,
    "total_duration": 17912684000,
    "load_duration": 4394720300,
    "prompt_eval_count": 132,
    "prompt_eval_duration": 583579000,
    "eval_count": 85,
    "eval_duration": 12932451000
}
```

### OS

Windows

### GPU

Nvidia

### CPU

AMD

### Ollama version

0.3.0
Repository: tauri
Issue: [bug] `tauri::manager::emit` and `tauri::manager::emit_to` tests are not testing the correct thing
Labels: type: bug,status: needs triage

### Describe the bug

The `emit` and `emit_to` tests take the longest to run (for unit tests), so me and @tweidinger looked into them. They are suspiciously taking as long as the timeout would take for every case, and this is easy to prove by increasing/decreasing the timeout used in the tests.

This was added in a093682d2df7169b024bb4f736c7f1fd2ea8b327 it looks like

### Reproduction

Change the `from_secs(1)` to `from_secs(2)` and see that the tests now take double the time to run.

### Expected behavior

Not taking the entire timeout duration and still passing.

### Additional context

cc @lucasfernog @amrbashir
Repository: ant-design
Issue: Datepicker 12 hours AM PM 
Labels: help wanted,Inactive

### Reproduction link

[![Edit on StackBlitz](https://developer.stackblitz.com/img/open_in_stackblitz.svg)](https://stackblitz.com/edit/antdesigndatepicker5-19-3)

### Steps to reproduce

Not sure whether luxon dates are important here, i just meant to show with correct versions (antd 5.14) the provided link for reproduction works.

### What is expected?

AM PM values should be listed correctly

### What is actually happening?

A
A

is shown

| Environment | Info |
| --- | --- |
| antd | 5.19.3 |
| React | 18.2 |
| System | macOS 14.2 |
| Browser | All browsers |

---
Not sure whether luxon dates are important here, i just meant to show with correct versions (antd 5.14) the provided link for reproduction works.

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: ollama
Issue: Documentation for API Options
Labels: documentation,api

When reading the [API Docs](https://github.com/ollama/ollama/blob/main/docs/api.md#request-7) many options are listed with no visible explanation for what they do. The only explanation I could find [here](https://github.com/taketwo/llm-ollama/blob/40c66002a449cd52da2dbe91ea356b59e76bc9a5/llm_ollama.py#L45-L101) explains some, but more advanced ones are not explained anywhere it seems. 

Since I am to make Langchains ChatOllama more feature complete, I require these explanations for the necessary doc-strings.
Repository: kubernetes
Issue: Feature gates to bypass in-tree plugin registration dropped without first graduating
Labels: kind/bug,priority/important-soon,sig/storage,sig/release,sig/architecture,lifecycle/rotten,needs-triage

### What happened?

In the upcoming v1.31 release, we plan to drop some alpha feature gates; see 
https://github.com/kubernetes/kubernetes/issues/126406#issuecomment-2255700515
However, people may have been setting these feature gates (even thought they have no effect).

Per https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/feature-gates.md, we should lock them to true for at least one release before removal.



### What did you expect to happen?

[For each feature gate] the feature gate cannot actually be disabled, but is documented as locked to true. Specifiying the feature gate on the command line does not cause component failure.

### How can we reproduce it (as minimally and precisely as possible)?

Read the code / try explicitly disabling these feature gates.

### Anything else we need to know?

I think this is a release blocker until we decide how we'll handle it.

If we leave things as they are, we should clearly call out the snag in the release notes.