sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Incorrect terminal.creationOptions.shellPath on window reload
Labels: confirmation-pending,terminal-persistence

<!-- ⚠️⚠️ 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

<!-- 🪓 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.94.0
- OS Version: macOS Sonoma 14.4, Windows 11

Steps to Reproduce:

1. Create multiple terminals with different shells
2. Log their `terminal.creationOptions.shellPath` which should be correct (or sometimes unpopulated)
3. Reload the window, existing terminals get restored
4. Log their `terminal.creationOptions.shellPath` which will all show the shell path of the default shell

This is particularly bad on Windows where a Powershell terminal may be reported as using a `bash.exe` shell path or vice versa.
Repository: ollama
Issue: mistral-nemo - context window 1024000?
Labels: bug

### What is the issue?

model_name='mistral-nemo'
ollama.show(model_name)['modelinfo']

{'general.architecture': 'llama',
 'general.basename': 'Mistral-Nemo',
 'general.file_type': 2,
 'general.finetune': 'Instruct',
 'general.languages': ['en', 'fr', 'de', 'es', 'it', 'pt', 'ru', 'zh', 'ja'],
 'general.license': 'apache-2.0',
 'general.parameter_count': 12247782400,
 'general.quantization_version': 2,
 'general.size_label': '12B',
 'general.type': 'model',
 'general.version': '2407',
 'llama.attention.head_count': 32,
 'llama.attention.head_count_kv': 8,
 'llama.attention.key_length': 128,
 'llama.attention.layer_norm_rms_epsilon': 1e-05,
 'llama.attention.value_length': 128,
 'llama.block_count': 40,
 'llama.context_length': 1024000, <<<<<
 'llama.embedding_length': 5120,
 'llama.feed_forward_length': 14336,
 'llama.rope.dimension_count': 128,
 'llama.rope.freq_base': 1000000,
 'llama.vocab_size': 131072,
 'tokenizer.ggml.add_bos_token': True,
 'tokenizer.ggml.add_eos_token': False,
 'tokenizer.ggml.add_space_prefix': False,
 'tokenizer.ggml.bos_token_id': 1,
 'tokenizer.ggml.eos_token_id': 2,
 'tokenizer.ggml.merges': None,
 'tokenizer.ggml.model': 'gpt2',
 'tokenizer.ggml.pre': 'tekken',
 'tokenizer.ggml.token_type': None,
 'tokenizer.ggml.tokens': None,
 'tokenizer.ggml.unknown_token_id': 0}

Shouldn't it be 128k instead of 1M+?

### OS

Windows

### GPU

Nvidia

### CPU

Intel

### Ollama version

0.5.4
Repository: transformers
Issue: Unknown quantization type, got fp8
Labels: bug

### System Info

- `transformers` version: 4.47.1
- Platform: macOS-15.1.1-arm64-arm-64bit
- Python version: 3.10.16
- Huggingface_hub version: 0.27.0
- Safetensors version: 0.4.5
- Accelerate version: 1.2.1
- Accelerate config: 	not found
- PyTorch version (GPU?): 2.5.1 (False)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed

### Who can help?

@SunMarc @MekkCyber

### Information

- [ ] The official example scripts
- [X] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [X] My own task or dataset (give details below)

### Reproduction

Issue arises when using AutoModelForCasualLM.from_pretrained()

The model used is `"deepseek-ai/DeepSeek-V3"`

  File "/Users/ruidazeng/Demo/chatbot.py", line 13, in init
    self.model = AutoModelForCausalLM.from_pretrained(
  File "/opt/anaconda3/envs/gaming-bot/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py", line 559, in from_pretrained
    return model_class.from_pretrained(
  File "/opt/anaconda3/envs/gaming-bot/lib/python3.10/site-packages/transformers/modeling_utils.py", line 3659, in from_pretrained
    config.quantization_config = AutoHfQuantizer.merge_quantization_configs(
  File "/opt/anaconda3/envs/gaming-bot/lib/python3.10/site-packages/transformers/quantizers/auto.py", line 173, in merge_quantization_configs
    quantization_config = AutoQuantizationConfig.from_dict(quantization_config)
  File "/opt/anaconda3/envs/gaming-bot/lib/python3.10/site-packages/transformers/quantizers/auto.py", line 97, in from_dict
    raise ValueError(
ValueError: Unknown quantization type, got fp8 - supported types are: ['awq', 'bitsandbytes_4bit', 'bitsandbytes_8bit', 'gptq', 'aqlm', 'quanto', 'eetq', 'hqq', 'compressed-tensors', 'fbgemm_fp8', 'torchao', 'bitnet']


### Expected behavior

This starts working when I manually reverted back to transformers (4.37.2), which has better compatibility with newer quantization methods.
Repository: pytorch
Issue: [Mac/M1] torch.compile() -- expm1 returns an inaccurate result compared to the interpreted version
Labels: oncall: pt2,oncall: cpu inductor

### 🐛 Describe the bug

Input:

```
davidino@davidino-mbp pytorch % cat /tmp/repro.py 
import torch

class Model(torch.nn.Module):

    def __init__(self):
        super().__init__()

    def forward(self, x):
        x = torch.floor(x)
        x = torch.angle(x)
        x = torch.sin(x)
        s = torch.positive(x)
        return torch.expm1(x)

func = Model().to('cpu')

x = torch.tensor([ 0.7076383233070374,  0.2585877180099487, -0.1782233268022537,
        -0.0771917924284935, -1.8218737840652466, -0.6442450284957886,
        -1.0207887887954712,  0.7611123919487000,  0.9056779742240906,
         1.7948490381240845])

pata = func(x.clone())
print(pata)
func1 = torch.compile(func, fullgraph=True)
tino = func1(x.clone())
print(tino)
print(torch.allclose(pata, tino, equal_nan=True))
print(torch.__version__)
```

Output:

```
davidino@davidino-mbp pytorch % python /tmp/repro.py
tensor([ 0.0000e+00,  0.0000e+00, -8.7423e-08, -8.7423e-08, -8.7423e-08,
        -8.7423e-08, -8.7423e-08,  0.0000e+00,  0.0000e+00,  0.0000e+00])
tensor([ 0.0000e+00,  0.0000e+00, -5.9605e-08, -5.9605e-08, -5.9605e-08,
        -5.9605e-08, -5.9605e-08,  0.0000e+00,  0.0000e+00,  0.0000e+00])
False
2.6.0a0+gitf3e5078
```

### Versions

Collecting environment information...
PyTorch version: 2.6.0a0+gitf3e5078
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 15.1.1 (arm64)
GCC version: Could not collect
Clang version: 16.0.0 (clang-1600.0.26.4)
CMake version: version 3.27.8
Libc version: N/A

Python version: 3.12.7 | packaged by Anaconda, Inc. | (main, Oct  4 2024, 08:22:19) [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-15.1.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1 Pro

Versions of relevant libraries:
[pip3] flake8==7.0.0
[pip3] mypy==1.11.2
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.26.4
[pip3] numpydoc==1.7.0
[pip3] optree==0.13.1
[pip3] torch==2.6.0a0+gitf3e5078
[conda] numpy                     1.26.4          py312h7f4fdc5_0  
[conda] numpy-base                1.26.4          py312he047099_0  
[conda] numpydoc                  1.7.0           py312hca03da5_0  
[conda] optree                    0.13.1                   pypi_0    pypi
[conda] torch                     2.6.0a0+gitf3e5078           dev_0    <develop>

cc @kulinseth @albanD @malfet @DenisVieriu97 @jhavukainen @chauhang @penguinwu
Repository: godot
Issue: Internal Script Error: Opcode 0 (Please report) when using CACHE_MODE_IGNORE_DEEP with ResourceLoader.load()
Labels: bug,topic:gdscript,topic:editor

### Tested versions

Godot version: 4.3.stable

### System information

Godot v4.3.stable - Windows 10.0.26100 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3060 (NVIDIA; 32.0.15.6636) - 12th Gen Intel(R) Core(TM) i7-12700F (20 Threads)

### Issue description

Got an internal script error Opcode 0 and it is requested that I report it so I'm reporting it. Here's the image.

![Image](https://github.com/user-attachments/assets/9bce3a17-4a14-4258-be1c-2977720e45c4)
![Image](https://github.com/user-attachments/assets/1a7c55a0-1874-41ab-be7b-f7395c907930)


### Steps to reproduce

Use ResourceLoader.load(..., CACHE_MODE_IGNORE_DEEP) to load the same Resource at least twice.

### Minimal reproduction project (MRP)

MRP attached
[opcode-0-bug.zip](https://github.com/user-attachments/files/18283798/opcode-0-bug.zip)

Update: it appears to be related to the cach_mode I was using with ResourceLoader. Loading the resource a second time causes the issue. My understanding is that my use case should be valid but correct me if I misunderstood.
Repository: pytorch
Issue: Torch.sparse.mm failing gradient computation at half precision.
Labels: module: sparse,triaged,module: half

### 🐛 Describe the bug

When using torch.autocast, torch.sparse.mm(sparse_csr_tensor, dense_tensor) fails on the gradient computation with an unhelpful error. Half precision matrix multiplication with csr tensors was completed here https://github.com/pytorch/pytorch/issues/41069. 

Simple reproduction: 
```
weight = torch.rand(5, 4, device = "cuda", dtype = torch.float32)
weight = (weight * (weight < 0.2)).to_sparse_csr().requires_grad_(True)
inp = torch.rand(4, 3, device = "cuda", dtype = torch.float32, requires_grad = False)
with torch.autocast("cuda", dtype = torch.float16, enabled = True):
	loss = torch.sparse.mm(weight, inp).sum()
loss.backward()
```

```
RuntimeError: sampled_addmm: Expected mat1 and mat2 to have the same dtype, but got Half and Float
```

Furthermore, if one tries to convert to half precision manually like below, they receive: 
```
weight = torch.rand(5, 4, device = "cuda", dtype = torch.float32)
weight = (weight * (weight < 0.2)).to_sparse_csr().requires_grad_(True).half()
inp = torch.rand(4, 3, device = "cuda", dtype = torch.float32, requires_grad = False).half()
loss = torch.sparse.mm(weight, inp).sum()
loss.backward()
```
```
RuntimeError: "sampled_addmm_out_sparse_csr" not implemented for 'Half'
```

### Versions

torch==2.6.0.dev20241231+cu124
and 
torch==2.5.1 (with cu124)


cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer @jcaip
Repository: rust
Issue: Tracking issue for RFC 3722: Explicit ABIs in `extern`
Labels: T-lang,C-tracking-issue,F-explicit_extern_abis

This is a tracking issue for:

- https://github.com/rust-lang/rfcs/pull/3722

The feature gate for the issue is `#![feature(explicit_extern_abis)]`.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.  They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.  A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.  Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps

- [x] Accept an RFC.
  - https://github.com/rust-lang/rfcs/pull/3722
- [x] Add migration lint.
  - https://github.com/rust-lang/rust/pull/132357
- [x] Make and FCP the change to warn-by-default in all editions.
  - https://github.com/rust-lang/rust/pull/132397
- [ ] Make this a hard error in the next edition on nightly under a feature flag.
  - Blocked on finalizing the name and timing of the next edition.
  - https://github.com/rust-lang/rust/pull/135340
- [ ] Add documentation to the [dev guide][].
  - See the [instructions][doc-guide].
- [ ] Add documentation to the [reference][].
  - See the [instructions][reference-instructions].
- [ ] Add formatting for new syntax to the [style guide][].
  - See the [nightly style procedure][].
- [ ] Stabilize on nightly on the next edition.
  - See the [instructions][stabilization-instructions].

[dev guide]: https://github.com/rust-lang/rustc-dev-guide
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs
[edition guide]: https://github.com/rust-lang/edition-guide
[nightly style procedure]: https://github.com/rust-lang/style-team/blob/master/nightly-style-procedure.md
[reference]: https://github.com/rust-lang/reference
[reference-instructions]: https://github.com/rust-lang/reference/blob/master/CONTRIBUTING.md
[stabilization-instructions]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[style guide]: https://github.com/rust-lang/rust/tree/master/src/doc/style-guide

### Unresolved Questions

None.

### Related

TODO.

### Implementation history

TODO.
Repository: vscode
Issue: [Accessibility, a11y] Color contrast ratio of tree view `description` text is 4.381:1 which is less than 4.5:1
Labels: bug,themes,accessibility

<!-- ⚠️⚠️ 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. -->

<!-- 🪓 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.97.0-insider
- OS: Windows
- Color Theme: Dark+ (Default Dark+)

This issue is being escalated from here: https://github.com/microsoft/vscode-azurefunctions/issues/4332

## Steps to Reproduce:

1.  Install the Azure Resources extension `ms-azuretools.vscode-azureresourcegroups`
2. Click on the `Azure` tab
3. Observe the "`Remote`" description in the `Resources` tree view

![Image](https://github.com/user-attachments/assets/1d367b22-087d-4448-ba88-694c984ce751)

## Actual:
Color contrast ratio of tree view's `description` text is 4.381:1 which is less than 4.5:1

## Expected:
Color contrast ratio of tree view's `description` text should be greater than or equal to 4.5:1

This should reproduce for any tree view description in default dark mode.
Repository: godot
Issue: Bug: MultiMesh uses_colors error vs use_colors property
Labels: topic:core,topic:rendering

### Tested versions

4.3 dev

### System information

Godot v4.3.stable - Windows 10.0.22631 - GLES3 (Compatibility) - NVIDIA GeForce RTX 4050 Laptop GPU (NVIDIA; 32.0.15.6070) - Intel(R) Core(TM) Ultra 7 155H (22 Threads)

### Issue description

Keep getting an error message using colors because its looking for the wrong property.
Following this tutorial:
https://docs.godotengine.org/en/stable/classes/class_multimesh.html#class-multimesh-property-use-colors

```
E 0:00:04:0397   game.tscn::GDScript_a3sjo:43 @ _ready(): Condition "!multimesh->uses_colors" is true.
  <C++ Source>   drivers/gles3/storage/mesh_storage.cpp:1714 @ multimesh_instance_set_color()
  <Stack Trace>  game.tscn::GDScript_a3sjo:43 @ _ready()
```

### Steps to reproduce

Create multimesh and enable `use_colors` and then set instance colors.


### Minimal reproduction project (MRP)

Official tutorial does it if you just switch on `use_colors`
https://docs.godotengine.org/en/stable/classes/class_multimesh.html#class-multimesh-property-use-colors
Repository: material-ui
Issue: [docs] Update "Unstyled" sections to point to new Base UI package
Labels: docs,priority: important,package: base-ui

### Related page

https://mui.com/material-ui/react-select/#unstyled

### Kind of issue

Other

### Issue description

Material UI components with Base UI equivalents have an "Unstyled" section in their component docs to direct users to the latter if they need them. With mui/base-ui now replacing the older legacy package in the material-ui repo, these links and descriptions should be updated to point to the new library.

The only question is when to do it. ASAP? Or should it coincide with a later milestone for Base UI—beta or stable release?

**Search keywords**: unstyled, base ui, docs
Repository: godot
Issue: Mathf.SmoothStep summary description could be improved
Labels: enhancement,documentation,topic:dotnet

I was using the summary description of SmoothStep to help me produce a smoother movement animation between two points, but it seems to work quite differently to how I'd expect it to. I was assuming that I'd use it the same way as Lerp but with a faster result at the beginning and slower at the end.

I can see the power in the method now (thanks kleonc for helping me get my head around how it works). It'd be nice for someone to update the description to better clarify it's use.

https://github.com/godotengine/godot/blob/2582793d408ade0b6ed42f913ae33e7da5fb9184/modules/mono/glue/GodotSharp/GodotSharp/Core/Mathf.cs#L1595-L1612
Repository: rust
Issue: Include Stabilization version in the tracking issue template
Labels: C-enhancement,A-docs,A-meta

### Location

- Tracking issues
- RFCs
- Stabilization Issues
- Unstable book
- Compiler error messages

### Summary

In a CI build against my crate's declared MSRV, I get this build failure:

```
error[E0658]: lint reasons are experimental
  --> webfinger-rs/src/types/rel.rs:6:1
   |
6  | / #[nutype(derive(
7  | |     Debug,
8  | |     Display,
9  | |     Clone,
...  |
19 | |     Eq,
20 | | ))]
   | |___^
   |
   = note: see issue #54503 <https://github.com/rust-lang/rust/issues/54503> for more information
   = note: this error originates in the attribute macro `nutype` (in Nightly builds, run with -Z macro-backtrace for more info)
```
The fix for this is to bump my MSRV, which I'm fine with doing. But the process for finding what version this feature was introduced in is convoluted and doesn't have any path from the error message. A good place for that information to live would the in the first comment of the tracking issue link. Adding the info to the RFC and stabilization issue would be nice too. The only place where this is recorded currently is the rust blog https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html#lint-reasons

Obviously this is just one case, but it's something I've seen happen a few times. The underlying goal of this issue is that the link to the tracking issue is not a dead end for fixing the issue, but instead contains enough information to fix immediately.
Repository: godot
Issue: Texture2D's has_alpha() function returns false regardless of whether the image has an alpha channel
Labels: discussion,topic:core,documentation

### Tested versions

v4.3.stable.official [77dcf97d8]
v4.4.dev7.official [46c8f8c5c]
v4.2.2.stable.official [15073afe3]
v4.0.stable.official [92bee43ad]

### System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated AMD Radeon RX 5700 XT (Advanced Micro Devices, Inc.; 32.0.12019.1028) - 12th Gen Intel(R) Core(TM) i5-12400F (12 Threads)

### Issue description

I'm using a script to determine whether the albedo texture has an alpha channel and then set the transparency mode of the material based on that. 
I have a ```Texture2D``` that I can verify as having an alpha channel, because of the editor preview, and through viewing the channels individually in GIMP. However, when I call ```has_alpha()``` on it, the function still returns ```false``` when I expect it to return ```true```.
This issue happens regardless if the texture is ```.png``` or ```.webp```

### Steps to reproduce

1. Export a ```Texture2D``` variable from a script
2. Set the variable to an imported texture known to have an alpha channel
3. Use the script to call ```has_alpha()``` on the ```Texture2D``` variable
4. Inspect the return value which will erroneously be ```false```

### Minimal reproduction project (MRP)

[Alpha Detection Test.zip](https://github.com/user-attachments/files/18284212/Alpha.Detection.Test.zip)
Repository: flutter
Issue: Triage process self-test
Labels: team-codelabs,team-infra,team-ecosystem,P2,team-release,team-news,team-android,triaged-android,triaged-codelabs,team-design,triaged-design,triaged-ecosystem,team-engine,triaged-engine,team-framework,triaged-framework,team-go_router,triaged-go_router,triaged-infra,team-ios,triaged-ios,team-tool,triaged-tool,team-web,triaged-web,team-games,triaged-games,team-text-input,triaged-text-input,team-macos,triaged-macos,team-windows,triaged-windows,team-linux,triaged-linux,team-accessibility,triaged-accessibility

This is a test of our triage processes.

Please handle this issue the same way you would a normal valid but low-priority issue.

For more details see https://github.com/flutter/flutter/wiki/Triage
Repository: neovim
Issue: C-c closes the command line window with multigrid
Labels: bug,ui,ui-extensibility,display,cmdline-mode

### Problem

The commandline window is closed instead of just moving to the command line when pressing `C-c` with multigrid clients. This is especially bad when a popup window is visible, since the cursor will then also be placed in the wrong place.

### Steps to reproduce

1. launch an UI client with multigrid support, like Neovide `neovide -- --clean`
2. open the command line window `q:`
3. Press `C-c`

Observe that the command line window is closed


### Expected behavior

The cursor should move to the command line without closing the window.

### Nvim version (nvim -v)

NVIM v0.10.3

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

N/A

### Operating system/version

Linux

### Terminal name/version

Neovide 0.13.3

### $TERM environment variable

alacritty

### Installation

pacman