sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: TensorDict - torch.compile issue tracker
Labels: triaged,oncall: pt2,module: dynamo,dynamo-dataclasses,dynamo-dicts,dynamo-nn-modules,dynamo-ctx-manager,dynamo-torch-function

### 🐛 Describe the bug

This is the sack of errors / improvements that would be required for a near-full support of tensordict functionalities within compile (will add other issues if they pop up)

Thanks for the support team, I was pleasantly suprised that a a lot of the items I had in this list were already closed!

```[tasklist]
### Tasks
- [ ] https://github.com/pytorch/pytorch/issues/129658
- [ ] https://github.com/pytorch/pytorch/issues/129659
- [ ] https://github.com/pytorch/pytorch/issues/130533
- [ ] https://github.com/pytorch/pytorch/issues/129666
- [ ] https://github.com/pytorch/pytorch/issues/127173
- [ ] https://github.com/pytorch/pytorch/issues/129667
- [ ] https://github.com/pytorch/pytorch/issues/130537
- [ ] https://github.com/pytorch/pytorch/issues/129665
- [ ] https://github.com/pytorch/pytorch/issues/130720
- [ ] https://github.com/pytorch/pytorch/issues/129664
- [ ] https://github.com/pytorch/pytorch/issues/129662
- [ ] https://github.com/pytorch/pytorch/issues/130719
- [ ] https://github.com/pytorch/pytorch/issues/129660
- [ ] https://github.com/pytorch/pytorch/issues/129661
```

cc @ezyang @anijain2305 @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @shagunsodhani @albanD @lezcano @bdhirsh @jbschlosser @drisspg
Repository: pytorch
Issue: Libtorch does not support SM90
Labels: module: cuda,triaged

### 🐛 Describe the bug

```
/home/username/miniconda3/envs/envname/lib/libz.so (found version "1.3.1")
-- Caffe2: Found protobuf with new-style protobuf targets.
-- Caffe2: Protobuf version 25.3.0
-- Found CUDA: /home/username/miniconda3/envs/envname/targets/x86_64-linux (found version "12.5")
-- Found CUDAToolkit: /home/username/miniconda3/envs/envname/targets/x86_64-linux/include (found version "12.5.40")
-- Caffe2: CUDA detected: 12.5
-- Caffe2: CUDA nvcc is: /home/username/miniconda3/envs/envname/targets/x86_64-linux/bin/nvcc
-- Caffe2: CUDA toolkit directory: /home/username/miniconda3/envs/envname/targets/x86_64-linux
-- Caffe2: Header version is: 12.5
-- /home/username/miniconda3/envs/envname/lib/libnvrtc.so shorthash is a29b3610
-- USE_CUDNN is set to 0. Compiling without cuDNN support
-- USE_CUSPARSELT is set to 0. Compiling without cuSPARSELt support
-- Autodetected CUDA architecture(s):  9.0a 9.0a 9.0a 9.0a 9.0a 9.0a 9.0a 9.0a
CMake Error at /home/username/miniconda3/envs/envname/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/select_compute_arch.cmake:227 (message):
  Unknown CUDA Architecture Name 9.0a in CUDA_SELECT_NVCC_ARCH_FLAGS
Call Stack (most recent call first):
  /home/username/miniconda3/envs/envname/share/cmake/Caffe2/public/utils.cmake:401 (cuda_select_nvcc_arch_flags)
  /home/username/miniconda3/envs/envname/share/cmake/Caffe2/public/cuda.cmake:326 (torch_cuda_get_nvcc_gencode_flag)
  /home/username/miniconda3/envs/envname/share/cmake/Caffe2/Caffe2Config.cmake:87 (include)
  /home/username/miniconda3/envs/envname/share/cmake/Torch/TorchConfig.cmake:68 (find_package)
  CMakeLists.txt:54 (find_package)


CMake Error at /home/username/miniconda3/envs/envname/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/select_compute_arch.cmake:231 (message):
  arch_bin wasn't set for some reason
Call Stack (most recent call first):
  /home/username/miniconda3/envs/envname/share/cmake/Caffe2/public/utils.cmake:401 (cuda_select_nvcc_arch_flags)
  /home/username/miniconda3/envs/envname/share/cmake/Caffe2/public/cuda.cmake:326 (torch_cuda_get_nvcc_gencode_flag)
  /home/username/miniconda3/envs/envname/share/cmake/Caffe2/Caffe2Config.cmake:87 (include)
  /home/username/miniconda3/envs/envname/share/cmake/Torch/TorchConfig.cmake:68 (find_package)
  CMakeLists.txt:54 (find_package)

```

### Versions

Versions of relevant libraries:
[pip3] No relevant packages
[conda] libmagma                  2.7.2                h173bb3b_2    conda-forge
[conda] libmagma_sparse           2.7.2                h173bb3b_3    conda-forge
[conda] libtorch                  2.3.0           cuda120_h2b0da52_301    conda-forge
[conda] mkl                       2023.2.0         h84fe81f_50496    conda-forge


cc @ptrblck @msaroufim
Repository: godot
Issue: C# code generation fails when using static imports in the initializer of exported variables
Labels: bug,topic:dotnet

### Tested versions

Found in version ``4.3.beta1.mono``

### System information

Godot v4.3.beta1.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated GeForce RTX 3070 () - 13th Gen Intel(R) Core(TM) i7-13700K (24 Threads)

### Issue description

I usually use static imports in C# to improve the legibility of commonly used APIs, such as `Godot.GD` and `Godot.Mathf`.
I just found that the code generation for `GetGodotPropertyDefaultValues()` doesn't take static imports into account, and fails to generate code any exported variable uses a Function from a statically imported library in its initializer.

### Steps to reproduce

Create a blank project and add the following to a new script:

```
using Godot;
using static Godot.Mathf;

public partial class Test : Node
{
    [Export] private float angle = DegToRad(10);
}
```

Build the project and notice the following error:

```
CS0103: The name 'DegToRad' does not exist in the current context Godot.SourceGenerators\Godot.SourceGenerators.ScriptPropertyDefValGenerator\Test_ScriptPropertyDefVal.generated.cs(15,39)

```

### Minimal reproduction project (MRP)

N/A
Repository: tensorflow
Issue: Document tf.Dataset.zip/map triggers tf.Dataset.shuffle
Labels: type:docs-bug,stat:awaiting tensorflower,comp:data

I just got bit by this and was wondering if it's intended or needs a warning label

@aaudiber in #41334 commented the below:

`tf.data.Dataset` objects don't eagerly compute all of their data. They work like blueprints, where the data is computed on the fly every time you iterate through the dataset. As a result, iterating through the same dataset multiple times could result in different output.

The `Dataset.zip` transformation takes multiple datasets and ***iterates*** through them in parallel. If you want to iterate through the input just once, use `map` instead of `zip`:
...

_Originally posted by @aaudiber in https://github.com/tensorflow/tensorflow/issues/41334#issuecomment-662747527_

I had a workflow like so for a tf.data pipeline:
```python
filenames, labels = getFileLabels()
loaded = loadFiles(filenames)
transformed = transformData(loaded)
labeled = tf.data.Dataset.zip(transformed, labels).shuffle()
```
I was just relying on the `filenames`, `labels`, and `transformed` datasets being in the same order. To avoid loading all data into RAM, I moved shuffling up to just the filenames

```python
filenames, labels = getFileLabels()
filenames = filenames.shuffle()
loaded = loadFiles(filenames)
transformed = transformData(loaded)
labeled = tf.data.Dataset.zip(transformed, labels)
```
And what I found was that the model's accuracy tanked because it was receiving data with random labels. It's not explicitly stated anywhere in the docs, but it seems calls to `map` and `zip`(and anything else that would iterate) trigger `shuffle`.

The workaround is easy - just map the loading over the shuffled filenames and return a tuple directly rather than relying on `zip` - but originally I was just going off someone's advice to shuffle "pointers" to files rather than the actual loaded files (which made a lot of sense). Because I don't actually know what's happening at a low-level in the execution graph, I had just assumed that `shuffle` wouldn't be triggered by its sibling methods, only by `model.fit`

**TL;DR**:  
I think it should be documented how `shuffle` can impact other operations, particularly `zip`
Repository: next.js
Issue: Icon component with dynamic svg imports vs bundle size
Labels: create-next-app,bug,Webpack,Lazy Loading,Performance

### Link to the code that reproduces this issue

https://github.com/pepew-le-boss/dynamic-icons-nextjs

### To Reproduce

1. read the `readme.md`
2. read the content of the `page.tsx` and modify it according to the directions
3. build the app
4. look at the bundle size

### Current vs. Expected behavior

When importing a single svg, it should not import all the svgs, making the bundle size huge.

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Enterprise
  Available memory (MB): 14274
  Available CPU cores: 8
Binaries:
  Node: 18.17.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.3 // There is a newer version (14.2.4) available, upgrade recommended!
  eslint-config-next: 14.2.3
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A
 ⚠ There is a newer version (14.2.4) available, upgrade recommended!
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
   Read more - https://nextjs.org/docs/messages/opening-an-issue
```


### Which area(s) are affected? (Select all that apply)

create-next-app, Lazy Loading, Performance, Webpack

### Which stage(s) are affected? (Select all that apply)

next build (local)

### Additional context

I'm trying to create an Icon component that imports svgs dynamically (without blowing up the bundle size).

I've gathered all the potential solutions we can find on the web, like `require.context()`, `dynamic()`, `await import()`, etc. but all of them are making the bundle size huge. Only one of them does not do that but it involves loading the svgs client side, meaning that the svgs appear on the page after a delay.

I don't get why when importing a single svg, all the svg are imported. NextJS should separate them into chunks.

I've set a repo with all the different solutions: [https://github.com/pepew-le-boss/dynamic-icons-nextjs](https://github.com/pepew-le-boss/dynamic-icons-nextjs)
Repository: terminal
Issue: Too little contrast in progress indicator of inactive tab in light theme
Labels: Help Wanted,Issue-Bug,Area-Accessibility,Product-Terminal,Priority-3,Area-Theming

### Windows Terminal version

1.20.11381.0

### Windows build number

10.0.19045.4529

### Other Software

_No response_

### Steps to reproduce

Configure the terminal to use the light theme (not legacy), and a tab bar separate from the title bar.
Open a PowerShell tab and run a command to output the OSC that sets 50% progress: ``"`e]9;4;1;50`e\"``
Do the same in another tab.



### Expected Behavior

The progress indicators in the tab bar should have good contrast so that I can see how much progress has been made.

### Actual Behavior

The progress indicator of the inactive tab is too light and doesn't have enough contrast to the light background:  
![image](https://github.com/microsoft/terminal/assets/46201428/5e68fa33-16fc-44ea-8a8c-c61c0884af3a)

Compare to the dark theme, where both progress indicators have adequate contrast:
![image](https://github.com/microsoft/terminal/assets/46201428/407b68f2-fb8c-474c-80e0-6ab7bddbcb51)
Repository: godot
Issue: Android Editor freezes when trying to use a virtual joystick addon
Labels: topic:editor,topic:thirdparty,needs testing

### Tested versions

Godot Android editor's 4.2.2.stable version

### System information

Godot Android Editor on Android 12 (Infinix Hot 20i)

### Issue description

I try to use a virtual joystick addon project on Android editor.

the test project opens but the editor interface freezes, except the project viewport where the two joysticks works to navigate it.

Please follow this issue:

https://github.com/MarcoFazioRandom/Virtual-Joystick-Godot/issues/75#event-13215190608

### Steps to reproduce

- On Android, install the editor.
- Download the virtual joystick addon
- open the test project.

### Minimal reproduction project (MRP)

Please follow this issue:

https://github.com/MarcoFazioRandom/Virtual-Joystick-Godot/issues/75#event-13215190608
Repository: rust
Issue: Type mismatch is incorrectly attributed in certain closures / async blocks
Labels: A-diagnostics,T-compiler

### Code

```Rust
pub fn type_error_1() {
    || {
        Ok::<(), ()>(())?;
        let x1: i32 = false;
        todo!()
    };
}

pub fn type_error_2() {
    || {
        Ok::<(), ()>(())?;
        let x2: i32 = { false };
        todo!()
    };
}

pub fn type_error_3() {
    || -> Result<(), ()> {
        Ok::<(), ()>(())?;
        let x3: i32 = { false };
        todo!()
    };
}
```


### Current output

```Shell
error[E0308]: mismatched types
 --> src/lib.rs:4:23
  |
4 |         let x1: i32 = false;
  |                 ---   ^^^^^ expected `i32`, found `bool`
  |                 |
  |                 expected due to this

error[E0308]: mismatched types
  --> src/lib.rs:12:25
   |
12 |         let x2: i32 = { false };
   |                         ^^^^^ expected `i32`, found `bool`
   |
note: return type inferred to be `i32` here
  --> src/lib.rs:11:9
   |
11 |         Ok::<(), ()>(())?;
   |         ^^^^^^^^^^^^^^^^^

error[E0308]: mismatched types
  --> src/lib.rs:20:25
   |
20 |         let x3: i32 = { false };
   |                         ^^^^^ expected `i32`, found `bool`
```


### Desired output

```Shell
error[E0308]: mismatched types
 --> src/lib.rs:4:23
  |
4 |         let x1: i32 = false;
  |                 ---   ^^^^^ expected `i32`, found `bool`
  |                 |
  |                 expected due to this

error[E0308]: mismatched types
 --> src/lib.rs:12:23
  |
4 |         let x2: i32 = { false };
  |                 ---     ^^^^^ expected `i32`, found `bool`
  |                 |
  |                 expected due to this

error[E0308]: mismatched types
 --> src/lib.rs:20:23
  |
4 |         let x3: i32 = { false };
  |                 ---     ^^^^^ expected `i32`, found `bool`
  |                 |
  |                 expected due to this
```


### Rationale and extra context

`x1` shows what the type error should be: the mismatched types are identified and correctly attributed to the type annotation on the local variable.

In `x2`, the previous statement (which makes use of the `?` operator) is incorrectly attributed as the cause of the type error, even though it is not relevant to the error. Commenting out the line or removing the `?` causes this attribution to disappear.

In `x3`, adding a return type annotation to the lambda also causes this attribution to disappear, but the origin of the type error is not identified as in `x1`.

### Other cases

```Rust
pub fn type_error_2() {
    async { // this also causes the same issue as ||
        Ok::<(), ()>(())?;
        let x2: i32 = { false };
        todo!()
    };
}
```


### Rust Version

```Shell
rustc 1.79.0 (129f3b996 2024-06-10)
binary: rustc
commit-hash: 129f3b9964af4d4a709d1383930ade12dfe7c081
commit-date: 2024-06-10
host: x86_64-unknown-linux-gnu
release: 1.79.0
LLVM version: 18.1.7
```


### Anything else?

_No response_
Repository: angular
Issue: Tutorial types are erroring out.
Labels: area: dev-infra,P3,area: docs-infra

### Describe the problem that you experienced

The tutorial types are not working as expected.

### Enter the URL of the topic with the problem

- https://angular.dev/tutorials/first-app
- https://angular.dev/tutorials/learn-angular

### Provide any additional information here in as much as detail as you can


"The types are ultimately based on tutorialFiles from metadata.json, [that currently is equal openFiles](https://github.com/angular/dev-infra/blob/main/docs/pipeline/tutorials/metadata.ts#L16).

openFiles should be only the files being shown in the code editor, and tutorialFiles should hold all files, so the TS files can be sent to the TS virtual file system, therefore identified by imports/types."

Credit to Leonardo Ortiz for diagnosing the issue.
Repository: pytorch
Issue: `max_entries` parameter of `torch.cuda.memory._record_memory_history()`
Labels: module: docs,module: cuda,triaged

### 📚 The doc issue

The memory profiling documentation https://pytorch.org/docs/stable/torch_cuda_memory.html could be improved by answering these questions:
- Can I keep `_record_memory_history()` always enabled with the default `max_entries=sys.maxsize` (9223372036854775807)? Will it consume a significant amount of CPU RAM?
- If I set `max_entries` to a lower value, e.g. 2000, will it keep the first 2000 entries and then stop recording or will it keep the most recent 2000 entries before each snapshot (fifo-style)?
- What is the expected size on disk of the snapshots? Some KBs, MBs?


cc @svekars @brycebortree @ptrblck @msaroufim
Repository: go
Issue: x/tools/gopls: fillstruct heuristic fails to look beneath current point, or in other files
Labels: gopls,Tools

The fillstruct code action looks for declarations in the current file, before the current point, as candidates for the initializers of each missing field. That seems doubly arbitrary: package-level declarations in other files should be candidates too, as should declarations beneath the current point.
Repository: flutter
Issue: Update samples repo to Swift 6
Labels: platform-ios,platform-mac,P2,team-ios,triaged-ios

# Background

Swift 6 language mode enables strict concurrency checking. Code changes may be necessary to upgrade a package to the Swift 6 language mode.

A Swift 6 app can depend on Swift 5 packages and vice-versa. The Swift 6 compiler supports [both Swift 6 and Swift 5 language modes](https://www.swift.org/migration/documentation/swift-6-concurrency-migration-guide/swift6mode/).

WWDC session: https://www.youtube.com/watch?v=75-c6jSE8kU
Migration docs: https://www.swift.org/migration/documentation/swift-6-concurrency-migration-guide/swift6mode/

See also:
* https://github.com/flutter/flutter/issues/150388
* https://github.com/flutter/website/issues/10820

# Work

Update the `flutter/samples` repo to use Swift 6:

https://github.com/search?q=repo%3Aflutter%2Fsamples+path%3A.swift+NOT+path%3AGeneratedPluginRegistrant.swift&type=code
Repository: pytorch
Issue: `KeyError: 'ac_graph_id'` when using compile+SAC+reparameterization with `inline_inbuilt_nn_modules=False`
Labels: triaged,oncall: pt2,module: dynamo,activation-checkpointing

### 🐛 Describe the bug

Repro: https://github.com/pytorch/pytorch/blob/bc51d79d58cdddef29019e87e9c08a5ad4c81a58/test/dynamo/test_activation_checkpointing.py#L1006 (please set `@torch._dynamo.config.patch(inline_inbuilt_nn_modules=False)` above this line)

From [Dynamo log](https://gist.github.com/yf225/3c5547f05474385b22116fb95e9aa7f6), it seems `checkpoint` is not being traced into, hence not triggering `TagActivationCheckpoint.tag_nodes` logic that populates `ac_graph_id` for the nodes.

@tianyu-l reported that it used to work several days ago, so this might be a recent regression.

I believe requiring `inline_inbuilt_nn_modules=True` is also okay, since we are moving in that direction already.

cc. @anijain2305 

### Versions

nightly

cc @ezyang @anijain2305 @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng
Repository: ollama
Issue: How can I set the parameter "num_return_sequences" to get multiple answers within one prompt?
Labels: feature request

The parameter "num_return_sequences" is a parameter in model.generate(), while I did not figure out how to set it when using ollama to run LLMs.
Repository: tauri
Issue: [feat] Windows Thumbnail Toolbar (like media control buttons)
Labels: type: feature request

### Describe the problem

In Electron I can add [thumbnail toolbar (or just thumbar)](https://www.electronjs.org/docs/latest/tutorial/windows-taskbar#thumbnail-toolbars) with buttons, which appears when you hover your mouse over the app icon in taskbar, however, I couldn't find anything similar in Tauri (both v1 and v2), except this abandoned discussion: #7257 

That's what I mean:
![image](https://github.com/tauri-apps/tauri/assets/61843974/37860014-25ae-4c97-87af-dcf592f2762b)
![image](https://github.com/tauri-apps/tauri/assets/61843974/f8538df4-d4d7-4a65-963d-4324301b5bbd)

Here's the link to MSDN about this: https://learn.microsoft.com/en-us/windows/win32/shell/taskbar-extensions#thumbnail-toolbars

P. S. Also this might be a bit related to #7332, but it's NOT the same.

### Describe the solution you'd like

I'd like to have an ability to add, remove and update thumbar buttons at runtime, including their icons and on-click actions. Also, perhaps someone could benefit from being able to have different thumbars on different windows.

### Alternatives considered

_No response_

### Additional context

_No response_
Repository: ollama
Issue: The main shell script runner for ollama downloader doesn't check for hash
Labels: bug

### What is the issue?

Hi team:

You have this ollama installer on the main website.
```
curl -fsSL https://ollama.com/install.sh | sh
```
If someone hacked into the website, and change the script, the end user would never know. You should bake the checksum into the downloader to make sure the installer is not modified.

Something like this would work: 

```
tmpfile=$(mktemp) && curl -fsSL -o "$tmpfile" https://ollama.com/install.sh && echo "2ecc4a9a5afd2f43ac474b59d3be5d81189cc79ca87bd29ed91e0e089a18c765  $tmpfile" | sha256sum -c - && sh "$tmpfile" && rm -f "$tmpfile"
```
Also, you will need to publish the checksum of the installer on github too. If you think this issue is not a big deal, take a look at this: https://www.howtogeek.com/devops/codecov-hacked-what-to-do-now-if-you-use-codecov/


### OS

_No response_

### GPU

_No response_

### CPU

_No response_

### Ollama version

_No response_
Repository: godot
Issue: Emulate Numpad editor setting has no effect when previewing a Camera3D (standard or cinematic preview)
Labels: bug,topic:editor,usability,topic:3d

### Tested versions

- Reproducible in: 4.3.beta cae2f853dcd1ecc26ca68de08cec62089dee1f26

### System information

Godot v4.3.beta (cae2f853d) - Fedora Linux 39 (KDE Plasma) - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4090 (nvidia; 550.78) - 13th Gen Intel(R) Core(TM) i9-13900K (32 Threads)

### Issue description

The **Emulate Numpad** editor setting has no effect when previewing a Camera3D (standard or cinematic preview). This means that if you press a keyboard shortcut that would be translated to the numpad, it'll work when not previewing a camera, but not when previewing a camera.

I discovered this while working on https://github.com/godotengine/godot/pull/93579.

### Steps to reproduce

- Assign an editor shortcut to use a numpad key. This shortcut must have a visible effect when previewing a camera (try **Half Resolution**), so camera *manipulation* shortcuts won't work for testing.
- Enable **Emulate Numpad** in the Editor Settings.
- Press the top row keys to activate the shortcut (not the numpad keys, even if you have a numpad).
- Preview a Camera3D node in the editor and try again.

### Minimal reproduction project (MRP)

N/A