sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: svelte
Issue: Styles are not removed after transition slide end
Labels: awaiting submitter

### Describe the bug

Sometimes the styles applied inline are not removed after the transition is finished. Causing the container that did the transition to have a `overflow: hidden` (and other things) as an inline style. But then it can work fine 4 tries after. 

But the big issue for us is that the `overflow: hidden` property is there. So any expandable container inside the container doesn't work. As shown in the demo

### Reproduction

I was not able to reproduce it locally. But it happens in our staging and production environment, so I've recorded a video. Where one can see that the inline styles are sometimes not removed after the transition finishes. And sometimes they are.

[Link to the video (youtube)](https://www.youtube.com/watch?v=uydj0kaL_UA)


### Logs

_No response_

### System Info

```shell
System:
    OS: Linux 5.15 Ubuntu 20.04.6 LTS (Focal Fossa)
    CPU: (16) x64 AMD Ryzen 7 2700X Eight-Core Processor
    Memory: 6.56 GB / 31.27 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 20.13.1 - ~/.local/share/pnpm/node
    npm: 10.5.2 - ~/.local/share/pnpm/npm
    pnpm: 8.6.7 - ~/.local/share/pnpm/pnpm
  Browsers:
    Chrome: 125.0.6422.141
    Chromium: 126.0.6478.114
  npmPackages:
    svelte: ^4.2.11 => 4.2.11
```


### Severity

annoyance
Repository: puppeteer
Issue: [Feature]: Provide API for configuring Chrome preferences in `puppeteer.launch()`
Labels: feature,P3

### Feature description

In https://github.com/mozilla/pdf.js/issues/18274 of Mozilla's PDF.js project we ran into the issue that if we print to PDF in Chrome the files automatically get saved to the user's download directory. This is suboptimal because we don't want the tests to leave persistent artifacts in the user's download directory.

For Firefox we fixed the issue by configuring the download directory to be a temporary directory that automatically gets wiped after the tests so no artifacts are left behind; see https://github.com/mozilla/pdf.js/blob/master/test/test.mjs#L930-L938. However, Chrome doesn't seem to allow us to do the same: we can only give `args` in `puppeteer.launch` options, but the download directory doesn't seem to be changeable via the command-line arguments of Chrome. Fortunately there _is_ in fact a Chrome preference called `download.default_directory` to configure this, but sadly Puppeteer doesn't seem to have an API to set Chrome preferences.

The only option we see is providing a custom `userDataDir` in `puppeteer.launch()` options, but this feels hacky and requires knowledge of how Chrome's profile directory is structured and how the preference file works (and I haven't been able to find good documentation on that). It'd be much nicer if Puppeteer had an API similar to the `extraPrefsFirefox` field that exists for Firefox already to equivalently set Chrome preferences.
Repository: storybook
Issue: [Bug]: webpack-dev-middleware Error: ENOENT: no such file or directory on Windows
Labels: bug,needs triage

### Describe the bug

When path to stories.ts file is too long, storybook failed with error:

`
<e> [webpack-dev-middleware] [Error: ENOENT: no such file or directory, open 'C:\Users\Mihail.Goloborodov\Downloads\github-vt6qqm\node_modules\.cache\storybook\1c3385a5d25e538d10b518b310c74d3ca2690b6aaffeadccd74da79736171f86\public\stories-very-very-very-very-very-
very-long-directory-name-very-very-very-very-very-very-long-directory-name-very-very-very-very-very-very-long-directory-name-very-very-very-very-very-very-long-directory-name-very-very-very-very-very-very-long-directory-name-very-very-very-very-very-very-long-file-
name-stories.iframe.bundle.js'] {
<e>   errno: -4058,
<e>   code: 'ENOENT',
<e>   syscall: 'open',
<e>   path: 'C:\\Users\\Mihail.Goloborodov\\Downloads\\github-vt6qqm\\node_modules\\.cache\\storybook\\1c3385a5d25e538d10b518b310c74d3ca2690b6aaffeadccd74da79736171f86\\public\\stories-very-very-very-very-very-very-long-directory-name-very-very-very-very-very-very-
long-directory-name-very-very-very-very-very-very-long-directory-name-very-very-very-very-very-very-long-directory-name-very-very-very-very-very-very-long-directory-name-very-very-very-very-very-very-long-file-name-stories.iframe.bundle.js'
<e> }
`

I think there is a problem with filenames longer then 256 symbols on Windows.


### Reproduction link

https://stackblitz.com/edit/github-vt6qqm

### Reproduction steps

1. Go to the link above
2. Download project and run on windows: `npm i` and `npm run storybook` (or `yarn` and `yarn storybook`)
3. Error in terminal

### System

```bash
System:
    OS: Windows 10 10.0.19044
    CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz     
  Binaries:
    Node: 20.11.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.2.4 - C:\Program Files\nodejs\npm.CMD <----- active
  Browsers:
    Chrome: 126.0.6478.114
    Edge: Chromium (126.0.2592.68)
  npmPackages:
    @storybook/addon-docs: ^8.2.0-alpha.10 => 8.2.0-alpha.10   
    @storybook/addon-essentials: ^8.2.0-alpha.10 => 8.2.0-alpha.10
    @storybook/addon-interactions: ^8.2.0-alpha.10 => 8.2.0-alpha.10
    @storybook/addon-links: ^8.2.0-alpha.10 => 8.2.0-alpha.10
    @storybook/angular: ^8.2.0-alpha.10 => 8.2.0-alpha.10
    @storybook/blocks: ^8.2.0-alpha.10 => 8.2.0-alpha.10
    @storybook/test: ^8.2.0-alpha.10 => 8.2.0-alpha.10
    storybook: ^8.2.0-alpha.10 => 8.2.0-alpha.10
```


### Additional context

_No response_
Repository: flutter
Issue: [iOS] substantial overhead from Webview itself?
Labels: c: performance,a: platform-views,P2,team-ios,triaged-ios

Running the ad banner benchmark and taking a CPU capture, it looks like most of the overhead on the mainthread is now from Webview operations themselves:

![ads](https://github.com/flutter/flutter/assets/8975114/9918e004-3c5c-4120-a5e4-d3386ef835f6)


Potentially related: while running this app the console is full of notifications like "0x1171058c0 - ProcessAssertion::acquireSync Failed to acquire RBS assertion 'WebProcess NearSuspended Assertion' for process with PID=4,989, error:" . I wonder if some of this CPU cost is posting these notifications? Is there a way to test turning these off.

![image](https://github.com/flutter/flutter/assets/8975114/67d4c922-2d70-429f-846f-6021bfe67efc)
Repository: terminal
Issue: TerminalPaneContent.cpp - TerminalPaneContent::TerminalPaneContent never knows the profile settings updated with the wt.exe cmdline arguments
Labels: Help Wanted,Issue-Bug,Area-TerminalControl,Product-Terminal

### Windows Terminal version

#16497 (which is in sync with main) - PR-Commit: 756d7b3e7860d1082ed87833521ed65638688abc

### Windows build number

10.0.19045.4529

### Other Software

_No response_

### Steps to reproduce

Try to access the profile configuration used by the current terminal pane content in a version that is updated based on the command line parameter used to start wt.exe .

### Expected Behavior

The `_profile` variable contains the current profile settings from settings file.
And the `_cache` contains the settings updated based on the wt.exe command line arguments.

### Actual Behavior

The `_profile` variable contains the current profile settings from settings file.
And the `_cache` contains the current profile settings from settings file too.

### Debug information
You can use my PR #16497 and check the value of `const auto closeMode` in `TerminalPaneContent::_controlConnectionStateChangedHandler`. It is always the one from settings and the same as the one from `_profile`.

If you compare the value against the value returned in `AppCommandlineArgs::_getNewTerminalArgs` you will see that the command line parsing works.
Repository: TypeScript
Issue: Consider making `WritableStreamDefaultWriter.write()` contravariant
Labels: Bug,Help Wanted

### ⚙ Compilation target

esnext

### ⚙ Library

dom

### Missing / Incorrect Definition

`WritableStreamDefaultWriter.write(chunk)`

### Sample Code

```TypeScript
const test: WritableStream<{ a: string }> = new WritableStream<{ a: string; b: string }>();
```

The above does not raise a type error. `test.getWriter().write({ a: "string" })` will not show an error, even though the underlying stream expects `b` properties on the chunks. A variation of the problem is this:
```typescript
const writable = new WritableStream<{ a: string; b: string }>();
new ReadableStream<{ a: string }>().pipeTo(writable); // No error
```

`WritableStream<A>` and `WritableStream<B>` differ in the signature of their `getWriter().write(chunk)` method. Because `WritableStreamDefaultWriter.write(chunk)` is a method, it is bivariant, leading to the above examples to pass.

Other than for example `Array`, `WritableStream` is only ever used for writing, never for reading, so as far as my understanding goes, bivariance does not have any use here. This is why I would suggest to change the typing of `WritableStream` to make it contravariant, to make the examples above raise errors. One way to achieve that would be to declare `WritableStreamDefaultWriter.write()` as a function property instead of a method, that would solve the problem at least in strict mode:
```typescript
    write: (chunk?: W) => Promise<void>;
```

Although I am not sure whether that would have any other implications.

As a workaround, I use the following code:
```typescript
declare const write: unique symbol;
declare global {
	interface WritableStreamDefaultWriter<W = any> {
		[write]?: (a: W) => void;
	}
}
```

Some more details about this can also be found [on StackOverflow](https://stackoverflow.com/a/78667928/242365).


### Documentation Link

_No response_
Repository: ollama
Issue: API works with non-functional params, no error messages
Labels: bug,api

### What is the issue?

The API should only accept the parameters `"model"`, "messages" and "options", but there won't be no error messages displayed if there are also non-functional params, like in this case `"seed"` or `"temperature"`:
```python
def query_model(prompt, model="llama3", url="http://localhost:11434/api/chat"):
    # Create the data payload as a dictionary
    data = {
        "model": model,
        "seed": 123,        # for deterministic responses
        "temperature": 0,   # for deterministic responses
        "messages": [
            {"role": "user", "content": prompt}
        ]
    }
```

It would be great if error messages could be displayed if there a non-working params defined in the API request.

### OS

Linux, Windows, Docker, WSL2

### GPU

Nvidia

### CPU

AMD

### Ollama version

0.1.45
Repository: ollama
Issue: ROCm on WSL
Labels: feature request,amd,wsl

Recently, AMD released preview drivers for Windows that, alongside userspace packages for WSL, enable one to use ROCm through WSL. Ollama detection of AMD GPUs in linux, however, uses the presence of loaded amdgpu drivers and other sysfs stuff to determine various properties of the GPU. These are not available with this WSL ROCm setup, nor is rocm-smi used for querying VRAM size and its usage etc. I was wondering if it was feasible to add some detection for this setup, so it can be used anyway, even if some runtime information is not available. Is runtime knowledge of the available VRAM strictly necessary? Could a user just not make sure not to load too big of a model, and in case of failing to do so, accept that the ROCm runtime will hard error out on failing hipMallocs etc? Perhaps we could warn users in the output that this might happen.
Repository: ollama
Issue: Support for Vision Language Models that can process Videos.
Labels: feature request

Is it possible to support loading the VLM's like VideoLLama, Chat-UniVi models that can process Videos?
Repository: vscode
Issue: Show removed entries in the settings editor
Labels: feature-request,settings-editor

Testing #217238

For a setting with object type like `files.exclude` we should show the removed entries in the settings editor. Note that an entry can be removed by the extension too.
Repository: vscode
Issue: Show the source of an entry as a separate column
Labels: feature-request,settings-editor

Testing #217238

Show the source of an entry in the object type setting as a separate column instead in hover
Repository: rust
Issue: Compiler hangs and consumes unbounded memory with complex trait bounds
Labels: C-bug,T-types,fixed-by-next-solver

I tried this code:

```rust
trait TraitWithOneGeneric<P> {
    fn method(&self);
}

impl<C, P1, P2> TraitWithOneGeneric<(P1, P2)> for C
where
    C: TraitWithOneGeneric<P1> + TraitWithOneGeneric<P2>,
{
    fn method(&self) {}
}

// Generic instead of impl trait also doesn't work
fn do_smth<P>(a: &&impl TraitWithOneGeneric<P>) {
    a.method(1, 2, 3, 4)
}
```

I expected to see this happen: Code should throw an error and `rustc` should exit (or compile) 

Instead, this happened: `rustc` doesn't exit at all and leaks memory infinitely.

### Meta

I ran this code either on rust [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0e0195f7f122d44d4361a1e1b6bcfe57) or via `rustc --crate-type rlib -v lib.rs`
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.81.0-nightly (6b0f4b5ec 2024-06-24)
binary: rustc
commit-hash: 6b0f4b5ec3aa707ecaa78230722117324a4ce23c
commit-date: 2024-06-24
host: x86_64-unknown-linux-gnu
release: 1.81.0-nightly
LLVM version: 18.1.7
```

Same behavior on stable:
`rustc --version --verbose`:
```
rustc 1.79.0 (129f3b996 2024-06-10)
binary: rustc
commit-hash: 129f3b9964af4d4a709d1383930ade12dfe7c081
commit-date: 2024-06-10
host: x86_64-unknown-linux-gnu
release: 1.79.0
LLVM version: 18.1.7
```
Repository: vscode
Issue: Profile/metadata feedback on testing
Labels: under-discussion,testing

              In Dart, we were already handling debug session ends and calling `.end()` on the test run (whether it was created by VS Code, or by us). We don't seem to have any bugs with stopping debug sessions that are test runs.

However, restart doesn't work great - because it seems to end the test run, then start a new debug session that is not tied to a test run (so you don't get the results recorded). It's not clear to me if your fix here will solve that, but I wonder if there are going to have issues with test runs where VS Code doesn't have all of the related data. We discussed this before in https://github.com/microsoft/vscode/issues/144169#issuecomment-1071143185 about "Test: Rerun Last Run" not working because of this. If we let VS Code handle restarting test runs by just calling `runTests`, I think any context that we weren't able to capture in the `TestRun` won't come back to us, and we'll start a test run with some parameters missing.

_Originally posted by @DanTup in https://github.com/microsoft/vscode/issues/214486#issuecomment-2157937737_
Repository: pytorch
Issue: Dynamo graph breaks on boxed ProcessGroup
Labels: oncall: distributed,triaged,oncall: pt2,module: dynamo

internal [xref](https://fb.workplace.com/groups/1075192433118967/permalink/1449192579052282/)

```
import torch
import torch.distributed as dist

torch.library.define(
    "my_lib::my_function",
    "(Tensor x, __torch__.torch.classes.c10d.ProcessGroup y) -> Tensor"
)

def my_function(x: torch.Tensor, y: dist.ProcessGroup) -> torch.Tensor:
    return torch.empty_like(x)

torch.library.impl("my_lib::my_function", "default", my_function)

@torch.library.impl_abstract("my_lib::my_function")
def my_function_abstract(x, y):
    return torch.empty_like(x)


x = torch.randn((2, 3))
g = torch.distributed.ProcessGroup(0, 0)
boxed_group = g.boxed()

@torch.compile(backend="eager", fullgraph=True)
def f(x, y):
    return torch.ops.my_lib.my_function.default(x, y)


f(x, boxed_group)
```

Fails with:
```
  File "/home/hirsheybar/local/b/pytorch/torch/_dynamo/symbolic_convert.py", line 1470, in CALL_FUNCTION
    self.call_function(fn, args, {})
  File "/home/hirsheybar/local/b/pytorch/torch/_dynamo/symbolic_convert.py", line 754, in call_function
    self.push(fn.call_function(self, args, kwargs))
  File "/home/hirsheybar/local/b/pytorch/torch/_dynamo/variables/torch.py", line 781, in call_function
    *proxy_args_kwargs(args, kwargs),
  File "/home/hirsheybar/local/b/pytorch/torch/_dynamo/utils.py", line 652, in proxy_args_kwargs
    unimplemented(
  File "/home/hirsheybar/local/b/pytorch/torch/_dynamo/exc.py", line 220, in unimplemented
    raise Unsupported(msg) from from_exc
torch._dynamo.exc.Unsupported: call_function args: TensorVariable() UserDefinedObjectVariable(ScriptObject)
```

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @wconstab @yf225 @chauhang @d4l3k @ezyang @anijain2305 @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng
Repository: godot
Issue: Callable.callv() will make call with wrong arguments if a const Array is passed
Labels: bug,topic:gdscript,confirmed

### Tested versions

- Reproducible in 4.3.beta2.official [b75f0485b]

### System information

Windows 10 - Godot 4.3.beta2.official [b75f0485b]

### Issue description

Using Callable().callv() will result in a call using the wrong arguments, if the Array being passed is a const.
The bug does not occur if the Array being passed is a var.
The bug does not occur if we use Callable().bindv().call() instead.

### Steps to reproduce

The following code can demonstrate the bug. The debugger does not show any errors or warnings.
```extends Node2D

const arr_const = ['one','two','three','four']
var arr_var = ['one','two','three','four']

func _ready() -> void:
	# non-const works
	somefunc.callv(arr_var)
	# const fails
	somefunc.callv(arr_const)
	# temporary workaround
	somefunc.bindv(arr_const).call()
	
func somefunc(v1,v2,v3,v4):
	print('%s,%s,%s,%s'% [v1,v2,v3,v4])
```
will print:
```
one,two,three,four
four,four,four,four
one,two,three,four
```
The first and third calls work as expected, with the four arguments in the arrays.
Only the second call, which used a const Array and .callv(), made a call with all arguments replaced by the last argument.

In this example, I use a function directly, but this can be reproduced with any Callable().

This seems like a similar issue as #69237, with a similar workaround, but in this case the correct number of arguments was passed.


### Minimal reproduction project (MRP)

[callablecheck.zip](https://github.com/user-attachments/files/15974691/callablecheck.zip)
Repository: TypeScript
Issue: Suspected breaking change with pushing and assigning a 'derived' value into a 'base' array
Labels: Help Wanted,Possible Improvement

### 🔎 Search Terms

inline assignment array derived base push 'Object literal may only specific known properties' 

### 🕗 Version & Regression Information

- This changed between versions 4.9.5 and 5.0.4

### ⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.0.4#code/JYOwLgpgTgZghgYwgAgEJwM4oN4FgBQyywAJgFzIgCuAtgEbQDcBAvgQaJLIigCLTAAbhBLIIAD0ggSGNJhwEiIODQgUMYKKADmzfG3wEEAexAbikGhgrosAbQC6yALzJHeggBsIYCxBoAjBT8WsIket6+wJYATMECYR740f4BLsjYxOTIAQA0lCpqyADkYAAWwLKVyMYA1shQENpwUCTeGBjFyCx6KVYAdAAOVBhlABR9AQCUSX0YQyPjE7HpmaQUMfnKqhSlFVWyAHIA8gAqNfWgyACs-QAM-QAs+XRUUbJ1xCDIj-0AnP1rl0WFMZkA

### 💻 Code

```ts
interface Base {
  id: number;
}

interface Derived extends Base {
  name: string;
}

const items: Base[] = [];

let item1: Derived;
let item2: Derived;

item1 = { id: 1, name: 'this is ok regardless' };
items.push(item1);

items.push((item2 = { id: 2, name: 'this is NOT ok in 5.0.4, but is ok in 4.9.5' }));
```


### 🙁 Actual behavior

'Object literal may only specific known properties' error 

### 🙂 Expected behavior

The code should not produce an error

### Additional information about the issue

It is possible that this is a change to the order in which types are inferred, but I have been unable to find any details in the documentation/changelog.
Repository: vscode
Issue: Incorrect editor scroll position when moving between stack frames after hitting exception
Labels: bug,editor-core

<!-- ⚠️⚠️ 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?: not applicable

<!-- 🪓 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.90.2
- OS Version: macOS 14.2.1

Steps to Reproduce:

1. The bug happens only when the editor height is small. Adjust the editor height to be small either by opening the bottom panel and enlarging it, or by making the whole VSCode window small.
2. Start debugging a Python app, and hit a runtime exception. Execution is paused. Exception details are overlayed in the editor. 
3. In the Call Stack panel, click the second stack frame. A code editor opens, but here is the bug: the correct line is not revealed.
4. Click again the second stack frame. Now the correct line is revealed.

Notes:
1. I think this happens for all languages, not just Python. But I didn't test it.
2. It seems to be a wrong calculation of the editor scroll position, maybe affected by the exception details overlay. It does not happen when transitioning between e.g. the 2nd and 3rd stack frames. Only when transitioning from the 1st stack frame to another stack frame.
3. It happened to me during a remote debug session, but it is probably reproducible on a local session too.

See attached video:

https://github.com/microsoft/vscode/assets/5028956/4201df85-391b-4a3b-b2ce-ec4fca9fa65f
Repository: go
Issue: x/benchmarks: monitor toolchain binary size
Labels: NeedsFix,compiler/runtime

Follow-up to #68109, it would be nice if we tracked the size of the toolchain binaries (or the entire archive).

We already track binary size of a bunch of tests on https://perf.golang.org/dashboard via bent, but none of the toolchain binaries themselves (compile, addr2line, etc).

cc @mknyszek @dr2chase
Repository: vscode
Issue: Issue Reporter doesn't respect underline setting
Labels: bug,issue-reporter

Testing #217636

Help > Report Issue

Expect `Review the guidance we provide` and the `show` links at the bottom to be underlined:

![Image](https://github.com/user-attachments/assets/98a25985-9599-4780-a98b-49f657737cd4)
Repository: vscode
Issue: Support word wrap in notebook diff editor
Labels: feature-request,notebook-diff

github notebook diffs on vscode.dev could be improved as they display all text in a single line per cell instead of the auto-indentation which happens in the regular editor
<img width="1644" alt="Screenshot 2024-06-25 at 11 37 39 AM" src="https://github.com/microsoft/vscode/assets/26030610/d22122ee-c673-460a-a3a9-c61619ccade6">
<img width="1645" alt="Screenshot 2024-06-25 at 11 37 32 AM" src="https://github.com/microsoft/vscode/assets/26030610/896597e3-9c7b-407e-ad93-8ce8a294c6ca">