sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: InteractiveViewer doesn't respect minScale
Labels: framework,has reproducible steps,P2,found in release: 3.0,found in release: 3.1,team-framework,triaged-framework

`InteractiveViewer` doesn't respect `minScale` when the content is smaller than the viewport.

Reproduction steps:

1. Display a widget as a child within an `InteractiveViewer` that's smaller than the viewport
2. Notice that the child initially displays at the expected size
3. Slightly pinch to scale the content

Expect result: The content gradually scales up as the user pinches to zoom

Actual result: The content immediately becomes as large as the viewport

Code sample:
```dart
import 'package:flutter/material.dart';

void main() {
  runApp(
    const MaterialApp(
      home: Scaffold(
        body: ScaleBug(),
      ),
    ),
  );
}

class ScaleBug extends StatelessWidget {
  const ScaleBug({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return DecoratedBox(
      decoration: BoxDecoration(
        color: Colors.grey.shade800,
      ),
      child: InteractiveViewer(
        constrained: false,
        minScale: 0.1,
        maxScale: 4.0,
        child: Container(
          width: 500,
          height: 500,
          color: Colors.white,
        ),
      ),
    );
  }
}
```

Flutter version:
```
Flutter 3.0.4 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 85684f9300 (3 weeks ago) • 2022-06-30 13:22:47 -0700
Engine • revision 6ba2af10bb
Tools • Dart 2.17.5 • DevTools 2.12.2
```
Repository: angular
Issue: Reactive form control `root` points to nothing or itself.
Labels: area: forms,P4,bug

### Which @angular/* package(s) are the source of the bug?

forms

### Is this a regression?

No

### Description

We need to have a validator for simple `FormControl` to compare multiple `FormGroup` values as well. Trying to reach that in two ways:

1. Use `control.parent.parent.parent` (doesn't look good);
2. Use `control.root.get(*path*)`.

However, both options have bug. Let's talk about latter one. `root` is either falsy or equal to `control` (points to itself) value. So, we had to add such workaround

```ts
    // In case form hasn't initialized
    if (control.root == null || control.root === control) {
        return null;
    }

    *Validation logic here*
```

But that doesn't work as expected because now form controls aren't validated on form init because of such workaround. How can we avoid such behavior?

### Please provide a link to a minimal reproduction of the bug

_No response_

### Please provide the exception or error you saw

_No response_

### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 14.0.4
Node: 14.17.5
Package Manager: yarn 1.22.18
OS: win32 x64

Angular: 14.0.4
... animations, cdk, cli, common, compiler, compiler-cli, core
... forms, language-service, material, platform-browser
... platform-browser-dynamic, router

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.1400.4
@angular-devkit/build-angular      14.0.4
@angular-devkit/build-ng-packagr   0.1002.0
@angular-devkit/core               14.0.4
@angular-devkit/schematics         14.0.4
@angular/flex-layout               14.0.0-beta.40
@schematics/angular                14.0.4
rxjs                               7.5.5
typescript                         4.6.3
```


### Anything else?

_No response_
Repository: godot
Issue: 2D lights are reduced to tiny squares when shadow buffer size is > 1024 and no LightOccluder2Ds present
Labels: bug,topic:rendering,needs testing,topic:2d

### Godot version

3.5.rc6.mono.official, but also occurs on 3.4.4.stable.mono.official

### System information

Windows 11, occurs on both GLES2 and GLES3, Radeon RX Vega 8 (Ryzen 5800U)

### Issue description

When using a Light2D with shadows enabled and a shadow buffer size > 1024 (like the default 2048), lights look like this:
![image](https://user-images.githubusercontent.com/87674058/179612374-78318566-cb03-4731-bd81-1c2e7ddd851b.png)
instead of like this:
![image](https://user-images.githubusercontent.com/87674058/179612567-8d3da068-df8d-472a-9904-1ee5cec3df2c.png)
Both images above have two lights, but the same thing happens with only one.

~~What's weird is that this issue only appeared yesterday, seemingly at random, yet now happens even across reboots, new projects, and deletion of Godot's folders in AppData. Hopefully this is reproducible for others...~~

EDIT: I think I've now figured out the exact cause: this seems to happen when no LightOccluder2Ds are present.

### Steps to reproduce

1. Create any visible Node2D as a base for the light to modulate.
2. Create a Light2D and set a texture
3. Enable shadows
The light should be nearly invisible, as above
4. Lower shadow buffer size to 1024
The light should now be fixed

### Minimal reproduction project

[Light2DTest.zip](https://github.com/godotengine/godot/files/9135642/Light2DTest.zip)
Repository: pytorch
Issue: [packaging] Conda install missing python local version label (+cu123 or +cpu)
Labels: oncall: releng,triaged

### 🐛 Describe the bug

I'm installing pytorch through Conda then using poetry in my projects.
The issue is that when I use the recommended installation method for pytorch (`conda install -y -c pytorch pytorch==1.11.0 cudatoolkit=11.3`), I end up with:
`conda list`: `pytorch 1.11.0 py3.7_cuda11.3_cudnn8.2.0_0 pytorch`.
`pip list`: `torch 1.11.0`.

My issue is that conda installed torch `1.11.0+cu113` but did not include the local version label (`+cu113`), so then when I use pip or poetry, it thinks it needs to replace torch `1.11.0` by `1.11.0+cu113`.

I use this dirty hack to fix the package version of torch:
```bash
mv /[...]/conda/lib/python3.7/site-packages/torch-1.11.0-py3.7.egg-info/ /[...]/conda/lib/python3.7/site-packages/torch-1.11.0+cu113-py3.7.egg-info/
sed -i -E 's/(Version: [^+]+)\n/\1+cu113\n/' /opt/conda/lib/python3.7/site-packages/torch-1.11.0+cu113-py3.7.egg-info/PKG-INFO
```

### Versions

PyTorch version: 1.11.0
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.3 LTS (x86_64)
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.17

Python version: 3.7.13 (default, Mar 29 2022, 02:18:16)  [GCC 7.5.0] (64-bit runtime)
Repository: flutter
Issue: [conductor] Not auto-incrementing new betas
Labels: P3,team-release,triaged-release

I tried to cut a new beta release with:
```
./dev/conductor/bin/conductor start  \
  --candidate-branch=flutter-3.2-candidate.5 \
  --release-channel=beta  \
  --framework-mirror=git@github.com:caseyhillers/flutter.git \
  --engine-mirror=git@github.com:caseyhillers/engine.git \
  --dart-revision=e020f8158a4ad7bae2584f5789fddd927022eb07 \
```

However, Conductor had some issues picking up the new version.

```
Repository framework is checked out at revision "08457a3d7ef81cec0662bce6f6ed6db37b6d9b8c".
Parsed version 3.0.0-0.0.pre.1600 has a different y value than candidate branch flutter-3.2-candidate.5
About to tag the release candidate branch branchpoint of 08457a3d7ef81cec0662bce6f6ed6db37b6d9b8c as 3.2.0-5.0.pre and push it to git@github.com:flutter/flutter.git. Is this correct? (y/n) n
```

My expectation is that the conductor would've realize the candidate branch has changed, and it can increment Y to create `3.3.0-0.0.pre` as the release version.

As a workaround, I added `--version-override` with the expected values.
Repository: flutter
Issue: Consider providing the necessary semantics for denoting tab bars for accessibility
Labels: c: new feature,platform-android,platform-ios,framework,engine,a: accessibility,platform-web,P1,customer: castaway,team-engine,triaged-engine

Presently, there seems to be no way to mark up custom tab bars with accessibility semantics. As a result, developers resort to simulating them by "stuffing" the accessibility lable with announcements such as:
"Notifications, tab 1 of 3"
Etc.

iOS, Android and web provide ways to denote tab bars to match native accessibility APIs for these platforms. SOme useful resources below:
- iOS: [iOS accessibility tabBar trait](https://developer.apple.com/documentation/uikit/uiaccessibilitytraits/1648592-tabbar), [real-life implementation](https://www.basbroek.nl/custom-tab-bar-accessibility).
- Android: setRoleDescription API
- Web: [ARIA tabpannel pattern](https://www.w3.org/WAI/ARIA/apg/patterns/tabpanel/)

/CC @goderbauer
Repository: go
Issue: net/http: ServeFile may be insufficiently hardened against misuse
Labels: NeedsInvestigation

The `http.ServeFile` function replies to a request with the contents of a named file on the local filesystem.

As a hardening measure, `ServeFile` attempts to guard against cases where it is called with an untrusted input as the source filename. In particular, `ServeFile` rejects requests where `r.URL.Path` contains a `..` path element to protect callers who might use `r.URL.Path` as a component of the filename.

This does not protect users who use a query parameter to construct the filename.

Perhaps we could additionally harden `ServeFile` by checking for `..` elements anywhere in the request URI, including query parameters. (What about form values? Would we check them too?)

Or perhaps there are some other measures we could take to harden `ServeFile` against misuse.
Repository: three.js
Issue: Reflector (WebGLRenderTarget): Fog Color problem in sRGB outputEncoding
Labels: Suggestion

<!-- Ignoring this template may result in your bug report getting deleted -->

From https://github.com/mozilla/hubs/issues/5572

**Describe the bug**

Fog color in `Reflector` (`WebGLRenderTarget`) can mismatch the one in the main scene.

I made an online example to show the problem.

https://raw.githack.com/takahirox/three.js/MirrorFogExample/examples/webgl_mirror_fog.html

**Screenshots**

sRGB output encoding + fog. Fog color in the reflector looks brighter than the one in the main scene. (See the green wall.)

![image](https://user-images.githubusercontent.com/7637832/179628595-d1d35be0-892e-4a6c-8bc4-87b8f9f00411.png)

sRGB output encoding + no fog. Color in the reflector looks the same as the one in the main scene.

![image](https://user-images.githubusercontent.com/7637832/179628919-9d9ba6fb-f1e9-4ab7-918b-ff678b49d146.png)

Linear output encoding + fog. Fog color in the reflector looks the same as the one in the main scene.

![image](https://user-images.githubusercontent.com/7637832/179629040-070f2049-842d-4154-92ea-7a3e906c711c.png)

***Live example***

https://raw.githack.com/takahirox/three.js/MirrorFogExample/examples/webgl_mirror_fog.html

**Expected behavior**

Fog color in the reflector looks same as the one in the main scene even in sRGB outputEncoding.

**Platform:**

 - Device: Desktop
 - OS: Windows 10
 - Browser: Chrome
 - Three.js version: dev
Repository: pytorch
Issue: Register refs for CompositeImplicitAutograd ops as decompositions
Labels: triaged,module: primTorch

There are some ops that explicitly don't have decompositions registered because they are CompositeImplicitAutograd

https://github.com/pytorch/pytorch/blob/bf36d8b987b2ef2fd9cb26bae3acc29c03b05072/test/test_ops.py#L1538-L1567

However, it is still possible to observe them in inference mode (or possibly if CompositeImplicitAutograd is overridden by a different kernel)
```python
from torch.testing._internal.logging_tensor import capture_logs_with_logging_tensor_mode

with capture_logs_with_logging_tensor_mode() as logs:
    with torch.inference_mode():
        a = torch.ones(2, 2)
        a.reshape(-1)

print('\n'.join(logs))
# $0 = torch._ops.aten.ones.default([2, 2], dtype=torch.float32, device=device(type='cpu'), pin_memory=False)
# $1 = torch._ops.aten.reshape.default($0, [-1])
```
When registering these ops as decompositions, to appease the test that detects that we have indeed registered it in the table, we may need to specify what op it decomposes into:

https://github.com/pytorch/pytorch/blob/443b13fa232c52bddf20726a6da040d8957a3c49/torch/testing/_internal/common_methods_invocations.py#L744-L745

cc @ezyang @mruberry @ngimel
Repository: godot
Issue: CanvasItems with modulate.a values below 0.01 don't render at all regardless of material
Labels: bug,topic:rendering,confirmed,topic:2d

### Godot version

3.5.rc6.mono, but it is reproducible on all 4.x and 3.x builds tested

### System information

Windows 10 Pro, Intel UHD Graphics 620 (27.20.100.8854), all rendering backends

### Issue description

A CanvasItem that has a modulate alpha value below 0.01 (or 2/255) will not render whatsoever, even if the material and/or shader specifically tells it to do so.
This is especially frustrating for cases where premultiplied blending is used to simulate additive blending by setting the alpha component to 0.

### Steps to reproduce

1. Create a CanvasItem node, like a Sprite(2D).
2. Attach a material with premultiplied alpha blending (AND/OR a shader that sets the alpha component of COLOR to 1).
3. Adjust the modulate alpha in the editor; below a threshold (0.01 or 2/255) the item will not appear at all.

### Minimal reproduction project

[Alpha Bug.zip](https://github.com/godotengine/godot/files/9136363/Alpha.Bug.zip)
Repository: flutter
Issue: Invariant violation in release mode is hard to debug
Labels: framework,dependency: dart,a: debugging,customer: money (g3),P3,team-framework,triaged-framework

Internal: b/292548384

The framework has many asserts that guard against invariant violation when running in debug mode.

If an application is released to the wild, some edge case may violate the invariant and dump a stack trace that provides little clue to the developer about how to identify the violation. For example, accessing `size` in `layout` incorrectly may result in a stack trace like 

```
Thread 0 MAIN THREAD_CastError: Null check operator used on a null value
at RenderProxyBoxMixin.performLayout    (box.dart:2023)
at RenderObject.layout    (object.dart:2054)
at RenderBox.layout    (box.dart:2418)
at RenderProxyBoxMixin.performLayout    (proxy_box.dart:122)
at RenderObject.layout    (object.dart:2054)
at RenderBox.layout    (box.dart:2418)
at RenderProxyBoxMixin.performLayout    (proxy_box.dart:122)
at RenderObject.layout    (object.dart:2054)
```

We currently store `debugActivePaint` and `debugActiveLayout` in debug mode, but if we stored something like that in release mode we could print better errors here that might give developers a better clue about where to look when a failure in the wild happens like this.

Developers cannot use the `debugDump*` methods in release mode in these cases, as they are unavailable/print nothing at all.

One other potentially interesting option is if Dart could somehow provide an "even more expensive" `StackTrace.toString` that includes the concrete runtime type instead of/in addition to the actual source location - I'm not sure if that's really feasible or not though (@a-siva @rmacnak-google would know).

The main goal here is to help developers act on crash reports from the wild - the above stack is based on an actual crash report for customer: money. They do not know how to further act on this crash because the entire stack is in framework code - they don't even know if the bug is in the framework or in their own app.

@goderbauer @Hixie @jacob314
Repository: PowerToys
Issue: Palm Check/Touch Pad Insulator
Labels: Idea-New PowerToy,Needs-Triage

### Description of the new feature / enhancement

Disable the touch pad while typing. The Windows option to lower sensitivity of the touch pad does not work well. And, now that laptop touch pads are gigantic, my palms cannot avoid touching the touch pad. Each time my palm inadvertently touches the touch pad, my cursor moves and the text I'm typing appears in a different place than intended. Worse yet, sometimes both palms touch and I accidentally highlight and type over several sentences at a time. It's a nightmare to draft and edit long letters and emails. Disabling the touch pad while typing would be a great addition. 

### Scenario when this would be used?

This tool will be used primarily on laptops with touch pads to prevent inadvertent touches of the touch pad from moving the cursor while typing. 

### Supporting information

_No response_
Repository: flutter
Issue: [video_player] Standardize support for "infinite" (live) streams.
Labels: platform-android,platform-ios,p: video_player,package,team-ecosystem,P2,triaged-ecosystem

## Use case

The current implementation for the video player plugin has some problems with live streams (videos with "infinite"/unknown/unset duration).

### Cross-platform TIME_UNSET 

TIME_UNSET is the value used as the "length" of a live video. Its current value [comes from ExoPlayer2](https://github.com/flutter/plugins/blob/28eff0a8c167d146d73d62aa21a7d93d95bc2578/packages/video_player/video_player_android/android/src/main/java/io/flutter/plugins/videoplayer/VideoPlayer.java#L291) directly ([C.TIME_UNSET](https://exoplayer.dev/doc/reference/constant-values.html#com.google.android.exoplayer2.C.TIME_UNSET)). They had [good reasons to pick that value](https://github.com/google/ExoPlayer/commit/1579b68cf63c0c3c2be310ce3c9e8caf933c7a99).

The [same value was reused](https://github.com/flutter/plugins/blob/a9d2381908cf7adf899d0fcec727f9968fbac01e/packages/video_player/video_player_avfoundation/ios/Classes/FLTVideoPlayerPlugin.m#L114-L119) when improving the live video features in the iOS implementation, so both platforms would behave the same.

When the Web platform attempted to reuse that same magic value; it was too "wide" to be represented exactly by JavaScript, so we needed to use [another one](https://github.com/flutter/plugins/pull/6101#issuecomment-1188499016).

* [ ] **Ensure that all the mobile implementations start returning what the web is returning:** `-(2^53) + 2`, or `-9007199254740990`. Note: **this is a breaking change!**

### Provided UI Widgets

`package:video_player` provides a bunch of Widgets that render different parts of the UI of a Video player, like the `_VideoScrubber`, the `VideoProgressIndicator` (and maybe others).

Currently, they all seem to behave as if the `duration` of the video was always finite, and positive. 

* [ ] **Update UI Widgets to support `TIME_UNSET` durations.**

### Player logic

Most of the player logic assumes that the video has a finite duration, and uses the `duration` coming from the video controller to do things like:

* handle the `VideoEventType.completed` event to seek "to the end"
* validate if a video can be `seekTo`'d to a given position (only if `0 < position < duration`)

Finally, 

* [ ] **Check that the player logic handles well `TIME_UNSET` durations.**
Repository: godot
Issue: move_and_slide() changes x and z trajectory when climbing slopes that count as floors
Labels: bug,confirmed,topic:physics,topic:3d

### Godot version

4.0 alpha 12

### System information

Windows 11, Vulkan, Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz   2.30 GHz

### Issue description

Moving up a slope that is within the `floor_max_angle` using `move_and_slide()` behaves unlike any primitive movement system in other game engines. Instead of simply adjusting the y velocity to keep up the slope, it slightly adjusts the x and z velocities. 

The expected behavior would be that climbing a slope that counts as the "floor" would have zero impact on your x and z trajectory, that it would simply adjust your Y velocity to climb the slope. This behavior is expected because this behavior is what the basic character controller does in both Unity and Unreal Engine, as well as in the Source engine. (Replicate steps 3 to 7 on these engines to see)

I've been trying to script a workaround for this since Godot 3. The closest I've gotten to fixing this was [this](https://github.com/Gamepro5/Custom_Godot_3D_KinematicBody_Controller/blob/main/KinematicBody.gd), but there were some collision detection issues as it was still using the bullet physics engine. This issues seems to be too deeply engrained into how `move_and_slide()` for me to find a workaround.


https://user-images.githubusercontent.com/23440295/179820793-29991123-d09f-463f-bdea-65c6f7b388ee.mp4

### Steps to reproduce

1. Open the project
2. Click Play
3. Climb the slope, position yourself such that your center of the screen (indicated with the visible collision boxes option) is lined up with the top corner of any slope.
4. Let go of your mouse, do not change your rotation
5. Press S to go down the slope
6. Press W to go up the slope again
7. Observe as you are not lined up with the corner as you once were

### Minimal reproduction project

[Example.zip](https://github.com/godotengine/godot/files/9136925/Example.zip)
Repository: pytorch
Issue: Provide an option to disable CUDA_GCC_VERSIONS
Labels: module: build,triaged

### 🚀 The feature, motivation and pitch

I really understand the motivations of recent additions to CUDA_GCC_VERSIONS that were done in
* https://github.com/pytorch/pytorch/commit/86deecd7be248016d413e9ad6f5527a70c88b454
* https://github.com/pytorch/pytorch/pull/63230

I do think they are a step in the right direction toward improving the situation (xref https://github.com/pytorch/pytorch/issues/55267)

I'm wondering if you could add an option, as an environment variable, for us to ignore it. The motivation is that I believe that it is  possible to patch up the GCC 10 compiler with a small patch to help nvidia compatibility.

https://github.com/conda-forge/ctng-compilers-feedstock/blob/main/recipe/meta.yaml#L22=

### Alternatives

I can patch things out.... However, I would rather have the override done by other packagers that assert they know what they are doing.

You can also patch things out with a sed command
```
sed -i '/ (MINIMUM_GCC_VERSION,/d' ${SP_DIR}/torch/utils/cpp_extension.py
```

### Additional context

The other motivation is that soon enough, the GCC 11 compilers should be compatible with nvidia.

I also believe that 10.4 is compatible with the nvcc

cc @malfet @seemethere
Repository: pytorch
Issue: Python operator registration API for subclasses
Labels: feature,triaged,module: dispatch,module: __torch_dispatch__

### 🚀 The feature, motivation and pitch

We have python op registration by @anjali411 but this is only allowed for dispatch keys. A nice extension would be to allow tensor subclasses to be passed in lieu of dispatch key and get the same behavior. This would be an alternative to defining `__torch_dispatch__` but would have better performance in the passthrough case as we could bypass calling into Python in that case.

### Alternatives

_No response_

### Additional context

_No response_

cc @Chillee @ezyang @zou3519 @albanD @samdow