sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: DISABLED test_device_mode_ops_sparse_mm_reduce_cpu_float32 (__main__.TestDeviceUtilsCPU)
Labels: module: sparse,triaged,module: flaky-tests,skipped,module: unknown

Platforms: asan, linux, mac, macos, win, windows

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

Over the past 3 hours, it has been determined flaky in 35 workflow(s) with 105 failures and 35 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_device_mode_ops_sparse_mm_reduce_cpu_float32`
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 "/Users/ec2-user/runner/_work/pytorch/pytorch/test/test_utils.py", line 1164, in test_device_mode_ops
    for sample in samples:
  File "/Users/ec2-user/runner/_work/_temp/conda_environment_10218731824/lib/python3.9/site-packages/torch/testing/_internal/common_utils.py", line 388, in __next__
    input_idx, input_val = next(self.child_iter)
  File "/Users/ec2-user/runner/_work/_temp/conda_environment_10218731824/lib/python3.9/site-packages/torch/utils/_contextlib.py", line 36, in generator_context
    response = gen.send(None)
  File "/Users/ec2-user/runner/_work/_temp/conda_environment_10218731824/lib/python3.9/site-packages/torch/testing/_internal/common_methods_invocations.py", line 1228, in sample_inputs_sparse_mm_reduce
    torch.eye(m, m)
RuntimeError: Please register PrivateUse1HooksInterface by `RegisterPrivateUse1HooksInterface` first.

To execute this test, run the following from the base repo dir:
    python test/test_utils.py -k TestDeviceUtilsCPU.test_device_mode_ops_sparse_mm_reduce_cpu_float32

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

</details>


Test file path: `test_utils.py`

cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer @jcaip @clee2000
Repository: flutter
Issue: Why both `FLUTTER_TEST_OUTPUTS_DIR` and `FLUTTER_LOGS_DIR`? Which one for logs?
Labels: framework,team-infra,P3,c: tech-debt,triaged-infra

In https://github.com/flutter/flutter/issues/152770, I'm investigating why driver failures are not being stored in LUCI logs.

To my knowledge, we have an environment variable called [`FLUTTER_LOGS_DIR`](https://github.com/search?q=org%3Aflutter+%22FLUTTER_LOGS_DIR%22&type=code), but we also have one called [`FLUTTER_TEST_OUTPUTS_DIR`](https://github.com/search?q=org%3Aflutter+%22FLUTTER_TEST_OUTPUTS_DIR%22&type=code). I know the _former_ is stored on LUCI with some recipe magic, but I can't say the same about the latter.

@cbracken wrote to me in a chat:

> @yjbanov is actually probably the right person to ask since he was the guy who came up with the initial test runner. I honestly have no idea if `FLUTTER_LOGS_DIR` existed at the time and if so, how/when it differed from `FLUTTER_TEST_OUTPUTS_DIR`.
>
> If I were to guess (and it would probably be wrong), I'd guess logs was for logs, and test outputs was for the JSON timeline files etc. that we dump timeline data to?
>
> I have no idea if this is something that end-users rely on... last time I wrote a driver test was probably years ago tbh.
Repository: terminal
Issue: win32-input-mode: clipboard paste weird escape sequences
Labels: Product-Conpty,Area-Input,Issue-Bug

### Windows Terminal version

1.21.1772.0

### Windows build number

10.0.22631.3958

### Other Software

standard ssh, Linux

### Steps to reproduce

1. Copy "test" string to clipboard
2. Run Terminal
3. Connect to Linux via SSH
4. Type `printf "\x1b[?9001h"` to enable win32-input-mode
5. Right-click on the terminal window to paste text from a clipboard

### Expected Behavior

`;4;20;116;1;0;1_;4;20;116;0;0;1_;18;101;1;0;1_;18;101;0;0;1_;3;31;115;1;0;1_;3;31;115;0;0;1_;4;20;116;1;0;1_;4;20;116;0;0;1_`

It's `t`, `e`, `s`, `t` key presses.

### Actual Behavior

`;0;27;1;0;1_;0;91;1;0;1_;0;50;1;0;1_;0;48;1;0;1_;0;48;1;0;1_;0;126;1;0;1_4;20;116;1;0;1_4;20;116;0;0;1_;18;101;1;0;1_;18;101;0;0;1_3;31;115;1;0;1_3;31;115;0;0;1_4;20;116;1;0;1_4;20;116;0;0;1_;0;27;1;0;1_;0;91;1;0;1_;0;50;1;0;1_;0;48;1;0;1_;0;49;1;0;1_;0;126;1;0;1_`

Decoded:
```
| Sequence          | Vk | Sc  | Uc  | Kd   | Cs | Rc | Description           |
|-------------------|----|-----|-----|------|----|----|-----------------------|
| `;0;27;1;0;1_`    | 0  | 27  | Esc | Down | 1  | 1  | Key Esc pressed       |
| `;0;91;1;0;1_`    | 0  | 91  | [   | Down | 1  | 1  | Key [ pressed         |
| `;0;50;1;0;1_`    | 0  | 50  | 2   | Down | 1  | 1  | Key 2 pressed         |
| `;0;48;1;0;1_`    | 0  | 48  | 0   | Down | 1  | 1  | Key 0 pressed         |
| `;0;48;1;0;1_`    | 0  | 48  | 0   | Down | 1  | 1  | Key 0 pressed         |
| `;0;126;1;0;1_`   | 0  | 126 | ~   | Down | 1  | 1  | Key ~ pressed         |
| `;4;20;116;1;0;1_`| 4  | 20  | t   | Down | 0  | 1  | Key t pressed         |
| `;4;20;116;0;0;1_`| 4  | 20  | t   | Up   | 0  | 1  | Key t released        |
| `;18;101;1;0;1_`  | 18 | 101 | e   | Down | 0  | 1  | Key e pressed         |
| `;18;101;0;0;1_`  | 18 | 101 | e   | Up   | 0  | 1  | Key e released        |
| `;3;31;115;1;0;1_`| 3  | 31  | s   | Down | 0  | 1  | Key s pressed         |
| `;3;31;115;0;0;1_`| 3  | 31  | s   | Up   | 0  | 1  | Key s released        |
| `;4;20;116;1;0;1_`| 4  | 20  | t   | Down | 0  | 1  | Key t pressed         |
| `;4;20;116;0;0;1_`| 4  | 20  | t   | Up   | 0  | 1  | Key t released        |
| `;0;27;1;0;1_`    | 0  | 27  | Esc | Down | 1  | 1  | Key Esc pressed       |
| `;0;91;1;0;1_`    | 0  | 91  | [   | Down | 1  | 1  | Key [ pressed         |
| `;0;50;1;0;1_`    | 0  | 50  | 2   | Down | 1  | 1  | Key 2 pressed         |
| `;0;48;1;0;1_`    | 0  | 48  | 0   | Down | 1  | 1  | Key 0 pressed         |
| `;0;49;1;0;1_`    | 0  | 49  | 1   | Down | 1  | 1  | Key 1 pressed         |
| `;0;126;1;0;1_`   | 0  | 126 | ~   | Down | 1  | 1  | Key ~ pressed         |
```

As you can see, there are much more key codes. Why?
Repository: godot
Issue: Node 'is_node_ready()' function and 'ready' signal do not function as expected with coroutines
Labels: discussion,topic:core,topic:gdscript,documentation

### Tested versions

v4.2.2.stable.official [15073afe3]

### System information

Godot v4.2.2.stable - Windows 10.0.22631 - GLES3 (Compatibility) - NVIDIA GeForce RTX 4070 Laptop GPU (NVIDIA; 31.0.15.3210) - 13th Gen Intel(R) Core(TM) i7-13700HX (24 Threads)

### Issue description

When waiting for a node to be ready, the 'ready' signal will fire before the _ready() function finishing, if it is a coroutine. Same issue is present when we check if a node is ready via is_node_ready. 

In my opinion (and what I would expect would be the case), nodes should not emit 'ready' until the whole _ready() function runs - even with coroutines - and a node's "is_node_ready" call should return false until the ready call finishes  (even with the coroutines). According to the [docs](https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-private-method-ready), this seems to be the intended behavior (see 'ready' signal description).

Not 100% sure if this is intended behavior, but if it isn't, it would be nice to get a fix, and if it is, then I think the docs for the 'ready' signal and 'is_node_ready' function should clarify that.

### Steps to reproduce

Here is some simple sample code you can throw in any file and run:
```
extends Node

class CustomNode:
	extends Node

	func _ready():
		print("CustomNode ready start")
		await get_tree().create_timer(1).timeout
		print("CustomNode ready end")

	func _init():
		ready.connect(_on_ready)

	func _on_ready():
		print("CustomNode onready")

func _ready():
	var custom_node = CustomNode.new()
	add_child(custom_node)
```
Notice that "CustomNode ready end!" prints _after_ "CustomNode onready." 

### Minimal reproduction project (MRP)

see sample code - not necessary to attach an entire project, just create a new one and throw the above in an autoload script
Repository: flutter
Issue: Impeller MaskFilter.blur isn't invariant over scale transforms
Labels: P2,e: impeller,team-engine,triaged-engine

When drawing a blurred circle whose radius and blur sigma are scaled inversely with the scale applied to the canvas, one would expect a more or less identical result regardless of the scale. This works with Skia, however, with Impeller, there are significant discontinuities with the applied blur.

<details>

<summary> Sample code </summary>

```dart
import 'dart:async';

import 'package:flutter/material.dart';

void main() {
  runApp(const Test());
}

class Test extends StatefulWidget {
  const Test({super.key});

  @override
  State<Test> createState() => _TestState();
}

class _TestState extends State<Test> {
  Timer? _timer;
  double _x = 1.0;
  
  @override
  void initState() {
    super.initState();
    _timer = Timer.periodic(const Duration(milliseconds: 200), _update);
  }

  void _update(Timer timer) {
    setState(() {
      _x *= 10;
      if (_x > 1e20) {
        _x = 1e-20;
      }
    });
  }
  
  @override
  void dispose() {
    _timer?.cancel();
    super.dispose();
  }
  
  @override
  Widget build(BuildContext context) {
    return Stack(
      textDirection: TextDirection.ltr,
      children: [
        CustomPaint(
          painter: Painter(_x),
        ),
        Positioned(
          top: 60.0,
          left: 20.0,
          child: Text(_x.toStringAsExponential(1), textDirection: TextDirection.ltr),
        ),
      ],
    );
  }
}

class Painter extends CustomPainter {
  Painter(this.x);

  final double x;
  
  @override
  void paint(Canvas canvas, Size size) {
    canvas.scale(1.0 / x);
    final Paint paint = Paint()
      ..color = const Color(0xFF66BBFF)
      ..maskFilter = MaskFilter.blur(BlurStyle.normal, 100.0 * x);
    canvas.drawCircle(Offset.zero, 500 * x, paint);
  }

  @override
  bool shouldRepaint(Painter oldDelegate) => x != oldDelegate.x;
}
```

</details>
Repository: neovim
Issue: Intro screen flashes before rgb colors get detected on terminal
Labels: bug,tui,startup

### Problem

This is now very apparent with the new default colorscheme of v0.10, which has significant difference between termguicolors and notermguicolors versions.

My setup is iTerm 2 on MacOS running NeoVim on Linux (Debian Bullseye) via SSH, using `TERM=xterm-256color` setting.

When I start NeoVim, it first shows the intro screen with notermguicolors, and then seems to update to termguicolors, which causes it to briefly "flash" as the colors change, after the intro screen is displayed.

I tried this with Neovim v0.10.1 on MacOS, from the GitHub build, and I don't have a problem there, so not sure what's different between both setups that I see this when running Neovim v0.10.1 from GitHub build on Linux via SSH, perhaps the way terminfo is handled?

Using `nvim -c "set termguicolors"` fixes the flashing, so it's one more indication that it has something to do with the RGB detection.

Happy to try local debugging, just need some pointers of what kind of debugging would be useful, or where I should introduce debugging logic to see what's going on under the hood :-) 


### Steps to reproduce

Just `nvim` or `nvim --clean`, let it show the intro screen and detect the termguicolors setting, but perhaps it needs the specific terminal + O.S. setup I have to reproduce

### Expected behavior

Maybe termguicolors detection should happen earlier than the first screen redraw?

### Neovim version (nvim -v)

0.10.1

### Vim (not Nvim) behaves the same?

N/A

### Operating system/version

Linux Debian Bullseye

### Terminal name/version

iTerm2

### $TERM environment variable

xterm-256color

### Installation

Download tarball from GitHub
Repository: TypeScript
Issue: Add `(` as a commit character to TSServer
Labels: Suggestion,Domain: Completion Lists

### Acknowledgement

- [X] I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

### Comment

VSCode has a setting for enabling `(` as a commit character ("Complete function calls"). In #59339, we started sending commit characters in TSServer, however that doesn't yet include `(`. We should add `(` to the commit characters TSServer sends.
Repository: material-ui
Issue: Add native shadow DOM support for Joy UI Tooltip component
Labels: on hold,package: joy-ui

### Summary

The Joy UI Tooltip component should have native support for usage within a shadow DOM, similar to the existing support for JoyModal and JoyMenu components. This would allow developers to easily use Tooltips in web components or other shadow DOM contexts without needing to implement complex workarounds.

### Examples

Currently, JoyModal and JoyMenu components support shadow DOM usage through a simple prop (in extendTheme):
`
components: {
JoyModal: {
defaultProps: {
container: shadowRootRef.current,
},
},
JoyMenu: {
defaultProps: {
container: shadowRootRef.current,
},
},
}`

We propose that the JoyTooltip component should have a similar API:
`components: {
JoyTooltip: {
defaultProps: {
container: shadowRootRef.current,
},
},
}`


This would allow the Tooltip to render correctly within the shadow DOM while maintaining its positioning relative to the trigger element.

### Motivation

Web components and shadow DOM usage are becoming increasingly common in modern web development. As developers build more complex applications using encapsulated components, it's crucial that UI libraries like Joy UI provide seamless support for these scenarios. 

Currently, implementing tooltips within a shadow DOM requires complex workarounds that can be error-prone and may not work consistently across different environments. Native support for shadow DOM in the Tooltip component would significantly improve developer experience, reduce potential bugs, and make Joy UI more versatile for a wider range of application architectures.

This feature would align with Joy UI's goal of providing a flexible and powerful component library for modern web applications, and would make it easier for developers to create consistent, accessible user interfaces within shadow DOM contexts.

**Search keywords**: joy ui, tooltip, shadow dom, web components
Repository: flutter
Issue: [skwasm] Blur filter does not render as expected at the edges of the picture
Labels: platform-web,P2,e: web_skwasm,team-web,triaged-web

Run this app that renders a blur filter using `flutter -d chrome run --wasm`.  Then shrink the window to the size of the image.

```
import 'package:flutter/material.dart';
import 'dart:ui' as ui;

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return Directionality(textDirection: TextDirection.ltr,
      child: Stack(
        children: [
          Image.network(
            "https://picsum.photos/500?image=15",
            fit: BoxFit.cover,
          ),
          ClipRect(
            child: BackdropFilter(
              filter: ui.ImageFilter.blur(sigmaX: 50, sigmaY: 50),
              child: Container(color: Colors.transparent),
            ),
          ),
        ]
      ),
    );
  }
}
```

The blur effect will not be visible at the right and bottom edges of the window.

This happens because the size of the surface allocated by Skwasm is larger than the window.  The portion of the surface beyond the window bounds is being filled with transparent pixels.  These pixels are then used to compute the blur around the edges of the image, making that part of the image look like it is not blurred.

The CanvasKit backend adjusts the surface size to avoid this (see https://github.com/flutter/engine/commit/c373f704c3676adde135be7ceed9a3a8dbd8fe8e).  Skwasm may need to use a similar strategy.

@eyebrowsoffire
Repository: tauri
Issue: [docs] add typings for `__TAURI_ISOLATION_HOOK__`.
Labels: type: documentation

Currently it's suggested to use untyped JavaScript for implementing the `__TAURI_ISOLATION_HOOK__`.
Recently I tried to implement the hook in TypeScript with Vite, but I recieve type errors. There doesn't seem to be official typings for `__TAURI_ISOLATION_HOOK__`. What is the general structure of an isolation payload? Does it change often, or is it always the same structure?
Repository: rust
Issue: libc::posix_memalign, libc::pwrite and pread are not considered unsafe operation during library build
Labels: C-bug,T-libs,O-vxworks

To resolve build errors, ununused_unsafe is allowed for target VxWorks. 
We use libc::pread as pread64 which is declared as unsafe in libc for VxWorks
https://github.com/rust-lang/rust/blob/master/library/std/src/sys/pal/unix/fd.rs#L129
We use libc::pwrite as pwrite64 which is also an unsafe fn
https://github.com/rust-lang/rust/blob/master/library/std/src/sys/pal/unix/fd.rs#L323

Error
```
error: unnecessary `unsafe` block
  --> std/src/sys/alloc/unix.rs:84:23
   |
84 |             let ret = unsafe { libc::posix_memalign(&mut out, align, layout.size()) };
   |                       ^^^^^^ unnecessary `unsafe` block

error: unnecessary `unsafe` block
   --> library/std/src/sys/pal/unix/fd.rs:137:9
    |
137 |         unsafe {
    |         ^^^^^^ unnecessary `unsafe` block
    |
    = note: `-D unused-unsafe` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(unused_unsafe)]`

error: unnecessary `unsafe` block
   --> library/std/src/sys/pal/unix/fd.rs:330:9
    |
330 |         unsafe {
    |         ^^^^^^ unnecessary `unsafe` block
```
Repository: deno
Issue: deno remove/rm - remove a package added with deno add
Labels: cli,suggestion

Hey folks, Deno is great, thanks!

Is there something like that already? I searched existing and closed issues and couldn't find anything.

Cheers.
Repository: flutter
Issue: Support executing dart from App Intents & Extensions
Labels: c: new feature,framework,P3,team-engine,triaged-engine

### Use case

I would like to execute dart code from Home Screen widgets and the other various intents/extensions and other such places where we currently need to switch to native code for development.

In flutter, you can execute background tasks using dart code https://docs.flutter.dev/packages-and-plugins/background-processes.

This has a major caveat that background tasks are not guaranteed to run depending on the state of the app, which narrows its use case.

It would also dramatically speed up the development of widgets and other extensions if you could write some of your business logic in dart.

A concrete example is my data intensive app is syncing data from firebase to an sqlite database for an offline-first experience. I would like to use the db and sync engine within an interactive widget, but the code is non-trivial and I don't want to replicate it twice again in kotlin and swift. So I'm just bypassing the synced db and directly querying firebase - and have lost the benefits of the offline first. If I was able to call dart code in either app intents or extensions, it would be straightforward for me to use the sync engine and speed up development.

If I was able to execute dart in this scenario I could
- From the widget extension, execute dart code to fetch data from the db, to be displayed using native ui
- On interaction in app intent, execute dart to write to the db & run the sync engine

### Proposal

Something similar to executing background tasks but for app intents
Repository: pytorch
Issue: Support for ROCm 6.2
Labels: module: rocm,triaged,topic: binaries

### 🚀 The feature, motivation and pitch

With the [release](https://rocm.docs.amd.com/en/latest/about/release-notes.html) of ROCm 6.2, it is suitable for PyTorch to release a `.whl`  to accommodate the latest ROCm version. The release notes discuss improvements specifically for some PyTorch utilities, and it would be nice to take advantage of these as soon as possible.

Specifically, there needs to be a `.whl` pushed to `download.pytorch.org/whl/rocm6.2` that is built for ROCm 6.2.

### Alternatives

_No response_

### Additional context

_No response_

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
Repository: rust
Issue: False `error: unknown x86 target feature: avx2` when passed to `is_x86_feature_detected!` as a `literal` instead of `tt`.
Labels: O-x86_64,T-compiler,C-bug,T-libs,A-target-feature

Minimal reproduction:
```rust
macro_rules! x86_feature_detect {
    ($name:ident -> $feature:literal) => {
        #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
        thread_local! {
            pub static $name: core::cell::LazyCell<bool> = core::cell::LazyCell::new(|| is_x86_feature_detected!($feature));
        }

    };
}

x86_feature_detect!(SUPPORTS_AVX -> "avx2");
```
[playground permalink](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0050880397607fdee860a78452d87976)

"avx2" is a feature for x86 documented at <https://doc.rust-lang.org/std/macro.is_x86_feature_detected.html>

The error: 
```
   Compiling playground v0.0.1 (/playground)
error: unknown x86 target feature: avx2
  --> src/lib.rs:11:1
   |
11 | x86_feature_detect!(SUPPORTS_AVX -> "avx2");
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` which comes from the expansion of the macro `x86_feature_detect` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `playground` (lib) due to 1 previous error
```

This error is unclear -- and hard to reason about/diagnose since it comes from within a macro.

Based on the docs at <https://doc.rust-lang.org/std/macro.is_x86_feature_detected.html>, 
I changed the type from `literal` to `tt` and it compiled as expected (["fixed" playground permalink](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2502829d5a139fb109f2614273075939)).

This behavior appears consistent on stable and nightly.