sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Unexpected behavior from torchscript (mixing trace with script)
Labels: oncall: jit

### 🐛 Describe the bug

Hi,

I have encountered some unexpected behavior with mixing torch.jit.script and torch.jit.trace. Here’s a example to reproduce.

```python
import torch
import numpy as np

@torch.jit.script
def select_rows(
    nums: int,
    data: torch.Tensor,
    size: int
):
    valid_choice = torch.multinomial(torch.ones(nums).float(), size)
    return data[valid_choice]

def do_selection(x):
    return select_rows(x.shape[0], x, x.shape[0])

t_4 = torch.tensor(np.array([1, 2, 3, 4]))
t_7 = torch.tensor(np.array([1, 2, 3, 4, 5, 6, 7]))

traced_selection = torch.jit.trace(do_selection, t_4)

print(traced_selection(t_4))
>>> tensor([3, 1, 2, 4])  # A random arrangement of the input data.

print(traced_selection(t_7))
>>> tensor([1, 3, 2, 4])  
# Another random arrangement, but of the TRACED EXAMPLE!
# Expected a random arrangement of the current input of size 7!
```

In my actual example, def do_selection() is extremely complicated, and cannot be scripted using torch.jit.script . What are my options here? Is this the expected behavior?

Thanks.

### Versions

PyTorch version: 1.10.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.4 (x86_64)
GCC version: Could not collect
Clang version: 13.0.0 (clang-1300.0.27.3)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.13 (main, Aug 25 2022, 18:29:29)  [Clang 12.0.0 ] (64-bit runtime)
Python platform: macOS-10.16-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.19.5
[pip3] pytorch-lightning==1.1.4
[pip3] torch==1.10.0
[pip3] torchaudio==0.10.0
[pip3] torchmetrics==0.10.0rc0
[pip3] torchvision==0.11.0
[conda] numpy                     1.19.5                   pypi_0    pypi
[conda] pytorch-lightning         1.1.4                    pypi_0    pypi
[conda] torch                     1.10.0                   pypi_0    pypi
[conda] torchaudio                0.10.0                   pypi_0    pypi
[conda] torchmetrics              0.10.0rc0                pypi_0    pypi
[conda] torchvision               0.11.0                   pypi_0    pypi


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Repository: godot
Issue: Scrollbar list has a duplicate of itself that doesn't move, but only for one project.
Labels: bug,topic:gui

### Godot version

4.0.beta5

### System information

Windows 10

### Issue description

On one specific project, and no other projects, when I scroll a list, there's an identical one behind it that doesn't move at all.

<img width="343" alt="Capture2" src="https://user-images.githubusercontent.com/86162343/203227125-a486f06a-d01a-4d10-89ba-2a2a303dfbd7.PNG">

<img width="169" alt="Capture" src="https://user-images.githubusercontent.com/86162343/203227108-dbeedbf8-3baf-4313-bcd9-de286a6db223.PNG">


### Steps to reproduce

I have no idea how to reproduce this issue, it is very odd. It only happened on the one project, and when I tried to remake it exactly the same way on another project, it worked just fine. It also didn't matter how I remade it to try and fix it because it always had the same issue

### Minimal reproduction project

N/A
Repository: godot
Issue: FlowContainer returns wrong line count
Labels: discussion,documentation,topic:gui

### Godot version

v3.6.beta.custom_build [0803b4168]

### System information

PopOS 22.04 LTS, GTX1060

### Issue description

Look like `FlowContainer` `get_line_count()` always returns 0, even if they have child-nodes on em, which is incorrect behiavour.

### Steps to reproduce

1. make new scene with `HFlowContainer` or `VFlowContainer` it doesn't matter
2. add some control-based child on them to increase line count
3. attach following script

```gdscript
extends FlowContainer


func _ready() -> void:
#	yield(get_tree(), "idle_frame")
	print(get_line_count())
```
4. run scene and see output
5. uncomment `yield` line
6. run scene and see output

### Minimal reproduction project

issue easily reproducible with any project
Repository: rust
Issue: Long build times for conflicting trait implementations (>35min on GitHub CI)
Labels: I-compiletime,C-bug

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried to compile this code: https://github.com/JonahPlusPlus/bevy_atmosphere/tree/4a0df51f7817e1f50294fc7abf69b5455cbc4f9e

I expected this to compile relatively quickly.

Instead, it took really long, and I thought that the compiler was broken. However, after 35min, my CI finished.

It returned the following error:
```shell
error[E0119]: conflicting implementations of trait `bevy::reflect::TypeData` for type `model::AtmosphereModelMetadata`
  --> src/model/mod.rs:49:1
   |
49 | impl TypeData for AtmosphereModelMetadata {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: conflicting implementation in crate `bevy_reflect`:
           - impl<T> TypeData for T
             where T: 'static, T: Send, T: Sync, T: Clone;
```

It turns out that I didn't need to implement [`TypeData`](https://docs.rs/bevy_reflect/latest/bevy_reflect/trait.TypeData.html) since it is already implemented for types that implement `Clone`.

I fixed it by simply removing my implementation, but I'm making this issue because waiting 35min to figure out the problem is frankly unacceptable and I'm sure the maintainers would like samples to figure out the root of the problem.

(I've tested this on the latest stable and nightly, both with the same results)

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose` (on my machine, it's different in the CI):
```
rustc 1.65.0 (897e37553 2022-11-02)
binary: rustc
commit-hash: 897e37553bba8b42751c67658967889d11ecd120
commit-date: 2022-11-02
host: x86_64-pc-windows-msvc
release: 1.65.0
LLVM version: 15.0.0
```
Repository: opencv
Issue: Segmentation fault with large image on kmeans
Labels: bug,category: core

### Expected behaviour

I expect when I run cv2.kmeans() to run and give the labels.

### Actual behaviour

Running on cv2.kmeans() on large image (38482, 44999, 3)  gives me "python: Segmentation fault (core dumped)" error. 

It runs fine if the image is cropped to a small size. 

### Steps to reproduce
- load a (38482, 44999, 3) (I used tifffle for loading for specific .svs extension)
- reshape the image into flat vectors
- cast to np.float32
- run kmeans with the following code:
```python
criteria = (cv2.TERM_CRITERIA_EPS + cv2.TERM_CRITERIA_MAX_ITER, 10, 1.0)
K = 5
attempts=10
ret,label,center=cv2.kmeans(vectorized,K,None,criteria,attempts,cv2.KMEANS_PP_CENTERS)

```

- operating system
Redhat 7.7

- architecture (e.g. x86)
 x86_64

- opencv-python version
4.6.0

##### Issue submission checklist

 - [x] This is not a generic OpenCV usage question (looking for help for coding, other usage questions, homework etc.)
   

   Use Q&A forums such as https://answers.opencv.org/questions/ and https://stackoverflow.com/ and other communities
   to discuss problems. Tickets without real issue statements related to this build toolchain will be closed.

   -->
 - [x] I have read the README of this repository and understand that this repository provides only an automated build toolchain for OpenCV Python packages (there is no actual OpenCV code here)
   <!--

   If you have some OpenCV bug report which needs to fixed in the C++ code, 
   please report issue to the OpenCV repository: 

   https://github.com/opencv/opencv/issues

   See also:

   * OpenCV documentation: https://docs.opencv.org
   * OpenCV FAQ page: https://github.com/opencv/opencv/wiki/FAQ
   * OpenCV forum: https://answers.opencv.org
   * Stack Overflow branch: https://stackoverflow.com/questions/tagged/opencv

   -->
 - [ ] The issue is related to the build scripts in this repository, to the pre-built binaries or is a feature request (such as "please enable this additional dependency")
 - [x] I'm using the latest version of ``opencv-python``
Repository: rust
Issue: Modules loaded using `#[path]` are seemingly treated like `mod.rs` files even when they're not
Labels: T-compiler,C-bug,needs-rfc

Assume the following file structure:
```
src
  bin
    foo.rs
  bar
    baz.rs
  bar.rs
  main.rs
```
where `bar.rs` has a `mod baz;` in it.

When doing
```rust
mod bar;
```
in `main.rs`, everything works like expected. The `bar` module is loaded from `bar.rs` and its `baz` module gets loaded from `bar/baz.rs`. Smooth sailing.

Now try adding
```rust
#[path = "../bar.rs"]
mod bar;
```
to `bin/foo.rs`. What I expected was that this would behave exactly identical to `mod bar` in `main.rs`; after all, I've just changed the implicit location of `bar.rs` to an explicit one.

Instead, this happens:
```
error[E0583]: file not found for module `baz`
 --> src\bin\..\bar.rs:1:1
  |
1 | mod baz;
  | ^^^^^^^^
  |
  = help: to create the module `baz`, create file "src\bin\..\baz.rs" or "src\bin\..\baz\mod.rs"

For more information about this error, try `rustc --explain E0583`.
```

Why is it looking for `src\bin\..\baz.rs`? It should be looking for `src\bin\..\bar\baz.rs`, since `bar.rs` is not a root module like `lib.rs` or `main.rs`, nor is it a `mod.rs` file.

If this behavior is expected, it's not very well documented, I certainly couldn't find anything explaining this behavior [in the documentation](https://doc.rust-lang.org/reference/items/modules.html#the-path-attribute).

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.65.0 (897e37553 2022-11-02)
binary: rustc
commit-hash: 897e37553bba8b42751c67658967889d11ecd120
commit-date: 2022-11-02
host: x86_64-pc-windows-msvc
release: 1.65.0
LLVM version: 15.0.0
```
Repository: pytorch
Issue: build: cmake: need to uniformize installation of libraries in CMAKE_INSTALL_LIBDIR (not lib)
Labels: module: build,module: cpp,triaged,needs research

### 🐛 Describe the bug

Installed pytorch from source, with cmake.

In particular I noticed that some libraries are installed in a hard-coded `$DESTDIR/$CMAKE_INSTALL_PREFIX/lib`, which is not expected on x86_64 (should be `.../lib64` from `CMAKE_INSTALL_LIBDIR`).

Looking at the cmake files:
```sh
git grep CMAKE_INSTALL_LIBDIR
git grep "DESTINATION lib"
```
and found issues.

So I propose to do this:
```sh
git grep " lib)" | perl -pe 's/(.*):(.*)$\s*/\1/g' | grep CMakeLists.txt | uniq | while read file; do sed -i -e 's@ lib)@ ${CMAKE_INSTALL_LIBDIR})@' "$file"; done
```
then reviewing with `git gui` or something else, to get rid of false positives (eg. test executables shouldn't go there, and it's OK for the deployed platform-agnostic `.py` files to be in `.../lib`).


### Versions

PyTorch version: 1.13.0+cu117

cc @malfet @seemethere @jbschlosser
Repository: pytorch
Issue: build: cmake: ability to disable -Werror* (-Werror considered harmful)
Labels: module: build,triaged

### 🐛 Describe the bug

Tried to compile pytorch with gcc 12 and it failed instead of warning due to `-Werror`.

Now while I'm convinced that leaving `-Werror` in the build files elsewhere than in the developer / CI environment is insanity, and I'm not alone (https://flameeyes.blog/2009/02/25/future-proof-your-code-dont-use-werror/ ; https://embeddedartistry.com/blog/2017/05/22/werror-is-not-your-friend/ ; https://news.ycombinator.com/item?id=28745949 ...), I'm simply requesting the ability of controlling it (eg. https://github.com/dotnet/runtime/issues/7122 ; https://github.com/RobotLocomotion/drake/issues/2428 ...) so source distribution is future-proof.

### Versions

PyTorch version: 1.13.0+cu117

cc @malfet @seemethere
Repository: pytorch
Issue: build: cmake: functorch.so not installed at expected location
Labels: module: build,triaged

### 🐛 Describe the bug

When building with cmake, the functorch library gets installed to `${DESTDIR}/${PROJECT_SOURCE_DIR}/functorch/`, which is unexpected:

```sh
$ cmake .. -DCMAKE_INSTALL_PREFIX=/usr ...
...
$ make install DESTDIR=$PWD/install
...
$ ls install
home  usr
$ find install/home
install/home/$USER/path/to/pytorch.git/functorch/functorch.so
```

The functorch library is moved by setup.py later, but nevertheless I'd expect that unless the quirk is documented, the cmake stage installed files in standard locations.

### Versions

pytorch cf9476554fce9a9c909eebd7439f4b3f4d208f6c

cc @malfet @seemethere
Repository: godot
Issue: glTF (.glb) importer fails with errors importing file with no objects/meshes
Labels: bug,topic:import,topic:3d

### Godot version

4.0.beta5

### System information

macOS 13.0.1

### Issue description

I recently discovered that it you try to import a glTF (.glb) file that contains no objects, the importer ungracefully fails with multiple errors that don't really help you understand what has gone wrong:

```
  modules/gltf/gltf_document.cpp:570 - Condition "!s.has("nodes")" is true. Returning: ERR_UNAVAILABLE
  modules/gltf/gltf_document.cpp:6927 - Condition "err != OK" is true. Returning: ERR_PARSE_ERROR
  modules/gltf/gltf_document.cpp:6597 - Condition "err != OK" is true. Returning: err
  modules/gltf/gltf_document.cpp:7032 - Condition "err != OK" is true. Returning: err
  editor/editor_file_system.cpp:1909 - Error importing 'res://Models/empty.glb'.
```

What I'd expect would be that the importer would not fail, just generate a scene with no mesh instances etc. Probably then also provide a helpful warning explaining there were no readable objects in the imported file as this was probably not intentional. Instead the importer now fails and breaks any scenes linking to the file.

This might seems like it's not a problem since you'd never try to import an empty file, but it can happen quite easily due to the way blender exports these files: A way I commonly use is to have a master blender file with several models in, and then export them to separate asset files by selecting them and exporting in blender using the "selected objects" option to only export the selected objects. What I discovered is that if you've accidentally deselected the object you're intending to export blender will still export a glb file with no warnings. Only the file will have no objects in it. And if this export has overwritten one of the imported models in your project Godot will now just provide the errors above and fail to load any scenes with the model linked to it. 

While I'm not familiar enough with the code to know fully, a guess would be that the problem is here in GLTFDocument::_parse_scenes:
https://github.com/godotengine/godot/blob/77f4670d001b12a5c7e1f50c100301c8fb1b4d1e/modules/gltf/gltf_document.cpp#L567-L570
It incorrectly assumes that all files that result in no nodes loaded have failed to load. While the case above illustrates that it may be the case that it has loaded, it's just empty. And in this case it should probably issue a warning instead and produce an empty scene instead of failing with ERR_UNAVAILABLE.

### Steps to reproduce

Simple: 
- Just try to import the empty.glb file linked below. 

Full experience:
- Import the example cube.glb model from below in a Godot project and instance this in your main scene.
- Replace the imported cube.glb file with the empty.glb renamed to "cube.glb" to simulate overwriting an imported asset with an empty one.

### Minimal reproduction project

[empty.glb.zip](https://www.lostminds.com/godot/empty.glb.zip)
[cube.glb.zip](https://www.lostminds.com/godot/cube.glb.zip)
Repository: kubernetes
Issue: kube-controller-manager memory leak when frequently create and delete same crd
Labels: kind/bug,priority/important-soon,sig/api-machinery,triage/accepted

### What happened?

 when frequently create and delete same crd, kube controller manager memory leak

throuth golang heap
![pprof](https://user-images.githubusercontent.com/13744637/203279108-4a0c4e96-4ffc-472e-9dab-a4844f9d5c04.PNG)

when create crd， gc controller will use shared  informer, and add a new event handler to shared informer.
when delete crd， gc controller only close stop chan, and not remove event handler from shared informer
so if frequently  create and delete same crd, leak event handler in shared informer, lead to kcm memory leak.

### What did you expect to happen?

no memory leaks

### How can we reproduce it (as minimally and precisely as possible)?

local up a cluster, and execute this script,finally memory usage continue rising

``` bash
#!/bin/bash

export KUBECONFIG=/var/run/kubernetes/admin.kubeconfig
while :
do
    cluster/kubectl.sh create -f crd.yaml
    sleep 30
    cluster/kubectl.sh delete -f crd.yaml
    sleep 30
done
```

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
```

</details>
1.23.10

### Cloud provider

<details>

</details>
local cluster

### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>
ubuntu

### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: excalidraw
Issue: Font should be "Virgil 3 YOFF" not "Virgil"
Labels: font

See https://github.com/excalidraw/virgil/issues/61
Repository: vscode
Issue: [css] Please add an option to switch to using line-by-line comments
Labels: feature-request,css-less-scss

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

When commenting on multiple lines of CSS properties, VSC will add `/*` and `*/` to the beginning and end of the entire block.

But there is a problem: Chrome (Edge)'s DevTools cannot recognize the entire-block comments, but can recognize the line-by-line comments.

So, is it possible to provide an option to switch the default comment style (entire-block or line-by-line), or provide a shortcut key to do line-by-line comments directly?

![1](https://user-images.githubusercontent.com/8857634/203286580-dd2afd39-14ad-48b7-938b-994d7b9f8b05.png)
Repository: rust
Issue: Don't leak non-exported symbols from staticlibs
Labels: A-linkage,T-compiler

When compiling a cdylib only `#[no_mangle]` symbols are exported. `#[rustc_std_internal_symbol]` and mangled symbols are not exported. This prevents symbol conflicts and avoids overriding symbols in ways that causes UB when using a rust cdylib in a rust program. For staticlibs however all symbols leak out of the staticlib. Causing symbol overrides that are potentially UB and symbols conflicts. For example when statically linking spidermonkey, you will get symbol conflicts if the rust version you compile your program with doesn't match the one the rust parts of spidermonkey were compiled with.

cc https://github.com/rust-lang/wg-allocators/issues/108#issuecomment-1323397329
cc https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/.E2.9C.94.20spidermonkey-wasm-rs/near/309604553
Repository: puppeteer
Issue: Support URL instances
Labels: feature

It would be nice if instead of strings, it’s possible to pass URL instances. For example the builtin Node.js `fs` module supports this too.

For example, it would be nice to make such changes:

```diff
- await page.goto(String(url))
+ await page.goto(url)
```

Or a more concrete example:

```diff
- await page.goto(String(new URL('index.html', import.meta.url)))
+ await page.goto(new URL('index.html', import.meta.url))
```
Repository: deno
Issue: Web API request: Storage events
Labels: web,suggestion

It would be great for Deno to support storage events as it already supports the WebStorage API.

```
addEventListener("storage", (event: StorageEvent) => void)
```

https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event
Repository: gin
Issue: Engine.Handler()  should initialize HTTP2 server Read/WriteTimeout to adequate Values
Labels: bug


## Description



<!-- Description of a problem -->

`Engine.Handler()` initialises `http2.Server` without setting `ReadTimeout` and `WriteTimeout` to adequate values, which leaves them to their default **off**  values. 

This expose the http server to [slowloris](https://www.cloudflare.com/en-gb/learning/ddos/ddos-attack-tools/slowloris/) DDoS attacks when dealing with untrusted clients.

You would be leaking connections and run out of descriptors..

## How to reproduce

You start a new engine with any of the `Run` methods. 

```
(...)
gin.SetMode(gin.ReleaseMode)
router = gin.New()
router.RunTLS("some ost url", "some ssl certificate",  "some ssl key")
(...)
```


## Expectations

The method `Engine.Handler()` should initialise the http server with proper timeout values so it doesn't expose it to the issue explained above.

i.e.

```
server := &http2.Server{
  (...),
  ReadTimeout:  5 * time.Second,
  WriteTimeout: 10 * time.Second,
  (...),
}
```



## Actual result
```
func (engine *Engine) Handler() http.Handler {
	if !engine.UseH2C {
		return engine
	}

	h2s := &http2.Server{}
	return h2c.NewHandler(engine, h2s)
}
```

## Environment

- go version: `go1.19.1`
- gin version (or commit ref): `github.com/gin-gonic/gin v1.8.1`
- operating system: `Linux bach 4.9.0-16-amd64 #1 SMP Debian 4.9.272-2 (2021-07-19) x86_64 GNU/Linux`
Repository: material-ui
Issue: [RFC] [docs] Add Flexbox Examples using the Stack component in the docs
Labels: discussion,RFC

### What's the problem? 🤔

If I read the mui system [documentation about flexbox](https://mui.com/system/flexbox/), I was expecting to see some examples of the `Stack` component because it's basically a `Box` that implements `flex`, right?
But there are only examples of flexbox implemented with `Box`.

### What are the requirements? ❓

The `Stack` component should be represented in the Flexbox documentation.

### What are our options? 💡

1. Either rewrite the docs using `Stack`

OR (preferred):

2. Add `flexbox` examples using `Stack` and show them first.

### Proposed solution 🟢

As said before, I would like to see `Stack` represented in the docs. Seeing only `Box` being used might lead to people thinking this is the preferred way of flexbox. 
BUT I can also see that the linked documentation is implemented using **only** `Box`, which might have been done for a valid reason.
Thats why I am asking for comments on this.

### Resources and benchmarks 🔗

_No response_