sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: [Bug]: Deployed stories do not work when they import the same style file as a string
Labels: bug,builder-vite

### Describe the bug

In a project using Storybook with ViteJS builder.

I import the same css style file named `style.css` inside two different stories. When I deploy the static version of the storybook, these stories does not work at all, even though they work with the dev version.

I discovered that using two different style file fixed the problem but I don't like this workaround.

### To Reproduce

https://github.com/elturpin/issue-storybook-style-import/tree/main

I created a minimal code in this git repository with details about the problem.

### System

```bash
System:
    OS: Linux 5.15 Linux Mint 21 (Vanessa)
    CPU: (8) x64 Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz
  Binaries:
    Node: 18.17.1 - ~/.nvm/versions/node/v18.17.1/bin/node
    npm: 9.6.7 - ~/.nvm/versions/node/v18.17.1/bin/npm
  npmPackages:
    @storybook/addon-essentials: ^7.3.2 => 7.3.2 
    @storybook/addon-links: ^7.3.2 => 7.3.2 
    @storybook/blocks: ^7.3.2 => 7.3.2 
    @storybook/web-components: ^7.3.2 => 7.3.2 
    @storybook/web-components-vite: ^7.3.2 => 7.3.2
```


### Additional context

On the browser (firefox):
+ The interface says "error loading dynamically imported module: [THE STORIES FILE]"
+ In the debug console, It says that it tries to GET `http://localhost:8000/assets/style-[NUMBERS].js` (vs `style.css`) with a 404 response.
+ the browser says it blocked the request because of forbidden MIME type (text/html).

Checking inside the storybook-static/assets directory to check the files and the content of the files, I discovered that
+ for the diff stories (two style file), the minified files contain the style as a string inside them.
+ for the same stories (one style file),
   + a minified style file exists,
    + the minified version of the stories try to import a js file named after the style file (something like style-645d583c.js). This particular file does not exist, but ...
    + There is a sourcemap file name style-645d583c.js.map.
Repository: godot
Issue: CapsuleCollider2D gets stuck on another CapsuleCollider2D and drags it around
Labels: bug,topic:physics,topic:2d

### Godot version

4.1.1.stable.mono.official

### System information

Windows 10 Forward+

### Issue description

A simple project with two CapsuleCollider2D has a behaviour where if one moves into the corner of another, the second one becomes stuck to the first and is dragged around with it.

I would expect that the second player shouldn't move at all, as it doesn't move when bumped from the side.

I discovered this issue with mono/C# but it is the same in gdscript. Repro below is using gdscript.

### Steps to reproduce

Create two CharacterBody2D with a CollisionShape2D and set up movement using the default movement script.

Remove the gravity and replace it with get_vector so it becomes a topdown game style movement.

Ensure the CollisionShape2D is a CapsuleCollider.

Bump one into the corner of the other. They get stuck together and suddenly start moving around together. More specifically, move the player into the left side of the second player, and press S and D together to slide along. Observe that player 2 suddenly starts moving.

### Minimal reproduction project

[CollideTest.zip](https://github.com/godotengine/godot/files/12704279/CollideTest.zip)
Repository: kubernetes
Issue: +default in PodSpec has too much ripple
Labels: sig/api-machinery,area/code-generation,triage/accepted

@alexzielenski @apelisse 

It's well understood that PodSpec is embedded in all sorts of types, so any new defaults in there change all those other types.  Usually we don't want that, and so the hand-coded defaulting has ` SetDefaults_PodSpec()` (which captures the existing ones) and `SetDefaults_Pod()` (which only triggers on actual Pod, which is where most new defaults should go).

There's no way to denote this with `+default`.  Maybe we don't want to because it is so specific to this case, but I wanted to file it to think about.
Repository: godot
Issue: Spotlight Projector - No light in forward+ - No projecting in compatibility
Labels: bug,topic:rendering,needs testing,topic:3d

### Godot version

4.1.1 Stable

### System information

Godot v4.1.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated AMD Radeon RX 5600 XT (Advanced Micro Devices, Inc.; 31.0.21031.1005) - AMD Ryzen 5 3500X 6-Core Processor (6 Threads)

### Issue description

When adding a spotlight object and trying to project any image with it, the light stops working completely in Forward+ mode. 
I tried a jpg file, I tried a png file with transparency, which caused the game to lag uncontrollably and I tried the Godot logo svg file. 
When switching from Forward+ to Compatibility, the Spotlight would still illuminate, but would not project the inserted image. 

### Steps to reproduce

Add a 3D scene node
Add a plane mesh
Add a spotlight and point towards plane mesh
Toggle preview sunlight
Add icon.svg in the projection option of the spotlight.
Result in Forward+: No light
Result in Compatibility: Light, but no projection

Replace icon.svg with a png image file containing an alpha channel i.e. transparency.
Result: No light, extreme lag ingame. 

### Minimal reproduction project

[Spotlight Projection Minimal.zip](https://github.com/godotengine/godot/files/12704851/Spotlight.Projection.Minimal.zip)
Repository: flutter
Issue: Update the packaging recipe to prevent release artifacts from being able to be overwritten.
Labels: P1,team-release

Currently, if you run the packaging recipe on the same release version, the new artifact will overwrite the previous artifact. We want to prevent this so that a new version of an existing SDK isn't accidentally uploaded
Repository: flutter
Issue: Update the packaging recipe or script to ensure that the sha of the artifact being created matches the sha of the corresponding release tag
Labels: P1,team-release

Without this protection, it is possible to trigger a packaging build and upload an artifact with a sha that was not tagged as the "official" version. We want to make sure that only the tagged shas are uploaded and released on flutter.dev
Repository: flutter
Issue: Migrate the flutter release json to a datastore in GCP
Labels: P3,team-release,triaged-release

Instead of having the releases in a file on GCS, migrate the releases to a database so that we can easily audit changes to release versions and reduce complexity.
Repository: go
Issue: proposal: slices: add `Swap` and `Swapper` functions
Labels: Proposal

I propose adding to package slices (or package sort):

```
// Swap swaps s[i] and s[j].
func Swap[S ~[]E, E any](s S, i, j int) { s[i], s[j] = s[j], s[i] }

// Swapper returns a function that swaps s[i] and s[j].
func Swapper[S ~[]E, E any](s S) func(i, j int) { return func(i, j int) { Swap(s, i, j) } }
```

This is a common operation when implementing `sort.Interface` (e.g., appears 164 times within $GOROOT). It's not hard to write out by hand, but it's tedious writing `s` 4 times when it's a long expression, or making sure to get the i/j/j/i ordering right.
Repository: godot
Issue: using DisplayServer.window_set_rect_changed_callback() breaks all types of Stretch Mode
Labels: bug,topic:porting

### Godot version

v4.1.1.stable.official [bd6af8e0e]

### System information

Godot v4.1.1.stable - Windows 10.0.19045 - Vulkan (Compatibility) - NVIDIA GeForce GTX 1660 SUPER (NVIDIA; 31.0.15.3623) - 11th Gen Intel(R) Core(TM) i7-11700 @ 2.50GHz (16 Threads)

### Issue description

Using DisplayServer.window_set_rect_changed_callback() breaks the stretch mode.


Stretch Mode : canvas_item / with DisplayServer.window_set_rect_changed_callback() 
![canvas-display](https://github.com/godotengine/godot/assets/49001332/e7049b79-28e0-45b7-a3ed-dc9a285bdc17)

Stretch Mode : canvas_item / without
![canvas-pass](https://github.com/godotengine/godot/assets/49001332/57e18968-39f1-40a1-a2ba-3835d2b3f92c)


Stretch  Mode : disabled / with DisplayServer.window_set_rect_changed_callback() 
![disabled - display](https://github.com/godotengine/godot/assets/49001332/5183522c-07aa-41fd-9b08-0972e0bd3aad)

Stretch Mode : disabled / without
![disabled - pass](https://github.com/godotengine/godot/assets/49001332/9666bdca-2ad9-4ea2-99f4-1cdae59bb7d7)



### Steps to reproduce

Simply use DisplayServer.window_set_rect_changed_callback()

```gdscript
extends Node2D


func _ready() -> void:
	DisplayServer.window_set_rect_changed_callback(_on_window_resize)


func _on_window_resize() -> void:
	print(DisplayServer.window_get_size())
```

### Minimal reproduction project

[window_set_rect_changed_callback.zip](https://github.com/godotengine/godot/files/12704584/window_set_rect_changed_callback.zip)
Repository: godot
Issue: EditorScenePostImport C# example code doesn't work, while GDScript code does
Labels: bug,topic:editor,topic:dotnet

### Godot version

4.1.1.stable.mono

### System information

Godot v4.1.1.stable.mono - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4080 (NVIDIA; 31.0.15.2824) - 13th Gen Intel(R) Core(TM) i7-13700KF (24 Threads)

### Issue description

Just now I tried figuring out how **EditorScenePostImport** works, by copying the example code from the documentation page:

https://docs.godotengine.org/en/stable/classes/class_editorscenepostimport.html

```
using Godot;

// This sample changes all node names.
// Called right after the scene is imported and gets the root node.
[Tool]
public partial class NodeRenamer : EditorScenePostImport
{
    public override GodotObject _PostImport(Node scene)
    {
        // Change all node names to "modified_[oldnodename]"
        Iterate(scene);
        return scene; // Remember to return the imported scene
    }

    public void Iterate(Node node)
    {
        if (node != null)
        {
            node.Name = $"modified_{node.Name}";
            foreach (Node child in node.GetChildren())
            {
                Iterate(child);
            }
        }
    }
}
```

I made a new C# script, based its template off of "Empty", named it **NodeRenamer**, and attached it to a .FBX file I wanted it to work on.

Then I pressed "Reimport", open the FBX file as a New Inherited Scene, and nothing had happened.

This is what my New Inherited Scene looks like:
![image](https://github.com/godotengine/godot/assets/8539860/a53fc73c-54bc-486d-a5ab-3679235c79ac)

So, in order to verify that I'm following the steps correctly, I attempt the exact same thing, except now using GDScript instead of C#, and I get the following:
![image](https://github.com/godotengine/godot/assets/8539860/127122bc-6df5-4b12-b92d-abac94f6305c)

GDScript works as it should, C# doesn't work at all.

I even tried putting some print logs in both scripts, and the GDScript prints everything fine, while the C# script never even appears to get triggered.

I'm not sure if this is an issue with the engine or with the documentation.

### Steps to reproduce

- Open the minimal reproduction project
- Open _"Deacon Mayflower Godot.fbx"_ as a New Inherited Scene and observe the mesh names
- Close _"Deacon Mayflower Godot.fbx"_
- On _"Deacon Mayflower Godot.fbx"_, change the import script to **NodeRenamer.cs**
- Click Reimport
- Open _"Deacon Mayflower Godot.fbx"_ as a New Inherited Scene and observe that the mesh names haven't changed
- Close _"Deacon Mayflower Godot.fbx"_
- On _"Deacon Mayflower Godot.fbx"_, change the import script to **NodeRenamerGDScript.gd**
- Click Reimport
- Open _"Deacon Mayflower Godot.fbx"_ as a New Inherited Scene and observe that the mesh names _have_ changed

### Minimal reproduction project

[BrokenSeeSharpImportScript.zip](https://github.com/godotengine/godot/files/12704722/BrokenSeeSharpImportScript.zip)
Repository: godot
Issue: Operator '*' cannot be applied to operands of type 'double' and 'Vector2'
Labels: enhancement,topic:core,topic:dotnet

### Godot version

v4.1.1.stable.mono.official [bd6af8e0e]

### System information

Godot v4.1.1.stable.mono - Windows 10.0.22621 - Vulkan (Forward+) - dedicated GeForce RTX 2060 () - Intel(R) Core(TM) i9-10900 CPU @ 2.80GHz (20 Threads)

### Issue description

the '*' Operator cannot be applied to operands of type 'double' and 'Vector2'. On the other hand, operands of type 'float' and 'Vector2' has the '*' operator which help the developer to write less code for this multiplication.
for example
```
dir =new((float)(dir.X * delta), (float)dir.Y*delta)
```

### Steps to reproduce

```
dir =new((float)(dir.X * delta), (float)dir.Y*delta)
```

### Minimal reproduction project

```
dir =new((float)(dir.X * delta), (float)dir.Y*delta)
```
Repository: stable-diffusion-webui
Issue: [Feature Request]: Option to create additional txt2img or img2img tabs
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 ?

This option would allow you to add additional generation tabs. This would be useful to work on multiple images at the same time. Currently there are two: txt2img and img2img. You can work separately on either of these, i.e. press generate for some txt2img, jump over to img2img and adjust your inpainting, press generate, then jump back to txt2img to adjust the prompt, etc. This way while you are making adjustments to one generation request the other one can be running in the background, making good use of your time.

By adding additional tabs you can not only have this work broken up between txt2img and img2img but you could also work on, say, multiple img2img images at the same time.

### Proposed workflow

1. Go to txt2img. Generate ten images of a castle.
2. You choose your two favorite ones, but you want to add some birds and flames in both of them.
3. For the first one, you send to inpaint. Adjust your generation and hit "generate".
4. Go back to txt2img, and send the second image to a *new* inpaint tab. adjust your parameters and hit "generate"
5. by now the first img2img may have completed. You open that tab and adjust parameters to add fire and hit generate.
6. go back and forth until you are happy.

In the meantime you may have also generated ten more images of a castle and found another you like. you can add that to a *new* img2img tab to now have 3 tabs running at once. You are the picture of efficiency.


### Additional information

_No response_
Repository: PowerToys
Issue: Quick Accent activation method is dreadful (for first timers and power users)
Labels: Idea-Enhancement,Needs-Triage,Product-Quick Accent

### Description of the new feature / enhancement

## The two existing activation keys are:

1. Key + Space within X delay.
2. Key + Left/Right Arrow within X delay.

## The problems:

### Key + Space within X delay:

1. If the delay is too short, there's a chance you can trigger accent causing the following output:
**Expected:**
`hello my name is mario`
**Got:**
`hellómy naméiímario`
2. If the delay is too long, because your typing speeds and/or method varies, then you end up with a huge disruption to the flow when writing. Oddly timed pauses, here and there, trying to get the accent to work.

### Key + Left/Right Arrow within X delay:

1. If the trigger is too short you might not reach the key. 
2. The key forces you to move your hand around (depending on the keyboard).

## My conclusions:

The current implementation:

1. Places too much burden on the user.
2. When things go wrong, it's very disruptive. And due to the human element quite "random", almost "buggy" at times. (Note the many issues mentioning variations of this with other words, sometimes reported as bugs)
3. When things go right, you have to wait, you have to rush, or that's what it feels anyway. Should I hold the key a bit longer? Am I going too fast? Too slow? Again, burdening the user. 

An ideal implementation would:

1. Not get in the way of the user typing. You shouldn't be surprised when you type the same phrase you have typed all your life, just to find out you have a tendency to hold spacebar a bit longer, or an equivalent.
2. Not require the user to move the hand away from what they are doing in the given moment (typing, not editing)
3. Be able to use it multiple times in a single sentence and word, without disrupting the writing speeds (mid word for example).

### Scenario when this would be used?

This scenario applies to every single user using this feature. Bringing benefits to all, from first timers to power users.

For first timers a better implementation would prove to be a less frustrating experience. Allowing the user to adopt it without the burden it currently has.

### Supporting information

_No response_
Repository: deno
Issue: [jupyter-kernel] previous cell outputs not cleared after cell is edited and re-run
Labels: bug,deno jupyter

To reproduce:

  * Create a new Jupyter Notebook in VS Code.
  * Set the kernel to Deno. (Seems to be ~/.deno/bin/deno.)
  * Enter a cell: `2+2` 
  * Execute the cell to get 4
  * Change the cell to: `console.log("hello")`
  * Execute the cell again. It shows two outputs, '4' and 'hello'. The '4' should be gone.
  
  A workaround is to clear the cell outputs manually.
Repository: angular
Issue: Type safe Input setting on components created with createComponent
Labels: area: core,core: inputs / outputs,core: dynamic view creation

### Which @angular/* package(s) are relevant/related to the feature request?

core

### Description

When a component is created via the `createComponent` method on `ViewContainerRef`, there are two ways inputs can currently be set:
1. Setting properties directly on the component instance. This seems to generally not be recommended due to the changes not respecting lifecycle hooks.
2. Using the `setInput` method on the `ComponentRef`. This seems to be the recommended method, however it comes with its own set of issues:
a. The `name` can be any `string`, and thus is not guaranteed to be the name of an actual input.
b. The `value` type is `unknown`, so even if you are always using the right names, there is no way to have any sort of type-checking on the value itself.

Additionally, for both options, because the inputs are being set one-by-one, there is no way to check for missing `required` inputs.

As a result, setting inputs on components created with `createComponent` is quite a bit riskier than using components in templates. It would be great if the API for creating component instances dynamically in TypeScript felt just as robust as instantiating a component inside of a template. Additionally, improvements here this could trickle down to provide a better interface for setting inputs in other use cases e.g. [Dialog creation in Angular Components](https://github.com/angular/components/issues/27776).

### Proposed solution

Add an `inputs` field to the options parameter of `createComponent` which allows passing in initial values for each input on the component. Ideally, this should:
1. Have full type info matching the inputs on the component itself.
2. Respect the `required` flag, so if an required input is missing, an error is passed along.

### Alternatives considered

- Alternative signature for `setInput` on `ComponentRef` which allows setting inputs in a type safe manner. This would be a more flexible option than the proposed solution, but has no ability to check if required inputs have been set.
Repository: deno
Issue: [jupyter-kernel] stack trace line numbers are wrong
Labels: bug,repl,deno jupyter

To reproduce:

  * Create a new Jupyter Notebook in VS Code.
  * Set the kernel to Deno. (Seems to be ~/.deno/bin/deno.)
  * Enter the following code:

```typescript
console.log("1");
console.log("2");
console.log("3");
throw new Error("fail");
```

The output is a stack trace:

```
Stack trace:
Error: fail
    at <anonymous>:5:7
```

So this is off by 1.

But this gets worse for classes:

```typescript
class Camera {
    constructor(public x: number, public y: number, public dir: number) {}

    get pos(): [number, number] {
        return [this.x, this.y];
    }

    get dirVector(): [number, number] {
        return [Math.cos(this.dir * Math.PI / 180), Math.sin(this.dir * Math.PI / 180)];
    }

    get left(): [number, number] {
        const half_width = params.camera_width / 2;
        const dir = (this.dir - half_width) * Math.PI / 180;
        return [Math.cos(dir), Math.sin(dir)];
    }

    get right(): [number, number] {
        const half_width = params.camera_width / 2;
        const dir = (this.dir + half_width) * Math.PI / 180;
        return [Math.cos(dir), Math.sin(dir)];
    }
}

throw new Error("fail");
```

The stack trace I get is:

```
Stack trace:
Error: fail
    at <anonymous>:40:7
```

The actual line number is 25. I suspect the JavaScript line number isn't getting run through a sourcemap to get the TypeScript line number?

(Also, this is more of a feature request, but it would be friendlier to reproduce the source code in the error message like Python does, since cells don't have line numbers turned on by default.)
Repository: pytorch
Issue: test test_2d_fsdp_integration_fsdp_nested_param_groups failed
Labels: oncall: distributed,triaged

### 🐛 Describe the bug

This test in `test_fsdp_2d_parallel.py` is trying to test 2D (TP + FSDP) with nested wrapping and multiple param groups. Somehow if I disable nested wrapping or comment the second param works, test all passed. 

We need to investigate why this happens and filed an issue to track it.

### Versions

PyTorch nightly build

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu
Repository: deno
Issue: Bad error message for undefined property (in repl and jupyter)
Labels: feat,upstream,deno jupyter

```
% deno repl
Deno 1.37.0
exit using ctrl+d, ctrl+c, or close()
> const foo = {}
undefined
> const [x,y] = foo.bar
Uncaught TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator))
    at <anonymous>:2:16
> 
```

It seems like this error should say something about bar being undefined, rather than undefined not being iterable. Also, the line number is wrong, and I filed a different bug for that: #20643

I originally saw this in a notebook, but here's the repl version of the bug.