sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: tauri
Issue: Cannot drag tauri app window on MacOS when titleBarStyle is set to Overlay
Labels: type: bug,status: needs triage

### Describe the bug

On MacOS Sonoma, I cannot move the application window of my tauri app when `titleBarStyle` is set to `Overlay`:

tauri.conf.json

```
 "windows": [
      {
        "title": "tauri-app",
        "width": 800,
        "height": 600,
        "titleBarStyle": "Overlay"
      }
    ]
```


### Reproduction

1. Generate a minimal tauri app (accept all default values)
`npm create tauri-app@latest`

2. Run npm install in `tauri-app`
`cd tauri-app`
`npm install`

3. Edit `src-tauri/tauri.conf.json` and add `titleBarStyle: Overlay` to the `windows` property section:
```
"windows": [
      {
        "title": "tauri-app",
        "width": 800,
        "height": 600,
        "titleBarStyle": "Overlay"
      }
    ],
 ```

4. Run tauri app 
`npm run tauri dev`



Faulty behaviour: The application window cannot be moved.



### Expected behavior

Expected behaviour: The application window can be moved.

### Full `tauri info` output

```text
npm run tauri info

> tauri-app@0.0.0 tauri
> tauri info


[⚠] Environment
    - OS: Mac OS 14.4.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.75.0 (82e1608df 2023-12-21) (Homebrew)
    ✔ cargo: 1.75.0
    ⚠ rustup: not installed!
      If you have rust installed some other way, we recommend uninstalling it
      then use rustup instead. Visit https://rustup.rs/
    ⚠ Rust toolchain: couldn't be detected!
      Maybe you don't have rustup installed? if so, Visit https://rustup.rs/
    - node: 21.5.0
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 1 (no lockfile)
    - tauri-build [RUST]: no manifest (no lockfile)
    - wry [RUST]: no manifest (no lockfile)
    - tao [RUST]: no manifest (no lockfile)
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.11

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: deno
Issue: Deno LSP taking time to load TypeScript in VSCode
Labels: bug,perf,lsp

Version: Deno 1.42.1
My laptop specs: MacBook Pro M1, 8gb ram, 512gb ssd - OS: Sonoma 14.4.1

```
deno 1.42.1 (release, aarch64-apple-darwin)
v8 12.3.219.9
typescript 5.4.3
```

I'm using the deco.cx stack to build a website. However, I notice that it is taking a long time to load the autocomplete into the file.
For example, in the image below, when you hover over the constant, you get a loading message instead of showing the details.
TypeScript's performance in type identification and auto-completion when writing is quite slow.

![image](https://github.com/denoland/deno/assets/10791688/b7ea62cd-3ad7-4adc-9ed0-665d550ec6e8)

A simple console.log, as you can see in the image below, is also not completing automatically.

![image](https://github.com/denoland/deno/assets/10791688/ac8fcb2e-929f-4355-9a84-fcfc7b5cfa19)

I tried to upgrade deno to the most current version, but I still have the same problem.
In my VSCode, I already have the most current deno extension installed.

After some time, the lsp deno "appears" to be a sign of life, but appears buggy.
As you can see, the comment made in the code is showing an error in a variable.

![image](https://github.com/denoland/deno/assets/10791688/64f50706-9069-4f55-86ba-5babd4862397)
Repository: next.js
Issue: RootLayout render infinitely 
Labels: bug

### Link to the code that reproduces this issue

https://github.com/maxy4u/gaurav-khurana-portfolio

### To Reproduce

1. Start application in dev (npm run dev or npm run build with npm run start , with or without node option inspect doesn't matter)
2. Visit localhost:3000
3. Verify console log on terminal , It will log "layout theme======> dark" infinitely.
4. Added console on page it never rerender. However, Root layout keeps re rendering.


### Current vs. Expected behavior

Current Behaviour : - 
Root Layout render infinitely tried with num run build then npm run start Or npm run dev with no avail

<img width="945" alt="Screenshot 2024-04-18 at 7 08 06 PM" src="https://github.com/vercel/next.js/assets/6682288/53008f5c-3190-4c89-a162-63f755927b89">

Expected Behaviour :-
Root layout must not re render infinitely. 



### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:10 PST 2023; root:xnu-10002.61.3~2/RELEASE_X86_64
Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.1.4
  eslint-config-next: 12.2.3
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 4.7.4
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

### Additional context

_No response_
Repository: storybook
Issue: [Bug]: Mediquery problem with panelPosition on the right
Labels: bug,needs triage

### Describe the bug

When the panel (with controls, etc.) is set to the right, either manually by the user or as part of the manager config, it doesn't collapse as expected on medium screens.

See this screen cast:

![chrome_s6nAAaqijW](https://github.com/storybookjs/storybook/assets/5051359/14a2aab8-960c-4279-a37c-be834eb741f9)

On medium width screens, the panel should either collapse to the bottom (IMO best since the sidebar is still visible as a column) or be hidden.

<details>
<summary>When the panel is set to the bottom, there are no issues:</summary>

![chrome_AoZBWjqrM1](https://github.com/storybookjs/storybook/assets/5051359/b2950bd9-e16b-4b65-a694-61f80aab5afa)
</details>




### To Reproduce

When the panel is set to the right, use dev tools to slowly shink the window (or use a tablet). At some points, the viewport will be too narrow.

### System

```bash
System:
    OS: Linux 5.15 Ubuntu 20.04.6 LTS (Focal Fossa)
    CPU: (8) x64 Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 20.12.2 - ~/.nvm/versions/node/v20.12.2/bin/node
    npm: 10.5.2 - ~/.nvm/versions/node/v20.12.2/bin/npm
    pnpm: 8.15.6 - ~/.nvm/versions/node/v20.12.2/bin/pnpm <----- active
  Browsers:
    Chrome: 123.0.6312.122
  npmPackages:
    @storybook/addon-a11y: ^8.0.8 => 8.0.8
    @storybook/addon-actions: ^8.0.8 => 8.0.8
    @storybook/addon-essentials: ^8.0.8 => 8.0.8
    @storybook/addon-interactions: ^8.0.8 => 8.0.8
    @storybook/addon-links: ^8.0.8 => 8.0.8
    @storybook/blocks: ^8.0.8 => 8.0.8
    @storybook/components: ^8.0.8 => 8.0.8
    @storybook/core-events: ^8.0.8 => 8.0.8
    @storybook/manager-api: ^8.0.8 => 8.0.8
    @storybook/preview-api: ^8.0.8 => 8.0.8
    @storybook/react: ^8.0.8 => 8.0.8
    @storybook/react-vite: ^8.0.8 => 8.0.8
    @storybook/test: ^8.0.8 => 8.0.8
    @storybook/theming: ^8.0.8 => 8.0.8
    eslint-plugin-storybook: ^0.8.0 => 0.8.0
    storybook: ^8.0.8 => 8.0.8
```


### Additional context

_No response_
Repository: pytorch
Issue: torch.histogramdd Inconsistent/Incorrect Documentation
Labels: module: docs,triaged,actionable,module: python frontend

### 📚 The doc issue

The doc for [torch.histogramdd](https://pytorch.org/docs/stable/generated/torch.histogramdd.html) says that "every bin is exclusive of its left edge. Only the rightmost bin is inclusive of its right edge." However, running some code suggests that every bin is _inclusive_ of its left edge.
```python
-> torch.histogramdd(torch.tensor([[0.0, 0.0], [0.5, 0.5], [1.0, 1.0]]), range=(0, 1.0, 0, 1.0), bins=2)
torch.return_types.histogramdd(
hist=tensor([[1., 0.],
        [0., 2.]]),
bin_edges=(tensor([0.0000, 0.5000, 1.0000]), tensor([0.0000, 0.5000, 1.0000])))
``` 
That is, [0,0] gets sent to the [0,0]th bin and both [0.5, 0.5] and [1.0, 1.0] get sent to the [1,1]th bin.

Additionally, I believe what the documentation says is not logically sound. If "every bin is exclusive of its left edge" and all but the rightmost bin is exclusive of its right edge, then there'd be holes in between the bins. 

### Suggest a potential alternative/fix

Change the documentation to instead say "every bin is inclusive of its left edge."

cc @svekars @brycebortree @albanD
Repository: godot
Issue: Clicking a button in the scene dock while a project is loading causes current scene to be overwritten
Labels: bug,topic:editor,needs testing

### Tested versions

v4.2.1.stable.official [b09f793f5]
v4.2.2.stable.official [15073afe3]

### System information

Windows 11 Home Godot Engine v4.2.1.stable.official.b09f793f5 Vulkan API 1.2.170 - Forward+ - Using Vulkan Device #0: Intel - Intel(R) UHD Graphics

### Issue description

When a project is loading, the scene dock appears and if you click a button before the last opened scene is fully loaded, the loading scene will be completely overwritten with a new scene. This is irreversible without rolling back to a previously saved version. No undo is possible.  This bug is more apparent when projects / scenes are large and hence take longer to load (giving you more time to click a button by accident!)

Haven't tested in 4.2.2 but this problem has been present since at least 4.0 so I'm assuming it's pervasive across versions.

### Steps to reproduce

1. Open a large project that is slow to load on your system.
2. As the current loaded scene is loading, click "2D Scene" in the Scene Dock.
3. You will notice that the current scene has been overwritten by a new "empty" scene with nothing but a Node2D.   

### Minimal reproduction project (MRP)

I cannot provide this because what is slow to load for you will be dependent on your system. Additionally, it wouldn't be practical to upload a large project for merely the purposes of providing you something slow to load. Bug is not project dependent.
Repository: ui
Issue: [bug]: FormMessage with useTranslations from next-intl
Labels: bug

### Describe the bug

When passing a translation key to FormMessage like:
`<FormMessage>{t(key)}</FormMessage>`
it displays the key and not the appropriate translation. Replacing it with
`<span>{t(key)}</span>`
works just fine.

### Affected component/components

Form

### How to reproduce

1. Build a standard nextjs project with create-next-app
2. Create any form using shadcn ui Form component with FormMessage as shown above
3. Add a translation table
4. Enter an invalid email address in the form
5. It will show the key instead of the translation
6. Replace FormMessage with span and it will work fine.

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
"next": "14.1.4",
"next-intl": "^3.9.5",
"react": "^18.2.0",
"zod": "^3.22.4”,
"@hookform/resolvers": "^3.3.4",
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: flutter
Issue: Stateless widget with FileImage widget has a child have a state (the filesystem)
Labels: framework,a: images,has reproducible steps,P2,team-framework,triaged-framework,found in release: 3.19,found in release: 3.22

### Steps to reproduce

I have a Stateless widget that takes a path as a parameter and creates a `FileImage` widget in its build method.
The user imports a new image that overwrites the current image. I immediately rebuild the interface but the old widget stays the same. If the path changes, the widget is updated. I imagine it is due to optimization on Flutter that thinks Stateless widgets are "Pure", meaning they don't need to be rebuilt if their parameters don't change. but in the case of Stateless widgets that contain `FileImage` this is a wrong assumption.
Is there any way to solve this issue while keeping the same file name?

### Expected results

a

### Actual results

a

### Code sample

<details open><summary>Code sample</summary>

```dart
[Paste your code here]
```

</details>


### Screenshots or Video

<details open>
<summary>Screenshots / Video demonstration</summary>

[Upload media here]

</details>


### Logs

<details open><summary>Logs</summary>

```console
[Paste your logs here]
```

</details>


### Flutter Doctor output

<details open><summary>Doctor output</summary>

```console
[Paste your output here]
```

</details>
Repository: vscode
Issue: Support workspace edits for chat participants
Labels: feature-request,inline-chat,panel-chat,chat

Currently when a chat response creates a workspace edit, the inline chat closes and the user's focus is moved to the Refactor Preview view in the panel. This doesn't feel very smooth, it would be much more pleasant if the refactor preview was shown directly in the inline chat.
Repository: vscode
Issue: Outline provider changes
Labels: debt,notebook-toc-outline

```[tasklist]
### Tasks
- [ ] Move outline provider to notebook worker
- [ ] Given that this was slow and hanging the renderer process, we might want to measure the perf of the computation
- [ ] https://github.com/microsoft/vscode/issues/210704
```
Repository: pytorch
Issue: [dynamo] Graph breaks in nested function increase compile time badly
Labels: triaged,oncall: pt2,module: dynamo

### 🐛 Describe the bug

On seeing a graph break, Dynamo restarts tracing. However, this restarting and aggressive inlining causes linear increase in compile time wrt how deep the call stack is. For the following repro, the compilation latency numbers are

~~~
Dynamo fn_no_graph_breaks: 3.56 seconds
Dynamo fn: 6.74 seconds
Dynamo gn: 10.07 seconds
Dynamo hn: 13.27 seconds
~~~

There is another idea floating around to better design the continuation functions to not cause graph breaks at function boundaries. That work might fix this issue. But I am wondering if there is an easier way to prevent this today. This was exposed in this PR - https://github.com/pytorch/pytorch/pull/124121 - where Dynamo starts tracing `_call_impl` instead of `forward`, doubling the compilation time for models with graph breaks.


cc @ezyang @msaroufim @bdhirsh @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @jansel @ezyan @mlazos @yanboliang @oulgen 

~~~
import torch
import time
from torch.fx.experimental.proxy_tensor import make_fx

x = torch.randn(4, device="cuda")


def compile_and_profile(f):
    torch._dynamo.reset()
    opt_f = torch.compile(f, backend="eager")
    t0 = time.perf_counter()
    opt_f(x)
    t1 = time.perf_counter()
    print(f"Dynamo {f.__name__}:", round(t1 - t0, 2), "seconds")


def fn_no_graph_breaks(x):
    for _ in range(5000):
        x = torch.ops.aten.sin(x)
    return x


compile_and_profile(fn_no_graph_breaks)


def fn(x):
    for _ in range(5000):
        x = torch.ops.aten.sin(x)
    torch._dynamo.graph_break()
    return x


compile_and_profile(fn)


def gn(x):
    return fn(x)


compile_and_profile(gn)


def hn(x):
    return gn(x)


compile_and_profile(hn)

~~~





### Error logs

_No response_

### Minified repro

_No response_

### Versions

N/A
Repository: vscode
Issue: Code symbols in Notebook outline is not when the text in a code cell is updated
Labels: bug,a11y-partner,notebook-toc-outline

* Create a notebook with code cells and md
* Ensure code is displayed in the nb outline
* Verify the symbol outlines are displayed in the nb outline
    * E.g. have a few functions (perhaps nested)
* Modify one of the functions and the symbol outline is not updated.
Repository: tauri
Issue: [bug] Tauri App's Close Functionality Fails After Minimize/Maximize Actions (Windows)
Labels: type: bug,status: needs triage

### Describe the bug

Encountered an issue where minimizing and then attempting to close a Tauri application. Results in the close handler losing its scope. This prevents the close handler from functioning as expected.

### Minimal Reproduction Example
[GitHub Repository](https://github.com/tance77/single-instance-min-repro-bug)

### Behavior Observed
The application is set up to intercept the `WINDOW_CLOSE_REQUESTED` event and prevent the default behavior, which typically closes the application. Instead, it invokes a Tauri command to hide the window. The application features a system tray implementation which allows it to remain open in the background and can be reopened with a click event on the system tray icon.

### Additional Notes
This issue seems to be triggered by specific interactions with window size adjustments and the taskbar functionalities when the application is in a minimized state.

I also have not tested this on Mac and may exist there too.

### Reproduction

1. Run the application using `npm run tauri dev`.
2. Right-click the application icon in the taskbar and choose "Pin to taskbar".
3. Optionally, click "Close" on the application window to observe it hiding instead of closing.
4. Click the Tauri icon in the system tray to display the window again. (Note: Clicking the icon pinned to the taskbar won't show the window in dev mode.)
5. Simultaneously press `Win + Up Arrow` and `Win + Down Arrow` to alternate window size. During this, right-click the pinned taskbar icon and choose "Close", while continuing to alternate window size with the arrows.
6. Attempt to close the application by clicking the 'X' button; observe that the application does not hide as expected, indicating a malfunction.

### Expected behavior

The close handler to continue to function as a close handler

### Full `tauri info` output

```text
[✔] Environment
    - OS: Windows 10.0.22621 X64
    ✔ WebView2: 123.0.2420.97
    ✔ MSVC:
        - Visual Studio Build Tools 2017
        - Visual Studio Build Tools 2022
    ✔ rustc: 1.77.1 (7cf61ebde 2024-03-27)
    ✔ cargo: 1.77.1 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 18.14.0
    - npm: 9.3.1

[-] Packages
    - tauri [RUST]: 1.6.1
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.7
    - tao [RUST]: 0.16.8
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.11

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: Vue.js
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context


https://github.com/tauri-apps/tauri/assets/3421501/20941d02-0d2c-482d-a193-3ebaa2ac019b
Repository: flutter
Issue: DisplayList should optimize out unused clips
Labels: engine,P3,team-engine,triaged-engine

Right now the DisplayList build process has no look ahead or buffer rewriting that can remove clip operations that were never used by any rendering operation before they were deleted by a `restore()` call. This can cause the rendering backend to do a lot of work to set up the clip buffers (sometimes stencil buffer, sometimes depth buffer) for no practical reason.

At the time of restore, the DisplayListBuilder could look at the last few ops and if there are clips that are after the most recent rendering op, they can be set to a nop status or removed from the buffer.
Repository: godot
Issue: Exported & animated `Node`/`Array[Node]`/etc lose reference(s) when the keyframe is reinspected after reopening the scene
Labels: bug,topic:editor,topic:animation

### Tested versions

- Reproducible in 4.3.dev (2efbc6bfb) and before

### System information

Godot v4.3.dev (2efbc6bfb) - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; 31.0.15.5222) - Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (8 Threads)

### Issue description

The exported `Node`/`Array[Node]` property/properties lose their path(s)/reference(s) (the array keep its size, just the elements are not assigned anymore) when there's an AnimationPlayer's keyframe for them, and the scene is saved then reopened then the keyframe is clicked again. Here's a video :


https://github.com/godotengine/godot/assets/75151379/fd045efa-0011-4eaa-a13a-0bf56c61ca99

This is not the same issue as https://github.com/godotengine/godot/issues/90190 which is fixed in current 4.3.dev

### Steps to reproduce

1. @export a `Node` or `Array[Node]`
2. Assign node(s)
3. Create animation in `AnimationPlayer`
4. Create keyframe for the exported property
5. Witness that the property in the `AnimationTrackKeyEdit` still have the reference(s)
6. Save, close and reopen that scene
7. Check the property for that keyframe again
8. Witness that they have lost the refs.

### Minimal reproduction project (MRP)

N/A
Repository: go
Issue: crypto/tls: bogo suite on Windows is flakey
Labels: OS-Windows,NeedsInvestigation

See e.g. https://ci.chromium.org/ui/p/golang/builders/ci/gotip-windows-amd64-longtest/b8750306255775534897/test-results?sortby=&groupby=

Seems like another case of Windows just not liking creating a lot of connections, unclear what a real solution here is. Probably just disabling it on windows builders?
Repository: vscode
Issue: Git - Execute multiple git operations at the same time on different repositories
Labels: bug,git

<!-- ⚠️⚠️ 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. -->
Extracted from <https://stackoverflow.com/questions/77327389/how-to-execute-multiple-git-operations-at-the-same-time-on-vscode-for-different>

Each time a commit, push, etc. is executed on VSCode (UI), all options are disabled until the operation completes. This is fine for operations on the same repository, but it shouldn't block the other repositories (on a Multi-root Workspace).

In the picture below, the repository 1 is pushing, but I'm unable to do a commit in the repository 2.

![image](https://github.com/microsoft/vscode/assets/405347/2a0083fc-6495-42ed-81ab-d6e43a8a21b6)

PS: Wasn't sure if this is a Feature request or a bug.
Repository: ollama
Issue: Download the models with alternative tools
Labels: feature request

How can I download models with other tools like wget/curl and then import them to a local Ollama server?

When I download a model **it takes up all the available bandwidth** and I want to be able to control the bandwidth so that it takes longer but does not leave my LAN without connectivity
Repository: next.js
Issue: Unhandled Runtime Error：ChunkLoadError: Loading chunk app/layout failed.
Labels: bug

### Link to the code that reproduces this issue

https://github.com/zhangwei900808/next-issue-demo

### To Reproduce

1、clone project
2、pnpm install
3、pnpm run dev
4、open the page and you can see chrome console output: Uncaught SyntaxError: Invalid or unexpected token
5、same minutes you can see error:Uncaught ChunkLoadError: Loading chunk app/layout failed.
<img width="998" alt="image" src="https://github.com/vercel/next.js/assets/4385154/37de7c45-c9dc-442d-9360-e7c69d66f949">



### Current vs. Expected behavior

1、First time open the page is error but you refresh page is work!
2、I expected is work all the time 

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 20.11.1
  npm: 10.2.4
  Yarn: N/A
  pnpm: 7.29.1
Relevant Packages:
  next: 14.2.2 // Latest available version is detected (14.2.2).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: N/A
Next.js Config:
  output: N/A
```


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

Not sure

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

next dev (local)

### Additional context

_No response_