sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Doubt about the actual behavior of handle.wait() in torch.distributed
Labels: oncall: distributed

### 📚 The doc issue

For `comm_handle.wait()` in the case of async comm, the doc (https://pytorch.org/docs/stable/distributed.html#synchronous-and-asynchronous-collective-operations) says 
`In the case of CUDA collectives, will block until the operation has been successfully enqueued onto a CUDA stream and the output can be utilized on the default stream without further synchronization.`
However, I doubt this should be
`the output can be utilized on the stream in which wait() is called`.

### Suggest a potential alternative/fix

I used nsys to profile a snippet to verify that handle.wait() calls `cudaStreamWaitEvent()`. It occured to me that when called in a stream context, the comm output will be synchonrized to be used on that stream.  Line 14 in python backtrace is exactly `handle.wait()` followed by elt-wise add, and I think this should ensure the correct output.
```
from torch.multiprocessing import spawn
import torch.distributed as dist
import torch
import os
def test(rank, world_size):
    # Code runs on each rank.
    dist.init_process_group("nccl", rank=rank, world_size=2)
    output = torch.ones((1000, 1000)).cuda(rank)
    s = torch.cuda.Stream()
    handle = dist.all_reduce(output, async_op=True)
    # Wait ensures the operation is enqueued, but not necessarily complete.
    # Using result on non-default stream.
    with torch.cuda.stream(s):
        handle.wait()
        # s.wait_stream(torch.cuda.default_stream())
        output.add_(100)
        if rank == 0:
            print(output)
    

    dist.destroy_process_group()
    
if __name__ == "__main__":
    os.environ['MASTER_ADDR'] = 'localhost'
    os.environ['MASTER_PORT'] = '29503'
    spawn(test, args=(2,), nprocs=2, join=True)
```

![Image](https://github.com/user-attachments/assets/cce9e376-ce6d-4ab1-bb66-d881a8bf91b2)

## One remaining question: 
In the C source code I see [Work::wait](https://github.com/pytorch/pytorch/blob/c6ad08357bf8e766b5220bfb5cbbfdb2a4ec0ca5/torch/csrc/distributed/c10d/Work.cpp#L81) has nothing to do with `cudaStreamWaitEvent`. I searched for `cudaStreamWaitEvent` in the whole codebase and couldn't find anything related to torch.distributed. Would love a explaination of the call stack.

Thanks for your attention.

cc @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o
Repository: neovim
Issue: 'guicursor' color change not working in Simple Terminal (suckless ST)
Labels: tui

## Issue Description
I have NeoVim configured to change the cursor's color depending on the mode. See exert from my configuration in Lua:
```
vim.cmd.highlight({"iCursor", "guibg=#a9b665"}) -- gruvbox green
vim.cmd.highlight({"rCursor", "guibg=#e78a4e"}) -- gruvbox orange
vim.cmd.highlight({"vCursor", "guibg=#ea6962"}) -- gruvbox red
vim.cmd.highlight({"cCursor", "guibg=#7daea3"}) -- gruvbox blue
vim.opt.guicursor = "a:block-Cursor,i:block-iCursor,v:block-vCursor,c-ci-cr:block-cCursor,r:block-rCursor"
```
This works as expected in WezTerm, as does the following simplified test. 
However in ST,  the cursor color never changes from the terminal set default #f8f8f2.

## Steps to reproduce
`nvim --clean`
`:set termguicolors`
`:highlight Cursor guibg=black`
`:highlight iCursor guibg=green`
`:set guicursor=n-v-c:block-Cursor,i:block-iCursor`

Enter *Insert Mode*
Exit *Insert Mode*
### Expected behavior
Cursor is black in *Normal Mode*, turns green upon entering *Insert Mode*, and returns back to black on exiting *Insert Mode*.
### Actual behavior
Cursor remains a #f8f8f2 colored block throughout, as defined by in ST's config.h:
```
/* special colors */
[256] = "#282a36", /* background */
[257] = "#f8f8f2", /* foreground */
```
## What I tried
### Method A 
`TERM=xterm-256color`
Setting $TERM to xterm-256color in ST.
#### Outcome
When preforming the **Steps to reproduce** above, behavior now matches the **Expected behavior**. However, after exiting NeoVim via 
`:q` the cursor remains black and all terminal text is colored black too, which should not happen.

### Method B 
Looking for a relevant ST patch
#### Outcome
Could not find one.

### Method C 
Verify via `printf "\033[31m"` that ST "actually supports termcodes to change the cursor color" [#29498](https://github.com/neovim/neovim/issues/29498#issuecomment-2322500302)
#### Outcome
Terminal text turns red, however cursor color remains #f8f8f2.

### Method  A + C
#### Outcome
No change from **Method C Outcome**, cursor still #f8f8f2.

## Thoughts
While the **Outcome** of **Method C** would indicate this is an issue with ST not supporting termcodes for cursor color change, the fact that setting `TERM=xterm-256color`(**Method A**) doesn't affect the outcome of the termcode, while it does affect NeoVim's behavior positivly (cursor changes color), I hope there may be a way to natively enable NeoVim to change ST's cursor color.

## Terminfo
Terminfo section from:
`nvim -V3log` and then `:q`
[log.txt](https://github.com/user-attachments/files/18552252/log.txt)

### Relevant software info

OS: Arch/ Linux 6.12.10-arch1-1 x86_64
`nvim --version`: NVIM v0.10.3 -- installed via `pacman -S neovim`
[ST](https://st.suckless.org/) version: [0.9.2](https://dl.suckless.org/st/st-0.9.2.tar.gz) 
_(for reference) WezTerm: 20240203-110809-5046fc22_

### $TERM
$TERM=st-256color

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

N/A, **Steps to reproduce** with vim 9.1, `vim -u DEFAULTS` do not working in ST *or* WezTerm
Repository: vscode
Issue: blackboxai troubleshooting with workspace
Labels: info-needed,triage-needed

ADD ISSUE DESCRIPTION HERE

Version: 1.95.3
Commit: f1a4fb101478ce6ec82fe9627c43efbf9e98c813
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0
Embedder: unknown

<!-- generated by web issue reporter -->
Repository: rust
Issue: macOS deployment target defaults differ between rustc, cc-rs and clang
Labels: A-linkage,T-compiler,C-tracking-issue,T-libs,O-apple

When `MACOSX_DEPLOYMENT_TARGET` is not set, rustc defaults to macOS 10.12 for Intel targets and 11.0 for aarch64 targets:

https://github.com/rust-lang/rust/blob/f85c6de55206dbee5ffedfd821df1503a7b92346/compiler/rustc_codegen_ssa/src/back/apple.rs#L69
https://github.com/rust-lang/rust/blob/f85c6de55206dbee5ffedfd821df1503a7b92346/compiler/rustc_codegen_ssa/src/back/apple.rs#L87

However, this does not match the default behavior for `clang`, which defaults to the selected SDK versions; unless changed otherwise, a C program built with `clang` uses the macOS host version as deployment target. The `cc-rs` crate also defaults to this behavior.

This difference in behavior causes issues when a Rust program has a dependency on a C library and does not set a minimum deployment target: The Rust binary tells the linker to target 10.12 / 11.0, but as the C library requires a higher minimum deployment target, a warning is emitted and the binary ends up targeting the higher version. [This was recently observed with miri](https://github.com/rust-lang/rust/issues/136086), which is built in a macOS 14 GitHub Runner:

```
ld: object file (/Users/runner/work/miri/miri/target/release/deps/libtikv_jemalloc_sys-80d1ddce8807bb5c.rlib[11](buf_writer.pic.o)) was built for newer 'macOS' version (14.5) than being linked (11.0)
```

In this case, miri does not have a deployment target set, so rustc tells the linker to emit a binary targeting 10.12; however, jemalloc-sys built jemalloc using clang's defaults, so it ended up targeting 14.5.

In a perfect world, projects would always set a deployment target and the linker would actually enforce that binaries cannot depend on objects that require a higher minimum macOS version instead of emitting a warning and targeting the higher version; alas, we're stuck with a warning with a not-so-great message. However, as incomprehensible the message may be, it is still indicative of a potential bug, especially if the user told the Rust part to create a binary targeting, say, 11.0, but the project then accidentally pulls in a dependency that targets 13.0 - the resulting binary would be created for 13.0 and might not run on 11.0 at all. Unfortunately, rustc can't not set a default deployment target by itself if the user hasn't specified one - it invokes the linker and has to pass it a deployment version; though it could compute the highest minimum version of all objects files it passes to the linker.

(@madsmtm has indicated wanting to change `cc-rs`'s defaults to match rustc's behavior, so that a Rust program building a C library via `cc` would not run into a deployment target mismatch; without such a change, it's too likely to be a false positive.)

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"madsmtm"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: vscode
Issue: Relative file link detection in log files
Labels: feature-request,output

When viewing `.log` files in the editor, absolute file paths will be detected as links, but not relative paths (to either the workspace root or the opened file). Notably this is different in the terminal, where relative paths are clickable without issue, and it would be useful if the detection in `.log` files was similarly flexible.

I am aware that you can insert `file://` at the start and it will be detected in a link, but no log file is going to have this by default, and it doesn't work with line/column numbers regardless.

<!-- ⚠️⚠️ 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.96.4
- OS Version: Windows 11 10.0.22621

Steps to Reproduce:

1. Create a `.log` file
2. Type the relative path and absolute path of a file in the workspace
3. The absolute path will be highlighted and clickable, but not the relative path
Repository: flutter
Issue: Add `BorderRadiusGeometry` Support to `Divider` Widget for Customizable Border Radius
Labels: c: new feature,framework,c: proposal,team-framework

### Use case

I can't set border radius to divider. this is necessary when you have a thick rounded border and almost all the cases, if you have a thick divider, you might have some corner radius. In this below SS, see that the edges are very sharp and there's no default way to make divider edge's rounded.
<img width="386" alt="Image" src="https://github.com/user-attachments/assets/025987f4-3361-40b2-bdcd-ac1d6cd77bf5" />
this is the code that produces above divider,
```dart
Divider(
  indent: 200,
  endIndent: 200,
  height: 40,
  thickness: 5,
  color: Colors.grey,
)
```

### Proposal

Add an way to pass the `BorderRadiusGeometry` to the divider as it's used a `Container` to construct the divider. So, this radius geometry value will pass to the Container's `BoxDecoration` field. something like this,
```diff
    @override
    Widget build(BuildContext context) {
      final ThemeData theme = Theme.of(context);
      final DividerThemeData dividerTheme = DividerTheme.of(context);
      final DividerThemeData defaults =
          theme.useMaterial3 ? _DividerDefaultsM3(context) : _DividerDefaultsM2(context);
      final double height = this.height ?? dividerTheme.space ?? defaults.space!;
      final double thickness = this.thickness ?? dividerTheme.thickness ?? defaults.thickness!;
      final double indent = this.indent ?? dividerTheme.indent ?? defaults.indent!;
      final double endIndent = this.endIndent ?? dividerTheme.endIndent ?? defaults.endIndent!;
  
      return SizedBox(
        height: height,
        child: Center(
          child: Container(
            height: thickness,
            margin: EdgeInsetsDirectional.only(start: indent, end: endIndent),
            decoration: BoxDecoration(
+             borderRadius: radius,
              border: Border(bottom: createBorderSide(context, color: color, width: thickness)),
            ),
          ),
        ),
      );
    }
```
Repository: terminal
Issue: Progress towards next release
Labels: Needs-Triage,Needs-Tag-Fix

Hi there,

I'm new round here, excitedly anticipating the release of 1.22 so I can save snippets of some of the longer commands I run!

Is there a publicly-available place I could view to check to give a coarse idea of how far away release is? Don't mean to bug you guys, but the [roadmap linked from the readme](https://github.com/microsoft/terminal/blob/main/doc/roadmap-2023.md) seems to be missing some recent details,

Many thanks and appreciate all you're doing!

-Ben
Repository: ollama
Issue: Error: an error was encountered while running the model: unexpected EOF (8x H100, deepseek-r1:671b)
Labels: bug

### What is the issue?

I'm using a server with 8xH100 GPUs, trying to run the deepseek-r1:671b model.
This works for a fair bit, say about 1000-2000 generated tokens, and then it ends with:
`Error: an error was encountered while running the model: unexpected EOF`

I don't quite know how to debug this -- is there a way to get a stack trace of some sort?
What could be causing this error?

Reproduction is pretty simple:
1. spin up a 8xH100 NVL instance (I use Lambda labs and Google gSC)
2. run ollama run deepseek-r1:671b
3. ask two or three questions that each generate more than a small amount of text
4. sudden `Error: an error was encountered while running the model: unexpected EOF` in the middle of generation

`NVIDIA-SMI 550.127.05             Driver Version: 550.127.05     CUDA Version: 12.4`

`Intel(R) Xeon(R) Platinum 8480+`



### OS

Linux

### GPU

Nvidia

### CPU

AMD, Intel

### Ollama version

0.5.7
Repository: TypeScript
Issue: Tsc does not behave correctly when files are moved or deleted
Labels: Suggestion,Out of Scope

### 🔎 Search Terms

tsc delete old files

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about tsc not deleting old files properly


### ⏯ Playground Link

_No response_

### 💻 Code

n/a

### 🙁 Actual behavior

Old files that tsc does not clean up can cause problems in a new build.

For example, if i have a file `src/foo.ts`, and then i delete it and replace it with a folder `src/foo/index.ts`, the fact that `dist/src/foo.d.ts` sticks around is a bug. Imports from `./foo` in the src folder will point to the old file that should have been deleted, rather than the new `foo` folder.

This can be worked around with a non-watch build by just saying `rm -rf dist/ && tsc` but that doesn't work for tsc watch, even with the clean option.


### 🙂 Expected behavior

At least for watch mode, but really for non-watch-mode too, there needs to be a way to delete the entire output directory before new output files are emitted. The way it works now is not correct and there's no way around it besides not using watch mode.

### Additional information about the issue

_No response_
Repository: ollama
Issue: requesting support new model(maybe not new): Qwen2.5-1M
Labels: model request

Qwen has released a long context version of Qwen 2.5 on hugging face, hoping to add support:
https://huggingface.co/collections/Qwen/qwen25-1m-679325716327ec07860530ba
Repository: pytorch
Issue: support arm architectures in your Docker images on docker hub? (
Labels: triaged,enhancement,module: docker,module: arm

### 🚀 The feature, motivation and pitch

`pytorch` images on Docker Hub are still only available for amd64 architectures.  Nvidia/cuda images support both arm64 and amd64.  I believe we are seeing more and more devices offering Nvidia GPUs witth ARM cpu architecture, and multi-arch builds are commonplace. It would be great to have pytorch docker images that support these.   

Thanks!

### Alternatives

_No response_

### Additional context

_No response_

cc @malfet @snadampal @milpuz01
Repository: PowerToys
Issue: The Powertoys Run panel background goes wrong
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.87.1

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

EDIT: I've noticed I am running Windows 21H2 while several similar issues indicates using 21H2 may cause this problem. Are there any workarounds to solve this instead of updating the system? 

I have just updated powertoys from 0.81.0 to 0.87.0 and the Powertoys Run tool seems to have something wrong with the background color.

![Image](https://github.com/user-attachments/assets/f677594b-683d-47a2-a02a-e58c9f478073)

[PowerToysReport_2025-01-27-12-43-08.zip](https://github.com/user-attachments/files/18553564/PowerToysReport_2025-01-27-12-43-08.zip)

### ✔️ Expected Behavior

The panel background should be white and the characters should be black.

### ❌ Actual Behavior

The panel background color goes wrong and I can't see what is displayed on it.

### Other Software

_No response_
Repository: iptv
Issue: Broken: US - Tubi, Four in a Bed 24/7 Channel
Labels: broken stream

### Broken Links

#EXTINF:-1 tvg-id="",Four in a Bed (1080p)
https://apollo.production-public.tubi.io/live/ac-four-in-a-bed.m3u8

### What happened to the stream?

Not loading

### Notes (optional)

To the best of my knowledge, Tubi lost rights to the TV series as Channel 4 in the UK made a deal with Amazon to carry the series content as of January 1, 2025.  As such, Tubi has dropped the 24/7 channel from their lineup and only has a few seasons under contract with Channel 4 UK in their video on demand section.    The channel should be removed from the master list as it no longer exists on Tubi servers.  Previous link to the content through their live-news server (as a backdoor) is also dead as are seemingly all other non-news channels.  That previous link to the content was at https://live-news-manifest.tubi.video/live-news-manifest/csm/extlive/tubiprd01,Four-in-a-Bed.m3u8 . It is unknown at this time if their are any other live tv services running the program as a 24/7 channel.

### Contributing Guide

- [x] I have read [Contributing Guide](https://github.com/iptv-org/iptv/blob/master/CONTRIBUTING.md)
Repository: PowerToys
Issue: 设置映射之后输入较快的情况下映射会失败
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.87.1

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

设置映射之后输入较快的情况下映射会失败  
the mapping will fail when i input is relatively fast

alt(left) key is pressed,then i trigger u/i/o  if i input slowly    it will output 7/8/9, 
but when i input swiftly, it maybe output 7/i/9  or 7/8/o  

this is my mapping set 
![Image](https://github.com/user-attachments/assets/bcf70896-43dd-45e1-9542-6bff796d4b41)\

### ✔️ Expected Behavior

no matter how fast, i hope it will output my mapping set key

### ❌ Actual Behavior

alt(left) key is pressed,then i trigger u/i/o  if i input slowly    it will output 7/8/9, 
but when i input swiftly, it maybe output 7/i/9  or 7/8/o  

### Other Software

_No response_
Repository: TypeScript
Issue: TypeScript inappropriately resolves directory imports in ESM mode, that fail at runtime (in Node, but probably all ESM environments).
Labels: Needs Investigation

### 🔎 Search Terms

ESM "directory import" "directory imports"

### 🕗 Version & Regression Information

Behaves this way for all versions tested on TSPlayground using module: ES*
Behaves this way in a local project with TS 4 and 5, and module: Node16 (moduleResolution: Node16)
I reviewed the FAQ for entries about directory imports and ESM



### ⏯ Playground Link

[Playground](https://www.typescriptlang.org/play/?target=99&moduleResolution=99&module=7&ts=5.7.3&jsx=0#code/PTAEFsHsBMFcBsCmAuUBRAygJgAxawFAECW4ADpAE4AuoA5MQLQAWAhgG6KOuPTGXcAdtEbhWxQXVAhQAeQDSAOlAAlRAGdI8TutDVIe5olAAiMRJOhEADwo0ANKD7rqwCdBuKAVupLkqtAwsHFw8fAKswqLigsDOruFSMgBi4vC6rLSUsILUpIiKBKDFJaVl5RWVpTIAKhiglBpaOobEuvrS8XH8bsKePvZFVcMjVTKZDTl54MbUzG2gC5GLguys8MTQTvyIAMb6lACei-40BEA)

A repro repository is here: https://github.com/RobertSandiford/ts-esm-dir-import-example
After cloning run `pnpm i && pnpm run dev`
I recommend this over the playground link because you can see the runtime errors.

### 💻 Code

the package `'i-have-a-dir-and-main'` has this file structure:
dist
--index.js
--dir
----index.js

package.json includes:
"type": "module"
"main": "dist/index.js"

An importing project may look like this. This compiles but fails at runtime:
```ts
import 'i-have-a-dir-and-main' // OK. Resolves to the "main" export, dist/index.js
import 'i-have-a-dir-and-main/dist/dir' // Fails at runtime.
                                        // TS resolves this to /dist/dir/index.js,
                                        // at runtime this is an invalid directory import
```


### 🙁 Actual behavior

TS resolves the import `'i-have-a-dir-and-main/dist/dir'` to `i-have-a-dir-and-main/dist/dir/index.js`, but this is not valid in ESM. Directory imports are not permitted (outside of exceptions like a node legacy behaviour flag)

```
Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import 'C:\xxx\ts-dir-import-repro\node_modules\i-have-a-dir-and-main\dist\dir' is not supported resolving ES modules imported from C:\xxx\ts-dir-import-repro\dist\index.js
Did you mean to import "i-have-a-dir-and-main/dist/dir/index.js"?
    at finalizeResolution (node:internal/modules/esm/resolve:259:11)
    at moduleResolve (node:internal/modules/esm/resolve:933:10)
```

### 🙂 Expected behavior

TSC to fail to resolve the import `'i-have-a-dir-and-main/dist/dir'` when in an ESM mode (import resolution: Node*, type module, or import resolution: ES*) and report an import error.
Repository: vscode
Issue: I cant paste anything
Labels: info-needed


Type: <b>Bug</b>

i can copy or cut but i cant paste anyting


VS Code version: Code - OSS 1.96.4 (cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba, 2025-01-17T08:53:36.849Z)
OS version: Linux x64 6.12.10-zen1-1-zen
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz (8 x 2400)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: disabled_software<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: disabled_off<br>webnn: disabled_off|
|Load (avg)|1, 1, 1|
|Memory (System)|15.49GB (10.96GB free)|
|Process Argv||
|Screen Reader|no|
|VM|0%|
|DESKTOP_SESSION|garuda-hyprland|
|XDG_CURRENT_DESKTOP|Hyprland|
|XDG_SESSION_DESKTOP|hyprland|
|XDG_SESSION_TYPE|wayland|
</details><details><summary>Extensions (3)</summary>

Extension|Author (truncated)|Version
---|---|---
tailwind-documentation|alf|0.1.15
vscode-tailwindcss|bra|0.10.2
five-server|yan|0.3.2


</details>
<!-- generated by issue reporter -->