sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: [Bug]: Vitest/Test Addon doesn't work if space in path
Labels: bug,windows,addon: test

### Describe the bug

If your project is in a folder that has a space in it, Vitest cannot find your tests. This may be a bug with Vitest but since it gives a specific error for Storybook I'll log it here. This could be windows only, unsure. 

Create any Storybook project, with the test addon as described here : https://storybook.js.org/docs/writing-tests/test-addon
Ensure that the path is something like c:\my projects\storybook\src with a space somewhere in the path

When I execute npm run test, I get the following error for *all* stories. Note that I do not have any specific spec/test files, at this stage I'm just using it as a smoke test. 

```
Error: No test suite found in file C:/my projects/storybook/src/stories/global/popover/popover.stories.tsx
```

If I remove the space in "my projects" the tests all run fine. 

I'm not sure if this should be added to the docs because it is "true" that I do not have specific test suite files in those files (They are simply stories), so I thought maybe I had to write specific spec files etc. 

### Reproduction link

http://no.com

### Reproduction steps

_No response_

### System

Storybook Environment Info:

  System:
    OS: Windows 10 10.0.19045
    CPU: (12) x64 12th Gen Intel(R) Core(TM) i5-1245U
  Binaries:
    Node: 20.10.0 - C:\Node\node-v20.10.0-win-x64\node.EXE
    npm: 10.2.3 - C:\Node\node-v20.10.0-win-x64\npm.CMD <----- active
  Browsers:
    Edge: Chromium (128.0.2739.42)
  npmPackages:
    @storybook/addon-a11y: ^8.4.2 => 8.4.2
    @storybook/addon-essentials: ^8.4.2 => 8.4.2
    @storybook/addon-links: ^8.4.2 => 8.4.2
    @storybook/blocks: ^8.4.2 => 8.4.2
    @storybook/experimental-addon-test: ^8.4.2 => 8.4.2
    @storybook/react: ^8.4.2 => 8.4.2
    @storybook/react-vite: ^8.4.2 => 8.4.2
    @storybook/test: ^8.4.2 => 8.4.2
    @storybook/test-runner: ^0.19.1 => 0.19.1
    eslint-plugin-storybook: ^0.11.0 => 0.11.0
    storybook: ^8.4.2 => 8.4.2

### Additional context

_No response_
Repository: deno
Issue: deno fmt: different configuration per language type
Labels: deno fmt,config

I would like to format my yaml files different than my typescript code. For example, I'd like to use different indentation level.
In Prettier, it's possible by using:

```json
{
    "tabWidth": 4,
    "overrides": [
        {
            "files": [".yaml"],
            "options": {
                "tabWidth": 2
            }
        }
    ]
}
```

It seems it's currently not possible to achieve in deno.json file.
Repository: ollama
Issue: Linux ollama 0.4.0, 0.4.2, 0.4.5, 0.5.0 custom compile for AMD ROCm fails missing ggml_rocm in go compile
Labels: bug,build

### What is the issue?

Report date: 2024-11-07

During a custom compile of ollama 0.4.0 on Linux (POP OS 22.04) for AMD ROCm GPUs (AMD 6650 GPU), the initial compile works. 

However, when trying to execute the go compile, the compile fails after about two minutes citing exit code 1 and saying the error is unable to find ggml_rocm.

ROCm 6.0

### OS

Linux

### GPU

AMD

### CPU

AMD

### Ollama version

0.4.0
Repository: flutter
Issue: [Impeller] Implement OpenGLES multisampling without render to texture extension.
Labels: P2,e: impeller,team-engine,triaged-engine,e: opengl

Currently the OpenGL backend uses an ES multisampling extension. We should also support "regular" desktop OpenGL multisampling via creating multisampled textures/render buffers and performing the blit resolve ourselves.
Repository: deno
Issue: Short flag `-w` for `--watch`
Labels: suggestion,--watch

Small quality-of-life improvement, but it'd be handy if the `--watch` option for `deno run`, `deno test`, etc. could be supplied as `-w`. At least for me, it's easily the single most common CLI option I use (certainly more common than `-c`, `-q`, or `-r`, which all get their own short flags).
Repository: excalidraw
Issue: Canvas panning on the right mouse button
Labels: enhancement

I need to move the canvas with the right mouse button; the middle mouse button is very inconvenient. Thanks!
Repository: pytorch
Issue: Building PyTorch from source fails when magma.h is in /usr/include
Labels: module: build,triaged,module: magma

### 🐛 Describe the bug

Building PyTorch from source fails when `magma.h` from libmagma2 is in `/usr/include` instead of a non-standard directory.

Breakage is:

```
In file included from /usr/include/c++/10/bits/stl_algo.h:59,
                 from /usr/include/c++/10/functional:65,
                 from /builds/py3ps/pytorch/c10/core/Allocator.h:5,
                 from /builds/py3ps/pytorch/aten/src/ATen/detail/CUDAHooksInterface.h:3,
                 from /builds/py3ps/pytorch/aten/src/ATen/cuda/detail/CUDAHooks.h:3,
                 from /builds/py3ps/pytorch/aten/src/ATen/cuda/detail/CUDAHooks.cpp:1:
/usr/include/c++/10/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
   75 | #include_next <stdlib.h>
      |               ^~~~~~~~~~
```

Commenting out these three lines seems to fix the issue:
https://github.com/pytorch/pytorch/blob/81d077cca2aacaf107afdefcd2e0292a95d2671b/caffe2/CMakeLists.txt#L986-L988

It seems those three lines are a workaround for an issue when `magma.h` lives on a non-standard directory, but then it fails when it lives in the standard include directory.

Can we have a fix for the cmake config that would take that into account? For now I'm patching the tree to comment out these lines, but it would be nice if I didn't have to maintain this downstream patch. Thanks!


### Versions

Collecting environment information...
PyTorch version: 2.2.1+cu12.xyz
Is debug build: False
CUDA used to build PyTorch: 12.2
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: Could not collect
CMake version: version 3.25.1
Libc version: glibc-2.31

Python version: 3.10.13 (main, Apr  4 2024, 19:12:22) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-6.6.43-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: LAZY

Nvidia driver version: 555.42.02
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.9.7

HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                         x86_64

Versions of relevant libraries:
[pip3] flake8==6.0.0
[pip3] gpytorch==1.13
[pip3] msgpack-numpy==0.4.8
[pip3] mypy==1.10.1
[pip3] mypy-extensions==1.0.0
[pip3] mypy-protobuf==3.2.0
[pip3] numpy==1.23.2
[pip3] numpyro==0.10.1
[pip3] pytorch-lightning==2.4.0
[pip3] torch==2.2.1+cu12.xyz
[pip3] torchmetrics==1.4.2
[pip3] triton==2.2.0
[conda] Could not collect


cc @malfet @seemethere
Repository: pytorch
Issue: Add Android Support (Python Wheel)
Labels: module: binaries,feature,triaged,module: android

### 🚀 The feature, motivation and pitch

Now that Python 3.13 has official support for Android, it would be great to have an Android wheel for PyTorch.

There’s a project called Chaquopy that has been manually patching libraries like PyTorch, and there’s currently an outstanding request for adding an updated wheel (so I figured I should bring the request to the official devs): https://github.com/chaquo/chaquopy/issues/1215

### Alternatives

_No response_

### Additional context

_No response_

cc @seemethere @malfet @osalpekar @atalman
Repository: godot
Issue: Reverb "Damp" parameter values don't match description.
Labels: bug,documentation,topic:audio

### Tested versions

Godot 4.3 .Net

### System information

Win10 x64 22H2

### Issue description

"Damp" parameter says it measures how reflective the reverb is.
0 Damping should imply full reflectivity AKA no damping
1 Damping should imply no reflectivity AKA full damping.

Right now, 0 Damping performs no reflectivity AKA full damping. 1 Damping performs full reflectivity AKA no damping.

Solution: Invert values and keep current description OR keep current values and change Damping to Reflectiveness.

### Steps to reproduce

n/a

### Minimal reproduction project (MRP)

n/a
Repository: pytorch
Issue: upsample_bilinear backward is super slow in bf16 as compared to fp32
Labels: needs reproduction,module: performance,module: nn,module: cuda,triaged

### 🐛 Describe the bug

backward of upsample_bilinear is super slow in bf16 as compared to fp32, may you please help check why? Thanks in advance.


following is the test case:
```python
import torch
import torch.nn as nn
import time

class MyModel(nn.Module):
    def __init__(self):
        super(MyModel, self).__init__()
        self.conv = nn.Conv2d(3, 1024, 3, padding=1)
        self.upsample = nn.Upsample(scale_factor=2, mode='bilinear', align_corners=True)

    def forward(self, x):
        x = self.conv(x)
        x = self.upsample(x)
        return x


def profile_forward_backward(model, input_data, dtype):
    model = model.to('cuda')
    input_data = input_data.to('cuda').to(dtype)
    optimizer = torch.optim.SGD(model.parameters(), lr=0.01)

    for _ in range(10):  
        optimizer.zero_grad()
        with torch.autocast(device_type='cuda', dtype=dtype):
            output = model(input_data)
            loss = output.mean()
        loss.backward()
        optimizer.step()
    print("finish warm-up")

    start_time = time.time()
    for _ in range(1000):  
        optimizer.zero_grad()
        with torch.autocast(device_type='cuda', dtype=dtype):
            output = model(input_data)
            loss = output.mean()
        loss.backward()
        optimizer.step()
    end_time = time.time()
    elapsed_time = end_time - start_time
    print(f"{dtype} - Forward and backward time: {elapsed_time} seconds")


model = MyModel()
input_data = torch.randn(1, 3, 32, 32)

profile_forward_backward(model, input_data, torch.bfloat16)

profile_forward_backward(model, input_data, torch.float32)
```

results: 
finish warm-up
torch.bfloat16 - Forward and backward time: 5.045899152755737 seconds
finish warm-up
torch.float32 - Forward and backward time: 0.5555577278137207 seconds

after profiling it further, we found that it is backward become slow, forward is quite close.


### Versions

pytorch2.3.0-py3.10-cudnn8-cuda12.3

cc @msaroufim @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @ptrblck
Repository: godot
Issue: FogVolume incorrectly culls nearby faces when looking "inward".
Labels: bug,topic:rendering

### Tested versions

Reproducible in 4.3 stable mono, 4.2.2 stable mono, 4.0 stable
Its been here the entire time

### System information

Godot v4.3.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; 32.0.15.6094) - Intel(R) Core(TM) i5-10600KF CPU @ 4.10GHz (12 Threads)

### Issue description

If a camera is within the "bounds" of a face of a fog volume and looks "inward" away from that face, the area of fog between the camera and that face will not be rendered creating a very obvious discontinuity; https://www.youtube.com/watch?v=7L5AhYp65Ec
This effect only occurs if the camera is close to the face that will be skipped. For a cube this region is quite small (https://www.youtube.com/watch?v=f6VrGqzpAyo) and can be mitigated significantly with edge fade, however the size of this region appears to be a function of the ratio between the length of each sides. For a very long or wide volume, this "error region" can extend all the way to the centre and fill the entire box creating extreme artifacts; https://www.youtube.com/watch?v=Lu84S4dGf5Q

for the sake of being verbose, my real world use case where I run into this bug is trying to create a a fog layer with mountains peeking out of them. Looks beautiful almost right out of the box when viewed from outside, my compliments to the ~~chefs~~ technical artists.
![fog1](https://github.com/user-attachments/assets/50af0f49-65e4-48a1-b1fa-d76b40b6804b)
however when viewed from within, the top and bottom of the frame are heavily culled depending on if you are looking down or up
![fog2](https://github.com/user-attachments/assets/00aa4b4a-094d-4f9b-adc6-3291e14d67dd)
![fog3](https://github.com/user-attachments/assets/1202762f-e3fd-41bf-a924-eaff78d5fdc2)

Currently to get around this I will have to make the fog volume extend as high as it is wide, or use a global volume, wasting many unnecessary frames.

This issue occurs on low (64x64) and high (512x512) sample resolutions, with procedural and shader fog materials (said shader directly set the density to a uniform value), and with all volume shapes except world.

I have been using terms like culling and occlusion in this report, I am using these to describe the visuals as I see them; I have no idea what process is causing it

### Steps to reproduce

open the reproduction project, and position the editor camera near the inside boundary of the fog volume.
oscillate between looking inwards and outwards to observe the cutoff. The camera already in the scene is in the right place and has a script for looking around attached to test in play mode. See the videos for specific.s
https://www.youtube.com/watch?v=Lu84S4dGf5Q
https://www.youtube.com/watch?v=7L5AhYp65Ec
https://www.youtube.com/watch?v=f6VrGqzpAyo

### Minimal reproduction project (MRP)

https://github.com/NatCracken/godot_fog_reproduction
was made in a mono build, but does not use any c#
Repository: pytorch
Issue: Support Joinable loss functions with DDP
Labels: oncall: distributed

### 🚀 The feature, motivation and pitch

I'm working on a loss function that requires synchronizing a buffer across workers, and that **isn't** recoverable by a custom reduction of gradients across workers (which is already achievable through DDP's `register_comm_hook`).

I would like it to also work with the `Join` context manager for handling uneven dataloader lengths, i.e. make the loss function a `Joinable`.

As of today, DDP only has a single `JoinHook` that shadows any operations in **both its forward and backward passes**. Note that DDP does indeed perform some distributed operations in its forward pass, namely `_check_global_requires_backward_grad_sync` in `def _pre_forward`.

Since the loss function's forward must operate _after_ the model's forward pass and _before_ the model's backward pass, there is no ordering of joinables to `Join` (either `[ddp_model, loss]` or `[loss, ddp_model]`) that is able to produce correct behavior: the workers will always hang.

Potential resolutions from looking at the source code:
- separate DDP's join hooks into forward and backward join hooks that can allow the user to insert their `Joinable` in between, or,
- avoid any distributed operations in the forward, so that the current DDP's join hook can be assumed to only shadow the backward pass.


Please let me know if the use case is not clear, or if I can help by providing a concrete example.

### Alternatives

For now, my alternative is to split my loss function into two steps, where I synchronize the buffer in question prior to the ddp_model's forward call, and perform the loss function's forward call using the pre-computed buffer.

This happens to work in the case of my loss function, but is not necessarily doable for a loss function whose synchronized buffer depends on the output of the model's forward.

### Additional context

_No response_

cc @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o
Repository: transformers
Issue: Add functionality for deleting adapter layers in PEFT integration
Labels: Feature request

### Feature request

This request aims to introduce functionality to delete specific adapter layers integrated with PEFT (Parameter-Efficient Fine-Tuning) within the Hugging Face Transformers library. This would enable users to manage memory and computational resources more efficiently by unloading adapters that are no longer needed during model inference or fine-tuning.

### Motivation

This feature request addresses scenarios where users load multiple adapters during fine-tuning or inference but need the ability to selectively unload adapters without reloading the entire model. This enhancement is crucial for optimizing performance in memory-constrained environments and enhancing the flexibility of adapter management within Transformer models.

### Your contribution

Yes, I have submitted a PR #34650
Repository: deno
Issue: Preserve double quotes in JSX with deno fmt
Labels: suggestion,deno fmt

**Description:**

When formatting code with `deno fmt`, it currently converts double quotes to single quotes in JSX (HTML in JS) components. This behavior differs from Prettier, which preserves double quotes in JSX if the `singleQuotes` option is set to `true`.

**Example:**

In Prettier, with `singleQuotes: true`, double quotes are preserved in JSX, as shown below:

```javascript
import React from 'react';

const SimpleComponent = () => {
  return (
    <div className="app">
      Hello, React!
    </div>
  );
};
```

However, `deno fmt` changes the quotes in JSX attributes to single quotes:

```javascript
import React from 'react';

const SimpleComponent = () => {
  return (
    <div className='app'>
      Hello, React!
    </div>
  );
};
```

**Feature Request:**

Could Deno provide an option to preserve or enforce double quotes specifically in JSX, similar to how Prettier handles this with `singleQuotes: true`?

This feature would help users maintain consistency with double quotes in JSX without affecting other parts of the code where single quotes might be preferred.
Repository: transformers
Issue: Add EXAONE
Labels: New model

### Model description

EXAONE is a large language model developed by LG AI Research. We released [EXAONE 3.0](https://github.com/LG-AI-EXAONE/EXAONE-3.0) in August, but we've since updated the model code and are working on integrating our implementation with the Huggingface transformers library.

### Open source status

- [X] The model implementation is available
- [X] The model weights are available

### Provide useful links for the implementation

- Model URL : https://huggingface.co/LGAI-EXAONE/EXAONE-3.0-7.8B-Instruct
- GitHub repo for EXAONE : https://github.com/LG-AI-EXAONE/EXAONE-3.0
Repository: ollama
Issue: I wanted to the add Donut LLM model which seems to be not supported at the moment
Labels: model request

after cloning: https://huggingface.co/docs/transformers/en/model_doc/donut

I have tried to run 
`docker run --rm -v .:/model ollama/quantize -q q8_0 /model` but it fails with:
`unknown architecture VisionEncoderDecoderModel`

I think one can never have enough vision models, so please add support for Donut models and its fine tunings.
Repository: transformers
Issue: The support of `Mllama` in AutoModel
Labels: Feature request

### Feature request

The `AutoModel.from_config` does not work with Mllama (MllamaConfig, MllamaVisionConfig). I would like to request the ability to use Mllama through `AutoModel`.

### Motivation

There are many codes written to dynamically load models using `AutoModel`. It would be great if `AutoModel` could support Mllama to accommodate these codes.

### Your contribution

not yet.
Repository: rust
Issue: `isqrt` treated as a `black_box`
Labels: I-slow,T-compiler

I tried this code:

```rust
#[inline(never)]
pub const fn f(n: u8) {
    assert!(n >= 4);
    assert!(2 <= n.isqrt());
}
```
> [!note]
> I've tried:
> - removing `const`
> - replacing `u8` by `usize`
> - replacing `4` by `9` and `2` by `3`
> 
> Outcome was the same

I expected to see this happen: 2nd assertion non-existent in assembly.

Instead, this happened:
```asm
# ... (snip)
.LBB0_4:
	leaq	.L__unnamed_4(%rip), %rdi
	leaq	.L__unnamed_5(%rip), %rdx
	movl	$32, %esi
	callq	*core::panicking::panic@GOTPCREL(%rip)
# ...
.L__unnamed_4:
	.ascii	"assertion failed: 2 <= n.isqrt()"
# ...
```

### Meta
[Playground](https://play.rust-lang.org/?version=nightly&mode=release&edition=2024&gist=1ace1f411cb80a044a15835fbdb4f2df)

`rustc --version --verbose`:
```
1.84.0-nightly (2024-11-06 8549802939cd01111c46)
```

_No Backtrace_

@rustbot label: +I-slow, -C-bug
Repository: three.js
Issue: TRAAPassNode: Incomplete MRT support.
Labels: Post-processing

### Description

If we add some other postprocessing node after TRAA, we got a black screen. 
It appears that TRAA can not work with other MRT, it only takes two textures as output when rendering pass.
https://jsfiddle.net/ligaofeng0901/g0u9qdb6/14/
I created a demo. In this demo, traa and bloom doesn't work fine together. Or, my usage of traa is not a proper way?

### Reproduction steps

1.
2.
3.


### Code

```js
// code goes here
```


### Live example

* [jsfiddle-latest-release WebGLRenderer](https://jsfiddle.net/3mrkqyea/)
* [jsfiddle-dev WebGLRenderer](https://jsfiddle.net/gcqx26jv/)
* [jsfiddle-latest-release WebGPURenderer](https://jsfiddle.net/8L2jkmx7/)
* [jsfiddle-dev WebGPURenderer](https://jsfiddle.net/L3n1w4yh/)


### Screenshots

_No response_

### Version

0.170.0

### Device

_No response_

### Browser

_No response_

### OS

_No response_
Repository: angular
Issue: Mistake in [Hierarchical Injection] "@Host and viewProviders" section
Labels: area: docs

### Description
The following line describes the behaviour of using the injection resolution modifiers `@Host` along with `@SkipSelf` but it says that `@SkipSelf` will start from `app-child` which looks incorrect, instead, I believe it should be `app-root`.

#### Original
When `@Host()` and `@SkipSelf()` were applied to the FlowerService, which is in the providers array, the result was null because `@SkipSelf()` starts its search in the `<app-child>` injector, but `@Host()` stops searching at `<#VIEW>` —where there is no FlowerService In the logical tree, you can see that the FlowerService is visible in `<app-child>`, not its <#VIEW>.

#### Correction
When `@Host()` and `@SkipSelf()` were applied to the FlowerService, which is in the providers array, the result was null because `@SkipSelf()` starts its search in the `<app-root>` injector, but `@Host()` stops searching at `<app-child> <#VIEW>` —where there is no FlowerService In the logical tree, you can see that the FlowerService is visible in `<app-root>`, not its <#VIEW>.

This is also evident in the logical tree representation given in the _Visibility of Provided tokens_ section

```
<app-root @ApplicationConfig
        @Inject(FlowerService) flower=>"🌺">
  <#VIEW> <!-- end search here with null-->
    <app-child @Provide(FlowerService="🌻")> <!-- start search here -->
      <#VIEW @Inject(FlowerService, @SkipSelf, @Host, @Optional)=>null>
      </#VIEW>
      </app-parent>
  </#VIEW>
</app-root>