sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: stable-diffusion-webui
Issue: [Bug]: StableSR extension/script not saving into the output directory since 1.6.0
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

Instead it saves into AppData\Local\Temp\Gradio

### Steps to reproduce the problem

Generate an image with StableSR script enabled.

### What should have happened?

The image should be saved into the output directory as per settings.

### Sysinfo

[sysinfo-2023-09-06-16-47.txt](https://github.com/AUTOMATIC1111/stable-diffusion-webui/files/12540544/sysinfo-2023-09-06-16-47.txt)


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

Brave

### Console logs

```Shell
Already up to date.
venv "C:\Software\StableDiffusion\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.6.0
Commit hash: 5ef669de080814067961f28357256e8fe27544f4
Launching Web UI with arguments: --xformers --no-half-vae
Loading weights [df955bdf6b] from C:\Software\StableDiffusion\stable-diffusion-webui\models\Stable-diffusion\v2-1_512-ema-pruned.safetensors
Running on local URL:  http://127.0.0.1:7860

To create a public link, set `share=True` in `launch()`.
Startup time: 9.7s (prepare environment: 1.9s, import torch: 3.6s, import gradio: 0.9s, setup paths: 0.6s, other imports: 0.6s, setup codeformer: 0.1s, load scripts: 0.9s, create ui: 0.6s, gradio launch: 0.3s).
Creating model from config: C:\Software\StableDiffusion\stable-diffusion-webui\repositories\stable-diffusion-stability-ai\configs\stable-diffusion\v2-inference.yaml
Applying attention optimization: xformers... done.
Model loaded in 6.0s (load weights from disk: 0.8s, find config: 1.2s, create model: 0.1s, apply weights to model: 2.1s, apply half(): 0.9s, calculate empty prompt: 0.8s).
[StableSR] Target image size: 768x768
[Tiled Diffusion] ignore tiling when there's only 1 tile or nothing to do :)
[Tiled VAE]: the input size is tiny and unnecessary to tile.
100%|██████████████████████████████████████████████████████████████████████████████████| 20/20 [00:03<00:00,  6.05it/s]
[Tiled VAE]: the input size is tiny and unnecessary to tile.███████████████████████████| 20/20 [00:02<00:00,  6.58it/s]
[StableSR] Error fixing color with default method: Given groups=3, weight of size [3, 1, 3, 3], expected input[1, 4, 770, 770] to have 3 channels, but got 4 channels instead
Total progress: 100%|██████████████████████████████████████████████████████████████████| 20/20 [00:03<00:00,  5.38it/s]
Total progress: 100%|██████████████████████████████████████████████████████████████████| 20/20 [00:03<00:00,  6.58it/s]
```


### Additional information

_No response_
Repository: pytorch
Issue: RuntimeError when calling conv_transpose2d with groups
Labels: needs reproduction,module: nn,triaged

### 🐛 Describe the bug

When calling conv_transpose2d with groups > 1, I run into the following error:
```
    r = torch.nn.functional.conv_transpose2d(a, wts, stride=stride, padding=padding, dilation=dilation,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: could not construct a memory descriptor using a format tag
```

Full code snippet:
```
import torch

device = "cpu"

a = torch.randn((9, 42, 1, 5), device=device, dtype=torch.float32)
wts = torch.randn((42, 1, 1, 1), device=device, dtype=torch.float32)
stride = [1, 1]
padding = [0, 0]
dilation = [4, 3]
groups = 2

r = torch.nn.functional.conv_transpose2d(a, wts, stride=stride, padding=padding, dilation=dilation, groups=groups)
print(r)
```



### Versions
```
PyTorch version: 2.0.0.post101
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A
OS: Ubuntu 20.04.4 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Clang version: Could not collect
CMake version: version 3.16.3
Libc version: glibc-2.31

Python version: 3.11.5 | packaged by conda-forge | (main, Aug 27 2023, 03:34:09) [GCC 12.3.0] (64-bit runtime)
Python platform: Linux-5.4.0-42-generic-x86_64-with-glibc2.31
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
...

Versions of relevant libraries:
[pip3] numpy==1.25.2
[pip3] torch==2.0.0.post101
[conda] mkl                       2022.2.1         h84fe81f_16997    conda-forge
[conda] numpy                     1.25.2                   pypi_0    pypi
[conda] pytorch                   2.0.0           cpu_mkl_py311had667d7_101    conda-forge
[conda] torch                     2.0.0.post101            pypi_0    pypi
```

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: stable-diffusion-webui
Issue: [Feature Request]: Add option for postprocessing accordion
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Currently, it's possible to add "postprocessing" to normal txt2img and img2img operations, allowing you to set up a workflow to immediately upscale or apply GFPGAN or CodeFormer to the result, rather than having to send it to the Extras tab and do it there. However, as it stands, those options will always appear in the main UI, with no option to roll them up into an accordion so you don't have them occupying UI space when you're not planning to use them. I would like it if I could hide those options when I'm not planning to use them.

I'm not sure how to describe this in a concise manner, but you know how you can add options (like clip-skip, as one example I use), to those tabs, and you can set it up so you can roll those up into an accordion when you're not using them? I'd like something like that, but for the postprocessing stuff.

### Proposed workflow

First off, to enable the setting:
1. Go to the Postprocessing menu in Settings (or User interface, I'm not picky)
2. Make sure some of the Postprocessing operations are set up to appear in the UI
3. Check off a checkbox similar to the "Options in main UI - place into an accordion" option in the User interface menu
4. Apply settings
5. Reload the UI

Then, to actually use it:
1. Go to the txt2img or img2img tabs
2. There's an accordion there saying Postprocessing, click on it to reveal the selected postprocessing options, click on it again to hide them

### Additional information

_No response_
Repository: godot
Issue: Weird physics behavior
Labels: topic:physics,needs testing,topic:2d

### Godot version

4.1.1 Mono & Non-Mono

### System information

Godot v4.1.1.stable - Fedora Linux 38 (Workstation Edition) - Vulkan (Forward+) - dedicated AMD Radeon RX 6600 XT (RADV NAVI23) () - AMD Ryzen 5 3600X 6-Core Processor (12 Threads)

### Issue description

Edge collision for 2d shapes (tested with CircleShape for the CharacterBody and RectangleShape for the StaticBody) is funky when there are only a few pixels overlap. Happens in both Mono and non-Mono

Amount of overlap:
- No overlap: Passes by and no collision. As expected
- 1px overlap: Gets stopped with collision. As expected
- 2 - 5px overlap: One collision, then the CharacterBody gets moved down and slightly right (in the test project), stops moving and doesn't register any collisions
- 6+px overlap: Everything works again as expected

### Steps to reproduce

Run the project.
Move the CharacterBody2D up and down a few pixel. Y = 408 is no collision, Y = 407 is 1px collision.

Use editor camera override to find the funky characterbody

### Minimal reproduction project

[ProblemProject.zip](https://github.com/godotengine/godot/files/12541163/ProblemProject.zip)
Repository: godot
Issue: Boot splash behavior is inconsistent on iOS with Compatibility / Mobile mode
Labels: bug,platform:ios,topic:rendering,topic:porting

### Godot version

v4.1.1.stable.official [bd6af8e0e]

### System information

Godot v4.1.1.stable - macOS 13.5.1 - Vulkan (Compatibility) 

### Issue description

With Compatibility mode, the boot splash is not shown on iOS, even if the minimum display time is set to a high number like 3000ms.

With Vulkan Mobile, the boot splash gets shown with the configured parameters.

On iOS with either the deprecated image splash or storyboard splash, the additional boot splash is a bit redundant and can be a headache if one wants to configure the storyboard splash to account for the safe areas. 

If I setup the boot splash with a fullscreen image, the exported Xcode project will use the same image for the storyboard. 
If I then want to modify the storyboard to account for safe areas (via constraints), leaving the Godot boot splash on will lead to the following with vulkan: storyboard (cut) -> boot splash (fullscreen) -> main scene (cut). So basically the safe areas will briefly flash with the image.

For this use case, I actually like the behavior of the GLES3 mode, where the (secondary) boot splash is not shown at all. The question is, which one is the expected behavior for iOS? Perhaps it could be configured if the boot splash is shown on iOS or not, for different use cases (although with the Xcode boot splash always showing, I'm not sure which).
Another idea would be an option that the boot splash can be blacked out (or custom colored) for safe areas. 

On Vulkan Mobile, I currently get a brief flash of the secondary splash. This can only be avoided if I use the same fullscreen image, but then I'm not able to modify the storyboard as described above. I'm using black to effectively hide the camera notch.

One workaround for this use case on vulkan would be a centered logo instead of a fullscreen image, but then I am forced to use black as background.

Tested on iPhone 8, iOS 16.6 (both mobile & compatibility)
Tested on iPhone 14 Simulator (compatibility)

### Steps to reproduce

Setup boot splash parameters, launch on iOS with storyboard splash on either compat/mobile mode.

### Minimal reproduction project

N/A
Repository: vscode
Issue: Update editorIndentGuide.background in built in themes editorIndentGuide.activeBackground
Labels: bug,debt,editor-indent-guides

These are deprecated and still used in a bunch of our themes.

![Image](https://github.com/microsoft/vscode/assets/2193314/ff9d6283-c3fb-42d5-a034-181a6b6a8dd6)



![Image](https://github.com/microsoft/vscode/assets/2193314/6c044bde-4319-4d85-adad-6af508473467)
Repository: pytorch
Issue: Adding Maximal Update Parametrization (µP) to torch.nn.init
Labels: module: nn,triaged,needs research

### 🚀 The feature, motivation and pitch

Using muP as the default parameter initializer as it represents a unique point in the parametrization space.

### Alternatives

Status Quo

as suggested in https://github.com/pytorch/pytorch/issues/102477#issuecomment-1574125554

### Additional context

https://github.com/microsoft/mup
https://arxiv.org/abs/2011.14522

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: godot
Issue: CPUParticles2D emitter glitches with global coordinates when far away from the world origin
Labels: discussion,topic:rendering,topic:2d,topic:particles

### Godot version

all versions, tested on 3.6beta2, 3.5.2-stable

### System information

Windows 10 Pro, 64 bit

### Issue description

When the position of a `CPUParticles2D` node is beyong a limit, the emitter behaves erroneously when the `Local Coords` box is unchecked, i.e. when we're using global coordinates.

In this reported case, a sphere emitter emits the particles in vertical stripes (Figure 1) when `position.x` is beyond pow(2, 22), instead of emitting them with the expected uniform distribution (Figure 2).

It was hard to pinpoint the reason triggering the issue but eventually it boiled down to the position of the node combined with the global coordinates setting.

I understand that we're playing on thin ice with floats here, but this clearly seems to be a bug since once emitted in stripes, the particles are moving smoothly on X, so it is not a precision issue, but a math overflow/truncation of some sort.

Figure 1 - bad
![stripes](https://github.com/godotengine/godot/assets/40200623/50249d31-2b12-462b-8995-25d61ee409fc)

Figure 2 - good
![normal](https://github.com/godotengine/godot/assets/40200623/c8bdae26-23d6-4e8c-b672-5e65fdb31d30)


### Steps to reproduce

Comment / uncomment the statement in Main related to positioning the particles node on X and check the output.

### Minimal reproduction project

[cpup_stripes.zip](https://github.com/godotengine/godot/files/12541871/cpup_stripes.zip)
Repository: svelte
Issue: Deep transition using svelte:self is trigerring despite condition not changing
Labels: transition/animation

### Describe the bug

I have a `Tree` component that recursively calls itself. On the wrapper that contains `<svelte:self />`, I have a slide transition. When I click to close the parent, I expect only the parent to transition out. But the inner child triggers its `in` transition.

### Reproduction

- Clone `https://github.com/melt-ui/melt-ui`
- Checkout branch `repro/transition-tree`
- Install deps and execute `pnpm run dev`
- Go to `http://localhost:5173/docs/builders/tree`
- Click on the `lib` folder in the example
- Check console logs

### Logs

```shell
lib outro started tree.svelte:63:33
tree intro started tree.svelte:62:33
lib outro ended
```


### System Info

```shell
System:
    OS: Linux 5.15 Ubuntu 20.04.4 LTS (Focal Fossa) (This is false, as I'm using WSL on Windows 10 x64)
    CPU: (12) x64 11th Gen Intel(R) Core(TM) i5-11400F @ 2.60GHz
    Memory: 9.05 GB / 15.57 GB
    Container: Yes
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 20.4.0 - ~/.nvm/versions/node/v20.4.0/bin/node
    npm: 9.7.2 - ~/.nvm/versions/node/v20.4.0/bin/npm
    pnpm: 8.6.7 - ~/.nvm/versions/node/v20.4.0/bin/pnpm
  npmPackages:
    svelte: ^4.0.0 => 4.0.0
```


### Severity

annoyance
Repository: rust
Issue: Misleading diagnostics in -(2147483649-1)
Labels: A-lints,A-diagnostics,T-compiler,L-overflowing_literals,L-arithmetic_overflow

### Code

```Rust
fn main() {
    let _ = -(2147483649-1);
}
```


### Current output

```Shell
Compiling playground v0.0.1 (/playground)
error: this arithmetic operation will overflow
 --> src/main.rs:2:13
  |
2 |     let _ = -(2147483649-1);
  |             ^^^^^^^^^^^^^^^ attempt to negate `i32::MIN`, which would overflow
  |
  = note: `#[deny(arithmetic_overflow)]` on by default

error: literal out of range for `i32`
 --> src/main.rs:2:15
  |
2 |     let _ = -(2147483649-1);
  |               ^^^^^^^^^^
  |
  = note: the literal `2147483649` does not fit into the type `i32` whose range is `-2147483648..=2147483647`
  = help: consider using the type `u32` instead
  = note: `#[deny(overflowing_literals)]` on by default

error: could not compile `playground` (bin "playground") due to 2 previous errors
```


### Desired output

```Shell
error: literal out of range for `i32`
 --> src/main.rs:2:15
  |
2 |     let _ = -(2147483649-1);
  |               ^^^^^^^^^^
  |
  = note: the literal `2147483649` does not fit into the type `i32` whose range is `-2147483648..=2147483647`
  = help: consider using the type `u32` instead
  = note: `#[deny(overflowing_literals)]` on by default
```


### Rationale and extra context

The paren's contents are not i32::MIN; it's denied by overflowing_literals, which means the expression doesn't have a value, and issuing diagnostics about a non-value is just misleading.

Especially considering it's above the real error; the top error is usually the most important, but not here.

### Other cases

_No response_

### Anything else?

_No response_

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"mojave2"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: go
Issue: runtime: unboundedly expensive equality testing
Labels: Performance,NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

playground (1.21, i think?)

### Does this issue reproduce with the latest release?

presumably

### What operating system and processor architecture are you using (`go env`)?

N/A, should happen everywhere

### What did you do?

https://go.dev/play/p/CcJuPywA867

summary: nest a handful of objects each of which is a struct{a, b, c, d any}, so that each points four times to the next. compare the "top" one. at N=16 or so, this begins taking longer to compare than the playground will let it run.

### What did you expect to see?

I don't know.

### What did you see instead?

Timeouts.

On the one hand, this is clearly You're Holding It Wrong. Don't Do That Then. Etcetera.

But I think in nearly all cases, I've been well-served by my belief that comparing go objects would have *reasonably* bounded runtime, because after all, anything that would cause them to explode or whatever would end up with pointer comparisons, and pointer comparisons come out equal-or-unequal quickly and easily. But interfaces provide a way to have a thing which sort of partakes in pointer-ish semantics, but doesn't actually fully copy things. If you weren't using interfaces for this, you'd actually have to populate all 4^16 items, or you'd have to use pointers (and then the comparisons would be fast). Interfaces let us bypass that perfectly good intuition and have copies of an arbitrarily-large nested tree that don't *actually* require copying it, but also don't enjoy the "we can compare these quickly" behavior of pointers. So each tier of this structure copies the next tier's four-interfaces header, but doesn't dereference the next tier's objects, so you can *assemble* the structure in time that's pretty much just linear with tree depth, but *reading* it is exponential.

On the one hand, I don't see a way to exploit this through user input to, say, encoding/json or anything like that. On the other hand, it feels like the way in which interface types are allowing us to, by copying a few words, create a thing that will *act* like it contains megabytes of data when you do `==` on it, is... unusual? Distinctive?

Obviously this is extremely susceptible to a small cache. On the other hand, the expense of building that cache for most comparisons would be punitive to every *other* go program in the world, pretty much. I don't have a good idea how to address this, or even whether it's worth addressing, but it sure is weird.
Repository: three.js
Issue: "When transmission is non-zero, opacity should be set to 0." Is that really true?
Labels: Question

### Description

The documentation for [`MeshPhysicalMaterial.transmission`](https://threejs.org/docs/#api/en/materials/MeshPhysicalMaterial) says:

> Degree of transmission (or optical transparency), from 0.0 to 1.0. Default is 0.0.
Thin, transparent or semitransparent, plastic or glass materials remain largely reflective even if they are fully transmissive. The transmission property can be used to model these materials.
When transmission is non-zero, [opacity](https://threejs.org/docs/api/en/materials/index.html#api/en/materials/Material.opacity) should be set to 0.

In my experiments, if I set `opacity = 0` the object disappears regardless of how high I set `transmission`.

### Reproduction steps

1. Use MeshPhysicalMaterial
2. set `transmission = 0.5`
3. works great with opacity > 0. When setting `opacity = 0` object becomes invisible


### Code

```js
    var material: THREE.MeshPhysicalMaterial = new THREE.MeshPhysicalMaterial({
        opacity: 0.0,
        color: Number(hex), 
        metalness: 1,
        roughness: 0,
        transmission: 0.8,
    });
    ```

### Live example

https://sbcode.net/threejs/meshphysicalmaterial/

### Screenshots

_No response_

### Version

0.156.0

### Device

Desktop

### Browser

Chrome

### OS

MacOS
Repository: flutter
Issue: [web] `targetWidth`/`targetHeight` block frames when decoding
Labels: engine,c: performance,platform-web,a: images,e: web_canvaskit,P2,team-web,triaged-web

When `targetWidth`/`targetHeight` are specified Flutter Web falls back to wasm image codecs, which are single-threaded (and probably less optimized compared to built-in browser codecs). This is where it's happening:

https://github.com/flutter/engine/blob/84c6f14ffc58aae4c08acbac4739fdf22f20b330/lib/web_ui/lib/src/engine/canvaskit/image.dart#L17

This leads to performance issues like https://github.com/gskinnerTeam/flutter-wonderous-app/issues/112. We should find a way to take advantage of browser codecs and resize on a separate thread.
Repository: flutter
Issue: Optimize pointer event handling on Web
Labels: c: performance,platform-web,perf: speed,P3,customer: quake (g3),team-web,triaged-web

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a performance problem, then fill out the template below.
     Please read our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Details

Internal: b/299346052

Pointer event handling takes 23% of a frame time. We can definitely see some improvements here.

**Reproduction:**
* Load the target Web app on a laptop with touchpad/mouse
* In Chrome Dev Tools/Performance, start recording
* Drag the app around
* Stop recording

<!--
1.  Please tell us exactly how to reproduce the problem you are running into.

2.  Please attach a small application (ideally just one main.dart file) that
     reproduces the problem. You could use https://gist.github.com/ for this.

3.  Switch flutter to master channel and run this app on a physical device
     using profile mode with Skia tracing enabled, as follows:
       flutter channel master
       flutter run --profile --trace-skia

     The bleeding edge master channel is encouraged here because Flutter is
     constantly fixing bugs and improving its performance. Your problem in an
     older Flutter version may have already been solved in the master channel.

4.  Record a video of the performance issue using another phone so we
     can have an intuitive understanding of what happened. Don’t use
     "adb screenrecord", as that affects the performance of the profile run.

5.  Open Flutter DevTools and save a timeline trace of the performance issue
     so we know which functions might be causing it. See "How to Collect
     and Read Timeline Traces" on this blog post:
       https://medium.com/flutter/profiling-flutter-applications-using-the-timeline-a1a434964af3#a499
     Make sure the performance overlay is turned OFF when recording the
     trace as that may affect the performance of the profile run.
     (Pressing ‘P’ on the command line toggles the overlay.)
-->

<!--
     Please tell us which target platform(s) the problem occurs (Android / iOS / Web / macOS / Linux / Windows)
     Which target OS version, for Web, browser, is the test system running?
     Does the problem occur on emulator/simulator as well as on physical devices?
-->

**Target Platform:** Web
**Target OS version/browser:** Chrome Version 116.0.5845.140 
**Devices:** Macbook

## Logs
The detailed profiling log is unfortunately extremely flaky with out-of-order or mislabeled function names, making it extremely hard to figure out the culprit. However, here's a few we could try:
* Skip the resampler when it's disabled.
* Re-enable the hover hit testing subtree.