sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: [User model][tracker] Improve compilation of PPO model (Stable-baselines3)
Labels: triaged,oncall: pt2,module: dynamo,dynamo-must-fix,dynamo-user-empathy-day

`pip install stable-baselines3[extra]`

## Repro

```python
from stable_baselines3 import PPO
import torchdynamo 



@torchdynamo.optimize("inductor")
def train():
    model = PPO("MlpPolicy", "CartPole-v1").learn(10_000)


import time 
tic = time.time()
train()
toc = time.time()
print(toc - tic)
```

Lots of assertion errors



## Logs

Current state of things (feel free to edit as we fix things):
https://github.com/pytorch/pytorch/issues/93697#issuecomment-1984826847

cc @ezyang @bdhirsh @anijain2305 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @mruberry @rgommers @wconstab @zou3519 @aakhundov @soumith @ngimel
Repository: pytorch
Issue: [minifier] Accuracy minification
Labels: triaged,oncall: pt2,module: minifier

- [ ] For integer tensors, currently we have torch.zeros for rand_strided (https://github.com/pytorch/torchdynamo/blob/main/torchdynamo/testing.py#L254). This is ok for Exceptions, but not really useful for accuracy. We need to get the maximum value from the original tensor and then replace zeros with randint(max_value)

* `git revert 35590bb9ae5781d93e483540e9492e1409347800`
* `TORCHDYNAMO_REPRO_AFTER="dynamo" TORCHDYNAMO_REPRO_LEVEL=4 benchmarks/huggingface.py -d cuda --inductor --training --float32 --accuracy  --only=BertForQuestionAnswering` shows that accuracy divergence was observed
* But `python /tmp/minifier_anijain/minifier_launcher.py` does not minify
* Changing torch.zeros to torch.randint(10, ..) as mentioned above would fix it. So, the goal is to get the max_value plumbed through.

- [ ] We currently do fwd_output.sum().backward() - This could hide indexing issues, because the loss is same for all the tensors. We should provide torch.rand_like() input gradients. More context here - https://github.com/pytorch/torchdynamo/pull/1414#issuecomment-1262801213


cc @ezyang @msaroufim @wconstab @bdhirsh @zou3519 @soumith @ngimel @williamwen42 @yanboliang
Repository: pytorch
Issue: End-to-End AMP training with GradScaler
Labels: triaged,enhancement,oncall: pt2

https://github.com/pytorch/torchdynamo/blob/main/benchmarks/training_loss.py performs end-to-end training with TorchDynamo and TorchInductor with AMP. However, we are not testing AMP training in a standard manner. 

AMP training has [GradScaler](https://pytorch.org/docs/stable/amp.html#gradient-scaling) which performs scaling, monitors gradients, discards batch sizes if gradients are inf/nan. More importantly, GradScaler is stateful. All this warrants an end to end training testing with TorchDynamo and TorchInductor stack.

There would be many great articles on AMP. This is the first one I stumbled upon - https://spell.ml/blog/mixed-precision-training-with-pytorch-Xuk7YBEAACAASJam

cc @ezyang @msaroufim @bdhirsh @zou3519 @chauhang @soumith @wconstab @ngimel @yanboliang 
cc @xuzhao9 if torchbench already has AMP setup for end to end training

cc @msaroufim if you are interested in this
Repository: pytorch
Issue: Inductor doesn't fuse outer dimension softmax into a single kernel.
Labels: feature,triaged,oncall: pt2,module: inductor,internal ramp-up task

http://ix.io/4cog

We generate two kernels:

![image](https://user-images.githubusercontent.com/6355099/194673608-c62b6f4e-3be9-4872-a7d8-0ae2b01bc44e.png)

The issue seems to lie in the memory dependencies not matching up.

cc: @jansel @ngimel

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler @soumith @ngimel
Repository: pytorch
Issue: Use bytecode rewriting to offer a __future__ feature
Labels: feature,low priority,triaged

Let's suppose we want to make a BC breaking API change to a function, and give sufficient time for users to migrate off the old API and onto the new one. Although this can be done by directly introducing `foo_old` and `foo_new` names of functions, a smoother way to opt into the old or new functionality is to control it at the module import level (`from torch import foo_new as foo`), which permits the new function to be used without having to modify the rest of the code (and when foo's semantics changes from foo_old to foo_new, you can just remove the import here.) The good thing about module imports is that the semantics change is lexical: if you are a user and you want to opt into the new behavior, but a library you use is still on the old behavior, changing your local imports lets you surgically only affect your own module, and not that of your library.

Unfortunately, this capability is not available for method changes, since a method is not imported in any meaningful way; instead, it is directly invoked on top of a Tensor object.

Python, the language, has internally provided a mechanism to do this for the migration from integer division to true division: `from __future__ import division`. This dynamically changed the meaning of `/` operator to translate into `__truediv__` opcode instead of `__div__`, until Python 3 when this translation was by default. There is no built-in way, however, for libraries to take advantage of the same sort of thing. That is... until torchdynamo.

torchdynamo interposes in bytecode rewriting level. This means it can detect occurrences where a method call should be translated. Suppose we want to rewrite `foo` to `foo_new` on Tensor objects. Then anywhere in bytecode we have `x.foo(*args)` call, we can rewrite it to `x.foo_new(*args) if isinstance(x, Tensor) else x.foo(*args)`. For better efficiency, torchdynamo could give a specialized program that eliminates the isinstance calls if it is compiling a trace where on entry we know that x happens to be isinstance.

I have discussed this with @jansel and at least the unoptimized version would be relatively easy to implement in torchdynamo. @jansel would be willing to help review a diff that added this functionality. This capability is another reason why I would like to see torchdynamo available by default for PyTorch users.

cc @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng @soumith @ngimel
Repository: pytorch
Issue: Don't over-specialize on list append/clear
Labels: triaged,enhancement,oncall: pt2,module: dynamo,dynamo-symbolic-analysis

This example:
```
mylist = []

@torchdynamo.optimize(...)
def foo():
   mylist.append(torch.randn(10) + 1)


foo()
foo()
foo()
```

We will compile 3 versions of foo:
- One guarding that mylist is len 0
- One guarding that mylist is len 1 (and has one matching tensor)
- One guarding that mylist is len 2 (and has two matching tensor)

Really, only 1 is version is needed.

Similarly.  A different function calling `mylist.clear()` will guard on the contents of the list, despite never looking at the contents.

This may cause an issue for [python autograd](https://github.com/facebookresearch/torchdynamo/blob/00b29660a438e6a0cb6ffd7e17ed11856f63a8b1/tests/test_python_autograd.py), as currently TorchDynamo will guard on the entire contents of the tape.  

cc @ezyang @bdhirsh @anijain2305 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @soumith @msaroufim @wconstab @ngimel @mlazos @yanboliang @Xia-Weiwen @desertfire @zdevito
Repository: pytorch
Issue: Improve handling of generators
Labels: triaged,enhancement,oncall: pt2,module: dynamo

Generators are currently partially supported. 

Suppose you have a generator:
```
def gen():
  x = torch.randn(8)
  yield x + 1
  yield x + 2
```

There are four main cases:


### Case 1: The generator is both created and used inside a dynamo context

```
@torchdynamo.optimize(...)
def case1():
  y = torch.zeros(8)
  for i in gen():
    y += torch.relu(i)
  return y
```

This is the common case.  It is currently supported, however the handling is slightly incorrect.  

TorchDynamo will reorder the computation as if you replaced `gen()` with `list(gen())`.  `x + 2` will happen before both `relu` calls rather than between them.

This is usually fine, however if the generator has side effects *and* those side effects conflict with things outside the generator it could generate a wrong answer.

This feels somewhat contrived, as users typically don't write code like that, however, we should either support this properly or detect this case (and break the graph).


### Case 2: The generator escapes the dynamo context

```
@torchdynamo.optimize(...)
def case2():
  it = gen()
  next(it)
  return it
```

This is currently supported, however the handling is slightly incorrect.  Again, dynamo acts as if you replaced `gen()` with `list(gen())`.  TorchDynamo will `return iter([x+2])`, which is not exactly right as x+2 should not be computed at all until `next()` is called on the return value, while dynamo pre-computes it.

I could see this causing issues if you mutate global tensors in-place inside a generator.  Rather similar to case 1.


### Case 3: The generator is the dynamo frame
```
with torchdynamo.optimize(...):
  gen()
```

This is currently not supported and will just fall back to eager.


### Case 4: The generator is passed to the dynamo context

```
it = gen()
next(it)
with torchdynamo.optimize(it):
  case4(it)
```

This is currently not supported and will just fall back to eager.

Both case 3 and case 4 will be someone tricky to support.  CPython implements generators by re-entering a partially evaluated frame in the middle, which makes re-writing the frame much harder.  Perhaps we could have a pre-pass that splits the generator into multiple frames like `gen_part1()`, `gen_part2()` etc.

I am curious if there is a need to support case 3/4.  Please comment if you have a good motiving example use case in the wild.





cc @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng @pbelevich @soumith @wconstab @ngimel @yanboliang @Xia-Weiwen @desertfire
Repository: pytorch
Issue: [Dynamo] Prints, logging, and warnings
Labels: module: logging,triaged,enhancement,oncall: pt2,module: dynamo

Debug printouts via the:
- `print()` builtin function
- [logging](https://docs.python.org/3/library/logging.html) builtin library
- [warnings](https://docs.python.org/3/library/warnings.html) builtin library
- Third party logging/stats libraries

Are all somewhat common in PyTorch code.  Currently, all of these will trigger graph breaks in TorchDynamo.  I have argued breaking the graph on prints is the only correct behavior.  If the user writes:
```
x = torch.sin(x)
print(time.time())
x = torch.sin(x)
x = torch.sin(x)
print(time.time())
x = torch.sin(x)
```
Implicitly moving prints to either the start or end of the function may be confusing for users and is not something we should do by default.

That said, I could see the value in adding a `reorder_prints=True` configuration option to TorchDynamo which would defer all prints to the after the graph.  This would allow larger graphs, with only a small change in program semantics.  It would be easy to implement and add value to users, so we should add it.

The `warnings` module might be fine to reorder by default.  For third party logging libraries, we might need a system for users register things it is safe to reorder with respect to PyTorch ops.








cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng @soumith @ngimel
Repository: godot
Issue: Importing objects with and without _nav causes node name collision
Labels: bug,topic:import

### Godot version

4.0beta16+0810eca

### System information

Windows 10

### Issue description

The function in `ResourceImporterScene::_pre_fix_node` which handles suffixes such as `_col` or `_vehicle` or `_nav` removes the suffix, which can cause a name collision with another node.

Due to the API used (`set_name` followed by `replace_by`), it can cause a name conflict to occur.

Elsewhere in the gltf importer, an explicit uniqueness is guaranteed, and additionally `Node::add_child(..., true)` protects against duplicate names in a better way.

I think it would be better to avoid removing the extension, but this would be compat breaking. Maybe we can add an option in 4.1 or later. (Not removing the extension would reduce the risk of affecting documents in which the "_wheel" naming was accidental, as in this issue: #72419 )

### Steps to reproduce

1. Open the attached project.
2. New inherited scene on the blend file.
3. Notice some node names are duplicated nondeterministicly with the `@` symbol
![godot_duplicate_invalid_node_names](https://user-images.githubusercontent.com/39946030/215920502-6c46cca9-1363-46ce-9f50-6fe5238ac198.png)


### Minimal reproduction project

[Duplicate_Collider_Name_Test.zip](https://github.com/godotengine/godot/files/10552308/Duplicate_Collider_Name_Test.zip)
Repository: pytorch
Issue: Support data-dependent control flow operators
Labels: module: onnx,feature,triaged,onnx-needs-info,oncall: pt2,module: dynamo

I've had a number of discussions with folks about the idea of using TorchDynamo to capture data-dependent control flow into some sort of (yet to be created) control flow operator in PyTorch/aten.

Technically, capturing the control flow wouldn't be that hard.  TorchDynamo sees the `POP_JUMP_IF_FALSE <tensor>` bytecode, and decides to break the graph on it.  It could instead decide to inject an `aten::if` or `aten::bailout_if` into the graph.

The real challenge is how do you trace the remainder of the function.  The easiest approach would be to follow a [tracing JIT](https://en.wikipedia.org/wiki/Tracing_just-in-time_compilation) pattern and only follow the branch taken with the initial example inputs TorchDynamo already tracks.  This would result in an `aten::bailout_if` op, that would allow early exit from the graph if the execution diverges from the original trace.

Other options that capture multiple sides of the branch would also be possible, but more complex to implement.

I'd be curious how well backend would do with these types of operators.  Currently, I don't think we do fusions that cross control flow boundaries, so the speedups from this could be limited.


cc @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @soumith @wconstab @ngimel @mlazos @yanboliang @Xia-Weiwen @desertfire
Repository: pytorch
Issue: Torchdynamo for Deepspeed and FSDP
Labels: oncall: distributed,feature,low priority,triaged,module: fsdp,oncall: pt2,module: dynamo

In AWS we are working with customers to enable gigantic transformer model training on EC2. Furthermore, we attempt to leverage compiler techniques to optimize Pytorch workloads due to its widely adoption. For example, we recently open-sourced [RAF](https://github.com/awslabs/raf), a deep learning compiler for training, that shows promising training acceleration for a set of models and verified it works with TorchDynamo. On the other hand, we do see the gap converting Pytorch programs to the IR we are using, especially when it comes to complex strategies such as distributed training.

One example is [Deepspeed](https://github.com/microsoft/DeepSpeed). It implements data parallelism (ZeRO) on top of Pytorch, introducing sharding for optimizer states, gradients and parameters. (FSDP is another approach to do ZeRO). The idea itself is pretty straightforward, but when trying to convert the Deepspeed implementation to RAF via lazy-tensor, it doesn’t work well. For instance, the [NaN check for gradients](https://github.com/microsoft/DeepSpeed/blob/master/deepspeed/runtime/zero/stage3.py#L2461) breaks the graph and result performance degradation; It doesn’t capture CUDA stream usage; etc.

In my understanding, those issues could potentially be resolved via TorchＤynamo as it has the capability to extract structures and call information via Python bytecode, apart from the lazy tensor tracing mechanism at higher level.

So we’d like to get suggestion from TorchDynamo community, what do you think about supporting such scenarios in TorchDynamo? Specifically, 1) how should TorchDynamo support ZeRO tracing? 2) would that be in the TorchDynamo soon or later? Due to our current roadmap and goals, we at AWS would be interested in collaboration along this direction if possible.

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @wconstab @yf225 @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng @kiukchung @lucasllc @d4l3k @soumith @ngimel @comaniac @szhengac @yidawang @mli @hzfan @zachzzc
Repository: godot
Issue: AnimationPlayer can't queue the same animations
Labels: bug,topic:animation

### Godot version

4.0 beta 8+

### System information

Nobara Linux

### Issue description

If an animation finishes, then is told to play again, the related AnimationPlayer will completely freeze, but only if it is trying to blend.

### Steps to reproduce

1. Run the MRP
2. Press up to play the corresponding animation
3. Press left while this animation is playing to queue the left one
4. Observe that this 'queued' animation plays normally
5. Allow the animation to stop
6. Press up once more
7. While the animation is playing, try to queue the same animation by pressing up again
8. Observe that the animation freezes

### Minimal reproduction project

https://github.com/irmozius/repeat-anim-glitch
Repository: PowerToys
Issue: [Feature] Add function of setting shortcut
Labels: Needs-Triage

### Description of the new feature / enhancement

It has to be said that this is a good application, but now this software can only map shortcut keys instead of setting shortcut keys. I want to add shortcut keys to run custom commands.

### Scenario when this would be used?

I want to quickly open an application, such as the Terminal.

### Supporting information

_No response_
Repository: flutter
Issue: Extending to paragraph/or word boundary on MacOS should default to the `downstream` position when at a word wrap
Labels: a: text input,framework,platform-mac,P2,team-text-input,triaged-text-input

When using keyboard shortcuts on MacOS
* shift + option + up/down to extend to the next/previous paragraph boundary
* shift + option + left/right to extend to the next/previous word boundary

And the caret is positioned at a word wrap initially, and the selection is extended, when returning to the original position (collapsing at the base when the selection inverts) the resulting selection should to default to the `downstream`  position.

Current Behavior:
The selection inherits the `affinity` from `selection.base.affinity`.

Expected Behavior:
The selection defaults to a `downstream` affinity.

Expected|Actual
---|---
<video src="https://user-images.githubusercontent.com/948037/215957886-fbafa1e7-8b3a-4df4-8403-f88dc84e372d.mov" />|<video src="https://user-images.githubusercontent.com/948037/215958318-7da3618b-2362-4791-97f9-7c3c19e97b33.mov" />
Repository: vscode
Issue: GitHub - Add support for `.issuetracker` file in Source Control feature
Labels: feature-request,github

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

### Overview

It would be good to have support for a way for the commit list to show links to mentioned issues in issue trackers such as GitLab, Jira or GitHub.

A nice way to solve this is with the `.issuetracker` convention used in other projects (see links below).

### Details

A lot of git GUIs and online tools have ways to automatically show issue references as a link in their UI (e.g. `#123` on GitHub will convert to a link to the relevant issue), however to add this support per repo requires complex integrations for each potential issue Tracker.

However, really this is a matter of a convention of writing issue references `ABC-123` or `~456` and then mapping that to a base URL.

### Example syntax

```
# Integration with Issue Tracker
#
# (note that '\' need to be escaped).

[issuetracker "Some label"]
  regex = "ABCD-(\\d+)"
  url = "https://my-company.atlassian.net/browse/ABCD-$1"
```

```
# Integration with Issue Tracker
#
# (note that '\' need to be escaped).

[issuetracker "vscode"]
  regex = "#(\\d+)"
  url = "https://github.com/microsoft/vscode/issues/$1"
```

## Links

* https://code.visualstudio.com/docs/sourcecontrol/overview - docs for source control
* https://developercommunity.visualstudio.com/t/add-issuetracker-file-support/1039014 - request to add this to Visual Studio
* https://github.com/fork-dev/TrackerWin/issues/265 & https://github.com/fork-dev/Tracker/issues/278 - original issue / notes for implementation into Git Fork
* https://tortoisegit.org/docs/tortoisegit/tgit-dug-bugtracker.html - solid reference for how to abstract the knowledge of IDs and base URLs
* https://desktop.github.com/ - because of its integration with the matched GitHub repo - will automatically include links to issues (see screenshots)
* https://docs.syntevo.com/SmartGit/Latest/Bugtraq-links-to-issue-trackers-.html - Syntevo implementation of the same feature, the inspiration for the generic syntax used by git fork
* https://github.com/mstrap/bugtraq - specification for the bugtraq used by Syntevo
Repository: material-ui
Issue: [Tooltip display bug] Tooltip will close if the tooltip height dynamically expand and exceeds the viewport
Labels: component: tooltip,status: expected behavior

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example:
https://codesandbox.io/s/frosty-wave-8r1mqt?file=/demo.tsx
Steps:
1 open the sandbox link, and maximum your browser
2. hover on "TOOLTIP",  then tooltip appears
<img width="570" alt="image" src="https://user-images.githubusercontent.com/31032742/215990139-f1728830-9fea-43c2-af8d-5015f56d7229.png">
3. click the button, the tooltip height will expand, then the tooltip blink on the top of "TOOLTIP" and closed



### Current behavior 😯

click the button, the tooltip height will expand, then the tooltip blink on the top of "TOOLTIP" and closed

### Expected behavior 🤔

first of all, it's reasonable that the tooltip should be showed on the top of element since its' height exceeds the viewport, however, it should be visible consistently rather than blink and closed unexpectedly

### Context 🔦

In my project, my tooltip will show general message and detail message, the detail message is hidden by default, and will show when user click the button.
And I find this issue in the case of if tooltip is show near the viewport of browser.

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
```
</details>