sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Vulkan: Lighting on CanvasTextures on TextureRects appears to incorrectly use normals
Labels: bug,topic:rendering,confirmed,topic:2d

### Godot version

4.0.beta2.official

### System information

macOS 12.3.1 (21E258), Metal GPUFamily Apple 7, Vulkan

### Issue description

I expected `CanvasTexture` to work with 2D lighting (specifically normals) on a `TextureRect`, but the light is is applied as if it was on the opposite side. Speculars work as expected.

The example shows brick walls. There are two `CanvasTexture`s, each on a `TextureRect`, each on a CanvasLayer, top and bottom. There are also two large `Sprite2D`s to show they work correctly. There is a `PointLight2D` in the middle, at a height of 40 px.

Top `TextureRect` has its Shininess set to 0. I expected the brick edges pointing towards the light to be lit more strongly, but the opposite is the case. Also, I expected the front of the bricks to be most strongly lit under the light, but the opposite is the case: the further out it is, the more strongly it is lit.
Bottom `TextureRect` has its Shininess set to 0.44 and looks more as I would expect, with highlights on bricks towards the middle.

<img width="1322" alt="Screenshot 2022-10-09 at 17 29 48" src="https://user-images.githubusercontent.com/3022/194765432-77b6059f-3972-4020-a331-4ab47c6d60a3.png">

Even if the normals should turn out to be correct in some way (wrong normal colors), I'd expect the Specular and Normal lighting to be congruent.


### Steps to reproduce

1. Open the attached project.
2. Inspect the top and bottom `TextureRect`s.
3. Notice that the lighting on the top `TextureRect` is incorrect.

### Minimal reproduction project

[Light2DBug.zip](https://github.com/godotengine/godot/files/9741896/Light2DBug.zip)

### Potentially relevant

Other issue with CanvasTexture 2D Lighting: #61832
Repository: stable-diffusion-webui
Issue: Request: Display image number/batch size in web ui and lightbox view
Labels: enhancement

**Is your feature request related to a problem? Please describe.**
When going through the results of a finished batch, when you have reached the last image of the batch and continue pressing the right arrow key, the page will wrap around and display the first image of the batch. That happens in and out of gallery view, and I don't have a problem with that. 
However, there is currently no feedback for when this happens and no indication of which image you are currently displaying. And that makes it hard/impossible to tell when you have reached the last image of a batch. It happens to me quite frequently that I cycle around unconsciously and look at images I have already seen. Especially with larger batch sizes (I occasionally like to run 25, 50 or 100) or batches of image variations you can't really rely on "Oh I've seen this already".

**Describe the solution you'd like**
I would like there to be a text like "Displaying image 8/50" in the webui as well as the lightbox view.

**Describe alternatives you've considered**
I can't think of alternative solutions.
Repository: stable-diffusion-webui
Issue: Star/heart/thumbs-up results for easier comparison
Labels: enhancement

**Is your feature request related to a problem? Please describe.**

Lack of functionality. Would like the ability to star/heart/thumbs-up results and then compare only those results, rather than scrolling through all generations over and over to determine the best images.

Additionally, it would be really useful if each filename (as well as dimensions, like after outpainting and sending to img2img, in order to set the correct size...or automatically detect input image size and set it automatically also) would be displayed with the images so that while scrolling through, it would be easier to locate on disk.


**Describe the solution you'd like**

See above...don't know how to elaborate further!


**Describe alternatives you've considered**

Can't think of anything else.
Repository: PowerToys
Issue: Allow selection of file properties within PowerRename
Labels: Idea-Enhancement,Help Wanted,Product-PowerRename

### Description of the new feature / enhancement

I would like to have the ability to reference some of the data within a file's properties in order to rename it.
For example, a video file may have properties like "frame rate" and "frame height" populated. An audio file may have properties like "Title" and "Album" populated. Those fields could be very useful for procedurally generating a useful file name.

### Scenario when this would be used?

In my specific use case, I have a lot of music files with very generic filenames like "song-1", "song-2", etc. , but all of the files have the proper song title contained in their metadata in the "Title" field. If I had some way of referencing the title field in PowerRename, I could rename all of the Files to the value of "Title" and I would be able to rename every song in a single click.

### Supporting information

![PowerRename Feature Request](https://user-images.githubusercontent.com/4276224/194768134-d0afb831-f558-48a7-8421-d64e11c3a3e5.png)
Repository: godot
Issue: Adding a collision shapes to Tileset with GDScript not working
Labels: bug,topic:core,topic:physics,needs testing,topic:2d

### Godot version

4.0 Beta 2

### System information

Windows 10

### Issue description

I'm importing Tilesets from Tiled.
I create the tileset Data with gdscript.

i can add a physics layer to a tilset but then i'm not able to add collision polygons or the data for it beacuse godot says:

> scene/resources/tile_set.cpp:5189 - Index p_layer_id = 0 is out of bounds (physics.size() = 0).

i can count the physics layers of the tileset and it says there is one but somehow the layer index doesn't count and it's not working

### Steps to reproduce

create a tileset through code
add a physics layer and try to change the tiledata of a tile with adding a polygon to the physics layer

### Minimal reproduction project

_No response_
Repository: rust
Issue: Unresolved import (E0432) when use'ing name that shadows a star-imported one
Labels: A-diagnostics,T-compiler

Let's say we have the following layout of files (simplified example with (hopefully) irrelevant details omitted):

## common/animation/plugins.rs

```rust
use bevy::prelude::*;

// shadows bevy::prelude::AnimationPlugin
pub struct AnimationPlugin;
```

## common/animation/mod.rs

```rust
mod animation;

pub use self::plugins::*;
```

## app.rs

```rust
use crate::common::animation::AnimationPlugin;
```

This results in the following error:

```
error[E0432]: unresolved import `crate::common::animation::AnimationPlugin`
  --> src/app.rs:11:5
   |
11 | use crate::common::animation::AnimationPlugin;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0432`.

```

At best, this is a confusing diagnostic message. The import isn't unresolved, though it might be ambiguous as to which `AnimationPlugin` we are referring to here. The message should highlight this fact, making it more clear what the possible solutions are (e.g. replacing `use bevy::prelude::*;` with more selective imports).

However, I'm not entirely sure if this is even the correct behavior. At any point inside `common::animation::plugins`, it is perfectly unambiguous which `AnimationPlugin` we are referring to; the custom one shadows the one defined in `bevy::prelude`. But for some reason, this doesn't carry over through a simple re-export in `common::animation` root module.

I'm reluctant to flag this as a compiler bug because I don't claim to fully understand the expected language rules here, but hopefully someone from the Rust team can determine if this is intended. But even if it's correct for the compiler to reject this code, the resulting error message could definitely be more clear.
Repository: godot
Issue: Vulkan canvas_item shader different to GLS3
Labels: topic:rendering,documentation,topic:thirdparty,topic:shaders

### Godot version

v4.0.beta.custom_build [380fba627]

### System information

Windows 10, Vulkan

### Issue description

Porting projects with complex shaders from 3.x GLS3 to 4.x Vulkan, trying to fix what appears broken. 
I've tried to strip it down to simpler parts that still showcase the issue. A ShaderMaterial applied to a ColorRect. None of the 'texture_filter' options seem to have any impact, nor 'texture_repeat' options in the node (which makes sense to me when directly modifying 'COLOR' in a canvas_item).
Godot 3.5:
![image](https://user-images.githubusercontent.com/115422160/194772416-42462893-c88f-4858-b177-689a9ffdbb74.png)

Godot 4 [380fba627]:
![image](https://user-images.githubusercontent.com/115422160/194771929-4688b1e6-2228-4789-b709-33d7ea380f82.png)

I've tried different render modes to no avail, maybe there's a project setting I'm missing. I know 'MODULATE' is gone and 'COLOR' has new behaviour but it doesn't seem related.

### Steps to reproduce

Same shader code on both projects:
```glsl
shader_type canvas_item;

float hash12(vec2 p) {
	return fract(sin(dot(p, vec2(12.9898,12.1414))) * 83758.5453);
}

float noise(vec2 n) {
	vec2 v2_floor = floor(n);
	vec2 v2_fract = fract(n);
	float m1 = mix(hash12(v2_floor), hash12(v2_floor + vec2(1.0, 0.0)), v2_fract.x);
	float m2 = mix(hash12(v2_floor + vec2(0.0, 1.0)), hash12(v2_floor + vec2(1.0)), v2_fract.x);
	float m3 = mix(m1, m2, v2_fract.y);
	return m3;
}

void fragment() {
	vec2 v_uv = UV*5.0;
	float n = noise(v_uv);
	COLOR = vec4(n);
}
```

### Minimal reproduction project

[Shader Issue 4.x.zip](https://github.com/godotengine/godot/files/10189068/Shader.Issue.4.x.zip)
[Shader Issue 3.x.zip](https://github.com/godotengine/godot/files/10189069/Shader.Issue.3.x.zip)
Repository: pytorch
Issue: Data conversion ops ignore `memory_format=torch.contiguous_format` 
Labels: triaged,module: primTorch

### 🐛 Describe the bug

**Bug**: a _contiguous_ format is requested for a _non-contiguous_ input, but a _non-contiguous view_ is returned.

Likely this is the same for all data conversion ops:
`bool`, `bfloat16`, `byte`, `char`, `double`, `float`, `half`, `int`, `long`, `short`.

Probably only happens when input dtype matches the conversion op (like `torch.bool` and `.bool()`).

**Expected**: a _contiguous copy_ is returned instead. Note: in primTorch, `to` returns a  _contiguous copy_ in this case.

```py
#!/usr/bin/env python3

import torch

input = torch.tensor([[True, False, False], [False, False, False]])
args = ()
kwargs = {'memory_format': torch.contiguous_format}

print("is contiguous?", input.is_contiguous())
input = input.t()
print("is contiguous after transpose?", input.is_contiguous())
print("is view?", input._is_view())

op=lambda x, *args, **kwargs: x.bool(*args, **kwargs)

torch_result = op(input, *args, **kwargs)

print()
print("torch is view?", torch_result._is_view())
print("torch is contiguous?", torch_result.is_contiguous())
```

Output:
```
is contiguous? True
is contiguous after transpose? False
is view? True

torch is view? True
torch is contiguous? False
```



### Versions

master (67434c70df5df353944f6ba876d9dd06b669bacd)

cc @ezyang @mruberry @ngimel @Lezcano @fdrocha
Repository: storybook
Issue: Add thumbnails to the left menu
Labels: feature request,needs triage

**Is your feature request related to a problem? Please describe**
For big and nested trees, it's hard to navigate in the component index shown in the left menu. 

**Describe the solution you'd like**
Generate thumbnails for each story showing the component that it renders. 

**Describe alternatives you've considered**
Picking different icons or colors to serve as bullets to the items (poor option IMO)

**Are you able to assist to bring the feature to reality?**
yes, 

**Additional context**
The tree icons are not semantic and they don't help into identifying the component when you have a big tree. On the other side, having thumbnails would incredibly increate the navigation because of the direct relation between the component and the thumbnail. We could also have a "mouseOver" to show a bigger image before the user decides to navigate. 

<img width="317" alt="Screen Shot 2022-10-09 at 17 15 41" src="https://user-images.githubusercontent.com/217240/194777747-687685b5-14ed-43c3-8122-6367db799e8a.png">

I have not used it before, but this looks like a helpful tool to help accomplishing this goal: 
https://www.npmjs.com/package/use-react-screenshot
Repository: godot
Issue: Setting AnchorPreset in _Ready has no effect
Labels: bug,topic:gui

### Godot version

4.0.dev (17c62a692)

### System information

Windows 10, Vulkan, AMD Radeon RX 6700 XT

### Issue description

I created a tool script which dynamically creates controls in the _Ready function.
For one of the controls I need to set the AnchorPosition to CenterLeft.

However when setting AnchorPreset in the _Ready or _Init function the editor shows that the property has this value, but the control still remains in it's default position.

Doing the same using set_deffered works as expected.


### Steps to reproduce

Create a control and assign a tool script.

In this tool script try to set an AnchorPreset in _ready like FullRect or CenterLeft.

When you now instantiate the control in another script or add this node from the node selection (only works if you add a class_name to the tool script)

### Minimal reproduction project

Instantiate a new instance of BuggyControl.gd (with Add node)
Control should be full size but stays in the default one instead.

[BugReport1.zip](https://github.com/godotengine/godot/files/9742687/BugReport1.zip)

The same happens with
anchor_preset = Control.PRESET_FULL_RECT
set_anchors_preset(Control.PRESET_FULL_RECT, true)
set_anchors_preset(Control.PRESET_FULL_RECT, false)
Repository: rust
Issue: Is exact count of other implementations useful in this error message?
Labels: A-testsuite,C-enhancement,A-diagnostics,T-compiler,D-papercut,A-contributor-roadblock

I got the following CI failure in #102862
```text
---- [ui] src/test/ui/try-trait/bad-interconversion.rs stdout ----
diff of stderr:

16	             <f64 as From<i16>>
17	             <f64 as From<i32>>
18	             <f64 as From<i8>>
-	           and 67 others
+	           and 68 others
20	   = note: required for `Result<u64, u8>` to implement `FromResidual<Result<Infallible, i32>>`
21	
22	error[E0277]: the `?` operator can only be used on `Result`s, not `Option`s, in a function that returns `Result`
```

I don't know if this is a diagnostics request or a UI test normalization request, but getting UI test failures when adding a `From` implementation is kinda annoying (if admittedly easy enough to fix).

So I wonder how much value the exact number here is providing.  I wonder if it might make sense to change the message to 

> and many others

if it's above some threshold.

I can't see any reason the exact count is useful to the programmer reading the error (at least when it's a large number), and it might save some work in error message generation to stop once it's found a bunch.
Repository: stable-diffusion-webui
Issue: Use zoomed in Stable Diffusion for face restoration
Labels: enhancement

**Is your feature request related to a problem? Please describe.**
The existing face restoration models work well on photos, but not on cartoons and anime.  Right now, I can improve anime faces by manually going to inpainting, masking the face, turning on inpainting at full resolution, and setting the masked content to "original", and this works extremely well, but it's a manual process.  Since it's already possible to detect faces, I feel like it ought to be possible to run Stable Diffusion with the same prompt (or optionally with a different one) zoomed in on the face and then resize it the way that can be done manually with inpainting.

**Describe the solution you'd like**
Allow us to select SD as a face restoration option, and then do the above automatically.

**Describe alternatives you've considered**
Doing it manually.

**Additional context**
Add any other context or screenshots about the feature request here.
Repository: godot
Issue: Internal collision position doesn't update immediately when changing a CharacterBody's CollisionShape position.
Labels: topic:physics

### Godot version

4.0 beta 2

### System information

Ubuntu 22.04.1 LTS

### Issue description

If you enable a CollisionShape and change its position in a script, for one physics frame it will detect collisions in its old place, although the node updates correctly.

### Steps to reproduce

1. Create a CharacterBody2D and give it a CollisionShape2D.
2. Make a script and in `_physics_process` add some kind of toggle that disables the CollisionShape2D and moves it a bit down, then enables it and moves it back up. At the start of the method, print something out.
3. Create an Area2D with its CollisionShape2D right under the CharacterBody2D.
4. Connect the Area2D's `body_entered` signal to the script and also make it print something.

And then watch Area2D report that a body has entered it, even though the CollisionShape2D exits it when enabled again. `physics_process` will even run again before the Area2D mistakenly reports.

### Minimal reproduction project

The MRP I put here is a bit more complex than the reproduction steps, though it showcases the issue in 2D and 3D, and is similar to how one may implement a crouch hitbox.

[PhysicsUpdateLate.zip](https://github.com/godotengine/godot/files/9743015/Highlighting.zip)
Repository: storybook
Issue: Web components argTypes mapper makes controls for internal/private members
Labels: bug,needs triage

**Describe the bug**
At least in the case of using `@custom-elements-manifest/analyzer` interpreting `stencil` components:

The `members` array documents all class members, whether they are exposed attributes/properties, internal methods, or otherwise. This line overwrites the `attribute` argTypes with `members` (categorized incorrectly(?) as `properties`), which creates controls for every field and method in the component, no matter what decorators are applied to the field (even "private", which is included in the manifest, is ignored here).

Here is the line: https://github.com/storybookjs/storybook/blob/ea70649db9bce2ed4ad2b1eaa13a380fb8cc8e57/code/renderers/web-components/src/docs/custom-elements.ts#L149

See the problem description and images in the issue I sent to open-wc: https://github.com/open-wc/custom-elements-manifest/issues/187

**To Reproduce**
The repro instructions don't work for this, because sb needs to be applied to an existing stencil project.
When connecting a stencil project to Storybook via a custom elements manifest like so:
```
import { defineCustomElements } from '../dist/esm/loader';
import { setCustomElementsManifest } from '@storybook/web-components';
import manifest from '../custom-elements.json';

defineCustomElements();
setCustomElementsManifest(manifest)
```
And the custom elements manifest is generated by @custom-elements-manifest/analyzer, we get all fields and functions, private/internal or not, added to the `members` array in addition to whatever other arrays apply-- most notably `attributes`, which is where exposed stencil attribute/properties (marked with `@Prop()` decorator) go.

Storybook then creates `argTypes` from `attributes`, then overwrites those with `argTypes` from `members` which includes _everything_. Then we have controls and docs for implementation details that are not exposed and should not be part of this documentation.

Storybook could just create controls from `attributes` and `properties`, but at the very least it should look for the `private` field to omit those from documentation.

**Additional context**
Found a related issue: https://github.com/storybookjs/storybook/issues/15436
Repository: pytorch
Issue: Instructions for Selective Build for Mobile Linux Platform
Labels: oncall: mobile

### 📚 The doc issue

1. The docs. at https://pytorch.org/tutorials/prototype/tracing_based_selective_build.html include instructions for iOS/Android, but not for Linux. Please could you add instructions for Linux?
2. The instructions on that page don't include a call to `optimize_for_mobile()`. Is it a required step or can selective build work without `optimize_for_mobile()`?
3. I also want to know a quick way to be able to check the approximate size change for my PyTorch build for the set of models I want to work with - is there any way to do that w/o doing a complete selective build?

The page above says:

> The custom build is still under development, and we will continue improving its size in the future. Note, however, that the APIs are subject to change in future versions.

4. What other size improvements can be expected in the future?


### Suggest a potential alternative/fix

1. Inclde steps for Linux based build
2. Clarofy if `optimize_for_mobile()` is a required step and what it does - I can't find documentation about this
3. ??
4. ??
Repository: vscode
Issue: Dropdowns are taller on web compared to desktop
Labels: ux,polish

## vscode.dev
<img width="499" alt="CleanShot 2022-10-09 at 20 16 01@2x" src="https://user-images.githubusercontent.com/25163139/194794695-7732282b-197c-4cfa-9878-0d04a9113140.png">

## macOS
<img width="483" alt="CleanShot 2022-10-09 at 20 15 45@2x" src="https://user-images.githubusercontent.com/25163139/194794699-a4950f93-7440-4854-88e2-af698e3d7673.png">