sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: stable-diffusion-webui
Issue: [Bug]:  I cannot use lowram. The codes of the webui.bat file have changed.
Labels: bug-report

### Checklist

- [ ] The issue exists after disabling all extensions
- [ ] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [ ] The issue exists in the current version of the webui
- [ ] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

I cannot use lowram. The codes of the webui.bat file have changed.

### Steps to reproduce the problem

I cannot use lowram. The codes of the webui.bat file have changed.

### What should have happened?

I cannot use lowram. The codes of the webui.bat file have changed.

### What browsers do you use to access the UI ?

_No response_

### Sysinfo

I cannot use lowram. The codes of the webui.bat file have changed.

### Console logs

```Shell
I cannot use lowram. The codes of the webui.bat file have changed.
```


### Additional information

_No response_
Repository: godot
Issue: set resource_local_to_scene in surface_material_override causes error
Labels: bug,topic:core,needs testing

### Tested versions

4.2 stable

### System information

Windows 10, Godot 4.2 Stable, Forward Mobile. 

### Issue description

![image](https://github.com/godotengine/godot/assets/106619492/c82f9221-0d4b-4455-9292-48c4a4e51851)

Read Steps to reproduce.
servers/rendering/renderer_rd/storage_rd/material_storage.cpp:xxxx - Parameter "material" is null.

works only when set this to surface_material_override, the same with material - not causes error

### Steps to reproduce

1. create 2 scenes
2. in 1st add meshinstance3D with any mesh
3. set any type material to surface_material_override
4. set in this material resource_local_to_scene to true
5. save, and dragNdrop this scene with mesh to second. causes an error to output

### Minimal reproduction project (MRP)

N/A
Repository: next.js
Issue: Warning: `Image with src "URL" has either width or height modified, but not the other.`
Labels: bug,Image (next/image)

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/charming-field-hlgq68?file=%2Fapp%2Fpage.tsx%3A9%2C2

### To Reproduce

1. Get an image, including its dimensions from a CMS (in my case Hygraph).
2. Render it using `next/image` with both width and height set as numbers.

### Current vs. Expected behavior

I'm setting both width and height. This warning shouldn't appear.

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
Binaries:
  Node: 20.11.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.1.0
  eslint-config-next: 14.1.0
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Image optimization (next/image, next/legacy/image)

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

The problem is not new and it's been like this since early next 13 when I bootstrapped the project so I don't think it's version specific.

What I'm doing is basically get the image URL and its real dimensions from Hygraph, hardcode the width that I want, and calculate the corresponding height of the image and pass it to the `<Image>` component. Here's how it looks:

```ts
const { src, width, height } = imageData;
if (!src || !width || !height) {
  return null;
}
const aspectRatioHeight = (+height/ +width) * 200;

return <Image src={src} alt="" width={200} height={aspectRatioHeight} />;
```

`width` and `height` are string values. I'm converting them to numbers using the plus sign.

I've tried setting height to `auto` and even `0` using the `style` attribute and Tailwind but it didn't work.
Repository: rust
Issue: nightly featuers: target-specific library features are painful
Labels: T-compiler,C-discussion

In https://github.com/rust-lang/stdarch/pull/1486, stdarch split up its one uber-feature into a lot of small ones.  This led to some rather [painful updates](https://github.com/rust-lang/portable-simd/pull/389). portable-simd now needs code like this to compile:
```rust
#![cfg_attr(
    all(
        any(target_arch = "aarch64", target_arch = "arm",),
        any(
            all(target_feature = "v6", not(target_feature = "mclass")),
            all(target_feature = "mclass", target_feature = "dsp"),
        )
    ),
    feature(stdarch_arm_dsp)
)]
#![cfg_attr(
    all(target_arch = "arm", target_feature = "v7"),
    feature(stdarch_arm_neon_intrinsics)
)]
#![cfg_attr(
    any(target_arch = "powerpc", target_arch = "powerpc64"),
    feature(stdarch_powerpc)
)]
```

I think the main issue is that library features "exist" only if at least one item with that feature exists, so one has to very carefully put `cfg_atrr` around the `feature` to avoid "unknown feature" errors. std doesn't have many target-specific features so this is not usually a problem, but for stdarch it is. Additionally, `feature` attributes must be in `lib.rs`, so this can't be put inside the modules that actually import these functions -- those modules usually are `cfg`d, but instead of reusing those `cfg` we have to repeat them.

Not sure what one could do about this. rustc could ignore unknown features, but that doesn't seem great. Maybe stdarch should have a way to "declare" feature to exist even if no item in the current configuration actually carries that feature? Then portable-simd could just do `#![feature(stdarch_arm_dsp, stdarch_arm_neon_intrinsics, stdarch_powerpc)]` which would be a lot better.

As a crude hack stdarch could have some "dummy item" for each feature that always exists on all targets, therefore bringing the library feature into existence and letting others enable it in a cfg-independent way.
Repository: stable-diffusion-webui
Issue: [Bug]: Stable DIffusion not installing
Labels: bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [X] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

![image](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/157136432/7c8be54a-48d7-4488-9e26-c12a00e34de2)
I was trying to install Stable Diffusion and got this error

### Steps to reproduce the problem

.

### What should have happened?

It shouldve installed SD

### What browsers do you use to access the UI ?

Other

### Sysinfo

I cant go to webUI

### Console logs

```Shell
venv "C:\stable-diffusion\stable-diffusion-webui\venv\Scripts\Python.exe"
Python 3.10.6 (tags/v3.10.6:9c7b4bd, Aug  1 2022, 21:53:49) [MSC v.1932 64 bit (AMD64)]
Version: v1.7.0
Commit hash: cf2772fab0af5573da775e7437e6acdca424f26e
Installing torch and torchvision
C:\stable-diffusion\stable-diffusion-webui\venv\Scripts\python.exe: No module named pip
Traceback (most recent call last):
  File "C:\stable-diffusion\stable-diffusion-webui\launch.py", line 48, in <module>
    main()
  File "C:\stable-diffusion\stable-diffusion-webui\launch.py", line 39, in main
    prepare_environment()
  File "C:\stable-diffusion\stable-diffusion-webui\modules\launch_utils.py", line 378, in prepare_environment
    run(f'"{python}" -m {torch_command}', "Installing torch and torchvision", "Couldn't install torch", live=True)
  File "C:\stable-diffusion\stable-diffusion-webui\modules\launch_utils.py", line 116, in run
    raise RuntimeError("\n".join(error_bits))
RuntimeError: Couldn't install torch.
Command: "C:\stable-diffusion\stable-diffusion-webui\venv\Scripts\python.exe" -m pip install torch==2.0.1 torchvision==0.15.2 --extra-index-url https://download.pytorch.org/whl/cu118
Error code: 1
Press any key to continue . . .
```


### Additional information

_No response_
Repository: pytorch
Issue: I hope PyTorch will open the sliding window local attention feature as soon as possible.
Labels: triaged,module: sdpa

### 🚀 The feature, motivation and pitch

FlashAttention supports sliding window local attention. 
Since Pytorch's FlashAttention has been upgraded to FlashAttention-2, I hope PyTorch will open the sliding window local attention feature as soon as possible.



### Alternatives

_No response_

### Additional context

_No response_

cc @jbschlosser @bhosmer @cpuhrsch @erichan1 @drisspg @mikaylagawarecki
Repository: godot
Issue: Vulkan Forward+ TAA causes small shimmering behind transparent GPU particles
Labels: bug,topic:rendering,topic:3d

### Tested versions

- Reproducable in v4.2.1.stable.official [b09f793f5]

### System information

Godot v4.2.1.stable - Windows 11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2080 Ti (NVIDIA; 31.0.15.4617) - Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (8 Threads)

### Issue description

On a project with TAA enabled and using the Forward+ renderer, GPUParticles3D that are using a transparent material will cause shimmering behind them, along with artefacts around the edges of the mesh/quad that should be transparent. I apologise if this is considered related to the low quality TAA issue, this just seems like a specific use case that hasnt been reported before, and this is in the latest release build of Godot on steam.

### Steps to reproduce

Using the MRP, in the editor just preview the camera in the scene res://Scenes/Main.tscn. Then disable TAA and look again. TAA causes artefacts around and behind the transparent smoke.

### Minimal reproduction project (MRP)

[TAAMRP.zip](https://github.com/godotengine/godot/files/14232502/TAAMRP.zip)
Repository: godot
Issue: PROBLEM the red line in godot 4.1.1 and 4.1.3
Labels: bug,topic:editor,needs testing,topic:gui

### Tested versions

godot 4.1
godot 4.2
godot 4.0

### System information

Godot v4.1.1.stable - Zorin OS 16.3 - Vulkan (Compatibility) - AMD RS880 (DRM 2.50.0 / 5.15.0-92-generic, LLVM 12.0.0) () - AMD Athlon(tm) II P320 Dual-Core Processor (2 Threads)

### Issue description

i have probleme in gred in godot 4.1.1 and the new version the problem is the red grid

https://github.com/godotengine/godot/assets/156949818/4b94e8fa-f459-41ae-adf3-e847dc836101



### Steps to reproduce

1 add scene


### Minimal reproduction project (MRP)

[game of jam.zip](https://github.com/godotengine/godot/files/14232679/game.of.jam.zip)

```[tasklist]
### Tasks
```
Repository: next.js
Issue: `suppressHydrationWarning` deactivates hydration completely
Labels: bug

### Link to the code that reproduces this issue

https://github.com/derweili/nextjs-hydration-issue/

### To Reproduce

1. Start the dev server and open the page. Alternatively use the [hosted example I deployed to vercel](https://nextjs-hydration-issue.vercel.app/).
2. Ensure you are using a different timezone in your browser/OS then UTC.
3. Click in the nav on "Example 1: Without supressed warning".
4. You can see that the date is first rendered using the servers timezone (UTC) but during hydration, the date is changed to the users timezone. You can also see a error happpening in the console: `Text content does not match server-rendered HTML.`
5. Click on the nav on "Example 2: With supressed warning".
6. You can now see the exact same page with only one difference: the div wrapping the time has a `supressHydrationWarning` set. But you can now also see, the date is not localized to uses timezone anymore. Instead the server time is shown.
7. Still on the same page (Example 2), open you console, you can see that the console log, called in the LocalizedDateTime is actually called and loggs the localized that should have been shown on the page. So "hydration execution" still seams to happen, but the HTML is not added to the DOM.
8. Click on the nav on "Example 3: combined"
9. Here you can see the date twice, one with `supressHydrationWarning` and one without. This time both are localized.

### Current vs. Expected behavior

Following the steps from the previous section, I would expect that the date always gets localized to the users timezone during hydration. The only difference I would expect is that when `suppressHydrationWarning` is set, only the warning disappears, but the hydration should still happen.

Even the [nextjs docs](https://nextjs.org/docs/messages/react-hydration-error#solution-3-using-suppresshydrationwarning) mention timestamps as a situation where `suppressHydrationWarning` could be used.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 23.1.0: Mon Oct  9 21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000
Binaries:
  Node: 18.19.0
  npm: 10.2.3
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.1.0
  eslint-config-next: 14.1.0
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


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

App Router

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

next dev (local), next build (local), next start (local), Vercel (Deployed)

### Additional context

I tested on multiple environments, Mac, Windows, Deployed on Vercel. So its not a environment specific issue.
Repository: rust
Issue: Several of the tests in tests/ui/error-codes/ do not actually test the respective error code
Labels: A-testsuite,T-compiler,C-bug

I noticed this for tests/ui/error-codes/E0388.rs and tests/ui/error-codes/E0017.rs, which both don't trigger the respective error code.

I did some random sampling and most tests are fine, but found one more that is not: tests/ui/error-codes/E0396.rs.
Repository: stable-diffusion-webui
Issue: Inpaint SDXL with resolution above 1024pix (16GBVRAM)
Labels: bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [X] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

Out of Vram if i inpaint resolution above 2000pix

### Steps to reproduce the problem

img2img tab
inpaint tab
put any image 
resolution dependent

2000x2000
ERROR: OUT OF VRAM
or 1200x1200 on my System (16GB VRAM)
it need 2min

### What should have happened?

faster  !!

copy and paste the code from 
FOOOCUS 
its open  . . .  do some thing with it ...  thats the goal    ;)

it can handle 4000x4000 on my system

### What browsers do you use to access the UI ?

_No response_

### Sysinfo

Win10
RTX4060-16GB VRAM

### Console logs

```Shell
-
```


### Additional information

_No response_
Repository: vscode
Issue: Add option to automatically move files to current tab group on open
Labels: feature-request,workbench-editors,workbench-editor-resolver

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

From @aguynamedben in https://github.com/microsoft/vscode/issues/41289:

> I wish to live in a "don't-care-about-tabs" world but still want a way to split my editor's UI. However, the idea of tabs and tab groups seems deeply embedded into VS Code's ability to split windows, so I'm skeptical this is coming any time soon.
>
> The best way out of this I can think of is some kind of settings such as:
>
> "workbench.editor.moveToCurrentTabGroupIfOpen": true,
>
> This would be similar to workbench.editor.revealIfOpen but opening a file that's already open in another tab group would move that file into the current tab group. Then I could disable all tab-centric UIs in VS Code and indiscriminately open any file within any split and not end up with a mess of duplicate files open across many tab groups. I think this might be sufficient for most tab-haters.
>
> [Working without Tabs](https://code.visualstudio.com/docs/getstarted/userinterface#_working-without-tabs) could say:
>
> > If you're used to text-focused editors such as Emacs or vi and simply want to view any open file within any split without regard for tab or tab groups, set:
> >
> > "workbench.editor.showTabs": true,
> > "workbench.editor.revealIfOpen": true,
> > "workbench.editor.moveToCurrentTabGroupIfOpen": true
> >
> >  With this setup, the underlying tabs and tab groups system will continue power which files are shown in which visual split, but that will be mostly irrelevant in day-to-day use. You wont see tabs, and opening a file will "move" the open file into whatever tab group ("visual split") you're focused on, similar to Emacs buffers and "windows".

https://github.com/microsoft/vscode/issues/41289 was originally closed as it was out of scope. However, this suggested feature does not seem out of scope and seems easier to implement than just removing editor groups altogether. I would be happy to try to implement this.
Repository: deno
Issue: `Temporal.PlainDate.yearOfWeek` not working
Labels: upstream

## Version

deno 1.40.4+26d9b2f (canary, x86_64-unknown-linux-gnu)
v8 12.1.285.27
typescript 5.3.3

## Summary

[`Temporal.PlainDate.yearOfWeek`](https://tc39.es/proposal-temporal/docs/plaindate.html#yearOfWeek) always return `undefined`. likely V8 not yet having implemented it like in #22143.

## To Reproduce

https://tc39.es/proposal-temporal/docs/plaindate.html#yearOfWeek

```sh
$ deno --unstable-temporal
Deno 1.40.4+26d9b2f
exit using ctrl+d, ctrl+c, or close()
REPL is running with all permissions allowed.
To specify permissions, run `deno repl` with allow flags.
> const date = Temporal.PlainDate.from('2022-01-01')
undefined
> console.log(date.yearOfWeek, date.weekOfYear, date.dayOfWeek)
undefined 52 6
```
Repository: material-ui
Issue: [material-ui][Autocomplete] Dropdown arrow visible with readOnly prop set to true
Labels: component: text field,package: material-ui,component: autocomplete,enhancement

### Steps to reproduce

Link to live example: https://mui.com/material-ui/react-autocomplete/

Steps:
1.Create an Autocomplete component with the readOnly prop set to true.
2.Observe the component on the page.

### Current behavior

The dropdown arrow should not be visible, and the component should be fully read-only, with no interaction allowed that would suggest the possibility of changing the selected value.

### Expected behavior

The dropdown arrow remains visible and clickable, though it should not change the selection due to the read-only state, suggesting that the input could be interactable.

### Context

_No response_

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
```
</details>


**Search keywords**: bug, Autocomplete, readOnly
Repository: next.js
Issue: Different behavior for dev and prod builds for client components within a layout
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://github.com/EugeneDraitsev/next-routing-issue

### To Reproduce

1. Clone a repo and run `yarn dev` or check it on [codesandbox](https://codesandbox.io/p/github/EugeneDraitsev/next-routing-issue/) ([deployed app link](https://srwyy3-3000.csb.app/))
2. Navigate between pages using the drawer (the drawer **always stays open**)


https://github.com/vercel/next.js/assets/16540432/e2c590e4-c859-4d6f-9a85-12bfa8233894


3. Do the same with  `yarn build` and `yarn start` or check it on [vercel](https://next-routing-issue.vercel.app/)
4. Navigate between pages using the drawer (the drawer **always closes** when navigating)


https://github.com/vercel/next.js/assets/16540432/8cd04521-36d9-4f20-b619-c474e9dd7f31


### Current vs. Expected behavior

Expected behavior: Dev and prod work the same (in an ideal scenario the dev behavior should be correct)
Current behavior: For some reason in the prod build the `<Header />` component is remounted and dev/prod behaves differently.

Btw, everything works as expected on dev and prod builds if I add `'use client'` to `layout.js` (which is a very bad workaround).

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
Binaries:
  Node: 20.10.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.1.0
  eslint-config-next: 14.1.0
  react: 18.2.0
  react-dom: 18.2.0
  typescript: N/A
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router, Routing (next/router, next/navigation, next/link)

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

### Additional context

_No response_
Repository: godot
Issue: Rendering discrepancies between forward_plus and gl_compatibility
Labels: topic:rendering,documentation,topic:3d

### Tested versions

- Reproducible in Godot 4.2.1 and Godot 4.3 dev3

### System information

Godot v4.2.1.stable.mono - Fedora Linux 38 (Workstation Edition) - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Laptop GPU () - 11th Gen Intel(R) Core(TM) i5-11400H @ 2.70GHz (12 Threads)

### Issue description

ShaderMaterials are drawn differently on the gl_compatibility render backend compared to the forward_plus backend.
Forward+ colors are desaturated and washed out - this does not happen with the StandardMaterial3D.
The scene, the shader and the environment settings are kept simple to minimize the odds of it being a side effect of a feature unsupported on gl_compatibility.

The shader in question:
```
shader_type spatial;

uniform sampler2D main_texture;

void fragment() {
	ALBEDO = texture(main_texture, UV).rgb;
}
```

It happens regardless of the render_mode (I also checked `unshaded` and `diffuse_toon`). The degree of "error" is also different between version 4.2.1 and 4.3dev3

### Steps to reproduce

- open the attached project
- run the default scene
- note colors of the displayed spheres
- change the renderer to gl_compatibility
- run the default scene and see that the sphere with a custom shader has much more saturated colors

### Minimal reproduction project (MRP)

[mrp.zip](https://github.com/godotengine/godot/files/14233249/mrp.zip)
Repository: PowerToys
Issue: [Settings] Cursor changes to resize when at the top of the screen in maximized mode
Labels: Issue-Bug,Product-Settings,Needs-Triage

### Microsoft PowerToys version

0.78.0

### Installation method

GitHub, PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Settings

### Steps to reproduce

1. Maximize the Settings window.
2. Move your cursor to the top od the screen
3. The resize cursor appears and you can't click the window buttons

### ✔️ Expected Behavior

Cursor doesn't change, you can move the window and click the window buttons when your cursor is on the top of the screen.

### ❌ Actual Behavior

_No response_

### Other Software

_No response_