sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: DISABLED test_tensorpipe_set_default_timeout (__main__.TensorPipeTensorPipeAgentRpcTest)
Labels: high priority,triage review,oncall: distributed,module: flaky-tests,module: rpc,skipped

Platforms: mac

This test was disabled because it is failing on master ([recent examples](http://torch-ci.com/failure/test_tensorpipe_set_default_timeout%2C%20TensorPipeTensorPipeAgentRpcTest)).

cc @ezyang @gchanan @zou3519 @bdhirsh @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @jjlilley @mrzzd
Repository: godot
Issue: Implicit conversion of float literals to double
Labels: discussion,topic:core,topic:codestyle,performance

### Godot version

Godot 3.4.2, Godot 4.0 dev (all current)

### System information

All

### Issue description

Throughout the Godot codebase the de facto standard way of writing float literals has turned out to be as follows:
```
real_t y = 0.5;
real_t x = y * 0.2; 
```
If you instead use the `0.5f` form, this works great when `real_t` is defined as float, but could maybe flag a truncation warning is `real_t` is double (untested).

There is a problem however, in that to preserve accuracy and do exactly as requested, afaik the compiler must treat the `0.5` form as a double. (This could do with independently testing, it could be we are using some compiler switch which prevents this, e.g. `-ffast-math`, but I would rather flag this as a potential problem than assume it isn't.)

If we look at the compiled assembly, using https://godbolt.org/ we can see that using when using 32 bit `real_t`, a double literal results in the compiler having to promote the `real_t` to a double before performing the operation, then convert back afterwards.

This is potentially a needless source of extra calculations in bottleneck code.

See also for example discussion here:
https://stackoverflow.com/questions/7662109/should-we-generally-use-float-literals-for-floats-instead-of-the-simpler-double

### Steps to reproduce

Using godbolt:

```
float test0(float num) {
    return num * 2.3f;
}

float test1(float num) {
    return num * 2.3;
}

double test_d0(double num)
{
    return num * 2.3f;
}

double test_d1(double num)
{
    return num * 2.3;
}
```

Assembly generated with -O3:
```
test0(float):
        mulss   xmm0, DWORD PTR .LC0[rip]
        ret
test1(float):
        cvtss2sd        xmm0, xmm0
        mulsd   xmm0, QWORD PTR .LC1[rip]
        cvtsd2ss        xmm0, xmm0
        ret
test_d0(double):
        mulsd   xmm0, QWORD PTR .LC2[rip]
        ret
test_d1(double):
        mulsd   xmm0, QWORD PTR .LC1[rip]
        ret
.LC0:
        .long   1075000115
.LC1:
        .long   1717986918
        .long   1073899110
.LC2:
        .long   1610612736
        .long   1073899110
```
The assembly shows that in test1 in particular, there is:
1) Conversion from float to double
2) Calculation takes place at 64 bit
2) Conversion back to 32 bit

Whereas, unless the extra precision is required at calculation, the more efficient alternative is shown in test0.
This could potentially be quite important in e.g. matrix operations, or autovectorized code (as 64 bit has half the bandwidth, not to mention the conversions), or on some mobile.

### Minimal reproduction project

N/A. See above.
Repository: godot
Issue: After fix dependencies in a scene, list not changed and button still says "Open anyway"
Labels: enhancement,topic:editor,usability

### Godot version

3.3.4.stable

### System information

Ubuntu

### Issue description

(low priority bug)
A scene has some broken dependencies. You open it, and a dialog appears to allow you to fix the dependencies.
Once you've fixed them all, the button below still says "Open anyway".
It should just say "Open".
Also, the dependencies list does not change in any way. Fixed items could maybe have a check mark or something.
It's a minor "bug" but it can still confuse the user for some seconds, e.g. thinking there is still some stuff to fix or that something went wrong.

### Steps to reproduce

Open the minimal reproduction project.
The dialog to fix dependencies will appear.
Click "Fix dependencies."
Choose "my_theme.tres", which is the original file that had been renamed outside of the editor.
Click "Ok."
The previous dialog still show a button called "Open Anyway" and the list of items stays the same.


### Minimal reproduction project

[FixDepButtonBug.zip](https://github.com/godotengine/godot/files/7797530/FixDepButtonBug.zip)
Repository: rust
Issue: Tracking Issue for `const` `Extend` impls in libcore
Labels: T-libs-api,C-tracking-issue

Feature gate: `#![feature(const_extend)]`

This is a tracking issue for `const` `Extend` impls in libcore.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::collect

impl<A, B, ExtendA, ExtendB> const Extend<(A, B)> for (ExtendA, ExtendB)
where
    ExtendA: ~const Extend<A>,
    ExtendB: ~const Extend<B>,

impl const Extend<()> for ()
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #92433
- [ ] Final comment period (FCP)
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.
Repository: rust
Issue: Tracking Issue for `const` `Iterator` impls and related `const fn`s
Labels: T-libs-api,C-tracking-issue,F-const_trait_impl

Feature gate: `#![feature(const_iter)]`

This is a tracking issue for `const` `Iterator` impls and related `const fn`s.

<!--
Include a short description of the feature.
-->

### Public API

```rust
// core::iter
impl<I: ~const Iterator + ?Sized> const Iterator for &mut I;
impl<I: Iterator> const IntoIterator for I;
impl<B, I: ~const Iterator, F> const Iterator for Map<I, F>
where
    F: ~const FnMut(I::Item) -> B + ~const Drop;

// core::option
impl<T> Option<T> {
    pub const fn iter_mut(&mut self) -> IterMut<'_, T>;
}

impl<T> const IntoIterator for Option<T>;
impl<'a, T> const IntoIterator for &'a Option<T>;
impl<'a, T> const IntoIterator for &'a mut Option<T>;
impl<'a, A> const Iterator for Iter<'a, A>;
impl<'a, A> const Iterator for IterMut<'a, A>;
impl<A> const Iterator for IntoIter<A>;
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Implementation: #106541
- [ ] Final comment period (FCP)
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.
Repository: godot
Issue: Oversampling causes DynamicFont metrics to lock to (onscreen) integer pixel height font sizes
Labels: bug,confirmed,topic:gui

### Godot version

3.x

### System information

Windows

### Issue description

Godot applies font oversampling by changing the font size it asks freetype to render the font with, via `FT_Set_Pixel_Sizes`. But because `FT_Set_Pixel_Sizes` only accepts integer font sizes, this has snowball effects everywhere else in all text flow logic. Everything gets its metrics from freetype, which are based on the floored font size, instead of the theoretical fractional font size. This means that the effective size of the metrics used for cursor advancement and line height (etc) go down between onscreen integer font heights.

This would not be an issue if godot used harfbuzz for all text flow, but AFAIK that's a 4.0 thing. If I had to guess, I'd reckon that the "right" thing to do might be to have two copies of the font loaded in freetype, one with and one without the oversampling adjustment, and to get all metrics (especially advancement, the most critical one) from the non-oversampling-adjusted font, but rendered glyph data from the oversampling-adjusted copy.

### Steps to reproduce

Add a text label with a large-ish (e.g. 32+ pixels) DynamicFont font and a lot of text (preferably enough to linewrap multiple times), enable the `2d` window scaling mode, then run the project and resize the window. Observe that non-linewrapping text stays mostly the same (maybe with some jitter) until it hits a new font pixel height, at which point it completely changes, and that linewrapping text reflows constantly as its size relative to the label it's in keeps changing.

I don't have a minimal reproduction project, but I have something that's probably better, a diff for the `3.x` branch that partially works around this bug to demonstrate that this is indeed where it's coming from, which you can use to compare:

[godot_font_oversampling_demonstration_diff.txt](https://github.com/godotengine/godot/files/7797712/godot_font_oversampling_demonstration_diff.txt)

without diff:

https://user-images.githubusercontent.com/585488/170847459-a3bac2ca-9f65-420b-b2d5-c82a9ead16a4.mp4

with diff:

https://user-images.githubusercontent.com/585488/170847463-8677d5c4-1184-4f84-8798-62b982bfed91.mp4

(this diff is purely for the sake of demonstration, it is not MR-ready. for example, not every usage of the new `oversampling_error` property is correct and it's not used in every place that it should be used in (e.g. it might be a good idea to use it for glyph rect size if the font has filtering enabled). it also doesn't completely fix advancement changing between font sizes when hinting is enabled. it's merely enough to demonstrate the nature of the problem.)

### Minimal reproduction project

_No response_
Repository: godot
Issue: Changing particle gizmo color doesn't have effect until restart
Labels: bug,topic:editor,confirmed,topic:3d,topic:particles

### Godot version

bc2445d

### System information

W10

### Issue description

When you change color for Particle 3D Gizmo, you need to restart editor for the change to have effect. Might be true for other gizmos too.

### Steps to reproduce

1. Create GPUParticles3D node
2. Change Editor Settings -> Editors -> 3D Gizmos -> Gizmo Colors -> Particles to different color
3. Notice it doesn't have effect
4. Restart editor
5. Notice it has effect

### Minimal reproduction project

_No response_
Repository: material-ui
Issue: Popover is too tall. Hardcoded `max-height` ignores `marginThreshold` prop
Labels: new feature,component: Popover

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [x] I have tested the latest version

### Current behavior 😯

Currently when a Popover component is given a marginThreshold prop that differs from 16 (the default value), the popover can exceed the height of the screen because the Popover Paper element has a static style of `max-height: calc(100% - 32px)`. The `32px` here represents `2 * 16` which is twice the default `marginThreshold` value (once for the space at the top and once for the space at the bottom).


The problematic lines are here:
https://github.com/mui-org/material-ui/blob/4c7937336675657fca87481f2fa0991449c15605/packages/mui-material/src/Popover/Popover.js#L90,L91

### Expected behavior 🤔

Instead, the max-height should be calculated dynamically based on the `marginThreshold` prop.

### Steps to reproduce 🕹

### Minimal reproduction case

Minimal reproduction case with a `marginThreshold` of 50 for example and content set to a height of 200vh:
https://codesandbox.io/s/popover-margin-threshold-lmgdl?file=/src/App.js

In this example, if you change the `marginThreshold` back to 16, it no longer exceeds the screen.

---

### Taking into account the anchorEl

As a second improvement, the Popover should ideally also calculate its height based on the anchor origin and the anchorEl given to it. For example, take a look at the following screenshot:

![max-height](https://user-images.githubusercontent.com/7953838/147856857-6af15134-a62f-47f8-968d-262896738242.png)

The max-height should respect the following design if possible. My current workaround is the followinig:

```
const MARGIN_THRESHOLD = 50;
<Popover
      anchorEl={anchorEl}
      sx={{
        maxHeight: `calc(100% - ${MARGIN_THRESHOLD + anchorEl?.getBoundingClientRect().bottom}px)`,
      }}
      marginThreshold={MARGIN_THRESHOLD}
      // ... other props
      />
```

### Context 🔦

_No response_

### Your environment 🌎

Tested on Chrome 96. Though this isn't a browser issue, it's a bug in the height calculation logic.

<details>
  <summary>`npx @mui/envinfo`</summary>

```
  System:
    OS: Linux 5.10 Ubuntu 20.04 LTS (Focal Fossa)
  Binaries:
    Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node
    Yarn: Not Found
    npm: 8.1.0 - ~/.nvm/versions/node/v16.13.0/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    @emotion/react: ^11.7.1 => 11.7.1 
    @emotion/styled: ^11.6.0 => 11.6.0 
    @mui/base:  5.0.0-alpha.60 
    @mui/icons-material: ^5.2.5 => 5.2.5 
    @mui/lab: ^5.0.0-alpha.62 => 5.0.0-alpha.62 
    @mui/material: ^5.2.4 => 5.2.4 
    @mui/private-theming:  5.2.3 
    @mui/styled-engine:  5.2.6 
    @mui/system:  5.2.4 
    @mui/types:  7.1.0 
    @mui/utils:  5.2.3 
    @types/react: 17.0.37 => 17.0.37 
    react: 17.0.2 => 17.0.2 
    react-dom: 17.0.2 => 17.0.2 
    typescript: 4.5.4 => 4.5.4 
```
</details>
Repository: yt-dlp
Issue: Stable speed and ETA in progress
Labels: enhancement,core:downloader

### Checklist

- [X] I'm reporting a feature request
- [X] I've verified that I'm running yt-dlp version **2021.12.27**. ([update instructions](https://github.com/yt-dlp/yt-dlp#update))
- [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)

### Description

When download a video, the speed rushes from very slow up to my maximum speed. And it does so all the time, which of course also makes the remaining time jumping like hell.

For example when I downloaded https://www.youtube.com/watch?v=5YLYFxoKVLg it can be showing e.g. to download with 2MiB/s and still needing 11 minutes to download:
![slow](https://user-images.githubusercontent.com/72162369/147858199-feba809e-8c07-4684-8cd3-bd3ce6e69cf8.png)

and e.g. 14.75MiB/s and a remaining time of less than two minutes.
![fast](https://user-images.githubusercontent.com/72162369/147858198-ac218d6c-99ee-48ab-9a12-d5b5a23568e2.png)

In the end the video was still downloaded within a few minutes though. Is it possible to get some kind of average speed? It's just a cosmetic thing, but I thought I ask.
Repository: create-react-app
Issue: "type": "module" with React. [module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"']
Labels: needs triage

Hello All. 
Currently I am trying to set up a backend in my react project and im running into issues trying to use ES 6 imports. 

![ReactModuletype](https://user-images.githubusercontent.com/35965702/147858367-8e3ee4ad-c027-4b36-97be-ea811273540b.png)

I went back and created a blank react app and added "type": "module" into my package.json and my server.js can now use ES 6 imports when I run nodemon server.js. However now When i try to npm start my react project I get the error.
```
Failed to compile.

Module not found: Error: Can't resolve './App' in '/home/user/Desktop/WebDev/React/temp/merntemplate/src'
Did you mean 'App.js'?
BREAKING CHANGE: The request './App' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

ERROR in ./src/index.js 8:0-24
Module not found: Error: Can't resolve './App' in '/home/user/Desktop/WebDev/React/temp/merntemplate/src'
Did you mean 'App.js'?
BREAKING CHANGE: The request './App' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
```
When I remove the "type": "module from my pakcage.json and run npm start the react apps works fine again however my server now cant use import and can only use require. I know there are other ways besides using module type like making my server.js to server.mjs or any file i want to use esm however I have always used type module when cloning templates but now that I am doing it on my own I am running into this issue and can't find anything on the web on how to use "type": "module" in a react project so that I dont have to name all my backend files .mjs.
Repository: deno
Issue: Tweak ICU data build settings to include more locale information
Labels: deno_core,chore

In looking at Deno, I discovered that its `Intl` seems to share Chrome's non-support for Icelandic.

Since both Node and Edge _do_ support Icelandic, it's clearly not a limitation of V8 as such. In Chrome's case, Google appear to specifically disable support for locales that don't have a full interface translation, which seems like a silly thing to do for a browser. Does Deno inherit that butchered ICU for some reason?
Repository: godot
Issue: Godot 3.4.x breaks all prior versions of Area2D because it changes body from int to RID
Labels: discussion,topic:physics

### Godot version

3.4.2

### System information

Linux

### Issue description

In all version of Godot the signature for body entered is this:

```
func _x(_body_id: int, _body: Node, _body_shape: int, local_shape: int) -> void:
```

In 3.4 it has changed to using RID

```
func _x(_body_id: RID, _body: Node, _body_shape: int, local_shape: int) -> void:
```

i.e. now using RID. This then fails to trigger any signals because the parameters do not match, so all signals fail to trigger.

I suspect everywhere that also changes to RID will also break too.

Observe the video.

https://user-images.githubusercontent.com/12863685/147861566-965a8414-7fab-41f2-9aa7-db5b5acccc5c.mp4



If this is known/documented, where is it and is there a list of all places where this/similar change will also break?

### Steps to reproduce

1. Use a body entered area2d from 3.3
2. Debug and the method never calls
3. Change to RID manually and it works

### Minimal reproduction project

_No response_
Repository: flutter
Issue: Test key simulator doesn't work with uppercase characters
Labels: a: tests,a: text input,c: new feature,framework,a: desktop,P3,team-text-input,triaged-text-input

I'm using `WidgetTester`'s `sendKeyDownEvent` and `sendKeyEvent` to simulate hardware interaction with a custom text field implementation. For example, typing "Hello, World!" into the text field using individual hardware keyboard keys.

It looks like the keyboard simulator for tests does not support uppercase characters:
https://github.com/flutter/flutter/blob/5a862ebecdb14ad389cdce9cd7f79470ece27a7f/packages/flutter_test/lib/src/event_simulation.dart#L31

What I would expect is that if the shift key is currently pressed in the simulator, then the resolved character would be uppercase. This is also true for the various non-alpha-numeric characters on the keyboard as well.

Flutter version:
```
Flutter 2.8.1 • channel stable • git@github.com:flutter/flutter.git
Framework • revision 77d935af4d (2 weeks ago) • 2021-12-16 08:37:33 -0800
Engine • revision 890a5fca2e
Tools • Dart 2.15.1
```

Here's the workhorse code for how I'm attempting to use the simulator to enter text:

```dart
      // Note: the keyCombo is just a data structure that contains the logical key and whether or not shift
      //            should be pressed. I have my own mappings for default characters vs shift characters.
      for (int i = 0; i < plainText.length; i += 1) {
        final character = plainText[i];
        final keyCombo = _keyCodeFromCharacter(character);

        if (keyCombo.isShiftPressed) {
          await sendKeyDownEvent(LogicalKeyboardKey.shift, platform: 'macos');
        }

        await sendKeyEvent(keyCombo.key, platform: 'macos');

        if (keyCombo.isShiftPressed) {
          await sendKeyUpEvent(LogicalKeyboardKey.shift, platform: 'macos');
        }
      }
```
Repository: flutter
Issue: [MacOS] LogicalKeyboard involving shift key throws error: Physical key for LogicalKeyboardKey not found in macos physical key map
Labels: a: tests,a: text input,framework,a: desktop,has reproducible steps,P2,found in release: 2.8,found in release: 2.9,team-text-input,triaged-text-input

When I try to press the exclamation logical keyboard key using `WidgetTester`, I get the following error:

```
Error: 'package:flutter_test/src/event_simulation.dart': Failed assertion: line 243 pos 12: 'result != null': Physical key for LogicalKeyboardKey#00021(keyId: "0x00000021", keyLabel: "!", debugName: "Exclamation") not found in macos physical key map
```

Flutter version:
```
Flutter 2.8.1 • channel stable • git@github.com:flutter/flutter.git
Framework • revision 77d935af4d (2 weeks ago) • 2021-12-16 08:37:33 -0800
Engine • revision 890a5fca2e
Tools • Dart 2.15.1
```