sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: ShapeEnv.produce_guards uses a lot of (CPU) memory
Labels: triaged,oncall: pt2,module: dynamic shapes

### 🐛 Describe the bug

Let's suppose you've generated a bajillion guards, e.g., via a bug at https://github.com/pytorch/pytorch/issues/118214

You might still expect we can generate guards in this case. However, apparently if you feed too many to produce_guards it will OOM. Figure out what inefficiency in produce_guards this is.

### Versions

main

cc @msaroufim @bdhirsh @anijain2305 @zou3519
Repository: vscode
Issue: In File Save as Dialog, clicking on an file with an extension longer than 4 characters only brings puts file name, no extension, as the default file name 
Labels: upstream,macos,confirmed,native-file-dialog

Type: <b>Bug</b>

1. Open a blank or any file
2. Save file as "test.htmlx" (or any valid 5 letter extension, including .ipynb)
3. open a new blank file 
4. Click file, Save as 
5. Click on test.htmlx
6. Observe file name field is now populated with "test" with no extension

Originally Noticed this on Jupyter notebooks (.ipynb files). Please lmk if the issue is with something else and I should open an issue elsewhere.
<img width="595" alt="image" src="https://github.com/microsoft/vscode/assets/1852285/d3180099-c10c-4985-9721-d0dbab78d4f0">


VS Code version: Code 1.85.2 (Universal) (8b3775030ed1a69b13e4f4c628c612102e30a681, 2024-01-18T06:40:32.531Z)
OS version: Darwin arm64 23.1.0
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Apple M1 Max (10 x 24)|
|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>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|2, 2, 3|
|Memory (System)|64.00GB (25.91GB free)|
|Process Argv|--crash-reporter-id cffa3374-53ad-4127-83b8-4845fc11554a|
|Screen Reader|no|
|VM|0%|
</details>Extensions: none<details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
vscod805:30301674
binariesv615:30325510
vsaa593:30376534
py29gd2263:30899288
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30933248
pythongtdpath:30769146
welcomedialogc:30910334
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
pythontbext0:30879054
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302

```

</details>

<!-- generated by issue reporter -->
Repository: storybook
Issue: [Bug]: docs addon can't compile mdx in "classic" jsx runtime mode
Labels: bug,help wanted,mdx,sev:S3

### Describe the bug

My project uses React 16 so I'm trying to set up the docs addon with "classic" jsx runtime mode for compiling mdx. When I do, mdx files fail to compile with the following error:

```
Module parse failed: Identifier 'React' has already been declared (6:7)

File was processed with these loaders:
 * ../../node_modules/@storybook/mdx2-csf/loader.js
You may need an additional loader to handle the result of these loaders.
| /*@jsxRuntime classic @jsx React.createElement @jsxFrag React.Fragment*/
| import {useMDXComponents as _provideComponents} from "/Users/sfishel/opt/splunk/olly/packages/olly-udf/node_modules/@storybook/addon-docs/dist/shims/mdx-react-shim";
> import React from "react";
| import {Meta, Canvas, PureArgsTable} from '@storybook/addon-docs';
| import * as Stories from './RestDataSource.stories';
```

### To Reproduce

https://stackblitz.com/edit/github-by2l74?file=.storybook%2Fmain.ts

Contents of my `main.js` file:

```js
import type { StorybookConfig } from '@storybook/react-webpack5';

const config: StorybookConfig = {
  stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|mjs|ts|tsx)'],
  addons: [
    {
      name: '@storybook/addon-docs',
      options: {
        mdxPluginOptions: {
          mdxCompileOptions: {
            jsxRuntime: 'classic',
          },
        },
      },
    },
    '@storybook/addon-webpack5-compiler-swc',
  ],
  framework: {
    name: '@storybook/react-webpack5',
    options: {},
  },
};
export default config;

```

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 14.2.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 16.20.2 - ~/.nvm/versions/node/v16.20.2/bin/node
    Yarn: 1.22.19 - ~/opt/splunk/olly/node_modules/.bin/yarn <----- active
    npm: 8.19.4 - ~/.nvm/versions/node/v16.20.2/bin/npm
  Browsers:
    Chrome: 120.0.6099.234
    Safari: 17.2.1
  npmPackages:
    @storybook/addon-a11y: ^7.6.3 => 7.6.3 
    @storybook/addon-docs: ^7.6.3 => 7.6.3 
    @storybook/addon-essentials: ^7.6.3 => 7.6.3 
    @storybook/addons: ^7.6.3 => 7.6.3 
    @storybook/react: ^7.6.3 => 7.6.3 
    @storybook/react-webpack5: ^7.6.3 => 7.6.3 
    @storybook/testing-react: ^2.0.0 => 2.0.1 
    @storybook/theming: 7.6.3 => 7.6.3
```


### Additional context

If I'm understanding the code correctly, the `@storybook/mdx2-csf` loader is explicitly inserting an `import React from 'react';` statement, but when the MDX compiler itself is in "classic" jsx runtime mode, it also inserts that same import.
Repository: node
Issue: Know when a process ended due to the `child_process.spawn()` `timeout` option 
Labels: child_process,feature request

### What is the problem this feature will solve?

When a process ends due to the `timeout` option of `child_process.spawn()`, there is no way to know whether that termination was due to the timeout. A `SIGTERM` is sent to the process, but that's pretty much it.

```js
import {spawn} from 'node:child_process'

const childProcess = spawn('node', ['-e', 'setTimeout(() => {}, 1e7)'], {
  timeout: 2e3, 
  stdio: 'inherit', // no stdout/stderr
})
childProcess.on('exit', (exitCode, signal) => {
  console.log({exitCode, signal}) // { exitCode: null, signal: 'SIGTERM' }
})
```

This makes debugging harder. Some users might be left wondering why the process ended if they don't pay attention to the `timeout` option.

### What is the feature you are proposing to solve the problem?

Having a way to know whether the process ended due to the `timeout` option. Any implementation would work. Some potential ideas:
  - `timeout` event on `childProcess`
  - third boolean argument `timedOut` passed to the `exit` event
  - emit an `error` event with `error.code: 'ETIMEDOUT'` on `childProcess`. This is a breaking change since many users are currently listening for `error` events, so would probably not be a good idea.
  - `childProcess.timedOut = true`
  - `childProcess.timedOut()` returning a boolean

### What alternatives have you considered?

One could possibly set a manual timeout like the following.

```js
let timedOut = false
setTimeout(() => {
  timedOut = true
}, 2e3)
```

However, it defeats some of the convenience of the `timeout` option, since that one might as well call `childProcess.kill()` themselves then. Also, it is slightly unreliable since an unrelated `SIGTERM` could theoretically have been sent at the exact same time.
Repository: pytorch
Issue: Support for banded matrix operations
Labels: feature,triaged,needs research,module: linear algebra

### 🚀 The feature, motivation and pitch

It would be amazing if there could be support for [banded matrix](https://en.wikipedia.org/wiki/Band_matrix) operations, which are more efficiently stored by their diagonals rather than full matrices.  Some common operations include [`solve_banded`](https://docs.scipy.org/doc/scipy/reference/generated/scipy.linalg.solve_banded.html#scipy.linalg.solve_banded) (solving banded linear systems), [`cholesky_banded`](https://docs.scipy.org/doc/scipy/reference/generated/scipy.linalg.cholesky_banded.html#scipy.linalg.cholesky_banded) (cholesky decompostition of banded matrices) and [`eig_banded`](https://docs.scipy.org/doc/scipy/reference/generated/scipy.linalg.eig_banded.html#scipy.linalg.eig_banded) (eigenvalues of banded matrices).  

### Alternatives

_No response_

### Additional context

The aformentioned functions are all currently implemented in `scipy.linalg`, which I believe calls Lapack under the hood.  TensorFlow also has a [`banded_triangular_solve`](https://www.tensorflow.org/api_docs/python/tf/linalg/banded_triangular_solve) that can perform batch processing.  However, none of these have GPU support.  
```[tasklist]
### Tasks
```


cc @jianyuh @nikitaved @pearu @mruberry @walterddr @xwang233 @Lezcano
Repository: vscode
Issue: Open-notebook search results not appearing correctly on re-opening notebook
Labels: bug,search,notebook

Repro:
1. search in open notebook with >1 result.
2. Close the notebook.
3. Click on the result again.
4. Sometimes, the restored results are less than expected :bug:
Repository: pytorch
Issue: PT2.1 cudagraph trees loss divergence
Labels: high priority,needs reproduction,triaged,module: cuda graphs,oncall: pt2

### 🐛 Describe the bug

On Pytorch 2.1, we're training a model with reduce-overhead and cudagraph trees turned on. It gives us a large speedup but the loss curves diverge from both eager and default compile. Loss curves match between eager mode and default compile, so it seems the issue is in cuda graphing.

I tried the accuracy minifier and was able to create a repro that throws an AccuracyError, but I don't think the repro uses cuda graphs. Also the repro is not very mini, has thousands of lines of aten ops. Could still be a place to start
[repro.py.txt](https://github.com/pytorch/pytorch/files/14043863/repro.py.txt)


### Versions

Ubuntu 22.04.1 LTS
Pytorch 2.1 with a few custom and upstream patches

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @mcarilli @eellison @peterbell10 @bdhirsh @anijain2305 @chauhang
Repository: next.js
Issue: `Invariant: page wasn't built` error during build when dynamic App Router route conflicts with dynamic Pages Router route
Labels: bug

### Link to the code that reproduces this issue

https://github.com/dstaley/overlapping-app-router-pages-router

### To Reproduce

1. `next build`

### Current vs. Expected behavior

When the Pages Router and the App Router both generate a page for the same dynamic URL, running `next build` returns the following error:

```
> Build error occurred
Error: Invariant: page wasn't built
    at C:\overlapping-app-router-pages-router\node_modules\next\dist\build\index.js:1727:47
    at Array.map (<anonymous>)
    at C:\overlapping-app-router-pages-router\node_modules\next\dist\build\index.js:1724:84
    at async Span.traceAsyncFn (C:\overlapping-app-router-pages-router\node_modules\next\dist\trace\trace.js:151:20)
    at async C:\overlapping-app-router-pages-router\node_modules\next\dist\build\index.js:1343:17
    at async Span.traceAsyncFn (C:\overlapping-app-router-pages-router\node_modules\next\dist\trace\trace.js:151:20)
    at async build (C:\overlapping-app-router-pages-router\node_modules\next\dist\build\index.js:374:9)
    at async main (C:\overlapping-app-router-pages-router\node_modules\next\dist\bin\next:155:5)
```

The expected behavior is that the site builds without errors, and renders `(app router)` on the `/one/two` route and `(pages router)` on `/one/three` and `/three/four`.

If it's intentional that overlapping a pages route with an app route shouldn't work, I'd expect the error message to specifically reference that, printing out the conflicting routes and suggesting that the developer pick either app or pages, but not both.

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro
Binaries:
  Node: 18.19.0
  npm: 10.2.5
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.1.1-canary.9 // Latest available version is detected (14.1.1-canary.9).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


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

App Router

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

next build (local), Vercel (Deployed)

### Additional context

_No response_
Repository: flutter
Issue: [Impeller] Optimize shadows with 0 or tiny sigmas
Labels: engine,P2,e: impeller,team-engine,triaged-engine

Currently when the sigma is small enough we avoid the use of the optimized shadow shader that might get NaN values when computing those. Unfortunately, the code that determines if we can use the optimized shader can only answer one of 2 values:

- true - I can do it and in fact I already did all the work to do it so we are done
- false - I can't do it so you have to use the slow case

Unfortunately, when the sigma is small enough, there is nothing special to be done to render the shadow. We'd like to just render it normally, but `AttemptDrawBlurredRRect` can only return "true" meaning it drew it using the special shader (which can't draw it because of NaN issues with tiny sigmas), or it can return "false" meaning the calling code should proceed as normally which involves going through the slow path for blurring the rect. So, in the specific case that should go the fastest (no shadow to draw), we use the slowest path.

There are a number of possible solutions:
- Simply don't record tiny sigmas when they come in through the DisplayList interface. This gets tricky when we don't necessarily know the final rendering transform in order to evaluate how "tiny" the sigma is. But, we could at least weed out "zero" sigmas.
- Fix the math in the fast shadow shader so it can deal with a zero sigma. It used to have code for this, but that code would render a blocky version of the shape (no MSAA) so it was removed.
- Teach the "slow path" to also ignore tiny sigmas and have that path just do a normal rendering of the content. This should be able to be dealt with in the `Paint` methods that wrap an entity with filters.
Repository: terminal
Issue: Command Decorations / Marks in the gutter / margin / padding 
Labels: Area-TerminalControl,Product-Terminal,Issue-Task,In-PR

placeholder thread while I actually write something up


> Now see, if it was up to me, I'd recommend instead a "icon in the gutter", ala vscode. They've been working on these terminal-driven "quick fixes", that put a lightbulb in the "gutter". That lightbulb is clickable and shows a menu.

![](https://user-images.githubusercontent.com/10746682/204557790-d8f924ed-77f7-44a1-80ad-1ade6b83fdaa.png) ![](https://user-images.githubusercontent.com/2193314/204605411-1106e6d4-70ed-4b45-884f-c09dba3cb040.png)
![](https://user-images.githubusercontent.com/29464607/204635771-335ac900-b13a-4a12-8808-36d6ab0f5080.png)

Basically, I'm thinking there's a few kinds of things that show up in the gutter:
* marks for each command, driven by shell integration 
* quick fixes that are driven by some VT escape sequence that we haven't authored yet (so a CLI app could specifically recommend a command)
* quick fixes that the Terminal generates on a CommandNotFound (<---- what you're working on)
* quick fixes that are generated based on pattern matching (from that spec)

From Teams: 
> Trick is, what is the gutter?
> We've already got the idea of "padding", but these icons all precipitate the need for like, at least 16px of padding on the left. 
> Which some people may greatly dislike
> But I suppose our DEFAULT_PADDING is "8,8,8,8" already?
> Alternatively, the "gutter" could be an "entirely separate thing from the padding". So a user could specifically opt into the gutter, and that would automatically reserve an additional 16px in the left padding. 
> And that, we could enable already by default (though, it would add left padding for people who already opt'd out)
> Regardless. We've got to come up with a clear plan on what to do there first. Then it's easy to just have a VT sequence stick and additional sendInput command into a mark on the gutter, IMO

#### references 

* #15700
* https://github.com/microsoft/vscode/issues/166761
* #16848
Repository: terminal
Issue: [Megathread] Broadcast input follow-ups
Labels: Product-Terminal,Needs-Tag-Fix,Issue-Scenario

#### [Original issue #2634] [Original spec #9365] [Original PR: #14393]

```[tasklist]
### Tasks
- [ ] Finish the spec draft
- [ ] #16593
- [ ] https://github.com/microsoft/terminal/issues/15812
```
Repository: material-ui
Issue: [joy-ui][Tooltip] Add ability to use tooltip in "childfree" mode
Labels: waiting for 👍,component: tooltip,package: joy-ui,enhancement

### Summary

Currently, the only way to have several elements with the same tooltip is to wrap each element with it:
```tsx
{rows.map(row => (
	<Tooltip key={rows.id} title={row.tooltipTitle}>
		<div>{row.text}</div>
	</Tooltip>
)}
```
If there are 100 rows, there are 100 `div`s and 100 `Tooltip`s.

For most cases this is okay.

But, if tooltips are controlled, each row must re-render on tooltip state change.

It seems that using something like a context tooltips can be made to work this way:
```tsx
{rows.map((row) => (
	<div key={row.id} onHover={(e) => setTooltipContextOrSmth({position: e.position, title: row.title)}>
		{row.text}
	</div>
))}
<Tooltip {...tooltipContextOrSmth} />
```

I am not sure how big of a portion of this behavior should be part of the library, but at least being able to set position (or anchor) I think is a must.

If this is already possible, I would like to see an example in docs, I did not find any.

You can probably already achieve this with menus or popovers, but it feels weird to reimplement tooltip just to move it somewhere.



### Examples

n/a?

### Motivation

In my pet project, I'm making a tooltip-synced """chart""":
![image](https://github.com/mui/material-ui/assets/17963791/d943b712-184a-4abd-9700-7d12de88d274)
If you hover one of the top columns or one of the bottom columns, the other's tooltip will open also, and for big """charts""" I'm getting performance hit on hover.

Yes, this particular use-case is probably solved by an actual charts built with <canvas>, like mui-charts, but same problem could happen in tables or for github activity for example:
![image](https://github.com/mui/material-ui/assets/17963791/8276a108-06e4-42c9-a1f7-b7a7073c08a3)


**Search keywords**: one tooltip multiple hosts childfree childrenless anchor position host
Repository: pytorch
Issue: [FSDP] NO_SHARD numerics with cpu offloading and orig params
Labels: triaged,module: fsdp

### 🐛 Describe the bug

loss would be different with NO_SHARD, cpu offload=True, orig param = True

repro

```
# torchrun --standalone --nproc_per_node=2 run_no_grad_numeric.py
import os
import torch
import torch.distributed as dist
import torch.nn as nn
from torch.distributed.fsdp.wrap import ModuleWrapPolicy
from torch.distributed.fsdp.fully_sharded_data_parallel import (
    FullyShardedDataParallel as FSDP,
    ShardingStrategy,
)
from torch.distributed.fsdp import CPUOffload, MixedPrecision, BackwardPrefetch


class Model(nn.Module):
    def __init__(self):
        super().__init__()
        self.layer0 = nn.Linear(4, 4, device="cuda")
        self.layer1 = nn.Linear(4, 4, device="cuda")
        self.layer2 = nn.Linear(4, 4, device="cuda")
    def forward(self, x):
        r1 = self.layer0(x)
        r2 = self.layer1(x)
        r3 = self.layer2(x)
        return torch.concat([r1, r2, r3])

def main():
    dist.init_process_group(backend="nccl")
    gpu_id = int(os.environ["LOCAL_RANK"])
    device = f"cuda:{gpu_id}"
    torch.cuda.set_device(device)
    fsdp_kwargs = {
        "device_id": torch.cuda.current_device(),
        "auto_wrap_policy": ModuleWrapPolicy({nn.Linear}),
        "sharding_strategy": ShardingStrategy.NO_SHARD,
        "use_orig_params": True,
        "cpu_offload": CPUOffload(offload_params=True),
    }
    torch.manual_seed(0)
    model = Model()
    model = FSDP(model, **fsdp_kwargs)
    if torch.distributed.get_rank() == 0:
        print(model)
    torch.manual_seed(0)
    ref_model = Model()
    ref_model = FSDP(ref_model, **fsdp_kwargs)
    torch.manual_seed(dist.get_rank() + 1)
    batch_size = 3
    x = torch.randn((batch_size, 4), device="cuda")
    loss1 = model(x).sum()
    loss1.backward()
    loss2 = ref_model(x).sum()
    loss2.backward()
    assert torch.equal(loss1, loss2), f"loss1={loss1} vs loss2={loss2}"


if __name__ == "__main__":
    main()
```

### Versions

d 

cc @zhaojuanmao @mrshenli @rohan-varma @awgu @fegin @penguinwu @kwen2501
Repository: ant-design
Issue: `<Card />` doesn't look good under dark theme with `bordered={false}` or `hoverable`
Labels: 💄 Design,Inactive,unconfirmed

### Reproduction link

[https://stackblitz.com/edit/vitejs-vite-6gj9cp?file=src%2FApp.tsx](https://stackblitz.com/edit/vitejs-vite-6gj9cp?file=src%2FApp.tsx)

### Steps to reproduce

View the reproduction

### What is expected?

Shadow color should be changed under dark algorithm, since the background color is likely to be nearly black.

### What is actually happening?

Shadow color is the same as in default algorithm, which is for light background.

| Environment | Info |
| --- | --- |
| antd | 5.13.2 |
| React | 18.2.0 |
| System | Windows 11 |
| Browser | Chrome 120 |

---
This might not only happen to `<Card />`, worth a look for all components using such shadow color in dark mode.

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: yt-dlp
Issue: Allow --print to return the full filepath of all downloaded files
Labels: enhancement,core-triage

### DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

- [X] I understand that I will be **blocked** if I *intentionally* remove or skip any mandatory\* field

### Checklist

- [X] I'm requesting a feature unrelated to a specific site
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I have **updated yt-dlp to nightly or master** ([update instructions](https://github.com/yt-dlp/yt-dlp#update-channels))
- [X] I've searched [known issues](https://github.com/yt-dlp/yt-dlp/issues/3766) and the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues **including closed ones**. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Provide a description that is worded well enough to be understood

When downloading multiple files at once (video, subtitles, thumbnail, infojson, etc), it's possible to get the final output path for the video by using an option such as `--print "after_move:%(filepath)j"`. 

However, that only returns the filepath for the video and there doesn't appear to be a convenient set of methods for returning the filepath of the non-video downloaded files. I've tried a few permutations of `--print "after_move:subtitle:%(filepath)j"` without luck. The information _is there_, but it's stored under many different, unrelated keys (`infojson_filename`, `thumbnails.:.filepath`, `requested_subtitles.:.<lang>`, etc).

My suggestion would be to group these under a section of `requested_files` which could be a list of dicts detailing the file's purpose (subtitle, thumbnail, etc) as well as its location on-disk (alongside any other pertinent metadata).

Thank you for all your good work! This is a wonderful piece of software.

### Provide verbose output that clearly demonstrates the problem

- [ ] Run **your** yt-dlp command with **-vU** flag added (`yt-dlp -vU <your command line>`)
- [ ] If using API, add `'verbose': True` to `YoutubeDL` params instead
- [ ] Copy the WHOLE output (starting with `[debug] Command-line config`) and insert it below

### Complete Verbose Output

_No response_