sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: io: ReadAll buffer resizing is inefficient
Labels: Performance,NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17.5 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/vagrant/.cache/go-build"
GOENV="/home/vagrant/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/vagrant/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/vagrant"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.5"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/vagrant/src/github.com/cortexproject/cortex/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-build2696308846=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Called `ioutil.ReadAll` to read everything from an http response.

### What did you expect to see?

Reasonable memory and CPU usage.

### What did you see instead?

~60% more memory is allocated when using `ioutil.ReadAll` compared with `bytes.Buffer.ReadFrom`.

See https://github.com/prometheus/client_golang/pull/976.
#46564 is making the same complaint, although it was solved in a different way.

The underlying reason is that `ReadAll()` uses `append` to resize its buffer, which goes up by a factor of 1.25 (slightly more in latest Go, but asymptotically the same) each time.

One might measure these alternatives on various axes:
* number of bytes allocated and freed
* max size of heap required to read a given size
* amount of copying while resizing
* percentage waste in returned buffer

The current implementation is better on the last one, and much worse on all the others.
Repository: material-ui
Issue: [SwipeableDrawer] disableDiscovery on a swipeable edge drawer has inverted effect.
Labels: new feature,component: SwipeableDrawer

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

This only has a noticeable effect if the drawer has a swipeable edge ([Docs](https://mui.com/components/drawers/#swipeable-edge)).
Leaving "disableDiscovery" as false means that when you hold click on the drawer (requires mobile touch emulation for touchstart), the drawer pops up a bit, which is correct.
Setting "disableDiscovery" to true, however, means that the drawer dips down a bit when you start holding the drawer, instead of staying still.
GIF showcase: https://imgur.com/a/q4MNvG6

### Expected behavior 🤔

Setting "disableDiscovery" to true should mean that the drawer should not move until the user starts to drag the drawer.

### Steps to reproduce 🕹

Steps:
Requires mobile touch emulation (can just use chrome / firefox mobile mode in dev tools)

1. Use codesandbox demo from: https://mui.com/components/drawers/#swipeable-edge
2. Add "disableDiscovery={true}" to the SwipeableDrawer component
3. Click on drawer, and it dips down.


### Context 🔦

I'm trying to get the drawer not to move, until the user starts moving.

I have tracked the cause to this line in SwipeableDrawer.js:
`(disableDiscovery ? 15 : -DRAG_STARTED_SIGNAL),`
This means that when disableDiscovery is true, the drawer dips down 15px on touchstart.

I assume it's 15 due to reasons related for when a drawer doesn't have a swipeable edge. I think this should just be a prop, something like "discoverAmount", where you can set the DRAG_STARTED_SIGNAL to a number for both up and down sides, or [number,number] for separate up and down amounts.

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
```
</details>
Repository: godot
Issue: HTTPClient connecting to closed port on web export
Labels: platform:web,topic:porting,documentation,topic:network

### Godot version

3.4.2.stable

### System information

Windows 10

### Issue description

HttpClient's connect_to_host after polling sets its state to HTTPClient.STATUS_CONNECTED in web export,
even though the port is closed.

While running localy the behaviour is the currect one. When exporting to web it is not.

### Steps to reproduce

Run the minimal reproduction project localy, the terminal prints HTTPClient.STATUS_CONNECTING - Correct
Run the minimal reproduction project via godot's Run HTML button, the terminal prints HTTPClient.STATUS_CONNECTED - Incorrect

### Minimal reproduction project

[test.zip](https://github.com/godotengine/godot/files/7926796/test.zip)
Repository: godot
Issue: Godot 4.0 (Vulkan) doesn't start if Godot 3.x (OpenGL) is running - Optimus on Linux with Bumblebee daemon
Labels: bug,platform:linuxbsd,topic:rendering,topic:thirdparty,needs testing

### Godot version

4.0alpha 1

### System information

Debian 11

### Issue description

As stated in title.
Also If I close 3.5 beta 1 then 4.0 alpha 1 start.
Is like 3.5 put on hold 4.0
ps.: I have NVIDIA Optimus . So to me seems pretty much similar to https://github.com/godotengine/godot/issues/48091#issuecomment-915226816

If I open just the 4.0 the I have this error:

```
Godot Engine v4.0.alpha1.official.31a7ddbf8 - https://godotengine.org
Can't open bumblebee display.
ERROR: GENERAL - Message Id Number: 0 | Message Id Name: Loader Message
	loader_scanned_icd_add: ICD libnv_vulkan_wrapper.so.1 doesn't support interface version compatible with loader, skip this ICD.
	Objects - 1
		Object[0] - VK_OBJECT_TYPE_INSTANCE, Handle 147716592
   at: _debug_messenger_callback (drivers/vulkan/vulkan_context.cpp:157)
MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete
Vulkan API 1.2.162 - Using Vulkan Device #0: Intel - Intel(R) HD Graphics 4000 (IVB GT2)

```
It let me open project manager and so on nevertheless.. 

Thanks

### Steps to reproduce

Its seems related who have NVIDIA Optimus. Not sure 100%

### Minimal reproduction project

NA
Repository: godot
Issue: [4.0] Godot not run a simple project
Labels: bug,topic:editor,needs testing

### Godot version

4.0alpha 1

### System information

Debian 11

### Issue description

I create a simple project and it not run. See attached minimal project.

I think is related to #57132 because if I export it I can run it normally. 

The editor deny to run the project. 

### Steps to reproduce

See project below.

### Minimal reproduction project

[Test01.zip](https://github.com/godotengine/godot/files/7927434/Test01.zip)
Repository: godot
Issue: The tile atlas editor lacks scrollbars
Labels: enhancement,topic:editor,usability,topic:2d

### Godot version

4.0 alpha 1

### System information

Windows 10

### Issue description

I can't select the scroll bars to scroll when zoomed in on a Tile Map so I can select an area above the visible area. There seems to be a scroll handle between the divider but whenever I try and select it, all I get is the resize window selector. The video here shows how I can't select the scroll bar and I am not sure there is any keyboard way to get to the top or the bottom.

https://user-images.githubusercontent.com/31901090/150838271-59555e89-9588-42b1-901c-2f01469a12de.mp4

 

### Steps to reproduce

Create a Tile Map
Add an image
Zoom in on it
Try and scroll to the top.


### Minimal reproduction project

_No response_
Repository: godot
Issue: [4.0] Icons in scene tree overlap node names
Labels: bug,topic:editor,usability

### Godot version

4.0alpha 1

### System information

Debian 11

### Issue description

When I reduce the horizontal space to the min in scene tree I still see the icons(toggle visibility) overlap node name even using horizontal scroll bar.
see picture

![image](https://user-images.githubusercontent.com/13235119/150839594-c7a7c651-787c-40f9-9708-acc4284b22e5.png)

I was expecting to see the last control node entirely.
So in my opinion the horizontal scroll don't takes into account  the horizontal size's toggle visibility 

### Steps to reproduce

Create tree as in picture the scroll horizontal bar

### Minimal reproduction project

NA
Repository: godot
Issue: Passing 64 bit integers in Array (Variant) to C# truncates the numbers
Labels: bug,documentation,topic:dotnet

### Godot version

3.4.2-stable

### System information

Linux

### Issue description

It seems like when passing data through to C# in a Godot Array 64 bit integers don't make it through. Instead they get truncated to 32 bit numbers. I encountered this issue when using a module that works fine from GDScript in C# and I ended up getting pretty nonsensical numbers. For now I can workaround the problem by bit hacking the int into an ulong. This approach will break once more bits than can fit in an integer are used.

Reading through the code that I think converts Variant objects to C# data I found this place:
https://github.com/godotengine/godot/blob/3.4.2-stable/modules/mono/mono_gd/gd_mono_marshal.cpp#L577
and it seems that there is a huge oversight here in the form that it's not considered that Variant can hold up to a 64 bit number when its type is INT.

### Steps to reproduce

- Call a method in C# that returns an Array
- Loop through the array and try to cast the elements to long (or ulong) as that is what data should be contained. Instead a cast exception is thrown. And if accessing the value through casting to int, then the number turns negative even though it shouldn't.

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: [FX] Support call_method in NormalizeArgs
Labels: triaged,module: fx

### 🚀 The feature, motivation and pitch

Currently NormalizeArgs only supports normalizing `call_function`s and `call_module`s. Ideally it would support `call_method`s as well. Example code:

```python
import torch
import torch.fx

class TestModule(torch.nn.Module):
    def forward(self, x):
        return x.flatten(), torch.flatten(x)

mod = TestModule()
gm = torch.fx.symbolic_trace(mod)
print(gm.graph)
```
Output shows flatten args for `call_method` and `call_function` not normalized with standard FX tracing (all kwargs usage or default values), as expected:
```
graph():
    %x : [#users=2] = placeholder[target=x]
    %flatten : [#users=1] = call_method[target=flatten](args = (%x,), kwargs = {})
    %flatten_1 : [#users=1] = call_function[target=torch.flatten](args = (%x,), kwargs = {})
    return (flatten, flatten_1)
```

Now when we normalize we see that the `call_function` is normalized with all kwargs and default values, but the `call_method` is not.
```python
from torch.fx.experimental.normalize import NormalizeArgs
gm = NormalizeArgs(gm).transform()
print(gm.graph)
```
```
graph():
    %x : [#users=2] = placeholder[target=x]
    %flatten : [#users=1] = call_method[target=flatten](args = (%x,), kwargs = {})
    %flatten_1 : [#users=1] = call_function[target=torch.flatten](args = (), kwargs = {input: %x, start_dim: 0, end_dim: -1})
    return (flatten, flatten_1)
```

### Alternatives

_No response_

### Additional context

_No response_
Repository: godot
Issue: [4.0] Export project don't save files
Labels: enhancement,topic:editor,usability,topic:export

### Godot version

4.0alpha 1

### System information

Debian 11

### Issue description

When I modify a project then export it the scenes are not saved. 

I expected scenes to be saved then project compiled then exported.


### Steps to reproduce

Any empty project with a simple node will be suffice to check the issue ( unless its expected behaviour)

### Minimal reproduction project

NA
Repository: create-react-app
Issue: Peer dependency warnings
Labels: needs triage,issue: bug report

### Describe the bug

Doing a fresh install results in a lot of peer dep warnings.

### Did you try recovering your dependencies?

```
❯ yarn --version              
1.22.0
```

### Which terms did you search for in User Guide?

peer dependency warning

### Environment

`react-scripts@5.0.0`.

### Steps to reproduce


1. `yarn create react-app my-app`

### Expected behavior

No warnings of any kind.

### Actual behavior

```
warning " > @testing-library/user-event@13.5.0" has unmet peer dependency "@testing-library/dom@>=7.21.4".                                                                                                           
warning "react-scripts > tailwindcss@3.0.16" has unmet peer dependency "autoprefixer@^10.0.2".      
warning "react-scripts > eslint-config-react-app > eslint-plugin-flowtype@8.0.3" has unmet peer dependency "@babel/plugin-syntax-flow@^7.14.5".
warning "react-scripts > eslint-config-react-app > eslint-plugin-flowtype@8.0.3" has unmet peer dependency "@babel/plugin-transform-react-jsx@^7.14.9".
warning "react-scripts > react-dev-utils > fork-ts-checker-webpack-plugin@6.5.0" has unmet peer dependency "typescript@>= 2.7".
warning "react-scripts > webpack-dev-server > http-proxy-middleware@2.0.2" has unmet peer dependency "@types/express@^4.17.13".                
warning "react-scripts > eslint-config-react-app > @typescript-eslint/eslint-plugin > tsutils@3.21.0" has unmet peer dependency "typescript@>=2.8.0 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev || >= 3.5.0-dev |
| >= 3.6.0-dev || >= 3.6.0-beta || >= 3.7.0-dev || >= 3.7.0-beta".                                                                                                                                                   
```
Repository: godot
Issue: [4.0] very slow upload of video frames in GPU
Labels: bug,topic:core,confirmed,performance

### Godot version

6a3ff8fa1f2cbad5752cf039827206ac265f68f6

### System information

Linux Mint 20.1, nvidia-driver-470

### Issue description

Hello,

I'm currently working on the ffmpeg module for godot 4.0 (see https://gitlab.com/polymorphcool/godot-ffmpeg/-/tree/4.0)

There's a massive performance drop when i try to upload HD textures. Textures < 1024x1024 are pushed seamlessly. As soon I try 1920x1080, frame rate drops around 1 fps, majority of the time is lost during the call to `ImageTexture::update(const Ref<Image> &p_image)`.

see https://gitlab.com/polymorphcool/godot-ffmpeg/-/blob/4.0/fast_forward_playback.cpp#L839

The code is inspired by the theora module.

### Steps to reproduce

- clone git@gitlab.com:polymorphcool/godot-ffmpeg.git into modules/ffmpeg/
- check out the 4.0 branch
- compile
- create a empty project
- add a videoplayer and put an HD mp4 stream in it
- play

### Minimal reproduction project

_No response_
Repository: go
Issue: testing/fstest: cannot test no permission on folder
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17.3 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes. Not totally sure if it is related to https://github.com/golang/go/issues/46776

### 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/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.3"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/user/gomodule/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-build3099453485=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

tested.go
```go
package x

import (
	"fmt"
	"io/fs"
	"os"
	"path/filepath"
	"strings"
)

func fileExists(fileSystem fs.FS, fileName string) (bool, error) {
	_, err := fs.Stat(fileSystem, fileName)
	if err == nil {
		return true, nil
	}
	if os.IsNotExist(err) {
		return false, fmt.Errorf("File %q does not exist.", fileName)
	}
	return false, err // test case should return here
}

func FileValid(fileSystem fs.FS, fileName string) (string, error) {
	fileExists, err := fileExists(fileSystem, fileName)
	if !fileExists || err != nil {
		return "", err
	}

	return "success", nil
}
```

tested_test.go
```go
package x

import (
	"io/fs"
	"testing"
	"testing/fstest"
)

var (
	fakeFS = fstest.MapFS{
		"secret-folder":          {Mode: 0000},
		"secret-folder/readme.md": {},
	}
)

func TestFileValidPermissionDenied(t *testing.T) {
	fileName := "readme.md"
	fsys, _ := fs.Sub(fakeFS, "secret-folder")
	wantOut := ""

	out, err := FileValid(fsys, fileName)
	if out != wantOut || err == nil {
		t.Errorf("want %q, nil got %q, %v", wantOut, out, err)
	}
}
```

### What did you expect to see?

This test should pass, returning "", and error that permission is denied.

### What did you see instead?

It can Stat the file, even with no permission to the folder.
Repository: TypeScript
Issue: A derived class is allowed be created without a parent's getter or setter.
Labels: Suggestion,Experience Enhancement

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->
class extend override getter setter accessor

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This seems to occur on all versions on the Playground (3.9+)

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.5.4#code/MYGwhgzhAEAKYCcCmA7ALtA3gKGn6ADgK4BGIAlsNAOZIYBmAFAJRbTJpEIrQvQC8APiwBfANzQR2KdlCQYAYQAW5EABNoSAB5pUamPGTosufMTKVoEOtCb0iKYAC5erIdABuAe3JrWmSWlsWS8UCAwqfmgUJAB3aGVVNRYxWQA6JmYJAHps9gc0cgBbJE0EBC8EaBIkYDAiawSVdWg1LyQIFAByDGKCECQS4zQlUto0XSr6SttsIA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
class Parent {
    public get f() { return () => {}; }
}

class Child extends Parent {
    public set f(func: () => void) { }
}

const c = new Child();
c.f(); // runtime error because Child doesn't implement the getter for f
```

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->
Class `Child` is allowed to extend class `Parent` even though, by adding a setter for `f`, it discards the getter for `f` and therefore doesn't implement Parent's contract.

### 🙂 Expected behavior

<!-- What you expected to happen instead, and why -->
TypeScript should emit an error because `Child` is not compatible with `Parent`.
Repository: flutter
Issue: Dispatch to Khronos validation layers in Vulkan embedder tests
Labels: a: tests,engine,e: embedder,P3,team-engine,triaged-engine

The khronos validation layers aren't running on the test harness yet. We're currently just running the Swiftshader ICD directly without a real loader/layer dispatch mechanism.

Although the LunarG SDK ships with Khronos validation layer builds, a convenient unified validation layer, and a loader that can be configured to use it by various means, I've avoided using it so far because:
* The LunarG SDK is a heavy dependency (the uncompressed SDK 1.2.198.1 MacOS build is 639MB).
* The loader that ships with the LunarG SDK has complicated configuration logic that we don't need. Layer resolution behavior can be overridden with environment variables and multiple text configuration paths, leading to more possibilities of accidental breakages, especially in less controlled environments like developer workstations. Having local dev builds run with identical CI configuration is desirable.

My recommendation:
1. Add the [repository](https://github.com/KhronosGroup/Vulkan-ValidationLayers) as a dependency and build the layer shared libraries from source on Windows+Mac+Linux for `embedder_unittests_gl`. Conveniently, there's a [gn build](https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/master/BUILD.gn) in the repository that can serve as a useful reference.
1. Collect each layer's `Get[Instance|Device]ProcAddr` by performing [layer version negotiation](https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/LoaderAndLayerInterface.md#layer-version-negotiation).
1. [Initialize the layers](https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/LoaderAndLayerInterface.md#layer-dispatch-initialization). When creating the instance/device, add a`VkLayer[Instance|Device]CreateInfo` via `pNext` and provide a `VkLayer[Instance|Device]Link` linked list via `VkLayer[Instance|Device]CreateInfo::pDeviceList`. Place each layers' appropriate `vkGet[Instance|Device]ProcAddr` pointer in the node. Khronos notes a recommended layer order in [this presentation](https://www.lunarg.com/wp-content/uploads/2016/07/lunarg-birds-feather-session-siggraph-july-26-2016.pdf#page=21).
1. Make the instance proc address callback (supplied to the Flutter Vulkan render config) trampoline to the `GetInstanceProcAddr` of the first layer node.