sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: force-unwind-tables has no effect
Labels: T-compiler,C-bug,A-panic,S-needs-repro

Hello, i'm building a no_std rust driver for windows and the unwind tables are not being generated in release mode. This is a large issue for be because i'm interacting with a kernel interfaces that requires the unwind_table entry for a specific function. Here is the issue in detail: https://github.com/rust-lang/backtrace-rs/issues/397#issuecomment-846422025

I'd expect that even though i've set the panic=abort mode that unwind tables are generated, and especially with the force-unwind-tables flag set to yes. I only need a specific function to have an unwind entry, so perhaps a #[unwind_entry] function attribute could make sense to introduce? The panic behavior should be separate from what binary tables are generated, they are separate concerns...
Repository: TypeScript
Issue: `keyof` on homomorphic mapped type over an array thinks keys are function types
Labels: Bug

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->
Creating a mapped type (where each value is just the key - `{ [K in keyof T]: K }`) when applied over a generic type `T`, where `T` has been passed as an array type, somehow manages to resolve the keys of an array as functions. I've read the FAQ about homomorphic mapped types but I can't imagine the `K` in `K in keyof T` ending up as a function type - no matter what the `T` eventually becomes.

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->
keyof, array, types, type constructors

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about homomorphic mapped types

Tested on 3.9.7, 4.2.3.

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?ts=3.9.7#code/C4TwDgpgBA0hIGcA8AVAfFAvFA3gWACgpioBtGKASwDsoBreAewDMoUBdALlgG5CBfUgxAs27PgUKhIUAOIosseMgTAATjQDmpdmgkB6fVAB6UABKMAbhDVQAFjYgA6JYigBDNdGYBXagGNgSkZqBCgAfkjCIA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
type Keys<T> = {
    [K in keyof T]: K;
}[keyof T];

type GT = Keys<string[]>;
// ^ Hover here. Keys are functions ???
```

![Type upon hovering](https://user-images.githubusercontent.com/44284917/119232164-cd813f00-bb41-11eb-8db8-b47d4863ad4f.png)

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->
`Keys` applied over an array, returns a union of functions.

### 🙂 Expected behavior

<!-- What you expected to happen instead, and why -->
`Keys` applied over an array, should return the property names of the array.
Repository: godot
Issue: Breakage of animation when copying coordinates of IK of a bone
Labels: bug,topic:animation

**Doll** and the **puppeteer** - an identical object.
The doll has to copy animation and position of the puppeteer through copying of its coordinates of an object and boneIK which leads to breakage. 
Without copying coordinate the same animation works correctly.

**godot v3.3 fix** [https://github.com/godotengine/godot/runs/2486991399](url)
![1_2IK](https://user-images.githubusercontent.com/75214342/119226801-686b2080-bb24-11eb-8f8c-7420cfdd8833.png)
![IKss2](https://user-images.githubusercontent.com/75214342/119229700-a4a57d80-bb32-11eb-9bee-0a2a1d521fa7.png)
**Godot project**
[IK_2.zip](https://github.com/godotengine/godot/files/6526725/IK_2.zip)
Repository: godot
Issue: right side joystick inputs dont work as expected on linux 
Labels: bug,topic:input

**Godot version:**
3.3.1 official


**OS/device including version:**
Pop OS 20.10 x86_64 


**Issue description:**
<!-- What happened, and what was expected. -->
when ever I move the right joystick on a game pad instead it will give the input that you would get if I were to move the joystick up
this only happens on linux while on windows it works as intended  

**Steps to reproduce:**
add up down left and right to your input map and assign the right joystick axis to them
then under _processes() or _input()  check for those inputs 
what will happen is if you move the joystick right is that the input action up will trigger instead of right


**Minimal reproduction project:**
[GamepadInput.zip](https://github.com/godotengine/godot/files/6526807/GamepadInput.zip)
Repository: flutter
Issue: Docstring for `Canvas.transform` Should include a blurb on idiomatically creating matrices
Labels: c: new feature,engine,d: api docs,c: proposal,P3,team-engine,triaged-engine

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case
[`Canvas.transform()`](https://api.flutter.dev/flutter/dart-ui/Canvas/transform.html) accepts a 4d matrix, but doesn't indicate any way to do it. Perusing only on documentation, only route forward is with `Float64List`. 

Creating matrices using [`Float64List`](https://api.flutter.dev/flutter/dart-typed_data/Float64List-class.html) is tedious, and it hampers code-readability.
Yet, its the only way somebody just reading docs would construct a matrix for `transform`.

## Proposal
Given the extreme utility of `transform`, and its indispensability, in lots of use-cases, we should indicate a convenient way to use it.
Currently, the (vector_math)[https://pub.dev/packages/vector_math] package offers a great way to create [`Matrix4`](https://pub.dev/documentation/vector_math/latest/vector_math/Matrix4-class.html)
 in a variety of ways, which can then be passed to `transform` via `.storage`. Moreover the package is maintained by Google.

I'd be more than happy to submit a PR for the same.

**TL;DR: Should add a mention of vector_math to the docstring of `Canvas.transform`, and add a simple example as well.**



<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching images showing what you are imagining.

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->
Repository: node
Issue: node-api ThreadsafeFunction is a leaky abstraction
Labels: node-api

The premise of the API is that it should make it easy to call into a loop thread from any other thread(s). However, the semantics of `napi_closing` and `finalize_cb` mean that the API user need to wrap calls to `call_threadsafe_function` and `release_threadsafe_function` into a mutex, because they are inherently not threadsafe. This technically is documented, but very not obvious given the name of the API object.

I suggest that we change the API making it so that:

* `call_threadsafe_function` never returns `napi_closing` and is safe to call up until internal `thread_count` drops to `0`
* `release_threadsafe_function` is safe to call up until internal `thread_count` drops to `0` irrespective of whether `finalize_cb` was called or not

Specifically, it sounds like for this to work we'll have to have an inner and outer classes for the `ThreadsafeFunction`. The inner would hold references to V8 objects and would be deleted on the loop/V8 thread during `finalize_cb`. The outer would be still accessible to the threads up until they all call the release method.

This is a breaking API change so I'd appreciate if we could have a discussion around that.

cc @nodejs/node-api @nodejs/addon-api @addaleax 

See https://github.com/neon-bindings/neon/pull/744 for particular woes on the API user side.
Repository: flutter
Issue: Set minimum OS required version in pubspec
Labels: c: new feature,tool,c: proposal,P3,team-tool,triaged-tool

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

With the recent bugs in flutterfire, and having to downgrade versions to avoid bugs, I've had to blow away my Podfile a few times to have it rebuild by flutter. I'd like to specify an OS version in the pubspec and have it propagate to Podfile, build.gradle, etc... That way when I need to regenerate the various OS, it already has my min OS requirements. 

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe the alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

## Proposal

Include OS version requirements in Pubspec.yaml

<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching images showing what you are imagining.

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->
Repository: godot
Issue: `AnimationPlayer.advance()` doesn't advance audio
Labels: bug,topic:audio,topic:animation

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
DONE -->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
v3.3.1.stable.official

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
OS: Arch Linux (I don't know how to provide a version for this)

**Issue description:**
<!-- What happened, and what was expected. -->
I have an `AnimationPlayer` with multiple tracks. One of them is an audio playback track. When I call the `advance()` method, I expect the audio to jump ahead. It doesn't do that.

**Workaround**
Call `AudioStreamPlayer.seek()` after calling `AnimationPlayer.advance()`.

**Steps to reproduce:**
1. Create an AnimationPlayer.
2. Give it an animation named "example".
3. Add an audio playback track to that animation.
4. Add a 2 minute long sound clip to that audio playback track.
5. Make sure that the animation is at least 2 minutes long.
6. Attach the following script to the AnimationPlayer:
```gdscript
extends AnimationPlayer


func _ready():
	play("example")
	advance(60)

	# Workaround:
	#$AudioStreamPlayer.seek(60)
```
7. Run the scene.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[animation_player_does_not_advance_audio.zip](https://github.com/godotengine/godot/files/6527228/animation_player_does_not_advance_audio.zip)
Repository: rust
Issue: bootstrap unable to copy `rust-llvm-dwp` when cross compiling rustc
Labels: O-windows,A-cross,T-bootstrap,C-bug

Similar to #85590, this is an issue with copying files when cross compiling (Linux -> Windows), however a bit more complicated so I didn't proceed with a fix (don't mind implementing one but would need guidance).

```
thread 'main' panicked at 'src.symlink_metadata() failed with No such file or directory (os error 2)', src/bootstrap/lib.rs:1196:24
stack backtrace:
```
<details>

```
   0: rust_begin_unwind
             at /rustc/215738137bcbef2c3637a5bd290ef612cffe6ba5/library/std/src/panicking.rs:493:5
   1: std::panicking::begin_panic_fmt
             at /rustc/215738137bcbef2c3637a5bd290ef612cffe6ba5/library/std/src/panicking.rs:435:5
   2: bootstrap::Build::copy
             at ./src/bootstrap/lib.rs:1196:24
   3: <bootstrap::compile::Assemble as bootstrap::builder::Step>::run
             at ./src/bootstrap/compile.rs:1116:17
   4: bootstrap::builder::Builder::ensure
             at ./src/bootstrap/builder.rs:1518:23
   5: bootstrap::builder::Builder::compiler
             at ./src/bootstrap/builder.rs:585:9
   6: <bootstrap::tool::Rustdoc as bootstrap::builder::Step>::make_run
             at ./src/bootstrap/tool.rs:500:23
   7: bootstrap::builder::StepDescription::maybe_run
             at ./src/bootstrap/builder.rs:179:13
   8: bootstrap::builder::StepDescription::run
             at ./src/bootstrap/builder.rs:220:21
   9: bootstrap::builder::Builder::run_step_descriptions
             at ./src/bootstrap/builder.rs:577:9
  10: bootstrap::builder::Builder::execute_cli
             at ./src/bootstrap/builder.rs:569:9
  11: bootstrap::Build::build
             at ./src/bootstrap/lib.rs:510:13
  12: bootstrap::main
             at ./src/bootstrap/bin/main.rs:33:5
  13: core::ops::function::FnOnce::call_once
             at /rustc/215738137bcbef2c3637a5bd290ef612cffe6ba5/library/core/src/ops/function.rs:227:5
```
</details>

From adding debug prints it attempts to copy

```
.../rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-dwp.exe
```
to
```
.../rust/build/x86_64-pc-windows-gnu/stage2/lib/rustlib/x86_64-pc-windows-gnu/bin/rust-llvm-dwp.exe
```

Looking at the [Relevant code](https://github.com/rust-lang/rust/blob/e4ca1662f255db774dcd16ed9c3776bf25ac8361/src/bootstrap/compile.rs#L1109-L1118) it appears to be running `llvm-config` from the host in order to find the copy of `llvm-dwp` to copy, however when cross compiling you can't just copy over the host's `llvm-dwp`. This results in an error due to the fact it *does* properly respect the exe suffix, which means the file won't exist when cross compiling as `llvm-dwp.exe` won't exist in the host copy of llvm's bin directory.
Repository: pytorch
Issue: Transferring tensor to the gpu and converting dtype in a single call to .to() is slower than first transferring, then converting.
Labels: module: performance,module: cuda,triaged

## 🐛 Bug

Converting a uint8 tensor on the cpu to a float32 tensor on the gpu takes significantly longer when done in one call:

```
T.to(dtype=torch.float32, device='cuda')
```

than when first transferring to the gpu and then converting the dtype:

```
T.to(device='cuda').to(dtype=torch.float32)
```

## To Reproduce

```
import torch, time

T = torch.zeros((1000, 1000, 100), device='cpu', dtype=torch.uint8)

for i in range(10):
    T.to(dtype=torch.float32, device='cuda')
    
times = [0, 0]
torch.cuda.synchronize()

for i in range(100):
    t0 = time.time()
    T.to(dtype=torch.float32, device='cuda')
    torch.cuda.synchronize()
    times[0] += time.time() - t0
    
    t0 = time.time()
    T.to(device='cuda').to(dtype=torch.float32)
    torch.cuda.synchronize()
    times[1] += time.time() - t0

print(times[0])
print(times[1])
```

```
8.725952625274658
0.9716556072235107
```

## Expected behavior

`.to(device, dtype)` should probably check whether the converted tensor will have a larger datatype and dynamically either first transfer and then convert or vice versa in order to minimize the amount of data needed to transfer.

## Environment

Collecting environment information...
PyTorch version: 1.7.1
Is debug build: False
CUDA used to build PyTorch: 11.0
ROCM used to build PyTorch: N/A

OS: Pop!_OS 20.10 (x86_64)
GCC version: (Ubuntu 10.2.0-13ubuntu1) 10.2.0
Clang version: Could not collect
CMake version: version 3.16.3
Libc version: glibc-2.32

Python version: 3.8 (64-bit runtime)
Python platform: Linux-5.11.0-7614-generic-x86_64-with-glibc2.10
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: GeForce RTX 3090
Nvidia driver version: 460.73.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.20.3
[pip3] numpydoc==1.1.0
[pip3] pytorch-lightning==1.1.2
[pip3] torch==1.7.1
[pip3] torch-tb-profiler==0.1.0
[pip3] torchaudio==0.7.0a0+a853dff
[pip3] torchsummary==1.5.1
[pip3] torchvision==0.8.2

cc @ngimel @VitalyFedyunin
Repository: pytorch
Issue: Single-Process Multi-GPU is not the recommended mode for DDP
Labels: oncall: distributed,triaged,module: ddp

### Problem
Hi, Everyone. I have encountered some problem about pytorch ddp on single node multiple gpus. 
My setting is follow as:
```python
os.environ["MASTER_PORT"] = "9999" 
os.environ["CUDA_VISIBLE_DEVICES"] = "0,1,2,3"
.....
distributed_sampler = torch.utils.data.distributed.DistributedSampler(dataset)
torch_dataloader = torch.utils.data.DataLoader(dataset,
                                                           batch_size=64,
                                                           pin_memory=True,
                                                           num_workers=4,
                                                           sampler=distributed_sampler)

model.cuda()
model = torch.nn.parallel.DistributedDataParallel(model)
```
But this setting is slower than `DataParallel`, and get some message.

### Error Message
```
UserWarning: Single-Process Multi-GPU is not the recommended mode for DDP. 
In this mode, each DDP instance operates on multiple devices and creates multiple module replicas within one process. 
The overhead of scatter/gather and GIL contention in every forward pass can slow down training.
Please consider using one DDP instance per device or per module replica by explicitly setting device_ids or CUDA_VISIBLE_DEVICES. 
```

### Environment
python: 3.7
pytorch: 1.7
GCP ml-engine image_uri: gcr.io/cloud-ml-public/training/pytorch-gpu.1-7
gpu_type: complex_model_m_p100 (p100x4 on single node)

Hope someone can answer my problem. I will appreciate.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu @gcramer23
Repository: yt-dlp
Issue: [Site Request] NFHS Network School/drilldown pages
Labels: site-request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of yt-dlp:
- First of, make sure you are using the latest version of yt-dlp. Run `yt-dlp --version` and ensure your version is 2021.05.20. If it's not, see https://github.com/yt-dlp/yt-dlp on how to update. Issues with outdated version will be REJECTED.
- Search the bugtracker for similar site feature requests: https://github.com/yt-dlp/yt-dlp. DO NOT post duplicates.
- Finally, put x into all relevant boxes like this [x] (Dont forget to delete the empty space)
-->

- [x] I'm reporting a site feature request
- [x] I've verified that I'm running yt-dlp version **2021.05.20**
- [x] I've searched the bugtracker for similar site feature requests including closed ones


## Description

<!--
Provide an explanation of your site feature request in an arbitrary form. Please make sure the description is worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient. Provide any additional information, suggested solution and as much context and examples as possible.
-->

This is a tracking bug for adding support for NFHS Network "drilldown" pages (Idk what else to call it)... This is pretty low priority as I'm pretty sure no one uses this extractor since I added it. I will try to make a PR for this soon but no promises, as it's a bit more complex than just downloading a single video. 

Example URLS:
Filtering on demand events by sport, school, and level: `https://www.nfhsnetwork.com/watch-events?activity=Cheerleading%20and%20Dance&drilldown=on%20demand&eventType=on%20demand&level=varsity&state=CO`
Events from a specific school: `https://www.nfhsnetwork.com/schools/prairie-view-high-school-henderson-co?drilldown=on%20demand`
Repository: pytorch
Issue: TensorIterator for sparse layouts
Labels: module: sparse,feature,triaged

So, sparse has a problem. The problem is that we have tons and tons of very regular operations in PyTorch (unary ops, binary ops), and each of these needs to be painstakingly reimplemented for every sparse layout we want to support. But at the same time, there are so many different sparse layouts (COO, CSR, more exotic block sparse layouts) and so even if you write an algorithm that works for an arbitrary binary operator, you still have to write boilerplate to stamp out the actual logic for every binary operation. Ugh.

So what we're looking for is some sort of TensorIterator-like abstraction that can remove the boilerplate of "and now instantiate this algorithm for every binary/unary operator in PyTorch." So let's say you want to stand up a new sparse layout in PyTorch. The new workflow would look like this:

1. Write your intersection/union algorithm for your sparse algorithm, but templated over the binary operation in question. (If you have different algorithms depending on various properties of the binary operator, e.g., commutative versus non-commutative, that's fine, you write algorithms for each).
2. This template is (somehow--magic happens here) instantiated for every operator for which it is applicable, and all these implementations are registered. You now have coverage for all of these operations?

P.S. This concept would also be useful for dtype extension, which also requires a sort of "recompile all the kernels" except in this case, it is the operators that must be reimplemented, but the TensorIterator algorithms that are preexisting.

cc @aocsa @nikitaved @pearu @mruberry @jbschlosser @ngimel @IvanYashchuk