sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: deno
Issue: 🙏🏻 [feat/req] suppress annoying "Terminate batch job (Y/N)?" for shimmed deno scripts (Windows)
Labels: feat

At least up to Deno 1.8.1, any shimmed Deno script under Windows will prompt with "Terminate batch job (Y/N)?" when terminated with a `CTRL-C` interrupt. I suggest that `deno install ...` create a BAT/CMD file with the construction `@goto #_undefined_# 2>NUL || @title %COMSPEC% & @deno ...`. This exploits a known CMD quirk:

> GOTO undefined label is a fatal error. It immediately terminates batch processing, but the currently executing block of code that has already been parsed continues to completion. However, the remainder of the code is executed using a command line context instead of a batch context.
> - dbenham (commenting on this [StackOverflow answer](http://stackoverflow.com/questions/23327304/my-goto-redirect-is-not-working-but-works-with-echo/23327977#23327977))

`@goto #_undefined_# 2>NUL` terminates the BAT/CMD script but only *after executing* the rest of the currently parsed code block. This executes the `@deno ...` portion in command line context (instead of batch context), so that there is no batch script to terminate. And so, the "Terminate batch job (Y/N)?" prompt is avoided.

Notably, this construction also protects against a possible future problem related to a CMD shell bug. Exiting a batch script via fall-thru, `exit ERROLEVEL`, or `exit /B ERRORLEVEL` does NOT return ERRORLEVEL as the process exit code unless the BAT/CMD file is executed with a `call BAT_FILE` command. The ERRORLEVEL *is* set and returned to the parent shell correctly, but the process exit code *is not*. There's more detail, some references, and an alternate solution in my [commit for `pl2bat`](https://github.com/Perl-Toolchain-Gang/extutils-pl2bat/commit/9a7db96696ce52292cf5d3d6aa6c8dcd1a9a8744), which is a similar command wrapper for `perl`.

It's a "possible future problem" because the current shim takes advantage of another countervailing CMD quirk which *does* pass the ERRORLEVEL out as the process exit code if and only if the command executing the target executable is the last command in the last parsable unit of the BAT/CMD file. If the shim is ever changed to have another code parse unit after the `@deno ...` execution line, then the process exit code will not be set correctly unless the shim is called using `call SHIM_NAME`, which cannot be expected.

The `title %COMSPEC%` command is included in order to work-around the fact that using this prevents the caller from resetting the window title to a prior value which can lead to ever-expanding window titles. I think it's a minor inconvenience for the benefits gained: both the suppression of "Terminate..." and correct process exit values, no matter how the script is called.

`yarn` has [adopted this construction](https://github.com/yarnpkg/berry/pull/1939).

[1] [MSFT terminal ~ Disable "Terminate batch job (Y/N)?" discussion](https://github.com/microsoft/terminal/issues/217#issuecomment-737594785)
Repository: deno
Issue: 🙏🏻 [feat/req] supply $0/%0 to shimmed scripts (cross-platform)
Labels: feat

It's helpful to supply users with exact, functional command line constructions when giving feedback (via error message suggestions, `--help` or `--usage`) about correct execution of a utility. Unfortunately, the initiating command ($0 or %0 for windows) is lost in the current shimming process, so the called script doesn't known the command that actually initiated it. The shims can be hacked to provide this information via environment variables or a command line option, but it would be better to have a formalized supplier for that information.
Repository: flutter
Issue: Improve handling of Kotlin versioning
Labels: platform-android,tool,c: proposal,P3,team-android,triaged-android

(See https://github.com/flutter/flutter/issues/78792 for background, with https://github.com/luanpotter/audioplayers/issues/714#issuecomment-784407448 as an example of the pain point)

Our create template is apparently using a fairly old version of Kotlin, and it appears that there are issues if plugin developers attempt to use a newer version. Some things we should consider:
- Updating the templates to a newer version (only fixes new apps)
- Warning (or migrating, if that's backwards compatible; I'm not familiar with the specifics of Kotlin versioning behaviors) for apps with old Kotlin versions.

However, we'll still have this a general problem going forward, so we should figure out how we're going to handle that. /cc @blasten as https://github.com/flutter/flutter/pull/59037#discussion_r437132959 sounds like a potential solution here. If each plugin can choose its version of Kotlin without conflicting with other plugins and/or the app, that would be ideal. Failing that we'll likely need an ongoing communication and migration strategy so that plugin developers a) know what version is safe to use, and b) can regularly get that version moved forward if possible.
Repository: vscode
Issue: [folding] Hover over the folding indicator to mention Alt and Shift 
Labels: feature-request,editor-folding

From https://github.com/microsoft/vscode/issues/97684#issuecomment-804988160_

A hover over the folding indicator could mention the various keyboard modifiers
Repository: nvm
Issue: How to completely uninstall
Labels: needs followup

Doing whats listed in the readme doesn't actually do it
Repository: excalidraw
Issue: Don't show a selected item as a pending item in library when its already added
Labels: enhancement,discussion

![Excalidraw (3)](https://user-images.githubusercontent.com/11256141/112172851-10469980-8c1b-11eb-95fd-c44ecd3d2147.gif)

Steps to reproduce
1. Create a shape
2. Add to library
3. Issue replicated

If an item is already added to the library and the same item is selected we shouldn't show it as a pending item (the 2nd item in the GIF above)
Repository: rust
Issue: Misleading error message with negative range
Labels: C-enhancement,A-diagnostics,T-compiler,A-inference,A-suggestion-diagnostics,D-confusing,D-newcomer-roadblock,D-terse

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur. 
-->

Given the following code: [Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=046e611931de232ad60923dac82f78b0)

```rust
fn main() {
  for x in -5..5 {
      do_something(x);
  }    
}

fn do_something(val: usize) {}
```

The current output is:

```
error[E0277]: the trait bound `usize: Neg` is not satisfied
 --> src/main.rs:2:12
  |
2 |   for x in -5..5 {
  |            ^^ the trait `Neg` is not implemented for `usize`

error: aborting due to previous error
```


This created confusion for a new Rust user on our team.

Ideally the range type would be inferred to be `i32`:

```
error[E0308]: mismatched types
 --> src/main.rs:3:20
  |
3 |       do_something(x);
  |                    ^ expected `usize`, found `i32`
  |
help: you can convert an `i32` to a `usize` and panic if the converted value doesn't fit
  |
3 |       do_something(x.try_into().unwrap());
  |                    ^^^^^^^^^^^^^^^^^^^^^
```

_Alternatively_ the output could mention why the type was inferred to be usize:

```
  |
2 |   for x in -5..5 {
  |            ^^ the trait `Neg` is not implemented for `usize`
  |
help: type `usize` was inferred due to call on line 3
  |
3 |      do_something(x);
  |                   ^
```

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions. The output might also be
different depending on the Edition.
-->
Repository: pytorch
Issue: Store created by dist.new_group doesn't appear to respect timeout
Labels: high priority,triage review,oncall: distributed,triaged,better-engineering

## 🐛 Bug

If default pg exists and user calls `dist.new_group` to create a new group, the corresponding prefix store created will have the default pg timeout as opposed to the timeout passed into `new_group`. It should probably have the timeout passed into `new_group` however.

This can result in issues if, say, we call `wait()` on a collective comm. issued by the new pg, and ProcessGroupNCCL calls into the store to broadcast unique nccl IDs, resulting in the wrong timeout being used. To reproduce, call `dist.new_group` with a small timeout, issue a collective comm. call that hangs, and log the timeout in FileStore.cpp (or whichever store implementation was used). 


Fix can probably be to set the right timeout here - https://github.com/pytorch/pytorch/blob/master/torch/distributed/distributed_c10d.py#L605


cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @agolynski @mrzzd @cbalioglu
Repository: rust
Issue: if let scoping of lifetime creates compiler warning
Labels: A-lints,T-lang,C-discussion,L-irrefutable_let_patterns

```rust
    use glium::Display;
    let display = Display::new(builder, context, &event_loop).unwrap();
    if let gl_window = display.gl_window() {
        let window = gl_window.window();
        platform.attach_window(&mut gui_display, window, HiDpiMode::Default);
    }
    return display;
```

The current output is:

```
warning: irrefutable `if let` pattern
   --> imgui-example\src\main.rs:153:5
    |
153 | /     if let gl_window = display.gl_window() {
154 | |         let window = gl_window.window();
155 | |         platform.attach_window(&mut gui_display, window, HiDpiMode::Default);
156 | |     }
    | |_____^
    |
    = note: `#[warn(irrefutable_let_patterns)]` on by default
    = note: this pattern will always match, so the `if let` is useless
    = help: consider replacing the `if let` with a `let`
```

Following the suggestion breaks the code, because lifetime in `gl_window` could be used in `Drop` of `gl_window` while display is still being used.

I am not even sure if this can be reasonably implemented, so it is more of an question/sugestion what you think about scoping with `if let` over manual call `Drop`, or wrapping with block like this:
```rust
    use glium::Display;
    let display = Display::new(builder, context, &event_loop).unwrap();
    {
        let gl_window = display.gl_window();
        let window = gl_window.window();
        platform.attach_window(&mut gui_display, window, HiDpiMode::Default);
    }
    return display;
```
n my **opinion** `if let` scoping is the shortest, and best explains the scope, without looking like too artificial scope.
Repository: PowerToys
Issue: [FZ] Change layouts on connected monitor change
Labels: Idea-Enhancement,FancyZones-Layouts,Product-FancyZones

When undocking a laptop, the zone will be changed because the windows will fit into one screen automatically.  Possible to implement a feature to save zones on different screen setup? Then use a shortcut key to switch?
Repository: flutter
Issue: Widget for Performant Rendering of Static Pictures
Labels: c: new feature,framework,c: performance,P3,team-framework,triaged-framework

An oft-made suggestion to quickly improve per frame rendering performance of widgets that specify their contents using complex pictures is to first render them to a texture and use that texture as the contents instead. A widget that makes this recommendation easy to adopt is desirable.

In Flutter, pictures usually become complex to render per frame when they involve a lot of render target switches, have too many draw calls, require complex fragment shaders, or necessitate operations like render buffer readbacks. On the other hand, once an image has been created, it requires no such operations to render.

Such complex pictures can be constructed in code but are usually generated from SVGs or from intermediate assets from tools (like After Effects) that assume a post production step.

The inclusion of many such pictures in a scene is detrimental to per frame performance. A widget very similar to the Image widget that takes a picture and converts it to an image before rendering that same image each frame in place of the picture works around these performance issues. This will not work for cases where each picture is one frame in an animation. This widget will also not be resilient to large changes in scale of the displayed picture. But, for performant rendering of static complex pictures at a specific resolution, such a widget would be a great fit and formalize the performance guidance given to numerous users already.
Repository: TypeScript
Issue: Transpilation of iterable spread is incorrect for non-iterable values.
Labels: Needs Investigation

# Bug Report

### 🔎 Search Terms

transpilation __spreadArray spread iterable

### 🕗 Version & Regression Information

- This changed between versions 4.1 and 4.2, but was broken in a different way in 4.1

### ⏯ Playground Link

https://www.typescriptlang.org/play?target=1&ts=4.2.3#code/MYewdgziA2CmB00QHMAUBteWCMBdAlANxA

### 💻 Code

```
console.log([...1]);
```

### 🙁 Actual behavior

print `[]`

### 🙂 Expected behavior

Throw a runtime exception. 1 is not an iterable.
Repository: angular
Issue: Select dropdowns with ngValue binding perform far worse than expected
Labels: area: performance,area: forms,state: confirmed,P4

# 🐞 bug report

### Affected Package
The issue is caused by package @angular/forms

### Is this a regression?

Regression from AngularJS.

### Description

I noticed that there was a noticeable delay when populating a select dropdown with several hundred+ items using an ngValue binding, which does not occur with other frameworks (I also tested AngularJS and Svelte). Digging into the Angular code it turns out that the `_compareWith` function in select_control_value_accessor.ts is being called an absurdly high number of times.

I expected that this function would just be called no more than once for each item in the dropdown (i.e. loop through the options until a match is found). However, it is actually called exponentially more. E.g. for a dropdown with 1000 items and the 500th item bound to the ngModel, the function is called 501,001 times. If there are 3000 items in the dropdown and the 1500th item is selected, the `_compareWith` function is called 1,002,501 times. It gets even worse if an option nearer the end of the list is selected.

## 🔬 Minimal Reproduction
https://stackblitz.com/edit/angular-select-performance?file=src%2Fapp%2Fapp.component.ts

Note that I added a custom `compareWith` method in this example to log how many times it is called, but the performance is just as bad with the default internal comparison method.

I think the problem stems from Angular's `SelectControlValueAccessor.writeValue()` method being called over and over for each individual option element that is rendered, rather than once after all the options are rendered.

## 🌍  Your Environment

**Angular Version:** 11.2.6

**Anything else relevant?**
This is especially problematic for our users with slower mobile devices.
Repository: storybook
Issue: Addon-backgrounds MDX support
Labels: bug,has workaround,addon: backgrounds,addon: docs,mdx

Hi @yannbf  ,

Your PR fixes the problem for DocsPage generated documentation, but not for manually written MDX stories in the style described [here](https://github.com/storybookjs/storybook/tree/next/addons/docs#mdx).

The code in the PR tries to set styles on the CSS selector  [here](https://github.com/storybookjs/storybook/blob/next/addons/backgrounds/src/decorators/withBackground.ts#L28-L56)

This works for DocsPage since it [generates Anchor components for every story](https://github.com/storybookjs/storybook/blob/next/addons/docs/src/blocks/DocsStory.tsx#L37-L47).
However this pattern is not documented in the MDX guide above, and actually seems to conflict with the behaviour of the Meta tag [here](https://github.com/storybookjs/storybook/blob/master/addons/docs/src/blocks/Meta.tsx#L29), which generates a single Anchor component at the top of the page for the first Story encountered (which is a bit strange tbh).

Would it be possible to make the background selection work on any story regardless of whether they are contained in an anchor?

_Originally posted by @angryzor in https://github.com/storybookjs/storybook/issues/7978#issuecomment-726797915_
Repository: flutter
Issue: [web] content-specific browser context menus
Labels: c: new feature,platform-web,c: proposal,P3,team-web,triaged-web

browsers often offer cotnent-specific context menus

examples that came into my head:


- [ ] <details><summary>image</summary>
![image](https://user-images.githubusercontent.com/39104740/112218984-79d3a180-8c35-11eb-8874-3e35b8a806a5.png)
</details>

- [ ] <details><summary>canvas</summary>
![image](https://user-images.githubusercontent.com/39104740/112218962-6fb1a300-8c35-11eb-92c0-79d26c06ebc5.png)
</details>

- [ ] <details><summary>audio</summary>
![image](https://user-images.githubusercontent.com/39104740/112220230-0f236580-8c37-11eb-8a07-b8ea4bd2bf22.png)
</details>

- [x]  <details><summary>video - implemented in `video_player`</summary>
![image](https://user-images.githubusercontent.com/39104740/112220087-e7340200-8c36-11eb-93f7-a327cc6b7572.png)
</details>

- [x] <details><summary>hyperlink - implemented in <a href="https://pub.dev/documentation/url_launcher/latest/link/Link-class.html">Link</a> from <code>url_launcher</code> package</summary>
![image](https://user-images.githubusercontent.com/39104740/112220941-e51e7300-8c37-11eb-850a-41daeb5f1711.png)
</details>

<br>

<details><summary>but in flutter web all from above do not work (except for hyperlink)</summary>

![image](https://user-images.githubusercontent.com/39104740/112216206-493e3880-8c32-11eb-8890-415c044a8c6a.png)
</details>
Repository: pytorch
Issue: Let backends specify a schema version when registering kernels
Labels: module: internals,triaged,module: backend,module: codegen

Right now, any time we make a change to the schema of an operator, we have to add a corresponding patch to the kernel registration logic in any external backends, e.g. XLA. This causes a temporary window when master is broken for the external backend, when we've merged our change in pytorch core but the corresponding patch hasn't merged yet.

See https://github.com/pytorch/pytorch/pull/53583 for an example, which code mods `Scalar` to `const Scalar&` in every op signature, and required corresponding changes in XLA.

To avoid breaking external backends during these changes, we could version our API's. The required changes would look something like:
- maintain a notion of versions (we could use a counter, or just new/old if we want to enforce no more than 2 versions)
- Somewhere in the codegen (probably `translate.py`), add branching logic to determine if we should generate schema according to the new version or the old version
- In PyTorch core, always codegen dispatcher registrations for the newest version
- In external backends, explicitly pass in information to tell the dispatcher which version of the API to use. This would incur a small runtime cost: we would probably need something like a `hacky_wrapper` to do the translation from whatever version to the "latest" version that the dispatcher expects.

This will also be easier to do when/if we end up using codegen to register external backend kernels.

cc @ezyang @bhosmer @smessmer @ljk53 @bdhirsh @ailzhang
Repository: node
Issue: Random hickups on `emitInitNative`
Labels: performance,async_hooks

Node versions: 15.12, 14.15.3

Not sure if this is a problem with the profiler but `emitInitNative` seems to randomly block the event loop for a second or more.

![image (1)](https://user-images.githubusercontent.com/3065230/112223810-a930e100-8c2a-11eb-89dc-b784042af56f.png)
![image](https://user-images.githubusercontent.com/3065230/112223816-aa620e00-8c2a-11eb-8a94-b4150c687fc6.png)
Repository: vscode
Issue: Cell tabs stops and keyboard navigation issues
Labels: bug,accessibility,notebook-commands

Testing #119118

Markdown Cell Scenarios:
1. click on a cell and press tab -- focus is moved to the cell toolbar
2. :bug: press shift+tab -- focus is moved to the previous cell rather than back to the current cell
---
1. click on a cell and press tab -- focus is moved to the cell toolbar
2. :bug: press right or left arrow -- focus will move between the pencil & ellipsis, but never to the trash can (have to tab again to get to the trash can)
3. :bug: moving the mouse when focus is in the toolbar can cause the toolbar to disappear
---
1. click on a cell and press tab -- focus is moved to the cell toolbar
2. press tab -- focus is moved to the trash can
3. press tab -- focus is moved to the + code/markdown toolbar
4. :bug: press tab -- focus jumps to the next markdown cell with the  + code/markdown toolbar focused
5. :bug: press tab -- sometimes focus jumps to the next markdown cell with the  + code/markdown toolbar focused -- sometimes it jumped to a code cell above
---
1. click on a cell and press tab -- focus is moved to the cell toolbar
2. press tab -- focus is moved to the trash can
3. press tab -- focus is moved to the + code/markdown toolbar
4. :bug: press shift+tab -- sometimes focus goes back to the cell toolbar, other times it jumps to the previous markdown cell with the  + code/markdown toolbar focused

Code Cell Scenarios:
1. :bug: click on a cell and press tab -- focus is moved to the cell toolbar -- IMO it should move to the run button
---
1. click on a cell and press shift+tab -- focus is moved randomly (I can't tell where/why)
---
1. click on a cell and press tab -- focus is moved to the cell toolbar
2. :bug: press tab -- focus is moved to trash can in the cell toolbar
3. press tab -- focus is moved to the run button (as noted above, imo this should be first)
4. :bug: press tab -- focus is moved to inside the editor and now you are trapped (maybe it should just put a focus rect around the editor requiring you to press enter/space to enter edit mode? Without that you can't tab to the + code/markdown toolbar
---
1. :bug: You can't keyboard navigate to the editor status bar where the "kernel" button is (as well as any other buttons)
---
1. :bug: You can't keyboard navigate to the results
--
1. :bug: click into the results (:bug: there is no focus indicator at all) and shift-tab -- focus jumps to the previous cell and back
---
1. :bug: click into the results and tab through all the results -- focus jumps to the next cell (and puts it in edit mode if markdown) and back

![tab](https://user-images.githubusercontent.com/641685/112228738-27c85700-8c08-11eb-916d-4761bcb1f530.gif)