sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: WASAPI audio driver produces ringing artifact when project's bit rate doesn't match device's sample rate
Labels: bug,platform:windows,confirmed,topic:audio

**Godot version:**
3.2.4-rc3
3.2.3-stable (*)

**OS/device including version:**
Windows 10, 64 bit
WASAPI audio driver
tested on: laptop speakers with 3.5mm headphones; Steelseries Arctis 7 headphones

**Issue description:**
When `mix rate` property in Project Settings (which defaults to 44100 Hz) is different from current audio device's sample rate setting in Windows Sound Control Panel (which, for my 2 devices I tested on, defaults to 48000 Hz), you can hear a ringing effect in any audio played in Godot. The ringing is more noticeable when playing low-end frequencies. This happens with WAV, OGG, and as of 3.2.4, MP3.

I have also tried to set devices to 44100 Hz and Godot to 48000 Hz, with same results.
Setting both to either 44100 Hz or 48000 Hz removes the ringing.

I also tested samples with sample rate set to 44100 Hz and 48000 Hz, but they don't make any difference for this issue.

Here is the video demonstrating the issue (listen with headphones to hear low-end frequencies better):

https://user-images.githubusercontent.com/26509794/109671975-d979e800-7b74-11eb-8dbf-eaf3f246a21c.mp4

I played these samples in FL Studio, VLC, and Audacity, and they all sound the same.

In case it is expected that Godot's and device's sample rates should match, shouldn't that be automatic? The tooltip for `Mix Rate` setting says: `In general, it's better to not touch this and leave it to the host operating system.` so I'd assume the audio should play just fine with all defaults.

This is a continuation of #23544. CC @Zylann @marcelofg55 @akien-mga 

**Steps to reproduce:**

Try playing audio samples provided below in the minimal reproduction project. You don't need a node, just play them from the editor.

`Mix Rate` setting in Godot is located in `Project Settings > audio/mix_rate`.

Device sample rate in Windows 10 is located in `Settings > System > Sound > Sound Control Panel`. Double-click your device, go to Advanced tab, and you should see your device's sample rate:

![nav2](https://user-images.githubusercontent.com/26509794/109673720-9751a600-7b76-11eb-819c-58577c263eac.png)

(*) note that on 3.2.3-stable, you can hear this ringing for OGG even with matching sample rates. #46086 fixes this issue and is merged in 3.2.4-rc3.

**Minimal reproduction project:**

[godot_wasapi_ringing.zip](https://github.com/godotengine/godot/files/6069784/godot_wasapi_ringing.zip)
Repository: create-react-app
Issue: Multiple [HMR] Waiting for update signal from WDS... after reload before it settles.
Labels: needs triage

I'm not sure if it is me or a bug, but during development when I need to refresh the page then multiple `[HMR] Waiting for update signal from WDS...` messages along other logs like the app would reload itself many times before it settles.

![image](https://user-images.githubusercontent.com/7643591/109677239-615df300-7b71-11eb-8c3e-c03328476c16.png)

Is it normal behaviour, or my fault here?

package.json dependencies
```
  "dependencies": {
    "@reduxjs/toolkit": "^1.5.0",
    "@testing-library/jest-dom": "^5.11.4",
    "@testing-library/react": "^11.1.0",
    "@testing-library/user-event": "^12.1.10",
    "@types/jest": "^26.0.15",
    "@types/node": "^12.0.0",
    "@types/react": "^17.0.0",
    "@types/react-dom": "^17.0.0",
    "axios": "^0.21.1",
    "connected-react-router": "^6.9.1",
    "history": "^4.10.1",
    "oidc-client": "^1.11.5",
    "react": "^17.0.1",
    "react-dom": "^17.0.1",
    "react-redux": "^7.2.2",
    "react-router-dom": "^5.2.0",
    "react-scripts": "4.0.3",
    "redux": "^4.0.5",
    "redux-devtools-extension": "^2.13.8",
    "redux-thunk": "^2.3.0",
    "typescript": "^4.1.2",
    "web-vitals": "^1.0.1"
  },
```
Repository: youtube-dl
Issue: Audible support
Labels: site-support-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 youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2021.03.02. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Make sure that all provided video/audio/playlist URLs (if any) are alive and playable in a browser.
- Make sure that site you are requesting is not dedicated to copyright infringement, see https://yt-dl.org/copyright-infringement. youtube-dl does not support such sites. In order for site support request to be accepted all provided example URLs should not violate any copyrights.
- Search the bugtracker for similar site support requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a new site support request
- [x] I've verified that I'm running youtube-dl version **2021.03.02**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that none of provided URLs violate any copyrights
- [x] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs

<!--
Provide all kinds of example URLs support for which should be included. Replace following example URLs by yours.
-->

- Single book: https://www.audible.com/pd/The-Invasion-Audiobook/1338641158
- Single book: https://www.audible.com/webplayer?asin=1338641158
- Playlist: N/A


## Description

<!--
Provide any additional information.
If work on your issue requires account credentials please provide them or explain how one can obtain them.
-->

Username and password would be required to download books. Since Audible only supports listening to books in the browser or in an app, it would be incredible if yt-dl could download one's purchases.

I'm not sure which of the above example links would be better as input. The latter is the page where the book plays directly, but the former is more obviously accessible to the average user.
Repository: terminal
Issue: Windows Terminal fails to instantiate Azure Shell when it is configured with an isolated VNET
Labels: Help Wanted,Issue-Bug,Product-Terminal,Area-AzureShell,Priority-2

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

<!--
This bug tracker is monitored by Windows Terminal development team and other technical folks.

**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.

If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible.

-->

# Environment

```none
Windows build number: Microsoft Windows [Version 10.0.18363.1379]
Windows Terminal version (if applicable):  Version: 1.0.1401.0

Any other software? No
```

# Steps to reproduce

Configure Cloud Shell with isolated VNET settings per https://docs.microsoft.com/en-us/azure/cloud-shell/private-vnet
Validate correct Cloud Shell behavior with https://shell.azure.com
In Windows Terminal attempt to create a new session for Azure Cloud Shell

# Expected behavior

Cloud shell opens.

# Actual behavior

Cloud shell fails to instantiate with the messages:
You have not set up your cloud shell account yet. Please go to https://shell.azure.com to set it up.
[process exited with code 1]
Repository: create-react-app
Issue: using %PUBLIC_URL% crashes on build
Labels: stale

in a css file using %PUBLIC_URL% in a background-image: url() will result in a compile crash with the following error. 

Failed to compile.

./src/css/theme.css (./node_modules/css-loader/dist/cjs.js??ref--5-oneOf-4-1!./node_modules/postcss-loader/src??postcss!./src/css/theme.css)
URIError: URI malformed
    at decodeURIComponent (<anonymous>)
Repository: flutter
Issue: [web] Text selection toolbar doesn't show up on first interaction with SelectableText
Labels: a: text input,engine,platform-web,P2,team-web,triaged-web

When running on web, the framework doesn't show the text selection toolbar. Instead, we rely on the browser to show its own.

SelectableText creates a text field under the hood to handle selection, etc.

The problem is the first interaction with the SelectableText happens before the underlying `<input>` has been created. So the browser doesn't show the context menu (aka the toolbar) until the user interacts again with the text.

**Upon first interaction**:

![Screenshot_20210302-095723](https://user-images.githubusercontent.com/1278212/109693473-8d13b580-7b3e-11eb-8a31-d286249583a0.png)

**After subsequent interactions**:

![Screenshot_20210302-095733](https://user-images.githubusercontent.com/1278212/109693542-a3ba0c80-7b3e-11eb-9b49-7452020f97ca.png)
Repository: godot
Issue: [Bullet] 3D RigidBody collisions with static collision shapes still bumpy
Labels: bug,confirmed,topic:physics,topic:3d

**Godot version:**
3.2.2-stable, 3.2.3-stable, edit: 3.2.4rc3, 3.1-stable

**OS/device including version:**
Windows 10 20H2, Kubuntu 20.10

**Issue description:**
When sliding a RigidBody in character mode over a flat static terrain, most often it will bump up into the air at the "shape boundaries"-- e.g. the edges of individual triangles in a trimesh, or the edges of convex shapes, but _not_ the edges of BoxShapes. Much less frequently the RigidBody will get stuck on the edge. The bumpy collision will slightly change the direction of motion as well, for example, I'll be trying to go straight forward but end up 10 degrees or so towards the right. What I expect to see is the RigidBody being able to slide across a flat surface in a straight line.

I've only seen this behavior when using Bullet. (When I switch to GodotPhysics the collision boundaries still seem broken, but in a different way so that's beyond the scope of this issue).

I know this is very similar to #[21341](https://github.com/godotengine/godot/issues/21341), but I'm still having this problem. Increasing the physics step as mentioned there helped slightly but did not eliminate the issue, and I've been using the "smooth trimesh collision" option as well. Hoped this might be fixed in 3.2.3, but having the same issue in both 3.2.2 and 3.2.3.

**Steps to reproduce:**
1. Enable "visible collision shapes" in the editor
2. Create a flat terrain out of trimesh (Many ways to do this, I used a GridMap to repeat a cube shape).
3. Add a RigidBody in character mode that can be moved around using the keyboard.
4. Don't forget to add a camera :)
5. Run the scene and observe the bumpy behavior.

**Minimal reproduction project:**
[IsPhysicsFixed_3_2_3.zip](https://github.com/godotengine/godot/files/6070721/IsPhysicsFixed_3_2_3.zip)
Make sure "visible collision shapes" is checked. Arrow keys to move, space to jump. Orange is planes with trimesh, red is cubes with trimesh, yellow is cubes with convex shapes, and green is cubes with BoxShapes.
Repository: pytorch
Issue: [fx] Handle models with Optional inputs
Labels: triaged,module: fx

As reported in https://dev-discuss.pytorch.org/t/adapting-models-to-use-torchscript-and-getting-them-to-produce-fusions/129, Optional[Tensor] inputs can block opportunities for fusion, because they introduce `if None` checks in the TorchScript graph.

I thought it might be reasonable to use fx to trace away the control flow, but it only really works if the optional input is a model parameter (passed to the constructor) not an input of the forward method.  concrete_args doesn't seem to solve the problem since that "burns in" the mask value.

In fact, I can't seem to symbolic trace this example at all.  Here's the repro script:

```
import torch
from typing import Optional
from torch.fx import symbolic_trace

class ExampleModule(torch.nn.Module):
    def __init__(self, hidden_size, scale_factor):
        super().__init__()
        self.scale = int(hidden_size / scale_factor)

    def forward(
        self,
        inputs : torch.Tensor,
        mask : Optional[torch.Tensor]=None
    ):
        tmp = inputs / self.scale
        if mask is not None :
           tmp = tmp + mask
        outputs = torch.nn.functional.softmax(tmp, dim=-1)

        return outputs

inp = torch.randn(16)

m = ExampleModule(1024, 512)
m = symbolic_trace(m)
m = torch.jit.script(m)
"""
RuntimeError: 
Arguments for call are not valid.
The following variants are available:
  
  aten::add.Tensor(Tensor self, Tensor other, *, Scalar alpha=1) -> (Tensor):
  Expected a value of type 'Tensor' for argument 'other' but instead found type 'Optional[Tensor]'.
... bunch more schemas ...
The original call is:
def forward(self, inputs : torch.Tensor, mask : typing_Union[torch.Tensor,NoneType] = None):
    truediv = inputs / 2;  inputs = None
    add = truediv + mask;  truediv = mask = None
          ~~~~~~~~~~~~~~ <--- HERE
    softmax = torch.nn.functional.softmax(add, dim = -1, _stacklevel = 3, dtype = None);  add = None
    return softmax
"""

m(inp, inp)
print(m.graph_for(inp, inp))
```

cc @ezyang @SherlockNoMad
Repository: pytorch
Issue: Deprecate and remove torch.set_default_tensor_type
Labels: triaged,module: deprecation

One of the things @gchanan keeps telling me we should do (and we still haven't done, all these years later), is get rid of torch.set_default_tensor_type. Why is it bad? Let me count the ways:

* It is a global modal flag that breaks libraries (https://discuss.pytorch.org/t/is-there-anything-wrong-with-setting-default-tensor-type-to-cuda/27949/4) that does the thing we've repeatedly kept fending off in issues like #27878 ; but it doesn't even do the job properly (since you can only switch default to CUDA, and not to a particular CUDA device)
* It is based off of the legacy constructors (e.g., torch.FloatTensor)
* It duplicates functionality provided by torch.set_default_dtype (e.g., registering torch.DoubleTensor)
* It makes torch/csrc/utils/tensor_new.cpp way more complicated than it should be

Unfortunately, it is also widely used (FB only: https://fburl.com/codesearch/b3bmi3lo ) (GitHub: https://github.com/search?q=torch.set_default_tensor_type&type=code)

Let's get rid of it. Because it is widely used, we will have to hard deprecate some aspects of the functionality, and soft deprecate others. Here is how I propose we go about doing it.

**Deprecation cycle one.** We narrow the API so it only supports exactly six call patterns:

```
torch.set_default_tensor_type(torch.HalfTensor)
torch.set_default_tensor_type(torch.FloatTensor)
torch.set_default_tensor_type(torch.DoubleTensor)
torch.set_default_tensor_type(torch.cuda.HalfTensor)
torch.set_default_tensor_type(torch.cuda.FloatTensor)
torch.set_default_tensor_type(torch.cuda.DoubleTensor)
```

All other call patterns are deprecated and to be removed. This list of call patterns is effectively all calls that actually work in `set_default_tensor_type` today; however, the purpose of hardcoding only six known patterns is to make sure we don't "accidentally" add support for more surface (as is what happened for HalfTensor) and to give us more leeway in refactoring our code (as we no longer have to assume, e.g., that set_default_tensor_type would work with XLA tensors).

Once other call types are removed, we can then refactor set_default_tensor_type into two pieces of functionality: setting default dtype (which exists today as `set_default_dtype`) and `_bc_only_set_default_cuda`, which is a BC-only knob for "turning on CUDA" as was done before by the torch.cuda invocations. `set_default_tensor_type` is updated to call these two pieces of functionality and no longer is a direct part of the C bindings; furthermore, we can refactor tensor_new.cpp to 

**Deprecation cycle two.** Ideally, we come up with some resolution to the #27878 cluster of issues. Now we can deprecate and remove `set_default_tensor_type` entirely, telling users to use `set_default_dtype` or some hypothetical #27878. Defaulting can be removed entirely from tensor_new.cpp
Repository: pytorch
Issue: Lint rule to forbid bare assert() in cuda
Labels: module: cuda,module: lint,triaged

Don't use assert(), use CUDA_KERNEL_ASSERT() (which works in non-DEBUG build). There should be a lint rule to complain about this if you use the wrong one.

cc @ngimel @aocsa
Repository: go
Issue: proposal: cmd/go: mark test dependencies in go.mod and go list -m
Labels: Proposal,GoCommand,modules

There have been a number of requests for a test dependencies section in `go.mod`. These requests actually don't make sense with the way that `go.mod` works, because it's really just a list of rules to follow for resolving dependencies, not a list of dependencies. The actual list of dependencies is per-package, not per-module, and is determined by the actual `import` statements in the code itself. The `go` tool, however, does add some extra information to the `go.mod` file in the form of an `// indirect` comment after dependencies that are only depended on by a dependency.

I propose adding an alternate comment flag, `test`, to indicate that a dependency is only required by tests. Along with this, add an indication of this to the `Module` struct used for formatting `go list -m` output.
Repository: pytorch
Issue: [JIT] Document __jit_ignored_attributes__
Labels: oncall: jit

## 📚 Documentation

This field is completely undocumented, but does exactly what we need.

It would be wonderful if this were documented, if the intention is to support this field for users' modules – it seems a bit dangerous to use a feature that has no documentation.

cc @gmagogsfm
Repository: flutter
Issue: BottomAppBar shape change is not animated
Labels: framework,f: material design,customer: gallery,has reproducible steps,P3,found in release: 3.3,found in release: 3.7,team-design,triaged-design

in the gallery app there's an example of the BottomAppBar with FloatingActionButton in different positions

if we change the FAB posistion, the BottomAppBar shape is animated, but when the shape itself is changed, there's no animation

https://github.com/flutter/gallery/blob/249507bb4fdda8c7e29c7d2b015ddedb467bfb74/lib/demos/material/bottom_app_bar_demo.dart#L139-L142

https://user-images.githubusercontent.com/39104740/109716260-af94e580-7bb5-11eb-98f2-aa7ce29aa2f8.mp4
Repository: godot
Issue: move_and_slide caches physics values between frames
Labels: bug,topic:physics


**Godot version:**
3.2.3

**OS/device including version:**
N/A

**Issue description:**

`move_and_slide` and the related KinematicBody API calls cache values at the point of collision, and they are not updated in the next frame.  I'll demonstrate this using `get_floor_velocity()`, but it also extends to:

* `get_floor_normal()`, `is_on_floor()`, `is_on_wall()` and `is_on_ceiling()`

They are wrong between frames, but technically also wrong on the same frame as well. Since they are only true at the point of collision, they may not be true after it has slid into its final position. For example, it collides with the floor, then it slides far enough that it is no longer above the floor.

Also, due to https://github.com/godotengine/godot-proposals/issues/2332, these values may be an additional frame behind.  Fixes to this problem should take that issue into account.

**Steps to reproduce:**

Use `move_and_slide()` with a velocity value `-get_floor_velocity()`.  Notice that it does not move on sliding platforms now, as this is the value it adds internally.  Now compare the value of `get_floor_velocity()` with the velocity the floor node has in the physics server: `PhysicsServer.body_get_direct_state(floor_node.get_rid()).linear_velocity`. Notice that these values are different.

**Minimal reproduction project:**
[move_and_slide-cached-values.zip](https://github.com/godotengine/godot/files/6071929/move_and_slide-cached-values.zip)

This project plots the difference between `get_floor_velocity()` and the `PhysicsServer.body_get_direct_state(floor_node.get_rid()).linear_velocity` both taken before `move_and_slide()` is called. When the floor is accelerating, these values differ.
Repository: pytorch
Issue: Structured kernels for operators that don't have out= variants
Labels: triaged,module: structured kernels

I was working on #53086 and I realized that structured operators could be useful even when there is no out= variant of an operator in question. This is because you still may have error checking that is common to multiple device implementations of the operator in question. Figure out a syntax for doing this.
Repository: godot
Issue: move_and_slide uses instaneous velocity on rotating platforms resulting in drift
Labels: bug,topic:physics

**Godot version:**

3.2.3.stable


**OS/device including version:**
N/A

**Issue description:**

When `move_and_slide()` is used on a rotating platform, it uses the instantaneous velocity at the point of collision. However, it should use the average velocity it would receive over the given time step:

![velocity due to rotation](https://user-images.githubusercontent.com/79001820/108517916-bb5ded80-7313-11eb-8240-45efc50bd848.png)

Here's a concrete example, that demonstrates the difference in behaviour:

**Instantaneous velocity calculation:**

![sliding off the platform](https://user-images.githubusercontent.com/79001820/108517515-3e327880-7313-11eb-8ffb-5c7559a2bedd.gif)

**Average velocity over delta time step:**

![fixed velocity calculation](https://user-images.githubusercontent.com/79001820/108517330-00cdeb00-7313-11eb-89d5-309d3e402daf.gif)


This issue has been raised in the past (https://github.com/godotengine/godot/issues/35365, https://github.com/godotengine/godot/issues/16450). There it was state this was a correct physical simulation, however kinematic bodies don't under go proper physical simulations and the workarounds provided don't resolve this issue.

Note to get correct calculations in more complex scenarios, it is also necessary to resolve https://github.com/godotengine/godot-proposals/issues/2332 and https://github.com/godotengine/godot/issues/46603.  This is because the centre of rotation can move between frames, and it is necessary to calculate the exact position the two objects have relative to each for velocity calculations to be correct.

**Steps to reproduce:**

Create a KinematicBody that is controlled by `move_and_slide()` and stand on a rotating platform.  Notice that over time the player gets thrown off the side of the platform.

**Minimal reproduction project:**

This project uses the correct velocity calculation. Press <kbd>Q</kbd> to toggle this behaviour on and off.

[rotating-platform-fix.zip](https://github.com/godotengine/godot/files/6072053/rotating-platform-fix.zip)