sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: 'Child windows can handle touches' in android_views integration tests is Flaky
Labels: team,P2,team-android,triaged-android

'Child windows can handle touches' frequently hangs and times out when being run on a LUCI android emulator.

https://github.com/flutter/flutter/pull/88475 skips the test to facilitate unblocking android emulators work.

Example hang: https://ci.chromium.org/raw/build/logs.chromium.org/flutter/led/garyq_google.com/6c3e75ca2b5014173f3126d6095708323142cc6241136a26cbd3e6d559869c0d/+/build.proto?server=chromium-swarm.appspot.com

```
...
00:25 [32m+1[0m: WindowManager AlertDialog from platform view context[0m

I/OpenGLRenderer( 8314): Davey! duration=723ms; Flags=1, FrameTimelineVsyncId=9571, IntendedVsync=663227214493, Vsync=663427214485, InputEventId=0, HandleInputStart=663432203139, AnimationStart=663432207762, PerformTraversalsStart=663444189307, DrawStart=663821741843, FrameDeadline=663243881159, FrameInterval=663431961068, FrameStartTime=16666666, SyncQueued=663895669690, SyncStart=663899993740, IssueDrawCommandsStart=663902299290, SwapBuffers=663928317509, FrameCompleted=663955107432, DequeueBufferDuration=119696, QueueBufferDuration=17406567, GpuCompleted=663954330753, SwapBuffersCompleted=663955107432, DisplayPresentTime=0, 
VMServiceFlutterDriver: waitFor message is taking a long time to complete...
D/EGL_emulation( 8314): app_time_stats: avg=10201.40ms min=10201.40ms max=10201.40ms count=1
D/CompatibilityChangeReporter( 8314): Compat change id reported: 171228096; UID 10146; state: ENABLED
I/Choreographer( 8314): Skipped 40 frames!  The application may be doing too much work on its main thread.
I/OpenGLRenderer( 8314): Davey! duration=1114ms; Flags=1, FrameTimelineVsyncId=9595, IntendedVsync=674443880711, Vsync=674827214029, InputEventId=0, HandleInputStart=674835633206, AnimationStart=674835637638, PerformTraversalsStart=674843837804, DrawStart=675232192713, FrameDeadline=674460547377, FrameInterval=674835245575, FrameStartTime=16666666, SyncQueued=675277614041, SyncStart=675278999279, IssueDrawCommandsStart=675280551348, SwapBuffers=675393633353, FrameCompleted=675559452220, DequeueBufferDuration=198556, QueueBufferDuration=14986383, GpuCompleted=675558372845, SwapBuffersCompleted=675559452220, DisplayPresentTime=0, 
D/EGL_emulation( 8314): app_time_stats: avg=2937.31ms min=516.16ms max=5358.47ms count=2
00:37 [32m+2[0m: WindowManager Child windows can handle touches[0m

D/EGL_emulation( 8314): app_time_stats: avg=2028.14ms min=234.10ms max=3822.18ms count=2
D/EGL_emulation( 8314): app_time_stats: avg=721.95ms min=320.49ms max=1123.40ms count=2
VMServiceFlutterDriver: get_text message is taking a long time to complete...
```
Repository: godot
Issue: No editor errors when calling non-existent functions or getting non-existent properties of another script
Labels: bug,topic:gdscript,topic:editor

### Godot version

3.3.2, 3.2.3

### System information

Windows

### Issue description

There are no errors in editor when I try to call non-existent functions or get/set non-existent 
properties of another script.
This is unexpected because the script is preloaded.
And this is annoing when creating tool scripts and plugins

### Steps to reproduce

new_script.gd:
```gdscript
extends Node
```
control.gd (main script):
```gdscript
extends Control

const NewScript: = preload("res://new_script.gd")

func _ready():
	NewScript.nonexistent_static_function()
	NewScript.nonexistent_const
	var  new_node:NewScript = NewScript.new()
	new_node.nonexistent_function()
	new_node.nonexistent_property
```

### Minimal reproduction project

_No response_
Repository: godot
Issue: Image function save_png is extremely slow
Labels: enhancement,topic:core,performance

### Godot version

3.3.2.stable

### System information

Zorin OS 16 (Ubuntu 20.04 LTS) Ryzen 5 2600

### Issue description

I need to save the screen as a png every frame for a utility I'm working on.
Just the code below is taking 60-100 msecs to run. The first two lines are taking 20-30 msecs to run and saving the png is taking ~50 msecs (timed in GDscript and with the debugger). The performance is poor in Godot on WINE too. Just tested on 4.0 as well and the problem persists there too.

```
var image: Image = get_viewport().get_texture().get_data()
image.flip_y()
image.save_png(get_full_image_path())
```

I'm not sure if this is a bug or a limitation, but it seems to me that saving a png shouldn't be this performance-intensive.

### Steps to reproduce

Put the code above in the _process function with a valid path.

### Minimal reproduction project

Use the above code.
Repository: flutter
Issue: Update the PaintingStyle.stroke documentation to indicate it is only for shapes/paths.
Labels: engine,d: api docs,has reproducible steps,P2,found in release: 2.2,found in release: 2.5,team-engine,triaged-engine

If I want to draw a set of vertices, the resulting triangles are filled every time. Even by setting the style of the paint to PaintingStyle.stroke, flutter wont just draw the outline of the resulting triangle. Does anyone know how to do this?
Repository: vscode
Issue: Allow `showOpenDialog` to open local files 
Labels: feature-request,api,api-proposal,simple-file-dialog

In the demo in https://github.com/microsoft/vscode-internalbacklog/issues/2178#issuecomment-901514989, I had to manually create a file in the web workspace since I couldn't figure out a way to get `vscode.window.showOpenDialog` to open a file on the user's machine. Rob suggested that adding a `file:///` URI as the `defaultUri` might work, but it doesn't.

Is opening a local file in this way already possible, and if not could we add a way for it to happen, perhaps using the defaultUri as Rob suggested?
Repository: godot
Issue: [Bullet] Gravity is not applied on RigidBody when rotated through transform change
Labels: bug,topic:physics

### Godot version

3.3.2 stable

### System information

Windows 10 GLES2

### Issue description

In godot, an area object can override the gravity in a collision shape.

However when there's anything in the _physics_process(delta) altering the location or orientation to the rigidbody, the area gravity will no longer work.

If set to GLES3, the .physics_process(delta) can be called to make the area gravity work again, however if set to GLES2, it will say Nonexistent function with both .physics_process(delta) or ._physics_process(delta)

```
func _physics_process(delta):
    .physics_process(delta)   # notice this will make it work in GLES3
#   doing anything setting orientation here, the area gravity will disappear
#   self.rotate(Vector3.FORWARD, deg2rad(5))  # removing this and the area gravity will work
    pass
```

What's the equivalent of that function in base class call in GLES2. As using GLES3 will be too slow on Android. Or do you just hardcode the gravity behavior using enter and exit into the rigidbody itself. (Statements like applyforce or impulse would not break the interaction, however the use case I had involving some teleportation interaction and setting the orientation of the rigidbody)

### Steps to reproduce

* Set global gravity to 0.0 in project settings (optional, just easy to debug)
* Properly set a area with "space override:replace"
* Have code that manipulate position/rotation in _physics_process in the rigidbody within the area
* Add .physics_process(delta) in GLES 3 will make it work
* Set to GLES 2 and .physics_process(delta) becomes an invalid function that will nullify the area gravity settings

### Minimal reproduction project

[TestAreaGravity.zip](https://github.com/godotengine/godot/files/7011324/TestAreaGravity.zip)
Repository: go
Issue: cmd/go: using newer standard library APIs with an incompatible go version in go.mod does not produce error 
Labels: NeedsInvestigation,GoCommand

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/brendan/.cache/go-build"
GOENV="/home/brendan/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/brendan/go/pkg/mod"
GOOS="linux"
GOPATH="/home/brendan/go"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/brendan/git/go-mod-time-version/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2597690025=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
When using standard library APIs added in 1.17 (`Time.UnixMilli()` in my case), I had hoped that the toolchain would ask me to update the `go` directive in the go mod file, exactly as it did when adding `go:embed` directives.

reproduction case: https://github.com/bmon/go-mod-time-version/tree/75f34ebbfdc044550c5577a7aef3b86fc7547216

```shell
$ cat go.mod
module github.com/bmon/mod-time-version

go 1.15

$ go run time/main.go
1629343955534

$ go run embed/main.go
# command-line-arguments
embed/main.go:8:3: go:embed requires go1.16 or later (-lang was set to go1.15; check go.mod)
```

### What did you expect to see?
I thought that the toolchain would ask me to modify the go version, exactly as it did with usage of `go:embed`
```shell
time/main.go:9: Time.UnixMilli() requires go1.17 or later (-lang was set to go1.15; check go.mod)
```

### What did you see instead?
The module builds, and passes `go mod tidy` and `go mod vet` without any issue, despite incorrectly setting the go version in the mod file.


Apologies if this is a duplicate, I spent some time searching but I wasn't able to find an issue matching this request. The closest I found was https://github.com/golang/go/issues/30241
Repository: youtube-dl
Issue: Issue forms for the Issue Templates.
Labels: 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.06.06. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Search the bugtracker for similar feature 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 feature request


## Description

<!--
Provide an explanation of your issue 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.
-->
Creating Issue Templates using the Issue forms and replacing the markdown files with YAML files.


Please assign it to me if you think this is good for your project.
Repository: pytorch
Issue: pytorch 1.8.1+cu111 used much more CPU RAM than pytorch 1.8.1 after run `import torch`
Labels: module: binaries,module: cuda,module: cpu,module: memory usage,triaged

## 🐛 Bug

pytorch 1.8.1+cu111 used 1G CPU RAM when only run `import torch`

## To Reproduce

Steps to reproduce the behavior:

1. Run `pip install torch==1.8.1+cu111 -f https://download.pytorch.org/whl/lts/1.8/torch_lts.html` to install pytorch 1.8.1 + cu111
2. Run `python`
3. Run `import torch`
4. Run `ps aux | grep python` to check the CPU RAM usage of that python process

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

It should use the same size of CPU RAM as pytorch installed by `pip install torch==1.8.1`

## 

*PS: Check more detail here: https://discuss.pytorch.org/t/pytorch-1-8-1-cu111-package-size-and-memory-usage-issue/128713*



cc @ezyang @seemethere @malfet @walterddr @ngimel @VitalyFedyunin
Repository: create-react-app
Issue: Changed behavior with filer-loader between v3 & v4
Labels: needs triage,issue: bug report

### Describe the bug

The PR #8950 updated the file-loader module to v6.0.0. Starting with v5.0.0 file-loader changed the default to emit an esModule by default (see https://github.com/webpack-contrib/file-loader/releases/tag/v5.0.0). which was not the case in earlier versions. Therefore code relying on the old behavior will no longer work with the newest react-scripts.

### Did you try recovering your dependencies?

Dependences are good (fresh project).

### Which terms did you search for in User Guide?

n/a

### Environment

n/a

### Steps to reproduce

1. Require file which is not handled by any other loader (e.g. `const woffFile = require("test.woff");`)
2. In v3.x `woffFile` will be an url pointing to the file
3. In v4.x `woffFile` will be an object with a `default` property pointing to the file

### Expected behavior

I expected to read something about it in the changelog or no changes in the behavior.

### Actual behavior

The behavior changed (see 3).

### Reproducible demo

n/a
Repository: pytorch
Issue: universal binaries for libtorch on mac (x86_64+arm)
Labels: module: binaries,feature,triaged,module: macos,module: arm

## 🚀 Feature
Universal binaries (x86_64+arm) made available on pytorch.org for the libtorch library on mac.

## Motivation

C++ applications requires libtorch to run PyTorch models saved as torchscript models.
All new Apple computers are now using Apple Silicon/M1 processors instead of Intel processors, and thus there is an increasing demand for native Apple Silicon support for mac applications.
As the developer of [a C++ mac application using AI through PyTorch models](https://new.steinberg.net/spectralayers/), I'm getting more and more requests for native Apple Silicon support but can't provide it until there's an universal binary version of the libtorch library.

## Pitch

An universal binary for libtorch that could be downloaded through https://pytorch.org/ instead of the current x86_64 version.

@albanD @malfet 

cc @ezyang @seemethere @malfet @walterddr @albanD
Repository: pytorch
Issue: Functional grid_sample: example of padding_mode="reflection" description error
Labels: module: docs,module: nn,triaged,module: interpolation

## 📚 Documentation

## Issue description
[torch.nn.functional.grid_sample](https://pytorch.org/docs/master/generated/torch.nn.functional.grid_sample.html#torch.nn.functional.grid_sample
)
Pick from the function description:
>padding_mode="reflection": use values at locations reflected by the border for out-of-bound grid locations. For location far away from the border, it will keep being reflected until becoming in bound, e.g., (normalized) pixel location x = -3.5 reflects by border -1 and becomes x' = 1.5, then reflects by border 1 and becomes **x'' = -0.5**.

## Expected description
x = **-0.5** should be x = **0.5**


cc @brianjo @mruberry @albanD @jbschlosser
Repository: godot
Issue: BackBufferCopy's Rect copy mode is confusing
Labels: topic:rendering,documentation,topic:2d

### Godot version

3.3.stable

### System information

Windows 10

### Issue description

BackBufferCopy's Rect mode may be working "as intended", but is very confusing and not useful at the moment.

- BackBufferCopy inherits from Node2D, but the copied region is not at all affected by the Transform. This is made even more confusing by the rectangle drawn in the editor, which is affected by both the rect property and the Transform.

- The origin for the rect's position is not at the top-left of the viewport, but at the bottom-left. This is extremely confusing as it is not documented, but it also causes problems when the size of the viewport is unknown/changing at runtime by stretching the game's window.

This makes the BackBufferCopy node confusing and hard to use. I think it should be changed to simply copy a region centered around or offset from the 2D position indicated by the Transform property.

This part is more of a proposal:
If the above brings issues of retro compatibility, I have a proposal for a new node. Instead of copying the screen to the back buffer, that node would copy a region of the screen, indicated by its transform and a rect, to an ImageTexture. I think this is what most people want from the Rect copy mode of BackBufferCopy anyway, since the region of the screen outside of the rect is outdated. This also enables the user to directly make a shader on this new node, using the TEXTURE and UV built-ins. It costs more memory, but would be in my opinion more understandable and usable.


### Steps to reproduce

See project below

### Minimal reproduction project

[backbuffercopy_test.zip](https://github.com/godotengine/godot/files/7013039/backbuffercopy_test.zip)

In this project a Sprite is affected by two screen-reading shaders making it more red. The BackBufferCopy node can be set to Viewport copy mode to see the intended effect (the image is very red). When in Rect copy mode, we can see that 
1) the Transform does not affect the copied region, even though the rectangle indicating a zone in the editor is affected
2) the copied region begins at the bottom-left of the game's window
3) even though the Sprite size is (64,64), and the rect size is (200, 100), the Rect is not covering the whole image because the test size of the project is set to (640, 640).
3) when resizing the window, the copied region moves, following the bottom left corner.

I think that these effects render the BackBufferCopy node confusing and hard to use in its Rect copy mode.
Repository: flutter
Issue: Add dismissLimits to Dismissible to limit the drag extent
Labels: c: new feature,framework,f: material design,c: proposal,team-design,triaged-design

## Use case

Currently, the Dismissible widget can be swiped the complete width, completely hiding the swiped item.
Having the possiblity to set some kind of limit, similar to dismissThresholds but as a maximum, makes it possible to show the background widget while still seeing part of the to be dismissed item.

## Proposal

Just like dismissThresholds, add something like a dismissLimits parameter where you can specify a maximum for each DismissDirection, which prevents the animition to go the full width but instead to a user chosen percentage.
In my case, you would only be able to swipe to about 20%, showing a delete icon in the background followed by a dialog to confirm the delete.
Repository: tauri
Issue: Cookie Support Inconsistencies
Labels: type: bug

I have created an app which requires accessing cookies from browser, while this works for debug builds it does not seem to work when building Tauri in release. I have also noticed that unlike Linux, Windows when testing release builds does not send cookies along with requests, however does work with debug builds on Windows.

Is there any reason why cookie support seems to be inconsistent?

This was wall tested using the latest Tauri beta.
Repository: node
Issue: Socket hang up while using keep alive bwteen node services
Labels: net

### Version

14.15.5

### Platform

Dokcer node:14.15.5

### Subsystem

_No response_

### What steps will reproduce the bug?

- Create 2 node serivces,  a listener and caller
- Setup HTTP agent (tested via axios) with keep-alive flag
- call from the caller to the listener via HTTP request every 10 sec
- In some point some requests will fail with socket hangup log,

### How often does it reproduce? Is there a required condition?

Not every time

### What is the expected behavior?

The connection issue should not appear, response should work

### What do you see instead?

The error

### Additional information

Logs from debug

The last log looks suspicious https://github.com/nodejs/node/blob/7ca2f1303996e0c79c354e979a1527da444ca886/lib/net.js#L415

<img width="300" alt="Screen Shot 2021-08-19 at 16 08 57" src="https://user-images.githubusercontent.com/11357455/130076493-0bf0e54a-508a-46b0-9a7e-379826453e1d.png">
Repository: godot
Issue: Pointer pointing at wrong object when instancing `GPUParticlesAttractorSphere` class
Labels: bug,topic:rendering

### Godot version

4.0.dev.custom_build. 819aa47fe

### System information

Ubuntu 21.04 - Nvidia GTX 970, Gnome shell 3.38 X11

### Issue description

Executing this code 
```
add_child(ClassDB.instantiate("GPUParticlesAttractorSphere"))
```
shows this undefined sanitizer error
```
servers/rendering/renderer_scene_cull.cpp:1299:37: runtime error: downcast of address 0x603000692960 which does not point to an object of type 'InstanceGeometryData'
0x603000692960: note: object is of type 'RendererSceneCull::InstanceParticlesCollisionData'
 be be be be  70 5f 4e 24 00 00 00 00  00 00 00 00 e5 03 00 00  02 11 00 00 18 00 00 00  4e 05 00 45
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'RendererSceneCull::InstanceParticlesCollisionData'

```
https://github.com/godotengine/godot/blob/e499758a77dfb94d5f8c13e9e74f6352f5c0e472/servers/rendering/renderer_scene_cull.cpp#L1299

### Steps to reproduce

Above

### Minimal reproduction project

_No response_
Repository: svelte
Issue: Crossfade opacity is incorrect
Labels: bug,runtime

### Describe the bug

When using `crossfade` to transition between two elements, the `in` element goes from 0 to `o` (where `o` is the natural opacity) while the `out` element goes from `o` to 0.

The result is that at the midpoint, the combined opacity is less than either element's natural opacity. In the common case where both elements have a natural opacity of 1, the combined opacity at the midpoint is 1 - 0.5^2 = 0.75.

This can be solved with a quadratic blending formula with special handling for the common case (which is complicated by the need to know which element is on top of the other).

### Reproduction

https://svelte.dev/repl/6dc637d0321f41f983da99907b2f451d?version=3.42.1

This also showcases a separate bug, which is a dupe of #4389. (There are [several open crossfade issues](https://github.com/sveltejs/svelte/search?p=1&q=crossfade&type=issues); the whole thing probably needs a bit of a cleanup.)

### Logs

_No response_

### System Info

Svelte 3.42.1


### Severity

annoyance