sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Internal SIMD layout specification is not flexible enough for SPIR-V
Labels: T-compiler,A-SIMD,PG-portable-simd,A-repr,A-align

In [`rust-gpu`](https://github.com/Rust-GPU/rust-gpu) we implement a codegen backend for SPIR-V.

SPIR-V supports vector types, which we currently model by analogue of Rust `Abi::Vector` types, i.e. `#[repr(simd)]`. However, SPIR-V supports vector types of the same size that have a different representation depending on their element, which is incompatible with how Rust currently handles vector type data layouts.

## Base SPIR-V Vector Layout

The default representation of SPIR-V vectors is specified in section [2.2.2](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#Vector) and [2.18.1](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_memory_layout) of the SPIR-V spec. This default representation is effectively an align of the underlying element type and size of `element_size * count`. As specified in section [2.16](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_validation_rules), the `count` is limited to 2, 3, or 4 elements, unless certain capabilities are enabled which allow 8 and 16 element vectors as well.

## Extra requirements

However, the actual layout requirements of vector types change and can get rather messy depending on where and how they are used. As far as the SPIR-V spec itself is concerned, the above are the only rules. In practice, you must run SPIR-V code through a client implementation of some graphics API. For Vulkan, this adds extra rules for how you can load vector types from different kinds of buffers. The rules are specified [in the Vulkan specification here](https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#interfaces-resources-layout).

Basically, under so-called *scalar alignment* rules (the least restrictive), stuff in buffers behaves just like `repr(C)` layout, with vectors retaining the property of having the same alignment as their *base element*.

Under the more restrictive layout rules (i.e. older versions of the spec without extensions enabled), vectors start to behave more like on x86 or aarch64: two component vectors have an alignment of twice their base element, and 3 and 4 component vectors both have alignment of 4 times the element.

Something that is unclear to me is whether it's even sensical within Rust's type model to allow the same type to exhibit different alignment requirements in different locations. If not, it makes most sense to me to always follow the *less restrictive* model and force the programmer to respect the more restrictive rules manually where applicable.

## Alternative solutions

We already have a set of `#[spirv(X)]` attributes. It would be possible, though more annoying and perhaps less flexible, for us to implement a `#[spirv(vector)]` attribute which handles things separately. Right now we are [experimenting](https://github.com/EmbarkStudios/rust-gpu/commit/7943f9e1ebbc65afefa7b248836e4e3f1e9377b9) with basically doing this to patch internal simd vector layouting.
Repository: vscode
Issue: Port forwarding fails after codespace restart, or rebuild
Labels: bug,upstream,github-codespaces

I have an example repository where this issue happens. https://github.com/mhitza/codespace-port-forwarding-bug (a devcontainer, a compose file and a Dockerfile which uses the php:8.1-apache as base image). Apache runs in the background and this is the base container in which the codespace user operates.

First time the codespace is built, the port 80 forwarded port will work. Opened in a new tab, a forbidden page should be shown (because this is a minimal reproduction proof on concept and I've included no additional files for Apache to render).

Once the codespace is left (closed), and later returned to it, or the container is rebuilt, the port forwarding will no longer work, and a 502 response will be what I will see instead. However, if I manually remove the port forwarding rule, and add it again manually (just typing port 80 in the field and hitting enter), the forwarding will work once again, until I do any of the previously mentioned actions.

Version: 1.93.1
Commit: 38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0
Embedder: codespaces

<!-- generated by web issue reporter -->
Repository: electron
Issue: [Feature Request]: Draw GTK window shadow when application have custom window frame
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Hello! With gnome-wayland and weston, the job of drawing the window frame, including the shadow, is all up to the client, the wayland server does not draw window shadow for the client. Electron's ozone-wayland normally draws a gtk-based client-side titlebar with the shadow on gnome and weston, this is good. When an application uses a custom window frame under ozone-wayland, electron doesn't draw any gtk decoration, this is good, **however** this extends to the window shadows, so applications with custom window frames **will be missing shadows with ozone-wayland on gnome and weston**

### Proposed Solution

When an app uses a custom window frame and WaylandWindowDecorations is enabled in electron, do not draw GTK window decorations, **but do still draw the GTK window shadow**.

### Alternatives Considered

use a shadow effect available with the rounded window corners reborn gnome extension.

### Additional Information

This is due to the fact GNOME wayland and Weston does not support the xdg-decoration protocol, leaving everything to be drawn by the app, from the window frame to the window shadow.
Repository: flutter
Issue: Allow any flutter.dev/dart.dev package in flutter/packages repo tooling
Labels: team,p: tooling,package,team-ecosystem,P3,triaged-ecosystem

Currently the flutter/packages repo tooling has an allow list for any package that's not an `sdk:` dependency and not from within flutter/packages. However, any package published by flutter.dev or dart.dev publisher accounts is allowed by policy, so it would be simpler (although slightly more fragile from a CI standpoint since it would add more network communication) to query the pub.dev API for the publisher, instead of having to list all of them individually.
Repository: kubernetes
Issue: Separate log and container lifecycle management
Labels: sig/node,kind/feature,lifecycle/rotten,needs-triage

This is a follow-up to issue #123279, as the scope of the discussion has expanded beyond the original issue. Therefore, I am opening a new issue to focus on this topic.

In issue #123279, the goal was to disable kubelet from removing container logs when the container is deleted. However, disabling kubelet from cleaning up logs of removed containers could introduce potential risks, such as log files consuming excessive disk space, eventually leading to the host running out of storage and becoming unresponsive.

With that in mind, I would like to further discuss a topic we had previously considered: **separating the lifecycle management of containers and their logs in kubelet**, with the retention of logs for deleted containers being a subset of this broader topic.
ref: https://github.com/kubernetes/kubernetes/blob/af2bf2d8f1b3437fe67e1686266a176320422465/pkg/kubelet/kuberuntime/kuberuntime_container.go#L1308-L1314

Below are some features that I think:

1. **Rotation and Compression of Logs from Deleted Pods**: Logs for containers are stored by default under /var/log/pods/, with a unique directory structure based on the pod's namespace-podName-podUUID. Perhaps we should consider compressing the entire pod log directory when the pod is deleted?

2. **Kubelet Management of Deleted Pod Logs**: Kubelet should have a clear configuration to manage the cleanup and retention policy for logs from deleted pods. We could introduce new settings, such as **podLogMaxFiles** and **podLogMaxSize**, similar to the existing containerLogMaxFiles and containerLogMaxSize.

3. **Capacity Limits for Pod Log Directories**: Should we enforce a maximum storage limit for pod log directories? If no limit is set, they could potentially fill up the entire host storage.

I'm not entirely sure if these ideas are on the right track, or if simply disabling kubelet's log cleanup for containers is sufficient. I would greatly appreciate any feedback or suggestions.

/sig node
/kind feature
Repository: godot
Issue: Opcode: 4 and 5 (please report) errors on scene Timer when changing code while the game is running
Labels: bug,topic:gdscript,topic:editor

### Tested versions

- Reproducable in Godot 4.3

### System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated AMD Radeon RX 6900 XT (Advanced Micro Devices, Inc.; 32.0.11037.4004) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)

### Issue description

I get different Opcode errors when changing a variable in a script and save while the game is running.
The error appears in a subclass of the script I changed.

![image](https://github.com/user-attachments/assets/e3390179-dfc3-4f34-b430-d59caa30905d)
![image](https://github.com/user-attachments/assets/14caaa12-b14e-4135-930f-1540edb72741)

The code:
![image](https://github.com/user-attachments/assets/8cafc40e-9188-4e93-aece-75a914a55e01)

I saw some issues related to Scene Timers and their cleanup, so maybe related to that.

### Steps to reproduce

1. I change a variable in my superclass script and save
2. The opcode error appears on a script that extends the class
3. It happens on code that create a scene timer, so might be related to that

### Minimal reproduction project (MRP)

Nothing yet, will see if I can make one
Repository: PowerToys
Issue: power toys Bug
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.68.1.0

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

General

### Steps to reproduce

![image](https://github.com/user-attachments/assets/1038c296-c617-44d0-833b-6decd830409a)


### ✔️ Expected Behavior

work normally, i guess...

### ❌ Actual Behavior

Something went wrong


Version: 0.68.1.0
OS Version: Microsoft Windows NT 10.0.22621.0
IntPtr Length: 8
x64: True
Date: 16/09/2024 12:42:31 AM
Exception:
System.IO.IOException: There is not enough space on the disk. : 'C:\Users\HP\AppData\Local\Microsoft\PowerToys\Settings Logs\cc14335e-1873-4718-ad60-bc3811dbe5deLog_2024-09-16.txt'
   at System.IO.RandomAccess.WriteAtOffset(SafeFileHandle handle, ReadOnlySpan`1 buffer, Int64 fileOffset)
   at System.IO.Strategies.OSFileStreamStrategy.Write(ReadOnlySpan`1 buffer)
   at System.IO.Strategies.BufferedFileStreamStrategy.Flush(Boolean flushToDisk)
   at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
   at System.Diagnostics.TextWriterTraceListener.Flush()
   at System.Diagnostics.TraceInternal.WriteLine(String message)
   at Microsoft.PowerToys.Settings.UI.Library.Utilities.Logger.Log(String message, String type)
   at Microsoft.PowerToys.Settings.UI.Library.Utilities.Logger.LogError(String message, Exception e)
   at Microsoft.PowerToys.Settings.UI.Library.SettingsUtils.SaveSettings(String jsonSettings, String powertoy, String fileName)
   at PowerLauncher.SettingsReader..ctor(PowerToysRunSettings settings, ThemeManager themeManager)
   at PowerLauncher.App.<>c__DisplayClass19_0.<OnStartup>b__0()
   at Wox.Infrastructure.Stopwatch.Normal(String message, Action action)
   at PowerLauncher.App.OnStartup(Object sender, StartupEventArgs e)
   at System.Windows.Application.<.ctor>b__1_0(Object unused)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)



### Other Software

_No response_
Repository: ui
Issue: [feat]: Multi state Toggle button
Labels: area: request

### Feature description

There is a [toggle](https://ui.shadcn.com/docs/components/toggle) already but... has only true or false kind of states.

What if a user(me) wants to add Dark mode without using the ugly select mode. Or what if someone wants to use the multi state toggle button to choose between "to do" | "incomplete" | "done" or even "public" | "protected" | " not choosen"

### Affected component/components

toggle, checkbox, any

### Additional Context

Additional details here...

### Before submitting

- [x] I've made research efforts and searched the documentation
- [X] I've searched for existing issues and PRs
Repository: three.js
Issue: ArcballControls error on mobile devices
Labels: Addons

### Description

Please, read:

https://discourse.threejs.org/t/arcballcontrol-problems-on-mobile/70160/3

### Reproduction steps

1.  Set  camera position after the creation of ArcballControls object.
2. On mobile devices, the model vanishes because this._nearPos0 < 0 in ArcballControls.js
3. It does not depend on the browser used.


### Code

```js
// code goes here
```


### Live example

* [jsfiddle-latest-release WebGLRenderer](https://jsfiddle.net/3mrkqyea/)
* [jsfiddle-dev WebGLRenderer](https://jsfiddle.net/gcqx26jv/)
* [jsfiddle-latest-release WebGPURenderer](https://jsfiddle.net/8L2jkmx7/)
* [jsfiddle-dev WebGPURenderer](https://jsfiddle.net/L3n1w4yh/)


### Screenshots

_No response_

### Version

r168

### Device

Mobile

### Browser

Safari

### OS

iOS
Repository: pytorch
Issue: [RFC] Default torch.compile backend customization
Labels: feature,triaged,oncall: pt2,module: inductor

### 🚀 The feature, motivation and pitch

This RFC proposes an enhancement to torch.compile to improve its backend agnosticism. The goal is to enable a more seamless experience for users working with devices that may not be well-supported by the current default backend, Inductor. By allowing for the customization of the default backend, we aim to improve the overall usability of torch.compile across a wider range of hardware.

**Background:** torch.compile currently defaults to the Inductor backend, which is optimized for GPUs and devices that benefit from Inductor's loop-level IR. Users can select the Inductor backend explicitly by specifying backend="Inductor" or implicitly by omitting the backend parameter. However, this can lead to compilation issues on devices without Inductor integration.

**Problem Statement:** The implicit selection of the Inductor backend can cause compatibility issues for devices that do not support it. While explicit backend selection by the user should be respected, the implicit case presents an opportunity to adapt to different device types.

**Proposal:** We propose to introduce a mechanism that allows for the customization of the default backend used by torch.compile. This would enable device-specific backends to be set as the default, thereby making user code more robust and backend-agnostic. For example, on an HPU, the default backend could be set to "hpu_backend," eliminating the need for code modifications when no backend is explicitly defined.

**Implementation:** The customization of the default backend could be achieved through a new configuration option within torch._dynamo.config or a similar in a dedicated configuration space. Device extensions could then specify their preferred backend during their initialization phase, such as during the autoload process (as discussed in https://github.com/pytorch/pytorch/issues/122468).

@albanD @ezyang @jgong5 please provide feedback.

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire
Repository: svelte
Issue: Better effect stack logging
Labels: feature request

### Describe the problem

See https://github.com/sveltejs/svelte/pull/13231#issuecomment-2351790857

### Describe the proposed solution

Attach location information to effects in development, so that it can be used when generating the error message. For simple cases where there's only a single effect involved we can do this sort of thing:

> Uncaught Svelte error: effect_update_depth_exceeded
> Maximum update depth exceeded **in App.svelte:3:1**. This can happen when a reactive block or effect repeatedly sets a new value. Svelte limits the number of nested updates to prevent infinite loops

If there are multiple effects running in a loop, the message could be more like this...

> Uncaught Svelte error: effect_update_depth_exceeded
> Maximum update depth exceeded. This can happen when a reactive block or effect repeatedly sets a new value. Svelte limits the number of nested updates to prevent infinite loops. Last ten effects:
>
> App.svelte:3:1
> App.svelte:10:1
> App.svelte:3:1
> App.svelte:10:1
> App.svelte:3:1
> App.svelte:10:1
> App.svelte:3:1
> App.svelte:10:1
> App.svelte:3:1
> App.svelte:10:1

...or we could try and be smarter about it so that we identify the actual loop (which aside from truly pathological cases should just be a case of going back until we see the most recent effect earlier in the stack?)

### Importance

nice to have
Repository: pytorch
Issue: [torch.export] Dim discrete/finite set
Labels: triaged,oncall: pt2,module: dynamic shapes,export-triaged,oncall: export

### 🚀 The feature, motivation and pitch

Is it possible to introduce `dynamic_shape` discrete/finite set?
Suppose that we need to export a model for a set of well known input resolution at inference. 
It seems currently there is not way to do it a we could define only min and max for Dim. How is it going to create optimized code if we only specify the full range? It seems to me too much relaxed

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @chauhang @penguinwu @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4
Repository: pytorch
Issue: [Distributed] Decouple ProcessGroupNCCL's regular exit from abort
Labels: oncall: distributed

### 🚀 The feature, motivation and pitch

The coupling was an issue left over from the time when `ncclCommDestroy` could hang and `ncclCommAbort` was a stronger hammer.

The downside is that their paths are now entangled in ProcessGroupNCCL and regular exits can see the overhead from the abort side (such as some post-failure processing/logging).

`ncclCommDestroy` is now async to CPU with NCCL non-blocking mode, and we should be able to kill it when it hangs. To avoid the cost from the entanglement, we should move regular exit back to this API. 

### Alternatives

_No response_

### Additional context

Cc: @atuljangra @c-p-i-o 

cc @XilunWu @H-Huang @awgu @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o
Repository: pytorch
Issue: DISABLED test_angle_cpu (__main__.CpuTritonTests)
Labels: triaged,module: flaky-tests,skipped,oncall: pt2,module: inductor

Platforms: inductor

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_angle_cpu&suite=CpuTritonTests&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/30170563905).

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 3 failures and 3 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_angle_cpu`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/workspace/test/inductor/test_torchinductor.py", line 267, in tearDown
    super().tearDown()
  File "/opt/conda/envs/py_3.12/lib/python3.12/site-packages/torch/_inductor/test_case.py", line 35, in tearDown
    self._inductor_test_stack.close()
  File "/opt/conda/envs/py_3.12/lib/python3.12/contextlib.py", line 618, in close
    self.__exit__(None, None, None)
  File "/opt/conda/envs/py_3.12/lib/python3.12/contextlib.py", line 610, in __exit__
    raise exc_details[1]
  File "/opt/conda/envs/py_3.12/lib/python3.12/contextlib.py", line 595, in __exit__
    if cb(*exc_details):
       ^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/py_3.12/lib/python3.12/contextlib.py", line 144, in __exit__
    next(self.gen)
  File "/opt/conda/envs/py_3.12/lib/python3.12/site-packages/torch/_inductor/utils.py", line 839, in fresh_inductor_cache
    shutil.rmtree(inductor_cache_dir)
  File "/opt/conda/envs/py_3.12/lib/python3.12/shutil.py", line 759, in rmtree
    _rmtree_safe_fd(stack, onexc)
  File "/opt/conda/envs/py_3.12/lib/python3.12/shutil.py", line 703, in _rmtree_safe_fd
    onexc(func, path, err)
  File "/opt/conda/envs/py_3.12/lib/python3.12/shutil.py", line 662, in _rmtree_safe_fd
    os.rmdir(name, dir_fd=dirfd)
OSError: [Errno 39] Directory not empty: '/tmp/tmpq_6cxgvi'
```

</details>


Test file path: `inductor/test_triton_cpu_backend.py`

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @clee2000 @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @muchulee8 @ColinPeppler @amjames @desertfire
Repository: pytorch
Issue: DISABLED test_open_device_registration (__main__.TritonExtensionBackendTests)
Labels: triaged,module: flaky-tests,skipped,oncall: pt2,module: inductor

Platforms: asan, linux, rocm, slow



This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_open_device_registration&suite=TritonExtensionBackendTests&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/30169319334).

Over the past 3 hours, it has been determined flaky in 22 workflow(s) with 22 failures and 22 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_open_device_registration`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/workspace/test/inductor/test_triton_extension_backend.py", line 93, in test_open_device_registration
    self.assertTrue(
  File "/opt/conda/envs/py_3.9/lib/python3.9/unittest/case.py", line 688, in assertTrue
    raise self.failureException(msg)
AssertionError: False is not true

To execute this test, run the following from the base repo dir:
    python test/inductor/test_triton_extension_backend.py TritonExtensionBackendTests.test_open_device_registration

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `inductor/test_triton_extension_backend.py`

cc @clee2000 @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire