sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Flags for GradientTexture2D and GradientTexture are ignored
Labels: bug,topic:core

### Godot version

v3.5.stable.official [991bb6ac7]

### System information

Ubuntu 22.04, AMD Radeon RX 6700 XT, driver: amdgpu

### Issue description

Updating the gradient in the editor will update its display ignoring any flags set, this is fixed when you update the flags by hand.
![Peek 2022-08-08 09-38](https://user-images.githubusercontent.com/8540266/183463184-e44d7ed5-6a9d-457f-9c1a-f31adaa38174.gif)
When running the scene, the flags will be completely ignored.
![ignored_at_runtime](https://user-images.githubusercontent.com/8540266/183467076-9da17d83-aac7-4abc-b449-1647e657aa99.gif)


The behavior above happens with GradientTexture2D. With GradientTexture the flags can't even be set to begin with
![cant_set_flags](https://user-images.githubusercontent.com/8540266/183466374-396dea9f-e73e-472d-bf52-6b17763731fa.gif)


There's another issue, which might be linked, regarding resizing the texture after the gradient has been updated to a different width/height
![doesnt-allow-resize](https://user-images.githubusercontent.com/8540266/183475377-c7ade3dc-8baf-4758-b65a-343c89f7c9e7.gif)




### Steps to reproduce

GradientTexture2D:
- Create a TextureRect
- assign it a GradientTexture2D
- assign the GradientTexture2D a Gradient
- unset all flags on the GradientTexture2D
- modify the gradient.

GradientTexture:
- Create a TextureRect
- assign it a GradientTexture
- attempt to modify flags


### Current workaround:

Regarding GradientTexture2D, the flags can be set just fine through code once a frame has passed. So putting this code at the end of a _ready function would fix it.
`yield`ing for `ready` doesn't solve it, but `yield`ing for an `idle_frame` does.
```
# save intended_value
var aux_flags = texture_rect.texture.flags
# change it to force an update, otherwise it is ignored
texture_rect.texture.flags = aux_flags+1
yield(get_tree(),"idle_frame")
texture_rect.texture.flags = aux_flags
```

This doesn't apply, however, to GradientTexture, the flags don't seem to respond to either code nor editor changes.

### Minimal reproduction project

[gradient bug.zip](https://github.com/godotengine/godot/files/9283495/gradient.bug.zip)
Repository: godot
Issue: Drag/box select does not work unless Vector3.ZERO is included in bounding box
Labels: bug,topic:editor,usability,topic:3d

### Godot version

3.5 stable

### System information

Windows 10 GTX 10606gb intel 4690k

### Issue description

When using drag/box select, it is expected that everything within the box is selected.

However, this is not true


https://user-images.githubusercontent.com/83078010/183469729-a862e7e6-3a15-46bf-ab0b-c95e12256cae.mp4





When you instance in a mesh instance, and attempt to select it, without the origin inside the bounding box, it will fail

This happens regardless of node orientation, selection etc.

### Steps to reproduce

1. Instance a mesh instance
2. Give it a box shape
3. Move it away from Vector3.ZERO
4. Try to box select it without Vector3.ZERO inside the bounding box

### Minimal reproduction project

[Bug.zip](https://github.com/godotengine/godot/files/9283551/Bug.zip)
Repository: vscode
Issue: Hover indication can stuck on multiple submenu options in main menu
Labels: bug,menus

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.70.0
- OS Version: Windows 10 Pro 21H2

Steps to Reproduce:

1. Open main menu's **3rd or 4th level**, on upper menu levels this issue does not occur:
1.1. If menu bar is disabled: starting from `Menu → View → Appearance` or any deeper nesting level
1.2. if menu bar is enabled: `View → Appearance → Panel position` for instance
2. Move cursor away from submenu to the right, then move cursor back to one of that submenu's options and move cursor again away from submenu but during disappearance animation of editor's scrollbar or after animation is finished. Hover indication will remain on that submenu option
3. Then if you move cursor back to **another** submenu's option, hover indication on that previously hovered option will remain and hover indication will appear on currently hovered option too
4. But again if you move cursor away from submenu during aforementioned animation or after it, hover indication will remain on 2 submenu options already
5. You can move cursor to one more option and it will have hover indication too additionally to two previous options
6. And that trick can be performed until every option of that submenu will have hover indication including options that has its own submenu.

**Actually I don't know if this issue is really somehow related to editor's scrollbar or it is a coincidence, but it seems that somehow animation affects appearance/disappearance of submenu options hover.**

Also I checked if that issue occurs if only Get started page is opened and if there is no opened tabs at all, and it behaves the same in all cases.

Example of this behavior you can see in the video below:

https://user-images.githubusercontent.com/44531490/183479896-8f3003cd-93a3-46ee-beee-c0f796efe7c9.mp4
Repository: godot
Issue: Octree collision broken?
Labels: bug,topic:physics,needs testing

### Godot version

3.5.stable.arch_linux

### System information

Operating System: EndeavourOS KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.18.16-arch1-1 (64-bit) Graphics Platform: X11 Processors: 6 × Intel® Core™ i5-8400 CPU @ 2.80GHz Memory: 15.6 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: Z370 AORUS Gaming WIFI

### Issue description

Disabling BVH collision will cause the game to crash with an error after moving character:
```
E 0:00:04.714   ~List: Condition "_first != nullptr" is true.
  <C++ Source>  ./core/self_list.h:108 @ ~List()
```

### Steps to reproduce

1. Turn off `Project Settings->General->Physics->3D->Godot Physics->Use BVH`
2. Start game
3. Move character around for a bit until it crashes with the error above.

### Minimal reproduction project

Note: rename to `FPS-test.tar.lzma` after download.
[FPS-test.zip](https://github.com/godotengine/godot/files/9284604/FPS-test.zip)
Repository: PowerToys
Issue: [PowerToys Run] Activation shortcut application exclusions
Labels: Idea-Enhancement,Product-PowerToys Run,Needs-Triage

### Description of the new feature / enhancement

Right now there isn't a way to stop the hotkey to open up PowerToys Run while a certain application is focused.

It would be great if there was a blacklist where all the selected applications would stop PowerToys Run to show up if the hotkey is pressed and the application is focused.

### Scenario when this would be used?

It would be useful in certain scenarios like games where the ALT+SPACE hotkey (the default one and the easiest one to press) should do something and PowerToys Run keeps showing up instead.

### Supporting information

_No response_
Repository: godot
Issue: Search/Replace in Files shortcuts don't work without opened scripts
Labels: enhancement,topic:editor,usability

### Godot version

4.0.alpha13

### System information

Ubuntu 20.04.3 LTS

### Issue description

When all scripts are closed, the "Search in Files" and "Replace in Files" operations are still useful. But they don't work.

### Steps to reproduce

Close all files while in the script editor. Try Ctrl+Shift+F or Ctrl+Shift+R and see that it doesn't work.

### Minimal reproduction project

N/A
Repository: godot
Issue: AnimatedSprite | Select Frames dialog, auto-select field contents
Labels: enhancement,topic:editor,usability,topic:gui

### Godot version

3.5.stable.official

### System information

Windows 10

### Issue description

When using the `AnimatedSprite | Select Frames` dialog, the current field (Horizontal, Vertical, Size, Separation, Offset) contents are not "auto-selected" when the field receives focus (either by pressing `Tab` or `mouse-click` into the field).

So, if you tab across the fields (for example) and enter values the typed information is concatenated to each field's current content rather than replacing it. So, to effectively change a value, you must either `Ctrl-A` to select everything in the field prior to typing or manually delete the current contents. This makes changing all of the fields much harder than necessary.

![image](https://user-images.githubusercontent.com/1459347/183498881-d78b6f4e-e8fe-4013-bddb-6d650fc9504f.png)



### Steps to reproduce

- Add an `AnimatedSprite` node the scene
- Set the `Frames` field to _new SpriteFrames_
- Selec the new `SpriteFrames` item to open the Animation Editor
- Create a new animation
- Press the `Add Frames from a Sprite Sheet` button in the editor's toolbar
- Select a sprite sheet file to open the _Select Frames_ dialog
- The fields at the top of the dialog have the described issue

### Minimal reproduction project

Unnecessary here I think, but happy to provide something if needed.
Repository: godot
Issue: Vulkan: VoxelGI does not take custom shaders into account for emission if the mesh's GI mode is Static
Labels: topic:rendering,documentation,topic:shaders,topic:3d

### Godot version

4.0.alpha13

### System information

Fedora 36, GeForce GTX 1080 (NVIDIA 515.57)

### Issue description

VoxelGI does not take custom shaders into account for emission if the mesh's GI mode is Static.
This may be a limitation, in which case this should be documented.

![2022-08-08_21 44 41](https://user-images.githubusercontent.com/180032/183502433-8a8d227d-c490-483e-b5f2-7b70feafcdd0.png)

For reference, it works with LightmapGI (dynamic objects are not included in the bake as expected):

![image](https://user-images.githubusercontent.com/180032/232611900-3a6b215c-7795-4882-ab83-cef631ecafc9.png)

### Steps to reproduce

- Add MeshInstance3D to act as a floor, with Static global illumination mode.
- Add a second MeshInstance3D with an emissive BaseMaterial3D (StandardMaterial3D). Keep its GI mode to the default Static.
- Add a third MeshInstance3D (with static GI mode). Assign it a ShaderMaterial whose contents are:

```glsl
shader_type spatial;

void fragment() {
	EMISSION = vec3(0.0, 1.0, 0.6);
}
```

- Add a VoxelGI node covering all 3 meshes, then click **Bake** at the top of the 3D editor viewport.

### Minimal reproduction project

[test_voxelgi_custom_shader_emission.zip](https://github.com/godotengine/godot/files/9284649/test_voxelgi_custom_shader_emission.zip)
Repository: godot
Issue: Vulkan: VoxelGI emission for meshes with Dynamic GI mode is much darker than Static
Labels: bug,topic:rendering,topic:3d

### Godot version

4.0.alpha13

### System information

Fedora 36, GeForce GTX 1080 (NVIDIA 515.57)

### Issue description

VoxelGI emission for meshes with Dynamic GI mode is much darker than Static. This is problematic for performance reasons as [Dynamic is significantly slower compared to Static](https://github.com/godotengine/godot/issues/55359).

![2022-08-08_21 44 41](https://user-images.githubusercontent.com/180032/183502433-8a8d227d-c490-483e-b5f2-7b70feafcdd0.png)

This darker apperance applies both to base material and custom emission shaders. Note that emission on Static meshes doesn't work for custom shaders (see https://github.com/godotengine/godot/issues/64124).

### Steps to reproduce

- Add MeshInstance3D to act as a floor, with Static global illumination mode.
- Add a second MeshInstance3D with an emissive BaseMaterial3D (StandardMaterial3D). Keep its GI mode to the default Static.
- Add a third MeshInstance3D with an emissive BaseMaterial3D (StandardMaterial3D). Set its GI mode to Dynamic instead of the default Static.

```glsl
shader_type spatial;

void fragment() {
	EMISSION = vec3(0.0, 1.0, 0.6);
}
```

- Add a VoxelGI node covering all 3 meshes, then click **Bake** at the top of the 3D editor viewport.

### Minimal reproduction project

[test_voxelgi_custom_shader_emission.zip](https://github.com/godotengine/godot/files/9284649/test_voxelgi_custom_shader_emission.zip)
Repository: pytorch
Issue: TestCommon.test_dtypes error message is confusing
Labels: triaged,module: testing

### 🚀 The feature, motivation and pitch

Here's what I think test_dtypes is doing:
- for each dtype, check if `op(*args, **kwargs)` works
- if it works, then add the dtype to a list of "acceptable" dtypes
- if it fails, then don't add the dtype to a list of acceptable dtypes.

test_dtype suppresses the error messages of those failures. This is confusing, because the error message suggests that the supported dtypes are wrong, but something else (e.g. a change to torch.testing) could responsible:
"AssertionError: The supported dtypes for _refs.broadcast_shapes on device type cpu are incorrect!
The following dtypes did not work in forward but are listed by the OpInfo: {torch.float32}." Furthermore, it makes it more difficult to debug because there is no exception to do a backtrace from.

I don't know if it would make the UX worse, but could we include the error messages of failures in the error message?


### Alternatives

_No response_

### Additional context

_No response_
Repository: pytorch
Issue: New PR template suggests a pattern that does not close PR
Labels: triaged

### 🐛 Describe the bug

https://github.com/pytorch/pytorch/pull/81991 introduced new template, which makes it harder for new contributors to mark PRs as fixing particular issue

Also, it is more verbose when ignored, perhaps we should come up with strategy to skip it if not filled, otherwise committed PR descriptions looks as follows(from https://github.com/pytorch/pytorch/commit/8d1ff9fc5dc70bdc65a83748c01cddf187728452):
```
### Description
<!-- What did you change and why was it needed? -->

### Issue
<!-- Link to Issue ticket or RFP -->

### Testing
<!-- How did you test your change? -->

Pull Request resolved: https://github.com/pytorch/pytorch/pull/82505
Approved by: https://github.com/razarmehr, https://github.com/albanD
```

### Versions

CI
Repository: pytorch
Issue: Support for CSR Tensor with NN layers
Labels: module: sparse,module: nn,triaged

### 🐛 Describe the bug

When I try to pass a CSR tensor to a forward pass for a NN it outputs NaN.

Here is the NN:


```
class Net(torch.nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        self.conv1 = GCNConv(292, 8)
        self.conv2 = GCNConv(8, 7)

    def forward(self, data):
         x, edge_index = data.x.to_dense(), data.edge_index
         x = self.conv1(x, edge_index)
         x = F.relu(x)
         x = F.dropout(x, training=self.training)
         x = self.conv2(x, edge_index)
         return F.log_softmax(x, dim=1)
```


Are there any specific reasons why CSR tensors are not supported yet?

### Versions

PyTorch 1.10

cc @nikitaved @pearu @cpuhrsch @amjames @bhosmer @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
Repository: angular
Issue: Canonical: Unexpected Behavior related to selector matching
Labels: area: core,core: directive matching,P3,canonical

### Which @angular/* package(s) are the source of the bug?

core

### Is this a regression?

No

### Description

There are cases where selector matching behavior can cause confusion due to it behaving in unexpected ways.

Examples:
#46986

### Please provide a link to a minimal reproduction of the bug

_No response_

### Please provide the exception or error you saw

_No response_

### Please provide the environment you discovered this bug in (run `ng version`)

_No response_

### Anything else?

_No response_
Repository: pytorch
Issue: [JIT] Scripting modules fails for modules that contain nested NamedTuples
Labels: oncall: jit

### 🐛 Describe the bug

When scripting a module that contains a nested NamedTuple instance variable, scripting fails.

Repro:
```python
import torch

from typing import NamedTuple, List

class AA(NamedTuple):
    a: torch.Tensor

class BB(NamedTuple):
    a: AA

class MyModule(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.x = BB(AA(torch.rand(2, 2)))

    def forward(self, input: BB) -> torch.Tensor:
        return self.x.a.a

torch.jit.script(MyModule())

'''
Traceback (most recent call last):
  File "/data/users/dberard/scripts/oncall/jackie.py", line 19, in <module>
    torch.jit.script(MyModule())
  File "/data/users/dberard/pytorch/torch/jit/_script.py", line 1286, in script
    return torch.jit._recursive.create_script_module(
  File "/data/users/dberard/pytorch/torch/jit/_recursive.py", line 476, in create_script_module
    return create_script_module_impl(nn_module, concrete_type, stubs_fn)
  File "/data/users/dberard/pytorch/torch/jit/_recursive.py", line 542, in create_script_module_impl
    create_methods_and_properties_from_stubs(concrete_type, method_stubs, property_stubs)
  File "/data/users/dberard/pytorch/torch/jit/_recursive.py", line 393, in create_methods_and_properties_from_stubs
    concrete_type._create_methods_and_properties(property_defs, property_rcbs, method_defs, method_rcbs, method_defaults)
RuntimeError:
'Tuple[Tuple[Tensor]]' object has no attribute or method 'a'.:
  File "/path/to/repro.py", line 17
    def forward(self, input: BB) -> torch.Tensor:
        return self.x.a.a
               ~~~~~~~~ <--- HERE
'''
```

### Versions

master branch, `e3dd4242657232d4b404465f2df848050cd7f088`
Repository: kubernetes
Issue: Cadvisor manager update machine info periodically, but hugepage info in node status is only updated when kubelet starts
Labels: kind/bug,area/kubelet,sig/node,sig/instrumentation,triage/accepted

### What happened?

Our resource management component fails, causing hugepage information on OS taking effect after kubelet starts. When hugepage information is updated on OS, k8s node status still has "0" about hugepage resource.

### What did you expect to happen?

Hugepage information in node status can be update dynamically

### How can we reproduce it (as minimally and precisely as possible)?

1、Start kubelet
2、Update hugepage information on OS

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
```
1.22.3

</details>


### Cloud provider

<details>
none
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>
docker 17.03.3
</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: pytorch
Issue: FSDP init can crash with shared parameters
Labels: high priority,triage review,oncall: distributed,triaged,module: fsdp

### 🐛 Describe the bug

FSDP initialization can crash when modules with shared params are wrapped separately. For example, if wrap https://github.com/facebookresearch/multimodal/blob/679f3596e4c44b483c68d4023b24e3c7f77292b3/torchmultimodal/modules/losses/flava.py#L138 linear (decoder) separately from the main module and then wrap the main module with `device_id` argument, this will raise an error due to `bias` param being shared. The `bias` param would have already been moved to GPU by the linear wrapped FSDP unit, but then the higher-level wrapper would still expect it to be on CPU, resulting in this error: https://github.com/pytorch/pytorch/blob/9e65e93c39238ec05aa7913693d7c3e4523bf257/torch/distributed/fsdp/fully_sharded_data_parallel.py#L814

### Versions

main

cc @ezyang @gchanan @zou3519 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
Repository: next.js
Issue: Changes to postcss.config.js do not take effect immediately after dev server restart
Labels: bug,Webpack

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Home
    Binaries:
      Node: 16.16.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.2.5-canary.0
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

next dev

### Describe the Bug

On initial ```next dev```, the source CSS files are processed as expected with the postcss.config.js configuration. This is evident by looking at the computed styles in devtools.
After making and saving changes to postcss.config.js and restarting the dev server, the computed styles do not reflect the changes made to the config file.
After saving a CSS file in a text editor, without even making changes to the file, and Next.js finishes compiling, usually the computed styles reflect the changes made to postcss.config.js (i.e. the source CSS file is processed as expected with the updated config file). Additionally, only that CSS file is processed with the updated postcss.config.js configuration; any other CSS file would have to be saved to update the computed styles.

### Expected Behavior

After making changes to postcss.config.js and restarting the dev server, the output CSS should be processed with the updated PostCSS config file.

### Link to reproduction

https://github.com/ozzy1136/next.js-postcss-config-test

### To Reproduce

1. Run ```git clone https://github.com/ozzy1136/next.js-postcss-config-test.git```
2. Run ```cd next.js-postcss-config-test```
3. Run ```npm install```
4. Run ```npm run dev```
5. Open web browser and inspect styles of ```<div>``` with class testDiv
6. Close the running dev server with ```^C```
7.  Open ```postcss.config.js``` and change the value of "display-two-values" from ```true``` to ```false```
8. Save ```postcss.config.js```
9.  Run ```npm run dev```
10. After compiling and page reload, save ```pages/test.module.css``` in text editor to process with updated PostCSS config file