sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: yt-dlp
Issue: [instagram] support reels/audio link type
Labels: site-enhancement

### DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

- [X] I understand that I will be **blocked** if I 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'm running yt-dlp version **2022.08.19** ([update instructions](https://github.com/yt-dlp/yt-dlp#update)) or later (specify commit)
- [X] I've searched 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

Test link:
https://www.instagram.com/reels/audio/5048757508568334/

extractor falls back to generic and then gives Unsupported URL error.



### Provide verbose output that clearly demonstrates the problem

- [X] Run **your** yt-dlp command with **-vU** flag added (`yt-dlp -vU <your command line>`)
- [X] Copy the WHOLE output (starting with `[debug] Command-line config`) and insert it below

### Complete Verbose Output

```shell
./yt-dlp -vU -F "https://www.instagram.com/reels/audio/5048757508568334/"
[debug] Command-line config: ['-vU', '-F', 'https://www.instagram.com/reels/audio/5048757508568334/']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.08.19 [48c88e088] (zip)
[debug] Plugins: ['SamplePluginIE', 'SamplePluginPP']
[debug] Python 3.9.13 (CPython 64bit) - macOS-12.5.1-arm64-arm-64bit 
[debug] Checking exe version: ffmpeg -bsfs
[debug] Checking exe version: ffprobe -bsfs
[debug] exe versions: none
[debug] Optional libraries: sqlite3-2.6.0
[debug] Proxy map: {}
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Latest version: 2022.08.19, Current version: 2022.08.19
yt-dlp is up to date (2022.08.19)
[debug] [generic] Extracting URL: https://www.instagram.com/reels/audio/5048757508568334/
[generic] 5048757508568334: Downloading webpage
WARNING: [generic] Falling back on generic information extractor
[generic] 5048757508568334: Extracting information
[debug] Looking for Brightcove embeds
[debug] Looking for embeds
ERROR: Unsupported URL: https://www.instagram.com/reels/audio/5048757508568334/
Traceback (most recent call last):
  File "./yt-dlp/yt_dlp/YoutubeDL.py", line 1442, in wrapper
    return func(self, *args, **kwargs)
  File "./yt-dlp/yt_dlp/YoutubeDL.py", line 1518, in __extract_info
    ie_result = ie.extract(url)
  File "./yt-dlp/yt_dlp/extractor/common.py", line 666, in extract
    ie_result = self._real_extract(url)
  File "./yt-dlp/yt_dlp/extractor/generic.py", line 3077, in _real_extract
    raise UnsupportedError(url)
yt_dlp.utils.UnsupportedError: Unsupported URL: https://www.instagram.com/reels/audio/5048757508568334/
```
Repository: terminal
Issue: [Settings]: Keyboard focus is not jumping on first control of the opened page.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11yCO,A11ySev3,Disability-All

### Windows Terminal version

1.15.2003.0

### Windows build number

10.0.25179.1000

### Other Software

**Test Environment:**
OS: Window 11 22H2 OS Build 25179.1000
App: Windows Terminal Preview
AT: Narrator

### Steps to reproduce

**Repro Steps:**
1. Open Windows Terminal.
2. Open Narrator AT.
3. Inside Settings> Defaults page, activate 'Appearance' tab and observe the issue
4. Then activate 'Defaults' breadcrumb item and observe the issue
 
**User Experience:**
People with Visual impairments like Screen Reader will have bad UX as they have to navigate back to access page control or might take time to figure out whether page opened or not.

**Guideline Reference:**
https://www.w3.org/WAI/WCAG21/Understanding/focus-order

**Attachments:**
[Tab Controls focus Order.zip](https://github.com/microsoft/terminal/files/9402113/Tab.Controls.focus.Order.zip)

### Expected Behavior

 When user activating 'Appearance' or 'Advance' or Defaults control, Keyboard focus should jump on first control of opened page.


### Actual Behavior

 When user activating 'Appearance' or 'Advance' tab control, Keyboard focus is jumping on 'Save' button
And When user activating 'Defaults' breadcrumb item, Keyboard focus is jumping on 'Save' button
Repository: PowerToys
Issue: [MeasureTool - ScreenRuler] Add units of measure to tooltip
Labels: Idea-Enhancement,Needs-Triage

> > Showing an indicator about which number is X (left/right) and which is Y (up/down) when measuring in rectangle mode and cross mode.
> 
> I like it, but since we're going to allow different display units of measure soon, it could look a bit cluttered, i.e. "W:10px H: 20px". 🤔 

Can we have a line break like this:
```
Width: 10px
Hight: 20px
```
Then it looks cleaner.

_Originally posted by @htcfreek in https://github.com/microsoft/PowerToys/pull/19701#issuecomment-1221405872_

---

cc: @yuyoyuppe
Repository: PowerToys
Issue: [Measure Tool - ScreenRuler] Improve measurement above complex background images
Labels: Idea-Enhancement,Needs-Triage

> > Maybe a featur to measure at one side to the nearest monitor border. (Example: You have a background that is very detailed and you want to measure the space between window and left monitor border. Then you press a key and the tool ignores the background image and enlarges the measurement until the left monitor border.) - Not sure if this is a real scenario as I can't try the tool currently
> 
> I think we could investigate changing desktop background to solid color during measurement.

Let's talk about later in a different step an create an issue for discussion.


_Originally posted by @htcfreek in https://github.com/microsoft/PowerToys/pull/19701#issuecomment-1221405872_

---
cc: @yuyoyuppe
Repository: vscode
Issue: Merge Editor: "Accept All Changes from Left" command discoverability
Labels: feature-request,merge-editor

Testing #158819

I would love for the "Accept All Changes from ..." command to be more discoverable as currently it is in the `...` context menu. Have we ever considered lifting it as a primary action in the editor toolbar? Could we put a checkbox in the editor toolbar right before the "Input 1" label, and when that is clicked all changes from the side are accepted?

<img width="1014" alt="image" src="https://user-images.githubusercontent.com/3372902/186159012-1080edf9-01a7-43e1-bde1-ea5b9fb938d4.png">
Repository: vscode
Issue: Don't allow extension to annoy users with auth asks
Labels: bug,authentication

* edge/chrome
* have gitlens installed
* reload page
* 😕 gitlens prompts for auth
* reload page
* gitlens again prompts for auth - this shouldn't happen and I am unsure what API is used for that to happen

https://user-images.githubusercontent.com/1794099/186180805-1db664f8-f5c2-4a65-ad36-37632a43fd02.mov
Repository: vscode
Issue: Shared noise for different cases
Labels: feature-request,accessibility,inlay-hints

Testing #158759

`Error hints` and `No Inlay Hints on Line` have the same sound
Repository: pytorch
Issue: Tracking nested tensor functions with backward kernels registered in derivatives.yaml
Labels: triaged,module: nestedtensor

### 🐛 Describe the bug

Context:

Backward formulas for certain nested tensor functions do not work as they call `.sizes()`. As a workaround, we can register formulas specific to the AutogradNestedTensor dispatch key in derivatives.yaml. This should be removed when SymInts for nested tensor sizes are ready for use. This issue serves as a tracker for functions for which we have added this workaround so that we can remove them in the future.

- [ ] [_nested_sum_backward](https://github.com/pytorch/pytorch/pull/82625)
- [ ] [_select_backward](https://github.com/pytorch/pytorch/pull/83875)

### Versions

n/a

cc @cpuhrsch @jbschlosser @bhosmer @drisspg @albanD
Repository: rust
Issue: Passing an array to an inlined function from another crate miscompiles on PowerPC
Labels: P-low,T-compiler,regression-from-stable-to-stable,C-bug,E-needs-mcve,I-miscompile

### Code

I tried this code:

crate1:
```rust
#[inline(always)]
pub fn check_something(array: [u8; 7]) {
    for f in array {
        assert!(f < 64);
    }
}
```
crate2:
```rust
fn main() {
    other_unrelated_function([0x00666666]);
    check_something([0x00, 0x00, 0x15, 0x16, 0x15, 0x00, 0x00]);
}
```

This was while trying to build [my GPU branch](https://github.com/linkmauve/luma/tree/bp) of the [Luma](https://github.com/rust-wii/luma) project, which targets the GameCube and the Wii (so use PowerPC codegen).  The bug as I could see it in [Dolphin](https://dolphin-emu.org/)’s debugger is that the register pointing to the beginning of the array minus one byte actually points to the beginning of the array minus five bytes, and thus it reads the four bytes prior to the beginning of the array, then the first three bytes.

Things which fix this bug:
- Adding a `println!("{array:?}")`
- Making the function `#[inline(never)]`
- Passing the array as an array reference instead.

I expected to see this happen: no assert would happen, as none of the values in the array are bigger than 0x16 (22).

Instead, this happened: `panicked at 'assertion failed: f < 64', /home/linkmauve/dev/rust/luma/luma_core/src/gx/bp.rs:150:13`

### Version it worked on

It most recently worked on: nightly from the 2022-08-11.

### Version with regression

`rustc --version --verbose`:
```
rustc 1.65.0-nightly (015a824f2 2022-08-22)
binary: rustc
commit-hash: 015a824f2dffe32707fceb59c47effaf7b73486c
commit-date: 2022-08-22
host: x86_64-unknown-linux-gnu
release: 1.65.0-nightly
LLVM version: 15.0.0
```

<!--
If you know when this regression occurred, please add a line like below, replacing `{channel}` with one of stable, beta, or nightly.

@rustbot modify labels: +regression-from-nightly-to-nightly -regression-untriaged
-->
Repository: node
Issue: NODE_V8_COVERAGE can run OOM when compiling a lot of scripts in one process
Labels: coverage

For more context, see https://bugs.chromium.org/p/v8/issues/detail?id=13183. In summary, in Node.js NODE_V8_COVERAGE is implemented by taking *precise* coverage, which holds on to all the feedback vectors of every function (including scripts) that has ever been compiled, even after the functions are gone. My understanding that this is by-design for precise coverage - by the time the coverage is collected, it's possible that the functions have already been GC'ed, but V8 still needs to consult the feedback vectors for invocation counts that were recorded when the functions were still alive. As an alternative V8 provides best-effort coverage that does not hold on to feedback vectors but as a result the data from functions that have been GC'ed by the time the coverage is taken can be missing.

Reproduction (h/t @ptomato):

```mjs
//  Run this with NODE_V8_COVERAGE=/tmp node --max_old_space_size=30 test.mjs
import vm from 'node:vm';
import v8 from 'node:v8';
const setupCode = new vm.Script('Date.now();'.repeat(10000));

for (let count = 1; count < 50000; count++) {
  const context = {};
  vm.createContext(context);
  setupCode.runInContext(context);
  if (count % 100 === 0) {
    console.log(count, v8.getHeapStatistics());
    console.log(process.memoryUsage());
  }
}
```

I think there are two options to tackle this:

1. When NODE_V8_COVERAGE is enabled, periodically collect coverage, which allows V8 to GC the feedback vectors of functions that are no longer alive. We either keep that data in memory and write it out when the process is about to exit (which is what we do now), or flush the collected coverage  periodically to the directory specified by NODE_V8_COVERAGE  (personally I like the latter better, I believe the existing coverage tooling can already merge the data from different files anyway?) We could add another environment variable for users to control the frequency, and they can use `Infinity` to tell Node.js to go back to the current behavior.
2. We can also provide an environment variable for the user to specify that they want best-effort coverage instead of precise coverage.

cc @bcoe
Repository: vscode
Issue: Live preview extension contributed task does not include the "Task" tab description
Labels: bug,tasks,terminal-tabs

Testing https://github.com/microsoft/vscode/issues/158835

![image](https://user-images.githubusercontent.com/2193314/186223045-fe526ebd-9be5-46e8-ac0a-819e687ab89a.png)

Not sure why it doesn't say Task like these:

![image](https://user-images.githubusercontent.com/2193314/186223119-7b1b5e39-7593-4e95-8748-c50e3cc51d8d.png)
Repository: go
Issue: runtime: allow short-term drop of work conservation to increase CPU efficiency
Labels: Performance,NeedsInvestigation,compiler/runtime

Currently Go's scheduler is [work conserving](https://en.wikipedia.org/wiki/Work-conserving_scheduler), meaning that it maximizes utilization of CPU resources. That is, if there is new work and an idle P, we will always wake that P to run the new work, rather than allowing runnable work and idle Ps.

In general, this is a good property that prevents us from getting in odd edge cases of under-utilizing CPU resources when we have work that could fill them. However, this is not without cost. Most notably, waking a thread to run a P is a heavyweight operation. If the work completes quickly, the thread may need to go back to sleep, which is another heavyweight operation.

This inefficiency has been a significant source of overhead in applications I've profiled. It is a contribution to #18237 and #21827, the target of #32113, and probably other issues I can't find at the moment.

There are several relevant measurements here w.r.t. cost of scheduling new work:

* The time to wake a sleeping thread to run this work. (`wake`)
* Alternatively, the time to wait for the work to schedule on an already running thread if we don't wake. (`wait`)
* The time the work will run for. (`run`)
* The time to put a thread with nothing to do to sleep. (`sleep`)

Some observations here:

* If `wake > wait`, then waking a thread is useless. It is worse for latency and CPU usage. However, this case is likely quite rare.
* If `wake + sleep ≫ run`, then waking a thread is quite wasteful w.r.t. CPU usage. There is no objective cutoff here, because latency is likely still better than `wait`, but we are paying quite a high price for better latency.

This last case is what I'd like to improve; we could make a trade-off that we'll accept higher latency in these cases in exchange for better CPU efficiency by not waking a thread (immediately) for the new work, thus dropping work conservation.

A prototype of this concept was created by @nixprime several months ago that did this via creation of a "latency target" knob in the scheduler defining how long we were willing to let `wait` get before waking a thread. This prototype achieved very solid improvements (+15% productivity for some applications) with very small target latencies (~20-40us).

Such a knob would be difficult to set intuitively, but 20-40us latencies are sufficiently low that I believe we may be able to make this a permanent, knob-less, feature of scheduler, perhaps with additional heuristics to avoid the worse cases (e.g., predicting that `run` will be very high?).

This needs more investigation, prototyping, and experimenting.

cc @aclements @mknyszek
Repository: vscode
Issue: Test merge editor: compare with base should maybe open at the line where the merge editor was
Labels: feature-request,verification-found,verification-needed,merge-editor

Testing #158819

Not sure if this is expected behavior, but comparing with base opens at the top of the file regardless of where in the merge editor I was. I think it'd be more helpful to open to where I was in the merge editor, since I'd maybe be more interested in what that particular part of the base had?
![Recording 2022-08-23 at 11 08 18](https://user-images.githubusercontent.com/31675041/186233140-3e28d86a-5e44-4376-9727-ecbd475ad06c.gif)
Repository: pytorch
Issue: Support primtorch view ops in functionalization
Labels: triaged,module: viewing and reshaping,module: functionalization,module: primTorch

I was starting to look at failing inductor models with `functorch.config.use_functionalize=True` turned on, and one failure that I noticed is:
```
// run this
python benchmarks/timm_models.py --float32 -dcuda --no-skip --training --inductor --use-eval-mode --only=mobilevit_s

// output
    return forward_call(*input, **kwargs)
  File "<eval_with_key>.4", line 394, in forward
    broadcast_in_dim_default = torch.ops.prims.broadcast_in_dim.default(var_default, [256, 256, 1], [0, 1]);  var_default = None
  File "/scratch/hirsheybar/work/benchmark/pytorch/torch/_ops.py", line 60, in __call__
    return self._op(*args, **kwargs or {})
RuntimeError: !schema.hasAnyAliasInfo() INTERNAL ASSERT FAILED at "/scratch/hirsheybar/work/benchmark/pytorch/aten/src/ATen/FunctionalizeFallbackKernel.cpp":30, please report a bug to PyTorch. mutating and aliasing ops should all have codegen'd kernels
```

This error didn't show up in my AOT + eager tests, probably because the inductor backend is choosing to run extra primtorch decompositions. This causes functionalization to see `prims.broadcast_in_dim`, which is a new "view" op that it doesn't know how to handle.

For what it's worth - the code above fails with `use_functionalize=False` turned off today, too, because of some issue's in dynamo' `normalize_ir()` code. So this technically isn't a regression, although it seems like time would be better spent fixing the problem with functionalization instead of fixing dynamo's normalization logic.


Two potential ways to handle this are:
(1) write a custom functionalization kernel for `prims.broadcast_in_dims.default`. We'd need to expose the right C++ API's to python in order to do this
(2) Beef up the functionalization boxed fallback to handle views. This would be very useful, but it's a bit unclear how this would work: for every primtorch view, the boxed fallback needs to know how to map it to a "view inverse" function.

cc @ezyang @mruberry @ngimel
Repository: pytorch
Issue: primTorch: support refs and decompositions when ATen and Python disagree
Labels: triaged,module: primTorch

### 🐛 Describe the bug

1. Policy (related): We need to agree on how to handle refs/decomps like `binary_cross_entropy` where the ATen op and the Python frontend have different number/type of arguments. Right now, `binary_cross_entropy` just defines a decomp. Do we want to split the ref/decomp implementations for these (with a shared core/conversion logic) or handle in some other way?

2. Bug: if `register_decomposition` is used with ops like these to define _one_ Python function that's both registered as a ref and a decomp, there are no type signature checks in `register_decomposition` to catch this. So it'll just run and we might not notice unless it breaks for some other reason.

I have a demo branch with this issue here, see the commit message and notes in the topmost commit:
https://github.com/nkaretnikov/pytorch/commits/primtorch-l1-loss-decomp-ref-compat-issue

### Versions

master (e0f2eba93d2804d22cd53ea8c09a479ae546dc7f)

cc @ezyang @mruberry @ngimel
Repository: pytorch
Issue: Hitting rate limits for pytorchbot token 
Labels: triaged,module: infra

example: https://github.com/pytorch/pytorch/runs/7733767854?check_suite_focus=true
Repository: angular
Issue: Add possibility to update particular validator
Labels: area: forms,P3

### Which @angular/* package(s) are relevant/related to the feature request?

forms

### Description

Currently in angular is tough to update validators dynamically.

For example, I have a component with `FromControl` and `@Input()` which contain settings for some validator. The component could update validator settings by combining the cache of validator and manual call of `removeValidators` and `addValidators`:

```typescript
@Component({...})
export class MyCustomComponent {
  @Input() set range(range: null | {min: number, max: number}) {
    this.formControl.removeValidators(this.currentRangeValidator)
    if (range) {
      this.currentRangeValidator = customRangeValidator(range)
      this.formControl.addValidators(this.currentRangeValidator);
    }
    this.formControl.updateValueAndValidity();
  }
  private currentRangeValidator: ValidatorFn | null = null;

  protected formControl = new FromControl();
}
```

or if there are too many such inputs, then it could be extracted to some function with a whole override of validators:

```typescript
@Component({...})
export class MyCustomComponent {
  @Input() set range(range: null | {min: number, max: number}) {
    this.updateValidators('range', range ? customRangeValidator(range) : null)
  }

  @Input() set required(required: boolean) {
    this.updateValidators('required', required ? Validators.required : null)
  }

  protected formControl = new FromControl();

  private validatorsCache = {};
  private updateValidators(key: string, validator: ValidatorFn | null) {
    this.validatorsCache[key] = validator;
    const filteredValidators = Object.values(this.validatorsCache[key]).filter(Boolean);
    this.formControl.setValidators(filteredValidators);
    this.formControl.updateValueAndValidity();
  }
}
```

But both ways look complicated and probably have performance issues.

### Proposed solution

Passing validators as object (`{}`) or `Map` and work with validators by key could be a better solution:

```typescript
@Component({...})
export MyCustomComponent implements ControlValueAccessor, Validator {
  @Input() set required(required: false) {
    if (required) {
      this.formControl.addValidators({requiredValidator: Validators.required});
    } else {
      // Imaginary new function for deleting validator by key
      this.formControl.removeValidatorsByKey('requiredValidator');
    }
  }

  @Input() set range(range: null | {min: number, max: number}) {
    this.formControl.addValidators({rangeValidator: range ? customRangeValidator(range) : null });
  }

  protected formControl = new FromControl();
}
```

### Alternatives considered

Possible workarounds were suggested in the description
Repository: go
Issue: cmd/compile: OpInlMark can get removed by SSA dead code elimination, resulting in invalid inlining trees
Labels: help wanted,NeedsFix,compiler/runtime

See discussion at https://github.com/golang/go/issues/46234.

The immediate issue is that https://go.dev/play/p/OikFLBmKguY?v=gotip causes the loop at https://github.com/golang/go/blob/7f632f76db65f28038b8797fbfe5e15a9f63e387/src/runtime/traceback.go#L362 to never terminate, because the inlining "tree" has cycles.

The bigger issue is that we're generating trees like this for kube-apiserver, and this is presumably the root cause of #54593.
Repository: TypeScript
Issue: Convert parameters to destructured object refactoring throws 'Could not apply refactoring'
Labels: Bug,Help Wanted,Domain: Refactorings


*TS Template added by @mjbvz*

**TypeScript Version**: 4.8.0

**Search Terms**
- getEditsForRefactor


---


Testing microsoft/vscode#158636

1. Open https://github.com/microsoft/vscode/blob/bb70d7ab19f7295fe669b6384a6c8ccd73d05cc3/src/vs/workbench/services/workspaces/common/editSessionIdentityService.ts#L35
2. Right click on `workspaceFolder`
3. Select Refactor > Convert parameters to destructured object from the context menu 
4. See an error like so:
<img width="433" alt="image" src="https://user-images.githubusercontent.com/30305945/186218331-cad0b51c-b028-4b3f-bdec-c611fd83e010.png">