sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [Autocomplete] Autocomplete Popper position breaks when container height changes
Labels: waiting for 👍,package: material-ui,component: autocomplete

### Steps to reproduce

Steps:
1. Open this link to live example: https://codesandbox.io/p/sandbox/fnxpf9
2. Choose at least one of the options in the Autocomplete
3. Autocomplete's Popper's position is not recalculated properly

**Important**: The issue can only be observed if `disableCloseOnSelect` is set to `true`

### Current behavior

Popper position stays the same and does not follow the input. When a condition is met that collapse is retracting, popper's position gets recalculated to the where it should have been on the previous render

### Expected behavior

Popper should "stick" to Autocomplete input no matter the Autocomplete position

### Context

I am aware of the fact that Popper's position for Autocomplete is always 'fixed'. I have tried to use `slotProps` to set `transition: true` for the popper, but it causes it to default to top left position of the screen regardless of `anchorEl` if `disablePortal=true`. It also starts throwing warnings that "Empty string was passed to getElementById" from useAutocomplete.ts (which I'm not using).

The reason I was trying to use the `transition` prop is that from my many attempts to fix this, I've got one case where it did fix the issue, but I could not reproduce it since then. In any case this is very frustrating.

Browsers: Firefox, Chromium

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
System:
    OS: Linux 6.11 Manjaro Linux
  Binaries:
    Node: 20.11.1 - ~/.nvm/versions/node/v20.11.1/bin/node
    npm: 10.2.4 - ~/.nvm/versions/node/v20.11.1/bin/npm
    pnpm: 9.10.0 - /usr/bin/pnpm
  Browsers:
    Chrome: Not Found
  npmPackages:
    @emotion/react: ^11.11.4 => 11.13.3 
    @emotion/styled: ^11.11.5 => 11.13.0 
    @mui/base: ^5.0.0-beta.66 => 5.0.0-beta.66 
    @mui/core-downloads-tracker:  6.2.0 
    @mui/icons-material: ^6.2.0 => 6.2.0 
    @mui/lab: 6.0.0-beta.19 => 6.0.0-beta.19 
    @mui/material: ^6.2.0 => 6.2.0 
    @mui/private-theming:  6.2.0 
    @mui/styled-engine:  6.2.0 
    @mui/system: ^6.2.0 => 6.2.0 
    @mui/types:  7.2.19 
    @mui/utils:  6.2.0 
    @mui/x-data-grid: ^7.15.0 => 7.22.2 
    @mui/x-date-pickers:  7.22.2 
    @mui/x-internals:  7.21.0 
    @types/react: ^18.2.79 => 18.3.12 
    react: ^18.2.0 => 18.3.1 
    react-dom: ^18.3.0 => 18.3.1 
    styled-components: ^6.1.8 => 6.1.13 
    typescript: ^5.4.5 => 5.6.3 

```
</details>


**Search keywords**: autocomplete popper collapse transition
Repository: langchain
Issue: Chroma is not ephemeral when persisted_directory=None
Labels: Ɑ: vector store,🤖:bug

### Checked other resources

- [X] I added a very descriptive title to this issue.
- [X] I searched the LangChain documentation with the integrated search.
- [X] I used the GitHub search to find a similar question and didn't find it.
- [X] I am sure that this is a bug in LangChain rather than my code.
- [X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

### Example Code

```python
from langchain.vectorstores import Chroma
from langchain_community.vectorstores.utils import filter_complex_metadata
from langchain_openai import OpenAIEmbeddings

def retrieval_gpt_generate(query: str,
                           retrieved_documents: List[Document],
                           ):
    texts = text_splitter.split_documents(retrieved_documents)
    embeddings = OpenAIEmbeddings(openai_api_key=constants.OPENAI_API_KEY, max_retries=1000)
    docsearch = Chroma.from_documents(filter_complex_metadata(texts), embeddings, persist_directory=None)
    
    doc_retriever = docsearch.as_retriever(search_kwargs={"k": 5})
    topk_relevant_passages = doc_retriever.get_relevant_documents(query)
    return topk_relevant_passages

for each new {query, retrieved_documents}:
	topk_relevant_passages  = retrieval_gpt_generate(query, retrieved_documents)
	print(topk_relevant_passages)
```

### Error Message and Stack Trace (if applicable)

_No response_

### Description

The `topk_relevant_passages` includes the one from the previous iteration, that is, it would use the previous retrieved_documents. I am pretty sure the retrieved_documents input is entirely different in each iteration. I checked the intermediate docsearch, it is persisted. But I believe by setting `persist_directory=None`, the RAG should be ephemeral in-memory. 

### System Info

Passage1
Passage2 # Using the source from the previous iteration (it shouldn’t)
Passage3 
...
Repository: vscode
Issue: Devcontainers ignores terminal profile settings from settings.json when opening local integrated terminal
Labels: bug,remote,terminal-process,containers

<!-- Please search existing issues to avoid creating duplicates, and review our troubleshooting tips: https://code.visualstudio.com/docs/remote/troubleshooting -->
<!-- Please attach logs to help us diagnose your issue. Learn more here: https://code.visualstudio.com/docs/remote/troubleshooting#_reporting-issues and here: https://code.visualstudio.com/docs/remote/vscode-server#_where-can-i-provide-feedback-or-report-an-issue -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

- VSCode Version: 1.94.2
- Local OS Version: Flatpak Freedesktop SDK runtime 24.08
- Remote OS Version: not relevant, we're talking about a local terminal outside of the container
- Remote Extension/Connection Type: Containers

Steps to Reproduce:

1. Add some configuration to the project's `.vscode/settings.json` that touches the terminal. In my case the following to launch a shell on my host outside of the Flatpak sandbox or container:
```json
{
    "terminal.integrated.defaultProfile.linux": "bash",
    "terminal.integrated.profiles.linux": {
        "bash": {
            "path": "/app/bin/host-spawn",
            "icon": "terminal-bash",
            "args": ["fish"],
            "overrideName": true
        }
    }
}
```
2. Press Ctrl + Shift + P and type `Terminal: Create New Integrated Terminal (Local)` to open a local terminal outside of the container

In my case this _should_ open the Fish shell on my host, and if I run the project outside of devcontainers this works as expected. However when the project is opened within a container and I open a local integrated terminal this is completely ignored and I get a `/bin/sh` shell (which is the default within Flatpak). It also suddenly complains about "bash" not being a valid option for `terminal.integrated.defaultProfile.linux`.

Yes I am running through Flatpak to make things complicated but I don't see how this has anything to do with that environment, this would just as well not work outside of it.

<!-- Check to see if the problem is general, with a specific extension, or only happens when remote -->
Does this issue occur when you try this locally?: No
Does this issue occur when you try this locally and all extensions are disabled?: No
Repository: vscode
Issue: We need an API or some way to know that URI Handling is possible
Labels: api,under-discussion,uri

@Yoyokrazy originally filed this internally... making it public.

> - install ghpri
> - click to sign in via accounts menu
> - browser opens with oath url
> - 🐛 other insiders instance starts up with my vscode oss workspace
> - 🐛 auth hangs in the instance with empty user-data-dir and extensions-dir
> - click cancel
> - "You have not yet finished authorizing this extension to use GitHub. Would you like to try a different way? (local server)"
> - sign in succeeds

user-data-dir is more of a debugging tool and is ultimately the cause here. When we start with a user data dir, but try to open the protocol handler `vscode://` it doesn't really know about user-data-dirs... so it just opens VS Code without that parameter and thus opens your "non-user-data-dir" instance.

I don’t think it’s possible to know if we’re running out of a different user-data-dir from an extension (I checked [vscode.env](https://github.com/microsoft/vscode/blob/2c626bbdb970cf661d86b22d7c9273312ab01b9a/src/vscode-dts/vscode.d.ts#L10017-L10203), [process.env](https://nodejs.org/api/process.html#processenv), [ExtensionContext](https://github.com/microsoft/vscode/blob/2c626bbdb970cf661d86b22d7c9273312ab01b9a/src/vscode-dts/vscode.d.ts#L7696-L7857)):

Feels like the real solution would be new API that says:
* whether or not we're running in a different user-data-dir (not sure who would own this)
* whether or not URI Handling is possible (my preference because it would be good to know for other things like if they're using Windows standalone or Linux from the zip)

https://github.com/microsoft/vscode/issues/213996 is related.

@joaomoreno liked the proposal of the second bullet.

I guess that might look like:

```
declare module 'vscode' {
    export namespace env {
        export const isUriHandlingEnabled: boolean;
    }
}
```
which follows similar pattern to `vscode.env.isTelemetryEnabled`.

or maybe the `vscode.window.registerUriHandler(....)` could return a `{ enabled: boolean } & Disposable`...

the API design is the easy part. I really am not sure how one would "detect" if the protocol handler is available.

Whoever owns URI Handling should own this... @joaomoreno historically that was you... who is it now?
Repository: ollama
Issue: When models don't fit in VRAM, Issue alert/confirmation instead of running and freezing computer for hours
Labels: bug,needs more info

### What is the issue?

When a model is selected that does not fit in VRAM, it runs on the CPU. This is a ridiculous fallback that freezes the whole computer, it should just fail. Or actually use the GPU with shared memory instead of falling back to the CPU only. 

### OS
Windows 11 Pro

### GPU
Nvidia

### CPU
Intel

### Ollama version
0.3.14
Repository: pytorch
Issue: higher rank convolution
Labels: module: nn,triaged

### 🚀 The feature, motivation and pitch

would it be possible to add official pytorch support for higher rank convolution? thanks!

### Alternatives

_No response_

### Additional context

working at a higher rank can be useful, depending on the application!

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: electron
Issue: browserWindow.getBounds() inconsistent between platforms for a minimized, maximized window
Labels: platform/windows,platform/macOS,bug :beetle:,status/confirmed,has-repro-gist,33-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

33.3.0

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

Windows, macOS

### Operating System Version

macOS Sequoia 15.1.1, Windows 10

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

macOS and Windows should be consistent on the bounds returned for a minimized, maximized window.

### Actual Behavior

My vote is for the macOS behavior to be the one to standardize to.

### Testcase Gist URL

https://gist.github.com/00784ca3419def0d6e3d9eb0c5f6a652

### Additional Information

On macOS, `geBounds()` returns the bounds of the maximized window.

On Windows, `getBounds()` returns the normal bounds.
Repository: vscode
Issue: Grouping/sorting of notebook command 
Labels: debt,notebook-commands,notebook-globaltoolbar

The grouping and sorting of the notebook layout commands is fairly random, all layout command should be in one group, all kernel commands in one, and export on in its own group. I have tried to color-code the groups in the screen shot below
 
<img width="469" alt="Screen Shot 2021-10-12 at 12 19 09 (1)" src="https://user-images.githubusercontent.com/1794099/137174183-842bba2c-9824-4d91-a437-9954aa37f41b.png">
Repository: vscode
Issue: Custom Keyboard Shortcuts don't work
Labels: bug,notebook-commands

### Applies To

- [X] Notebooks (.ipynb files)
- [ ] Interactive Window and\/or Cell Scripts (.py files with \#%% markers)

### What happened?

I added a new keyboard shortcut Cmd+Shift+A - in Command mode, this should "run all cells above". This is what my keybindings.json looks like. However, when I hit this combination, nothing happens.

```
[
    {
        "key": "shift+cmd+a",
        "command": "jupyter.runallcellsabove",
        "when": "editorTextFocus && jupyter.hascodecells && !jupyter.webExtension && !notebookEditorFocused"
    }
]
```



### VS Code Version

1.89.1

### Jupyter Extension Version

v2024.4.0

### Jupyter logs

_No response_

### Coding Language and Runtime Version

3.10.12

### Language Extension Version (if applicable)

v2024.6.0

### Anaconda Version (if applicable)

_No response_

### Running Jupyter locally or remotely?

Local
Repository: electron
Issue: UtilityProcess.kill() blocks main process and therefor freezes renderer process
Labels: platform/macOS,bug :beetle:,component/utilityProcess,33-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

[33.3.0](https://releases.electronjs.org/release/v33.3.0)

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

macOS

### Operating System Version

Sequoia 15.1.1 (24B91)

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

When calling the `kill` method on a `UtilityProcess` I expected the main process to handle the graceful killing of the process as describec in [the docs](https://www.electronjs.org/docs/latest/api/utility-process#childkill)

It would be nice to only have the actual result of the method to come at the `utilityProcess.on('exit', () => {})` and not lock up the main process or have a `killAsync` method available

### Actual Behavior

The main process freezes until the process has been shut down.

### Testcase Gist URL

_No response_

### Additional Information

_No response_
Repository: pytorch
Issue: Locale issues in colab: after tensor(1j).cuda().abs() !commands cannot be executed.
Labels: triaged,module: third_party,module: python frontend

### 🐛 Describe the bug

Running the following in colab (T4 runtime):
```
import torch
a=torch.tensor(1j,device="cuda")
a.abs()
!echo "cake is a lie"
```
results in an  `NotImplementedError: A UTF-8 locale is required. Got ANSI_X3.4-1968`

it has to be a) complex b) abs c) on cuda.
otherwise, the final commands succeeds.

It seems like the complex abs cuda kernel modifies the locale?

Related: https://github.com/googlecolab/colabtools/issues/3409

### Versions

default google colab

torch 2.5.1+cu121
python 3.10.12 (main, Nov  6 2024, 20:22:13) [GCC 11.4.0]

cc @albanD
Repository: pytorch
Issue: [ONNX] Rename dynamic shapes produced by ExportedProgram to dynamic_axes
Labels: module: onnx,triaged,onnx-triaged

`torch.export.export` names dynamic shapes to be s0, s1, s2, s3, ..., etc. However, in ONNX, users could pass in the naming through `dynamic_axes` and `input_names`. We need to rename them to what users request.
Repository: material-ui
Issue: Material UI: Pressing Escape key closes Dialog before Snackbar/Alert
Labels: docs

### Steps to reproduce

Steps:
1. Open this link to live example: [MUI-Dialog-Toast-Escape-Example](https://codesandbox.io/p/sandbox/mui-dialog-toast-escape-example-forked-8h7r93)
2. Press "Open Modal" to open the Dialog
3. Press "Open Toast" to open the Snackbar Alert
4. Press the Escape key


### Current behavior

When the Escape key is pressed, the `Dialog` is closed first and the `Alert` is still displayed.

### Expected behavior

Not sure what behavior _should_ be enabled by default. Was expecting the layers to be closed in the order the user opened them (Toast on the first Escape key press, then the Modal on the second press). Ideally, we'd like to see a quick and easy way to configure this behavior.

### Context

I am trying to implement a feature for a common use case in a production-facing React application. There are 50+ pages where a user can have both MUI `Alert`s and `Dialog`s open simultaneously. We need a solution that doesn't cause components that use `Dialog`s to be dependent on the open state of `Snackbar` or `Alert` components. We have been searching the MUI documentation and StackOverflow for this particular use case, but it has not come up in searches.

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: Linux 5.15 Ubuntu 20.04.6 LTS (Focal Fossa)
  Binaries:
    Node: 18.18.0 - ~/.nvm/versions/node/v18.18.0/bin/node
    npm: 9.8.1 - ~/.nvm/versions/node/v18.18.0/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: Version 131.0.6778.140 (Official Build) (64-bit)
  npmPackages:
    @emotion/react: ^11.13.3 => 11.13.3 
    @emotion/styled: ^11.13.0 => 11.13.0 
    @mui/base:  5.0.0-beta.58 
    @mui/core-downloads-tracker:  6.1.3 
    @mui/icons-material: ^6.1.1 => 6.1.3 
    @mui/lab: ^6.0.0-beta.10 => 6.0.0-beta.11 
    @mui/material: ^6.1.1 => 6.1.3 
    @mui/material-nextjs: ^6.1.1 => 6.1.3 
    @mui/private-theming:  6.1.3 
    @mui/styled-engine:  6.1.3 
    @mui/system: ^6.1.1 => 6.1.3 
    @mui/types:  7.2.18 
    @mui/utils:  5.16.6 
    @mui/x-data-grid: ^7.18.0 => 7.19.0 
    @mui/x-data-grid-pro: ^7.18.0 => 7.19.0 
    @mui/x-date-pickers:  7.19.0 
    @mui/x-date-pickers-pro: ^7.18.0 => 7.19.0 
    @mui/x-internals:  7.18.0 
    @mui/x-license:  7.18.0 
    @mui/x-tree-view: ^7.18.0 => 7.19.0 
    @types/react: ^18.3.9 => 18.3.11 
    react: 18.3.1 => 18.3.1 
    react-dom: ^18.2.0 => 18.3.1 
    typescript: ^5.6.2 => 5.6.3
```
</details>


**Search keywords**: Dialog Snackbar Alert Escape
Repository: kubernetes
Issue: Recreate strategy doesn't create new replicaset on its own
Labels: kind/bug,needs-sig,needs-triage

### What happened?

We've switched some of our deployments to the recreate strategy and as a result we're seeing long delays between a replicaset scaling down and a new one scaling up when a new version is rolled out (10+ minutes between events). This can be due to a number of things but it seemed to only impact our workloads on the recreate strategy. After digging into the source code it appears that the recreate logic doesn't actually create the new replicaset even though it seems like it should. Instead it looks like it exits out early and relies on the cluster/replicaset controller to naturally resolve the out of sync state when it gets around to it (which in our case can be pretty slow). This can result in very long deploy cycles for workloads using the recreate strategy. The issue I believe is stemming from [here](https://github.com/kubernetes/kubernetes/blob/v1.31.2/pkg/controller/deployment/recreate.go#L45) where we return early after updating the deployment status if the previous replicaset has scaled down regardless of the new replicaset. Checking the history of the code this has been around for [9 years](https://github.com/kubernetes/kubernetes/commit/92798408af90569f492be3a1a4d8de02538a6787#diff-c553184997fa4c9f63e697af2f39eb2e6fb43eeff64a0ef66c9e955f61347b02R428) so either I am not interpreting what should be happening correctly or just no one has noticed but I would expect that the code doesn't return there but instead continues to spin up the new replicaset like the logic after that return statement does in that method.

### What did you expect to happen?

I expected my deployments that use the recreate strategy to deploy their new replicasets shortly after the old ones have been scaled down.

### How can we reproduce it (as minimally and precisely as possible)?

A unit test could probably reproduce this but I'm more curious about an explanation of the code to make sure I understand it correctly.

### Anything else we need to know?

_No response_

### Kubernetes version

<details>
v1.31.2

```console
$ kubectl version
Client Version: v1.32.0
Kustomize Version: v5.5.0
```

</details>


### Cloud provider

<details>
AWS
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: godot
Issue: `GraphNode` doesn't shrink automatically
Labels: bug,topic:gui

### Tested versions

v4.4.dev.custom_build [abf47965f]

### System information

Debian Linux X11

### Issue description

`GraphNode` doesn't shrink automatically when
- `size_flags_vertical = SIZE_SHRINK_CENTER`
- the size of child Control nodes decreases

I would expect, that a container node with `SIZE_SHRINK_CENTER` automatically shrinks, when the size of their child nodes decreases.


### Steps to reproduce

1. Load and run MRP
2. Drag the top `HSlider` to the right to increase the vertical size of the labels.
3. Drag the top `HSlider` to the left to decrease the vertical size of the labels.

After 3:
- The label inside the GraphNode became smaller, but the GraphNode didn't adjust its size and appears too big
- For comparison there is a working example on the right side of the scene with a HBoxContainer, that adjusts its vertical size automatically (indicated by the red color)


### Minimal reproduction project (MRP)

[bug-graph-edit-resize.zip](https://github.com/user-attachments/files/18172298/bug-graph-edit-resize.zip)
Repository: PowerToys
Issue: [PowerToys Run] Background on top of window when AccentColorInactive is set
Labels: Issue-Bug,Product-PowerToys Run,Area-User Interface,Status-Reproducible

### Microsoft PowerToys version

0.87.0

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

1. Set a custom accent color for inactive windows by adding the registry key `AccentColorInactive` (DWORD) in _HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM\\_ with value `ff262626`.
2. Restart the computer to ensure that the change has taken effect.

This was not a problem prior to 0.87.0

### ✔️ Expected Behavior

PowerToys Run window is not affected

### ❌ Actual Behavior

Accent color is visible through the window (even when focused)
![Image](https://github.com/user-attachments/assets/c66e7dfb-95eb-4de5-a820-eff5fb2635da)


### Other Software

_No response_