sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: [RFC] Activation Checkpoint API improvements
Labels: oncall: distributed,module: checkpoint,module: ddp,Stale,module: fsdp

with @zhaojuanmao 

Activation checkpointing is an important technique to trade off compute for more GPU memory, thereby enabling larger batch sizes or the training of larger models.

It is especially relevant in the case of large model training with `FullyShardedDataParallel`, where the goal is to train models that are much bigger than what can fit in a single GPU by using a variety of techniques: sharding, activation offloading, parameter and gradient offloading. 

As a result, we would like to add the following APIs to `torch.utils.checkpoint`:

1. A `checkpoint_wrapper` function that wraps an `nn.Module` instance so that it is always run with checkpointing. This is helpful so that the user will not have to call `checkpoint` everytime the model's forward pass is run in code. It also allows for better composition with FSDP and DDP, i.e. the user can choose whether to do `FSDP(checkpoint_wrapper(model))` or `checkpoint_wrapper(FSDP(model))`, which, depending on model and other training conditions can have different performance implications. A prototype of `checkpoint_wrapper` has been added with this PR: https://github.com/pytorch/pytorch/pull/69955, and we would like to upstream this to `torch.utils.checkpoint`. The implementation is derived from [fairscale's checkpoint_wrapper](https://github.com/facebookresearch/fairscale/blob/main/fairscale/nn/checkpoint/checkpoint_utils.py).

2. Support for _activation offloading_. To understand this, assume that we have the following model structure: `nn.Sequential(checkpoint_wrapper(l1), checkpoint_wrapper(l2), ..., checkpoint_wrapper(ln))`. In this case, _inner_ activations are within each checkpointed layer and memory is saved by discarding and recomputing them. Although there are still so-called _outer_ activations between the layers that need to be saved on GPU for recomputation. _activation offloading_ refers to the idea of offloading these activations to CPU to additionally save on GPU memory. It is especially helpful when outer activations are very large. A prototype for activation offloading is here: https://github.com/pytorch/pytorch/pull/70024. The implementation is derived from [fairscale's checkpoint_wrapper](https://github.com/facebookresearch/fairscale/blob/main/fairscale/nn/checkpoint/checkpoint_utils.py)

In addition, there are 2 checkpoint-based implementations, the traditional reentrant-backwards passed one and the recently added (https://github.com/pytorch/pytorch/pull/69508) checkpoint based on saved tensor hooks. We would like to support both APIs for the time being, because reentrant-based checkpoint is still the default offering and used by FSDP, DDP as well, although we will migrate to saved tensor hooks based checkpointing in the future.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: vscode
Issue: Emmet: update tag
Labels: feature-request,emmet

Issue Type: <b>Bug</b>

The command `editor.emmet.action.updateTag` is not working correctly.
e.x.: `#test` called on `<div></div>` returns `<#test></#test>` instead of `<div id="test"></div>`.

VS Code version: Code 1.63.2 (899d46d82c4c95423fb7e10e68eba52050e30ba3, 2021-12-15T09:40:02.816Z)
OS version: Windows_NT x64 10.0.19042
Restricted Mode: No

<details><summary>Extensions (11)</summary>

Extension|Author (truncated)|Version
---|---|---
increment-selection|alb|0.2.0
ecsstractor-port|diz|0.0.3
google-fonts|lio|0.0.1
vscode-scss|mrm|0.10.0
vscode-language-pack-ru|MS-|1.62.3
material-icon-theme|PKi|4.9.0
vscode-css-navigation|puc|1.10.7
live-sass|rit|3.0.0
LiveServer|rit|5.6.1
vscode-scss-formatter|sib|2.3.2
transpose|v4r|0.0.5

(1 theme extensions excluded)

</details>
<!-- generated by issue reporter -->
Repository: node
Issue: Move debug testing over to ARM from X86
Labels: test,arm

The Red Hat team spent the day looking at how we could move the CI closer to green. One of the top issue causing failures reported in the reliability reports are the debug builds running out of memory (21 failures in last report). - See https://github.com/nodejs/reliability/issues/146 as an example.

The container machine for x86 where this test runs already has 32G of memory but debug builds take a lot of memory and we have a number of containers that can all be running on that machine. 

Our new arm machines form equinix metal have 512G memory which should be more than enough. We only have debug coverage on 1 platform/os so thinking an option might be to be to move our debug builds over to ARM. It looks like we have a similar number of container based agents running on the host, the main difference being that there should be a lot more memory.

I created a temporary job to see how the debug build runs on ARM. There are 2 consistent failures:

https://github.com/nodejs/node/issues/41204
https://github.com/nodejs/node/issues/41208

I'm still thinking it would be worth marking the 2 tests ask flaky (1 for main, 17.x,16,x and the other for 14.x) and move over the debug builds to see if that helps us get closer to green.

Any concerns with that approach ?

@nodejs/build, @Trott
Repository: godot
Issue: [3.4] [HTML5] WorldEnvironment node, Background = Canvas gives black screen on iOS / iPadOS 15
Labels: bug,platform:web,platform:ios,topic:rendering,needs testing

### Godot version

3.4

### System information

macOS, GLES3

### Issue description

Using GLES3 and the HTML5 export on iOS / iPadOS 15, when using the WorldEnvironment node, if you select "Canvas" in the Background property, the Scene becomes black, making it impossible to do anything.
<img width="578" alt="WorldEnvironmentNode-Background-Canvas" src="https://user-images.githubusercontent.com/890553/146450684-c3560159-26c9-4ba5-9593-fac4a2f2ccf3.png">



### Steps to reproduce

1. Create a new project
2. Create some dummy nodes (i.e. ColorRect) which are visible on the Scene.
3. Create a WorldEnvironment node
4. In the WorldEnvironment node, deploy the Background parameter
5. In the Background parameter / Mode setting, select "Canvas"
6. Export your project to HTML5.
7. Run the HTML5 inside any browser on Desktop.
8. Notice everything looks fine.
9. Run the HTML5 inside any browser on iOS / iPadOS 15
10. Notice the screen is completely black.

### Minimal reproduction project

[Godot Glow Test.zip](https://github.com/godotengine/godot/files/7730525/Godot.Glow.Test.zip)
Repository: rust
Issue: Consider removing --max-memory linker flag for WebAssembly.
Labels: A-linkage,C-enhancement,O-wasm

The relevant line: https://github.com/rust-lang/rust/blob/38030ffb4e735b26260848b744c0910a5641e1db/compiler/rustc_codegen_ssa/src/back/linker.rs#L1044

Presently `--max-memory` defaults to limiting memory imports to 1GB in size. If that flag were not set the default behavior (as documented here: https://lld.llvm.org/WebAssembly.html) is an unlimited maximum.

It's not immediately obvious to me what problem setting that flag prevents, however it's easy to get confused by this limit when trying to use Rust with memory imports larger than 1GB.

Could the flag just be removed?

@alexcrichton as you were the one who added the relevant code.
Repository: flutter
Issue: Flutter tool should ensure all SDK files are present when running from pre-built SDK package
Labels: c: new feature,tool,P3,team-tool,triaged-tool

One way to solve this problem would be, during the SDK packaging CI build right before compressing/zipping the Flutter SDK directory, create a manifest text file listing all the contents and the cloud path where the archive will be uploaded and include it (gitignored) in the directory that gets compressed. Then, in the tool, when running *for the first time*, check if the manifest file exists; if it does, validate that all the expected files are present locally; if any are not, fail and give the link to the archive on cloud storage.

This would preclude the tool from running into issues like: https://github.com/flutter/flutter/issues/80418
Repository: pytorch
Issue: Feature request: [STFT] Add warning message if signal length is not a multiple of hop_length in torch.stft
Labels: feature,triaged,module: complex,module: fft

Some users reported that the output signal is shorter than the original one after ``torch.stft`` and ``torch.istft``.

Though the issue can be mitigated by defining the ``length`` argument in ``torch.istft``, which pads zero tensors after the inverted signal. The true reason is that the tail samples are discarded in ``torch.stft``, if the signal length is not a multiple of ``hop_length``.

We can add a warning message in ``torch.stft`` which warns users if the input length is not a multiple of ``hop_length`` and suggests users to do zero-padding before ``torch.stft`` in order to make full use of the input signal.

cc @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @nikitaved @peterbell10 @cpuhrsch @mthrok
Repository: godot
Issue: Creating Detail Albedo texture in GDScript causes infinite textures being created.
Labels: bug,topic:3d

### Godot version

v3.4-stable

### System information

Manjaro Linux, GLES3, NVIDIA Geforce GTX 1060 495.44

### Issue description

In my script I create a detail texture in the ``_ready`` function for bullet holes. It works flawlessly but I noticed the object id of the image object increase steadily. So this might be a memory leak, or needless swapping of textures in the engine.  
![Peek 2021-12-17 00-33](https://user-images.githubusercontent.com/14081613/146464404-3fd932c6-c8ec-4e34-b3b1-27a9972ff3e6.gif)



### Steps to reproduce

1. Open reproduction project.
2. Run project.
3. Click on the object in Material slot 0.
4. Click the object in ``Detail Albedo``.
5. See the object id of the ``Image`` increase.

### Minimal reproduction project

[BugReport.zip](https://github.com/godotengine/godot/files/7731029/BugReport.zip)
Repository: neovim
Issue: Misreported v:t_ variables for type() documentation
Labels: bug,vimscript,has:vim-patch

### Neovim version (nvim -v)

v0.6.0

### Vim (not Nvim) behaves the same?

No, Vim does not have this issue.

### Operating system/version

Kubuntu 21.10

### Terminal name/version

Konsole 21.08.1

### $TERM environment variable

xterm-256color

### Installation

appimage

### How to reproduce the issue

```vim
:help type()
```

### Expected behavior

The documentation says "Instead of using the number directly, it is better to use the `v:t_` variable that has the value".

For most of the numbers, the corresponding `v:t_` variable is reported in parentheses.

I expected this to be the case for Boolean and Null as well.


### Actual behavior

For Boolean and Null, values of the type are reported, as opposed to the `v:t_` variables.

For Boolean, the parentheses should have `v:t_bool`.

For Null, the parentheses should seemingly have `v:t_null`, but that does not exist. The documentation that follows says that "In place of checking for `v:null` type it is better to check for `v:null` directly as it is the only value of this type".

Vim's documentation shows `v:t_` variables for these types, followed by the values for these types.

```
Boolean:    6  v:t_bool (v:false and v:true)
None:       7  v:t_none (v:null and v:none)
```
Repository: node
Issue: AsyncLocalStorage behaviour change breaking test suite
Labels: async_hooks

### Version

v16.7.0

### Platform

Darwin au-fvfwj01dhv2g 20.6.0 Darwin Kernel Version 20.6.0: Tue Oct 12 18:33:42 PDT 2021; root:xnu-7195.141.8~1/RELEASE_X86_64 x86_64

### Subsystem

_No response_

### What steps will reproduce the bug?

We use AsyncLocalStorage and have a large suite of end-to-end tests. Our app currently uses v14 but now that v16 has gone LTS we are preparing to upgrade. When we started testing node v16 we noticed all our e2e tests were failing. It turned out this was because we initialise AsyncLocalStorage in our e2e tests and depend on it persisting to the processing of the request.

By testing different versions of node I found the behaviour changed in v16.7.0 and persists through v16.13.1. Versions from v14 through to v16.6.2 and v17+ all 'work' as far as our e2e tests are concerned.

I have distilled this down to a simple repo - git@github.com:horrendo/als-test.git.

### How often does it reproduce? Is there a required condition?

Using the tests in the above repo shows the issue we're having 100% of the time.

### What is the expected behavior?

The supplied test passes.

### What do you see instead?

The supplied tests fails with v16.7.0 through v16.13.1.

### Additional information

_No response_
Repository: vscode
Issue: Long text always wrap
Labels: bug,editor-wrapping

版本: 1.63.2 (system setup)
提交: 899d46d82c4c95423fb7e10e68eba52050e30ba3
日期: 2021-12-15T09:40:02.816Z
Electron: 13.5.2
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 6.1.7601
---
It is not respect the `Word Wrap` setting.
[LongTextSample.zip](https://github.com/microsoft/vscode/files/7731293/LongTextSample.zip)
Repository: vscode
Issue: User customizable ambiguous characters for Unicode Highlight
Labels: feature-request,unicode-highlight

<!-- ⚠️⚠️ 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. -->
I would like to set my own customized list of additional abmiguous unicode characters to be highlighted.

As a person writing CJK characters daily, I have been using Highlight Bad Chars extension to avoid the annoyance that arises from the ambiguity of unicode glyphs. I'm very happy to see the latest vscode comes with a similar feature integrated, but I feel sorry to find that the list of ambiguous characters are not customizable. 
There are lots of candidates of possibly confusing sets of characters, so it would be better to ask the users to define the list of characters at their disposal.
Repository: create-react-app
Issue: HTML webpack plugin error
Labels: issue: install problem,needs triage

After creating react app and when I am typing "npm start" inside the application and web browser is is opening with an error "HTML Webpack plugin".


<img width="960" alt="react2" src="https://user-images.githubusercontent.com/94891246/146494578-aff4a0fc-e6b7-4702-8c0d-d5006100462e.png">
<img width="960" alt="react1" src="https://user-images.githubusercontent.com/94891246/146494588-c5452527-12b8-4874-ba23-1638156e0b2c.png">
<img width="960" alt="react" src="https://user-images.githubusercontent.com/94891246/146494592-1b31d29b-378d-43a1-98a0-78e4733c7be6.png">
Repository: terminal
Issue: [Settings>Startup] : Screen Reader is taking 4 down arrow key strokes to read full 'Default terminal application' combo-box information in scan mode.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,Priority-3,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11yCO,A11ySev3

### Windows Terminal version

1.12.3472.0

### Windows build number

22509.1011

### Other Software

**Test Environment: **
OS: Windows 11 Version Dev (OS Build 22509.1011)
App: Windows Terminal Preview
Screen Reader: Narrator

### Steps to reproduce

**Repro Steps:** 

1.Open Windows Terminal.
2.Open the 'Settings' tab using 'Ctrl + ,'
3.Navigate to 'Startup' tab-item & press enter.
4.Turn on the narrator using 'Ctrl + Windows + Enter' keys & Toggle to scan mode using 'Caps lock + Space bar'.
5.Now navigate to 'Default terminal application' combo box via down arrow key & observe the issue.

**User Experience**
Users who rely on screen reader will get impacted here & gets irritated, if Narrator takes 4 down arrow key strokes in order to read complete 'Default terminal application' combo box in scan mode.

**Guideline reference**
https://www.w3.org/TR/WCAG21/#meaningful-sequence

**Attachment :** 
[Screen Reader is taking 4 down arrow key strokes to read full 'Default terminal application' combo-box information in scan mode..zip](https://github.com/microsoft/terminal/files/7732316/Screen.Reader.is.taking.4.down.arrow.key.strokes.to.read.full.Default.terminal.application.combo-box.information.in.scan.mode.zip)


### Expected Behavior

Narrator focus should move on to 'Default terminal application' combo box by pressing only 'one down arrow' key & narrate should read complete information of the combo box at once.

### Actual Behavior

Screen Reader is taking 4 down arrow key strokes to read full 'Default terminal application' combo-box information in scan mode.
**For ex :** If 'windows console host' is selected.
-->In first arrow key stroke- narrator is reading as 'Default terminal application combo box collapsed followed by help text'.
-->In second arrow key stroke-Narrator is reading as '1 of 3' selected.
-->In Third arrow key stroke- Narrator is reading as 'Windows console host'.
-->In Fourth arrow key stroke-Narrator is reading as 'Microsoft corporation'.

Note : 
1.Similar issue repro for 'Default profile' combo box present in 'Startup tab' & 'Language' combo box present in 'Appearance' tab- as screen reader is taking two key strokes to get complete information of combo box.
Repository: kubernetes
Issue: Various bugs in APF configuration producing controller
Labels: kind/bug,sig/api-machinery,lifecycle/frozen,triage/accepted

### What happened?

While reviewing #105800 I noticed some things.

1. The annotation key `apf.kubernetes.io/autoupdate-spec` is not mentioned anywhere in the user-facing documentation (https://kubernetes.io/docs/concepts/cluster-administration/flow-control/) --- but it should be.

2. https://github.com/kubernetes/kubernetes/blob/712745cb6755b3a28ca12292b30d138d5f737aa6/pkg/registry/flowcontrol/ensurer/strategy.go still references v1beta1 even though we now have v1beta2.

3. https://github.com/kubernetes/kubernetes/blob/712745cb6755b3a28ca12292b30d138d5f737aa6/pkg/registry/flowcontrol/ensurer/strategy.go#L311-L314 ignores the value of the annotation --- which is wrong.

### What did you expect to happen?

Perfection

### How can we reproduce it (as minimally and precisely as possible)?

Should be clear from the above.

### Anything else we need to know?

_No response_

### Kubernetes version

<details>
current `master` branch
</details>


### Cloud provider

<details>
N/A
</details>


### OS version

<details>
N/A
</details>


### Install tools

<details>
N/A
</details>


### Container runtime (CRI) and and version (if applicable)

<details>
N/A
</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>
N/A
</details>
Repository: pytorch
Issue: Add support for a `default` arg in `ModuleDict.pop`
Labels: feature,module: nn,triaged,Stale

### 🚀 The feature, motivation, and pitch

Given that `ModuleDict` is a dictionary that holds modules, it should implement its API. A user should manipulate it as a `dict`, not having to think which operations are actually implemented and which don't (it's like re-inventing the wheel in a way).

Methods not implemented, that I have identified (see [`dict` reference](https://docs.python.org/3/library/stdtypes.html#dict)):

* [x] `copy()`
* [x] `get(key[, default])`
* [x] `popitem()`
* [x] `reversed(d)`
* [x] `setdefault(key[, default])`
* [x] `d | other`
* [x] `d |= other`
* [ ] `pop` doesn't support a default.

Maybe the simpler way to do it is by inheriting from `dict`? Not sure about the consequences of multiple inheritances here.

### Alternatives

One alternative is to do nothing at all. However, the user needs to know which methods are implemented and how, instead of relying on their knowledge on how a dictionary usually works.

Can't come up with others.

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345
Repository: terminal
Issue: [Settings>Action] : Narrator focus is moving on to 'Shortcuts' present in 'actions' tab un-necessarily in scan mode.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,Priority-3,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11yCO,A11ySev3

### Windows Terminal version

1.12.3472.0

### Windows build number

22509.1011

### Other Software

**Test Environment: **
OS: Windows 11 Version Dev (OS Build 22509.1011)
App: Windows Terminal Preview
Screen Reader: Narrator

### Steps to reproduce

**Repro Steps: **

1.Open Windows Terminal.
2.Open 'Settings' tab using 'Ctrl + ,'
3.Navigate to 'Actions' tab via down arrow key & press enter.
4.Turn on the narrator using 'Ctrl + Windows + Enter' & toggle to scan mode using 'Caps lock + Space bar'.
5.Navigate in the actions present in right pane using 'Up/down' arrow key.
6.Observe the issue.

**User Experience**
Users who rely on screen reader will get impacted here & may gets irritated, if narrator focus moves on to 'Shortcuts' present in 'actions' tab un-necessarily in scan mode.

**Guideline Experience**
https://www.w3.org/TR/WCAG21/#meaningful-sequence

**Attachment :** 
[Narrator focus is moving on to 'Shortcuts' present in 'actions' tab un-necessarily in scan mode..zip](https://github.com/microsoft/terminal/files/7733381/Narrator.focus.is.moving.on.to.Shortcuts.present.in.actions.tab.un-necessarily.in.scan.mode.zip)







### Expected Behavior

As Narrator is reading the 'shortcut' information along with the 'Action' name, there is no need of moving Narrator focus to 'Shortcuts' present in 'actions' tab separately in scan mode.

### Actual Behavior

On Navigating using down arrow key, focus is moving on to entire action & shortcut, Narrator is reading the entire information of action & shortcut. But, on pressing down arrow key further - focus is moving on to 'Shortcut' again.
Repository: terminal
Issue: [Command Prompt] : User is not able to Select commands using 'Shift+ right/Left arrow keys' inside Command Prompt.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,HCL-E+D,A11yUsable,HCL-WindowsTerminal,A11yCO

### Windows Terminal version

1.12.3472.0

### Windows build number

22509.1011

### Other Software

**Test Environment: **
OS: Windows 11 Version Dev (OS Build 22509.1011)
App: Windows Terminal Preview
Screen Reader: Narrator

### Steps to reproduce

**Repro Steps:** 

1.Open Windows Terminal.
2.Open 'Command prompt' using 'Ctrl + Shift + 2' keys.
3.Now type any text in text-area of 'Command prompt'.
4.Now try to select the command text using 'Shift + right/left arrow'.
5.Observe the issue.

**Users Experience**
Users who rely on keyboard will get impacted here & fail to use the 'Command prompt' effectively, if User is not able to Select commands using 'Shift+ right/Left arrow keys' inside Command Prompt.

**Attachment :** 

[User is not able to Select commands using 'Shift+ right or Left arrow keys' inside Command Prompt..zip](https://github.com/microsoft/terminal/files/7733539/User.is.not.able.to.Select.commands.using.Shift%2B.rightLeft.arrow.keys.inside.Command.Prompt.zip)


### Expected Behavior

User should be able to Select commands using 'Shift+ right/Left arrow keys' inside Command Prompt, which is happening in 'Windows Power shell' tab.

### Actual Behavior

User is not able to Select commands using 'Shift+ right/Left arrow keys' inside Command Prompt.
Repository: pytorch
Issue: Question:  what is "Parameter indices"?
Labels: oncall: distributed,Stale

I meet the error. I know some variables which do not contribute to loss. How I can know these parameters' name?  I don't know whether "Parameter indices" help me or not?

> Parameter indices which did not receive grad for rank 7: 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @mruberry @jbschlosser @walterddr @kshitij12345