sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: [DTensor] Allow multiple dimensions to be sharded together (as if flattened)
Labels: oncall: distributed,module: dtensor

### 🚀 The feature, motivation and pitch

PyTorch's utilities for sequence parallelism seem to suppose that tensors will have two separate dimensions for batch (dim 0) and sequence (dim 1), and shard only along dim 1. However, if batch > 1, this means that each rank's shard will be non-contiguous. This is a problem because NCCL wants contiguous storages, hence we end up with extra kernels for (un-)compacting the data. You can clearly see them in this profiler trace obtained from such a job:
![](https://github.com/user-attachments/assets/68c0d2ff-eeb3-44e9-9f9e-cee3de7c3e76)

The simplest solution here, which wouldn't require changing user code, is for these tensors to be shared across the _joint_ 0 and 1 dimensions, i.e., as if those two dimensions were flattened. In other terms, we'd need DTensor to support a placement type that looks like `Shard(dims=[0, 1])`.

### Alternatives

The only alternative I see is for users to flatten those tensors manually in their own model code. This is not too hard, but I claim it's undesirable, since it _worsens_ the user code (makes it more opaque) our of a concern for efficiency, whereas the aim of torch.compile and DTensors should be to deal with efficiency without the user's intervention.

### Additional context

_No response_

cc @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o @tianyu-l @XilunWu
Repository: PowerToys
Issue: Critical: .NET Install links are changing
Labels: Priority-0,Area-Build

### Description of the new feature / enhancement

We are currently making an unexpected change to the way that .NET installers and archives are distributed. This change may affect you and may require changes in your development, CI, and/or production infrastructure. We expect that most users will not be directly affected, however, it is critical that you validate if you are affected and to watch for downtime or other kinds of breakage.

The most up-to-date status is being maintained at [dotnet/core #9671](https://github.com/dotnet/core/issues/9671). Please look to that issue to stay current.

https://devblogs.microsoft.com/dotnet/critical-dotnet-install-links-are-changing/
Repository: godot
Issue: LSP performance issues on "slower" devices
Labels: topic:gdscript,topic:editor,performance

### Tested versions

- Reproducable in 4.3.stable

### System information

Godot v4.3.stable - Windows 10.0.26100 - Vulkan (Mobile) - integrated AMD Radeon(TM) Graphics (Advanced Micro Devices, Inc.; 31.0.21024.2004) - AMD Ryzen 7 7735U with Radeon Graphics (16 Threads)

### Issue description

Using the LSP server via NeoVim or VSCode on my laptop results in very slow responses (several seconds) when working with specific scripts in my project.

I have investigated the LSP client-side settings and could not find any differences between files that respond quickly and those with slow responses. Additionally, the project runs without any issues on my desktop PC. Running the LSP server on my desktop and connecting to it from my laptop also eliminates the problem.

File length does not seem to be a factor. Even after deleting the entire content of a problematic file, leaving only the class name and its extends declaration, the slow response persists. Similarly, the number of references to the class does not appear to influence performance. Certain classes consistently cause slow responses, while others resolve normally.

I have also noticed a significant increase in memory usage by Godot when editing files with slow responses—about 2–3 times the usual amount. This behavior does not occur on my desktop PC, even for the same files/classes.

Unfortunately, I don’t have any additional insights at this time, as I haven’t been able to identify a specific cause within the project, the files, or their references. However, it seems there might be a performance issue with the LSP server that the desktop's processing power overcomes but manifests as slow responses on the laptop.

If anyone has experienced a similar issue or can provide guidance on debugging the LSP server side, I would greatly appreciate your help.

Thanks in advance!

### Steps to reproduce

Unfortunately not yet.

### Minimal reproduction project (MRP)

Unfortunately not yet.

_Bugsquad Edit:_
- _MRP: [lsp_slowdown_large_scenes.zip](https://github.com/user-attachments/files/18301626/lsp_slowdown_large_scenes.zip)_
Repository: godot
Issue: UI issues using the Microsoft Surface
Labels: bug,platform:windows,topic:gui

### Tested versions



Using Godot v4.3 stable



### System information

Windows 11, Surface Pro 11th Edition

### Issue description

Hello! I got the new Surface Pro 11th Edition to work in the train, hotels or whereever live leads me.

There seem to be some UI problems dublicating buttons or moving important parts out of the frame. It's not just a visual problem, but also blocks other UI (invisible). Is that a known issue? Is it surface specific? I know a bit about computers (uhuuw....), but I'm not really sure where a surface is between tablet and pc. Already realized that there are for example weird problems with swiping in slay the spire, therefore it might be something surface specific?...or maybe something connected to touch screens?

If you got a surface and know your way around godot I would be happy about a fix. 

Example of the bug:

![Image](https://github.com/user-attachments/assets/5d20582b-2d1d-42b5-923c-e307e0f6b0e8)


![Image](https://github.com/user-attachments/assets/7c57cfe6-9bbd-407a-ac4d-a7dfe210d907)


### Steps to reproduce

Using the microsoft surface pro 11th Edition, the error should instanlty exist if you want to use Godot 4.3

To me the project appears as soon as I want to create a project and switch the type (mobile etc.)


### Minimal reproduction project (MRP)

No Project but Engine specific bug... it already happens outside of the project, as you see in the screenshot. But it also happens inside of the project. It can block blicks and for example even deny access to other development types in the starter that way.
Repository: pytorch
Issue: Add a knob to control how many blocks are used by persistent matmul/attn kernels
Labels: module: cuda,triaged,module: cublas,module: linear algebra

### 🚀 The feature, motivation and pitch

We train a transformer-style model using FSDP, and we have a very good overlap between the matmul kernels (from cuBLAS) and the NCCL operation in the background. However, when profiling, we have observed that the **matmuls take 2x as long** to complete when they are overlapped with a NCCL kernel!

We believe this is easily explained: we're running on H100 GPUs and, upon inspection, all the matmuls look like they are using "persistent" kernels. That is, they launch as many CUDA blocks as there are SMs on the GPU (i.e., 132) and each of these blocks will process several tiles in a row. What we're observing is thus a form of "wave quantization" where, due to NCCL occupying some SMs, not all blocks of the matmuls can be scheduled at once, thus breaking them into two waves, which thus take twice as long to complete.

Since NCCL only occupies ~10% of the SMs, it would be much more efficient if the matmuls tried to launch a number of blocks that corresponds to ~90% of the SMs. This would allow the two kernels to run simultaneously in a single wave, with the matmuls only being ~10% slower, not ~50%!

For that, however, we need PyTorch to add a new knob allowing us to control such a value, and to forward that knob when launching its cuBLAS kernels (and others).

### Alternatives

None. We couldn't find any environment variable provided by cuBLAS that allows us to override the number of blocks launched.

### Additional context

With longer NCCL kernels, matmuls take a long time:
<img width="1555" alt="Screenshot 2024-12-30 at 17 29 23" src="https://github.com/user-attachments/assets/d91d192e-16e9-4108-9d8e-5cb7caef80f6" />

With shorter NCCL kernels, the non-overlapped matmuls now take less time:
<img width="1439" alt="Screenshot 2024-12-30 at 17 29 42" src="https://github.com/user-attachments/assets/6e1fff67-b1a8-4b3b-a582-6648fc8b00bf" />


cc @ptrblck @msaroufim @eqy @csarofeen @xwang233 @jianyuh @nikitaved @pearu @mruberry @walterddr @Lezcano
Repository: svelte
Issue: Migration guide: Mention `$state.snapshot` as potentially being required
Labels: documentation

### Describe the problem

Third party APIs (and some built-ins like `structuredClone`) may be unable to deal with state proxies, this can cause errors/confusion.

The fact that proxies are created by `$state` and how that matters is not explained. (There is only a single mention of proxies in the "Modern browser required" section.)

### Describe the proposed solution

- Explain that objects and arrays are proxied.
- Give an example where a proxy could cause an error and how `$state.snapshot` helps.

### Importance

nice to have
Repository: PowerToys
Issue: Always on Top - Excel Protected view stolen focus
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.87.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Always on Top

### Steps to reproduce

1. Open two instances of Microsoft Excel 2021 (no idea if other versions of Office have this behaviour), with at least one of them opened in protected view.
2. Enable Always on Top on one of the two instances
[PowerToysReport_2024-12-30-17-40-48.zip](https://github.com/user-attachments/files/18276391/PowerToysReport_2024-12-30-17-40-48.zip)


### ✔️ Expected Behavior

The non-pinned Excel instance should be interactable (i.e., the user should be able to move it, resize it, and so on).

### ❌ Actual Behavior

The instance pinned by Always on Top steals the focus from the other instance, rendering it impossible to move or resize.

If none of the instances are running in read/write mode, the behaviour doesn't occur.

The behaviour also doesn't occur with Word. I don't have the chance to test it with PowerPoint, but I suspect this issue only affects Excel.

Attaching a screen capture that illustrates this bug.

https://github.com/user-attachments/assets/6726f7e9-1a16-4ec0-9371-76eeb2846e1f


### Other Software

Microsoft Office 2021
Repository: TypeScript
Issue: Allow dynamic usage of `import = require` syntax
Labels: Suggestion,Awaiting More Feedback

### 🔍 Search Terms

dynamic import, require, verbatimmodulesyntax

### ✅ Viability Checklist

- [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [x] This wouldn't change the runtime behavior of existing JavaScript code
- [x] This could be implemented without emitting different JS based on the types of the expressions
- [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [x] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

I propose that `import = require()` should be allowed anywhere a `require()` statement is allowed (under appropriate module settings).

```ts
function foo() {
   import foo = require('./module.js');
}
```

### 📃 Motivating Example

I've been trying to convert a commonjs project to verbatimModuleSyntax. Currently dynamic JSON imports are written as 
```ts
function foo() {
   const json = await import('./foo.json');
}
```
which are rewritten as `Promise.resolve().then(() => require('./foo.json'));` by TS due to my module setting. The `import()` syntax currently has the advantage that TS statically analyzes and provides types for the imported JSON.

I'd like to convert the JSON import to a `require()` call, however, a bare `require()` loses static analysis. Therefore, I'd like to be able to use
```ts
function foo() {
   import json = require('./foo.json');
}
```
in order to have type inference and static analysis of the json file (also to have it copied to the output build).

(using a node `import()`-from-CJS is not available to me at this time)

### 💻 Use Cases

1. What do you want to use this for? dynamic require()s with static analysis, under verbatimModuleSyntax
2. What shortcomings exist with current approaches? No static analysis of dynamic `require()`s.
4. What workarounds are you using in the meantime? Not using verbatimModuleSyntax

***

Somewhat relates to https://github.com/microsoft/TypeScript/issues/60598
Repository: pytorch
Issue: Return attention weights in scaled_dot_product_attention
Labels: triaged,module: sdpa

### 🚀 The feature, motivation and pitch

I'd like to reopen the request #119811, but for a special case, namely generative inference, where the Q tensor is very small (just a single token). The request is to return the attention weights along with the normal MHA output.

Why is this important? In order to implement KV cache eviction strategies, like heavy hitter oracle, these weights are needed.

The suggestion in the issue, to pass an identity as V, is not useful, because this tensor would be huge, defying the whole purpose of efficient MHA in this case. It would be square the size of the KV cache at least. And the application is not just for some visualization, it must run efficiently inside generation.

I digged a bit into your sources. It seems that some functions called by `scaled_dot_product_attention` return attn_weights as second argument, for example `_scaled_dot_product_attention_math` in `aten/src/ATen/native/transformers/attention.cpp`. But most others do not. They return tuples with `(output, logsumexp, ...)`, and `scaled_dot_product_attention` returns `output`. I don't really know what `logsumexp` is, but it has the wrong shape, scales with size of Q.

Any hint for how to get this done would be appreciated, except for the "trick" to pass the identity as V.

### Alternatives

_No response_

### Additional context

_No response_
Repository: pytorch
Issue: DISABLED test_setting_meta_device_model_broadcasting_and_memory (__main__.TestStateDict)
Labels: oncall: distributed,module: rocm,triaged,skipped

Platforms: rocm

Started probably at https://github.com/pytorch/pytorch/pull/142845
https://hud.pytorch.org/hud/pytorch/pytorch/9d026000de01bbd4d5c97bdca88cc6228507617a/3?per_page=100&name_filter=distributed&mergeLF=true

https://github.com/pytorch/pytorch/actions/runs/12409302699/job/34672198799



This test was disabled because it is failing on main branch ([recent examples](https://torch-ci.com/failure?failureCaptures=%5B%22distributed%2Fcheckpoint%2Ftest_state_dict.py%3A%3ATestStateDict%3A%3Atest_setting_meta_device_model_broadcasting_and_memory%22%5D)).

cc @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @naromero77amd
Repository: go
Issue: x/tools/gopls: out-of-memory failure on Windows
Labels: NeedsInvestigation,gopls,Tools,gopls/telemetry-wins

```
#!stacks
"runtime.bgsweep" && "runtime.newArenaMayUnlock:+6" && "runtime.throw"
```
Issue created by [stacks](https://pkg.go.dev/golang.org/x/tools/gopls/internal/telemetry/cmd/stacks).

I suspect this is another manifestation of #70445, but I thought I should report it since the call stack is completely different.

This stack `F860lA` was [reported by telemetry](https://storage.googleapis.com/prod-telemetry-merged/2024-12-28.json):

- `crash/crash`
- [`runtime.throw:+9`](https://cs.opensource.google/go/go/+/go1.23.4:src/runtime/panic.go;l=1067)
- [`runtime.newArenaMayUnlock:+6`](https://cs.opensource.google/go/go/+/go1.23.4:src/runtime/mheap.go;l=2498)
- [`runtime.newMarkBits:+22`](https://cs.opensource.google/go/go/+/go1.23.4:src/runtime/mheap.go;l=2418)
- [`runtime.(*sweepLocked).sweep:+185`](https://cs.opensource.google/go/go/+/go1.23.4:src/runtime/mgcsweep.go;l=683)
- [`runtime.sweepone:+37`](https://cs.opensource.google/go/go/+/go1.23.4:src/runtime/mgcsweep.go;l=389)
- [`runtime.bgsweep:+28`](https://cs.opensource.google/go/go/+/go1.23.4:src/runtime/mgcsweep.go;l=298)
- [`runtime.gcenable.gowrap1:+0`](https://cs.opensource.google/go/go/+/go1.23.4:src/runtime/mgc.go;l=204)
- `runtime.goexit:+0`
```
golang.org/x/tools/gopls@v0.17.1 go1.23.4 windows/amd64 vscode (1)
```
Repository: godot
Issue: Script editor fails to reload closed scripts after externally modified
Labels: bug,topic:editor,needs testing

### Tested versions

- Reproducible in v4.4.dev7.official [46c8f8c5c]

### System information

Godot v4.4.dev7 - Windows 11 (build 22631) - Multi-window, 2 monitors - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2070 SUPER (NVIDIA; 32.0.15.6603) - Intel(R) Core(TM) i7-10700F CPU @ 2.90GHz (16 threads)

### Issue description

When a script is edited externally, it correctly reloads in the script editor if the script is open. Otherwise, the edit appears to be undetected, and the wrong script is displayed.

This greatly affects teams where script changes are frequently pulled, where an editor restart is currently required after every pull ( not good ), but can be tested manually with two editor processes running, or by editing a script externally.

The scripts are only out of date within the editor itself. Running the project will use the updated changes, even when its script editor conflicts with what is expected.

Video demonstration (using two editors):

https://github.com/user-attachments/assets/7d6aacb5-9ec8-48b3-9151-74cd79d6f093


### Steps to reproduce

1. Run the editor, and leave a script closed.
2. Edit that script externally by any means.
3. Focus the editor, and it will not pick up the script changes.

### Minimal reproduction project (MRP)

N/A
Repository: transformers
Issue: 8bits GPTQ quantization output
Labels: bug

### System Info

Hi, I noticed that with 8-bit quantization using GPTQConfig, the model inference generally produces really bad results, with outputs that often don't make sense. Could this be an engineering issue with GPTQ, or is this typical behavior for GPTQ when using 8-bit quantization? Thank you in advance! 

### Who can help?
@SunMarc @ArthurZucker 
_No response_

### Information

- [ ] The official example scripts
- [ ] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [x] My own task or dataset (give details below) - NQOpen

### Reproduction

1. By using Qwen2.5 `Qwen/Qwen2.5-7B-Instruct-GPTQ-Int8`
2. By using GPTQConfig on `meta-llama/Llama-3.1-8B-Instruct`

```python 
quantization = GPTQConfig(
    bits = 8,
    group_size = 128,
    dataset = "c4",
    desc_act=False,
)

tokenizer = AutoTokenizer.from_pretrained(model)

model = AutoModelForCausalLM.from_pretrained(model, quantization_config=quantization, device_map="auto")
```
### Expected behavior

1. model tends to generate unrelated outputs, such as `the !!!!!!!!!!!!!!!!!.....` as the output. The generated output does not make sense at all.
Repository: go
Issue: crypto/tls: map boringssl errors to go errors in BoGo shim config
Labels: NeedsFix

The BoGo shim config has a field (ErrorMap) that allows mapping between BoringSSL style error strings to local error strings, which we should populate.

We currently don't map these, which can lead to failures being masked (see [#70915](https://go.dev/issue/70915)).
Repository: PowerToys
Issue: FancyZone - Layout Type Mismatch: Columns Saved as Grid
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.87.1

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

FancyZones

### Steps to reproduce

1. Open the FancyZones editor.

2. Select or create a layout of type columns.

3. Save the layout.

4. Check the JSON file for custom layouts at `%UserProfile%\AppData\Local\Microsoft\PowerToys\FancyZones\custom-layouts.json`.

### ✔️ Expected Behavior

The layout of type *columns* should be saved as columns in the type field of the JSON file

### ❌ Actual Behavior

The layout of type columns is being saved as grid in the type field of the JSON file.

### Other Software

_No response_
Repository: storybook
Issue: [Bug]: favicon doesn't work for dev server
Labels: bug,good first issue,help wanted,sev:S3

### Describe the bug

For the dev server (aka localhost), the favicon does not appear and the link in the HTML header is invalid.

### Reproduction link

N/A

### Reproduction steps

Start the dev server.

### System

```bash
Storybook Environment Info:

  System:
    OS: Windows 11 10.0.26100
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
  Binaries:
    Node: 20.11.1 - C:\Program Files\Node.js\node.EXE
    npm: 10.8.2 - C:\Program Files\Node.js\npm.CMD <----- active
    pnpm: 9.14.4 - C:\Program Files\Node.js\pnpm.CMD
  Browsers:
    Edge: Chromium (131.0.2903.86)
  npmPackages:
    @storybook/addon-actions: 8.4.2 => 8.4.2
    @storybook/addon-controls: 8.4.2 => 8.4.2
    @storybook/addon-docs: 8.4.2 => 8.4.2
    @storybook/addon-links: 8.4.2 => 8.4.2
    @storybook/manager-api: 8.4.2 => 8.4.2
    @storybook/react: 8.4.2 => 8.4.2
    @storybook/react-vite: 8.4.2 => 8.4.2
    storybook: 8.4.2 => 8.4.2
```

### Additional context

For a build, the favicon works correctly.
Repository: godot
Issue: Partial Classes Are Not Found When They Not Defined In Main Assembly
Labels: topic:dotnet

# Partial Classes Are Not Found When Defined Outside the Main Assembly

## Description  
When working with partial classes in Godot projects, I encountered an issue where partial classes are not recognized if they are defined in assemblies other than the main assembly. This behavior disrupts workflows that rely on modular design and separate assemblies for organizational purposes.

## Expected Behavior  
Godot should seamlessly recognize and compile the partial class, regardless of whether its definitions are in the main assembly or an external assembly. This would allow for proper modular development.

## Actual Behavior  
Godot fails to recognize the partial class defined outside the main assembly. This results in errors indicating missing definitions, even though the class is defined correctly in an external assembly.

## Impact  
- This limitation forces developers to place all partial class definitions in the same assembly, leading to less modular code and increased complexity in large projects.  
- It restricts the ability to use libraries or shared code effectively.  

## Additional Context  
This issue might be linked to assembly resolution and Godot's build pipeline not accounting for cross-assembly partial class definitions. Similar issues have been reported, such as:  
- [#77675](https://github.com/godotengine/godot/issues/77675)  
- [#75352](https://github.com/godotengine/godot/issues/75352)  

These discussions highlight related problems with assembly dependencies and type recognition. Resolving this would greatly enhance Godot's flexibility and support for more complex project structures.

## Environment  
- **Godot Version:** Godot 4.3
- **OS/Platform:** Windows 11 Home 23H2 22631.4602
- **Mono/.NET Version:** .NET 7.0

### Issue description

When working with partial classes in Godot projects, I encountered an issue where partial classes are not recognized if they are defined in assemblies other than the main assembly. This bug disrupts workflows that rely on modular design and separate assemblies for organizational purposes.

### Steps to reproduce

1 Create a Godot project.
2 Define a partial class that inherit from Godot.Node outside the main assembly (e.g., MyItemView.cs).
3 Create another Node class in the main assembly that Exports a MyItemView field and assign it in the editor.
4 Attempt to read the field of type MyItemView.