sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: Duplicated entries when using StoryStoreV7 and auto title globs
Labels: bug,core

**Describe the bug**

When using the new stories format in main.js, given you have a folder structure like this:
![image](https://user-images.githubusercontent.com/1671563/153196191-6e45eb93-fbae-4f19-8710-8993e3226fbd.png)

With the following use case:
- As a user, I want to have auto title stories for everything _but_ the stories under `/stories/molecules`.

Defining a finer grained path + wider path, like so:

```js
module.exports = {
  stories: [
     // default title prefix
    {
      directory: '../stories',
    },
    // defined title prefix
    {
      titlePrefix: 'Composed atoms',
      directory: '../stories/molecules',
    },
  ],
  features: {
    storyStoreV7: true,
  }
}
```

will resolve into duplicated stories:

![image](https://user-images.githubusercontent.com/1671563/153196936-0e9a9dec-4588-4349-a7de-ff9c1fab6e35.png)
Repository: pytorch
Issue: Zero-copy on shared memory of NVIDIA Jetson devices
Labels: feature,triaged,module: jetson

### 🚀 The feature, motivation and pitch

### Feature
Nvidia's Jetson devices share memory between the device's CPU and GPU. In theory, this would enable a [zero-copy](https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#um-unified-memory-programming-hd) where a (zero)-tensor is previously allocated in the memory. Then the actual tensor is written to this mapped tensor and the `.to(cuda:0)` should take close to no time at all. If I understand correctly, Pytorch performs a redundant copy from one place to another on the same memory.

### Motivation
In our real-time inference setting, every millisecond is important. We get a NumPy array from our cameras, convert it to a tensor, move it to the GPU, and pass it through the model. Inference itself can be sped up significantly using tools like `TensorRT`. However, moving the tensor to the Cuda device memory currently takes a lot of time and was identified as a bottleneck for inference speed in this setting. So getting rid of the redundant copy would decrease time without compromising image resolution or model performance.

### Pitch
If shared memory between cpu and gpu is available, adding a simple `zero_copy=True`, like so:
```python
x=torch.randn(1,3,224,244).to('cuda:0', zero_copy=True)
```
should not perform the redundant copying step and return a mapped and pinned tensor. If memory is not shared, it should have no effect besides throwing a warning.

### Alternatives

_No response_

### Additional context

Further reading
- default pinned memory versus zero-copy: https://stackoverflow.com/questions/5209214/default-pinned-memory-vs-zero-copy-memory
- Pytorch currently does not support zero-copy https://forums.developer.nvidia.com/t/torch-tensor-cuda-very-slow/125857
- CUDA docu on Unified Memory Programming https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#um-unified-memory-programming-hd
- Pytorch does zero-copy in `from_numpy()` https://blog.christianperone.com/2018/03/pytorch-internal-architecture-tour/






cc @ptrblck @puririshi98 @ngimel
Repository: rust
Issue: Large memory usage in codegen, probably due to symbol names
Labels: A-LLVM,T-compiler,I-compilemem,C-bug

My crate (around 1000 lines of code) composes streams, futures, closures and other types without type erasure through `impl Trait` return values and associated types (thanks to `type_alias_impl_trait`). The resulting symbol names quickly reach rustc-demangle's 1 million character limit, and the whole build uses 7GB, see this extract of a run with `-Ztime-passes`:

```
[…]
time:   0.000; rss:  329MB ->  329MB (   +0MB)  find_cgu_reuse
time: 110.308; rss:  327MB -> 7141MB (+6814MB)  codegen_to_LLVM_IR
time: 244.762; rss:  179MB -> 7141MB (+6962MB)  codegen_crate
time:   0.000; rss: 7141MB -> 7141MB (   +0MB)  serialize_dep_graph
[…]
```

This is with `symbol-mangling-version=v0`, `incremental = false`, `lto = true`, `opt-level > 0` and `debug = 0`. Wwithout any of these options rustc is killed on my machine at 12GB usage.
Repository: flutter
Issue: Compatibility with CPack
Labels: c: new feature,platform-windows,c: proposal,a: desktop,P3,team-windows,triaged-windows

## Use case
I need cpack to package my application as an msi, but flutter isn't compatible with it out of the box. Flutter uses absolute paths for its install targets, which is incompatible with cpack. 

## Workaround
1. In `windows/CMakeLists.txt` I replaced every occurrence of `CMAKE_INSTALL_PREFIX` with `.`
2. I added an install target before every other install target:
```cmake
install(SCRIPT preInstall.cmake COMPONENT Runtime)
```
3. created `windows/preInstall.cmake` with:
```cmake
if(NOT CMAKE_INSTALL_PREFIX OR CMAKE_INSTALL_PREFIX STREQUAL "$<TARGET_FILE_DIR:BINARY_NAME>")
    set(CMAKE_INSTALL_PREFIX "${CMAKE_BINARY_DIR}/runner/${CMAKE_INSTALL_CONFIG_NAME}")
endif()
```
where I replaced `BINARY_NAME` with my package name, which you can find in windows/CMakeLists.txt, where it says:
```cmake
set(BINARY_NAME "my_package")
```
4. I placed my CPack configuration at the end of `windows/CMakeLists.txt`

## Proposal

Flutter should just support it out of the box! The only thing that may need to change is, that flutter provides `CMAKE_INSTALL_PREFIX` at installation time.
Repository: go
Issue: x/build: android-arm-corellium failures with clang-13 link errors
Labels: Builders,OS-Android,NeedsInvestigation,arch-arm

`greplogs --dashboard -md -l -e 'clang-13: error: linker command failed' --since=2022-01-01`

[2022-02-09T05:39:47-255acb0/android-arm-corellium](https://build.golang.org/log/bd83883312a1fa2ea59459e05194c4a73c9e334a)
[2022-02-08T23:29:18-c5bce74/android-arm-corellium](https://build.golang.org/log/e3ccd4e8b0f098ae80607c1e0f11f8b7dc2dbb0c)
[2022-02-08T22:39:05-0cbe3e0/android-arm-corellium](https://build.golang.org/log/d64a60a5bddd3b06872eec4bdf4a3a0726c2dce3)
[2022-02-08T22:26:40-5442f4d/android-arm-corellium](https://build.golang.org/log/e3b9de10bafd2b2715ecf53b815a88de85468f7c)
[2022-02-08T22:25:54-5406328/android-arm-corellium](https://build.golang.org/log/4ef518b9c0cb474359f7aaa227328634396f7f35)
[2022-02-08T22:16:52-3e514a0/android-arm-corellium](https://build.golang.org/log/34d484e951a46b4ac13b0adb1b51ada9d9f7e700)
[2022-02-08T21:31:01-1fe8f47/android-arm-corellium](https://build.golang.org/log/d33fb40018cf25cc2ccac2b66d338bc295ee505b)

@steeve, @changkun: was this caused by a configuration change? (If it has been reverted, perhaps run `retrybuilds` to clear the failures?)
Repository: deno
Issue: APIs to facilitate connection pools
Labels: suggestion

I am unsure if [`Deno.connect`](https://doc.deno.land/deno/stable/~/Deno.connect) requires clients to implement connection pooling, because the current API surface that `Deno.Conn` exposes makes it tricky to implement one (though, [folks indeed have impl poolers atop it using `try..catch` semantics](https://github.com/denodrivers/postgres/blob/b68d3ebfd1a5805050f12e74ddaa4df3185bb86f/client.ts#L486)).

In comparing with NodeJS `net`, I believe equivalent of these two APIs are needed in [`Deno.Conn`](https://doc.deno.land/deno/stable/~/Deno.Conn) (TCP):

1. [`socket.readyState`](https://nodejs.org/api/net.html#socketreadystate) tells if conn is open or half-open.
2. [`socket.destroyed`](https://nodejs.org/api/net.html#socketdestroyed) tells if conn is open at all.
3. An adjustable [`socket.keepalive`](https://nodejs.org/api/net.html#socketsetkeepaliveenable-initialdelay).

([Here's how we use those APIs to determine health of a tcp-conn](https://github.com/serverless-dns/serverless-dns/blob/688c3110f6/src/core/dns/conns.js#L20-L22)).

NodeJS `net` also exposes [`socket.resume`](https://nodejs.org/api/net.html#socketresume) and [`socket.pause`](https://nodejs.org/api/net.html#socketpause), though those are not really required to build a pooler.

From NodeJS `dgram`, for _connected_ UDP sockets, [`Event.close`](https://nodejs.org/api/dgram.html#event-close) and `Event.error` come in handy to remove failed conns preemptively from the pool.

([Here's how we use those events to evict udp-conns from the pool](https://github.com/serverless-dns/serverless-dns/blob/688c3110f6/src/core/dns/conns.js#L152-L153)).

Of course, if Deno doesn't require client-code to pool (TCP/UDP) conns at all (like for HTTP), then that's even more awesome. [From this github discussion](https://github.com/tokio-rs/tokio/issues/1079), it is confirmed that `tokio` doesn't pool conns, but that [`tower`](https://github.com/tower-rs/tower) does... but I am not fluent in Rust to deduce anything from Deno's use of `tower`.

cc: @bartlomieju
Repository: yt-dlp
Issue: [AlphaPorno]: Unable to extract video url
Labels: good first issue,NSFW,site-bug,patch-available

### Checklist

- [X] I'm reporting a broken site
- [X] I've verified that I'm running yt-dlp version **2022.02.04**. ([update instructions](https://github.com/yt-dlp/yt-dlp#update))
- [X] I've checked that all provided URLs are alive and playable in a browser
- [X] I've checked that all URLs and arguments with special characters are [properly quoted or escaped](https://github.com/ytdl-org/youtube-dl#video-url-contains-an-ampersand-and-im-getting-some-strange-output-1-2839-or-v-is-not-recognized-as-an-internal-or-external-command)
- [X] I've searched the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues including closed ones. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)
- [ ] I've read about [sharing account credentials](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#are-you-willing-to-share-account-details-if-needed) and I'm willing to share it if required

### Region

_No response_

### Description

See title and log.
The same error happens with `Youtube-dl`.

### Verbose log

```shell
yt-dlp -vU --no-check-certificates "https://www.alphaporno.com/videos/anal-threesome-for-girls-younger-than-the-average/"
[debug] Command-line config: ['-vU', '--no-check-certificates', 'https://www.alphaporno.com/videos/anal-threesome-for-girls-younger-than-the-average/']
[debug] Encodings: locale cp1252, fs utf-8, out utf-8, err utf-8, pref cp1252
[debug] yt-dlp version 2022.02.04 [c1653e9] (win_exe)
[debug] Python version 3.8.10 (CPython 64bit) - Windows-10-10.0.19044-SP0
[debug] exe versions: ffmpeg 4.2.3, ffprobe 4.2.3
[debug] Optional libraries: Cryptodome, mutagen, sqlite, websockets
[debug] Proxy map: {}
Latest version: 2022.02.04, Current version: 2022.02.04
yt-dlp is up to date (2022.02.04)
[debug] [AlphaPorno] Extracting URL: https://www.alphaporno.com/videos/anal-threesome-for-girls-younger-than-the-average/
[AlphaPorno] anal-threesome-for-girls-younger-than-the-average: Downloading webpage
ERROR: [AlphaPorno] anal-threesome-for-girls-younger-than-the-average: Unable to extract video url; please report this issue on  https://github.com/yt-dlp/yt-dlp , filling out the "Broken site" issue template properly. Confirm you are on the latest version using -U; please report this issue on  https://github.com/yt-dlp/yt-dlp , filling out the "Broken site" issue template properly. Confirm you are on the latest version using -U
  File "yt_dlp\extractor\common.py", line 612, in extract
  File "yt_dlp\extractor\alphaporno.py", line 41, in _real_extract
  File "yt_dlp\extractor\common.py", line 1186, in _search_regex
```
Repository: electron
Issue: [Feature Request]: Add a flag/setting to allow large cursors intersecting native UI
Labels: enhancement :sparkles:

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

In 2021 Chrome [started hiding](https://chromestatus.com/feature/5825971391299584) custom cursors that are larger than 32x32 when they intersect native UI to prevent abuse from websites. That makes sense for websites, but not so much for native applications that fully control the content being rendered. Particularly games, in which large cursors is very common, and having them fall back to native cursors when the cursor approaches the edge of the screen looks unprofessional.


### Proposed Solution

The proposed solution is having that code be conditional (enabled by default) so that particular apps can disable it. Ideally it would be a setting in `WebContents`, so we can choose where it's safe to disable that code because we control the contents being rendered.


### Alternatives Considered

 Alternatively, a commandline flag would also work in some cases (apps that don't render third-party content in any window).

### Additional Information

_No response_
Repository: three.js
Issue: MeshPhysicalMaterial should use the thin surface model when thickness is zero
Labels: Enhancement

The [thin-surface model](https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_materials_transmission) and the [volume model](https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_materials_volume) should be separate models in the `MeshPhysicalMaterial` shader.

Currently, only the volume model is implemented, and if thickness is 0, all components of attenuation color must be non-zero, otherwise the material renders black. A properly-implemented thin-surface model would prevent that.

Maybe define `USE_VOLUME` if `( .thickness > 0 )`. Then something like:

```glsl
#ifdef USE_TRANSMISSION

	#ifdef USE_TRANSMISSIONMAP

		transmissionFactor *= texture2D( transmissionMap, vUv ).r;

	#endif

	#ifdef USE_THICKNESSMAP

		thicknessFactor *= texture2D( thicknessMap, vUv ).g;

	#endif

	#ifdef USE_VOLUME

		vec4 transmission = getIBLVolumeRefraction( ... );

	#else

		vec4 transmission = getIBLThinSurfaceRefraction( ... );

	#endif

	totalDiffuse = mix( totalDiffuse, transmission.rgb, transmissionFactor );

#endif
```

 three.js version: r.137
Repository: pytorch
Issue: Can't forward pass conv2d with kernel_size=1, and padding=1
Labels: needs reproduction,module: build,module: nn,module: convolution,triaged,module: macos,module: nnpack,module: arm

### 🐛 Describe the bug

I was trying to implement resnet but using `nn.functional` module instead, and I ran across this error. This behaviour only happen when `kernel_size=1`, and `padding=1`. Is this an expected behaviour?

Reproduce
```python
import torch
from torch.nn import functional as F

F.conv2d(
    torch.rand(16, 3, 10, 10),
    torch.rand(5, 3, 1, 1),
    bias=None,
    stride=1,
    padding=1,
    dilation=1,
    groups=1,
)
```

**Expected Behaviour**
The output is return

**Current Behaviour**
Throw runtime error
```python
RuntimeError: NNPACK SpatialConvolution_updateOutput failed
```

### 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.1 (arm64)
GCC version: Could not collect
Clang version: 13.0.0 (clang-1300.0.29.30)
CMake version: version 3.22.2
Libc version: N/A

Python version: 3.9.9 | packaged by conda-forge | (main, Dec 20 2021, 02:41:07)  [Clang 11.1.0 ] (64-bit runtime)
Python platform: macOS-12.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
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

Versions of relevant libraries:
[pip3] numpy==1.19.5
[pip3] pytorch-lightning==1.5.7
[pip3] pytorchcv==0.0.67
[pip3] torch==1.10.0
[pip3] torch-summary==1.4.5
[pip3] torchmetrics==0.6.2
[pip3] torchvision==0.11.2
[conda] numpy                     1.19.5           py39h1f3b974_2    conda-forge
[conda] pytorch                   1.10.0          cpu_py39h7601aee_0    conda-forge
[conda] pytorch-cpu               1.10.0          cpu_py39hd610c6a_0    conda-forge
[conda] pytorch-lightning         1.5.7              pyhd8ed1ab_0    conda-forge
[conda] pytorchcv                 0.0.67                   pypi_0    pypi
[conda] torch-summary             1.4.5                    pypi_0    pypi
[conda] torchmetrics              0.6.2              pyhd8ed1ab_0    conda-forge
[conda] torchvision               0.11.2                   pypi_0    pypi

cc @malfet @seemethere @albanD @mruberry @jbschlosser @walterddr @kshitij12345
Repository: godot
Issue: FileSystem rename causes git delete+add instead of git rename
Labels: topic:editor,needs testing

### Godot version

3.4.2

### System information

Linux

### Issue description

FileSystem rename causes git delete+add instead of git rename



### Steps to reproduce

Add a PNG to your project
Open up your git GUI or CLI (for users new to git I recommend GitHub Desktop).
Commit your changes (1st commit).
Use Godot's FileSystem UI to rename the PNG.
Commit your changes (2nd commit).
With your git GUI or CLI view your 2nd commit's file changes.
It should show as PNG renamed, not PNG deleted with PNG added.

### Minimal reproduction project

_No response_
Repository: rust
Issue: Tracking Issue for `cfg_target_has_atomic_equal_alignment`
Labels: T-lang,C-tracking-issue,S-tracking-needs-to-bake,S-tracking-design-concerns

This is a tracking issue for the `target_has_atomic_equal_alignment` CFG flag which was added in #76965 for `Atomic*::from_mut`.

It indicates whether an `AtomicX` has the same alignment as the equivalent `X` integer type. On some 32-bit platforms (e.g. x86) `AtomicI64` has an alignment of 8 while `i64` is only aligned to 4 bytes.

---

Potential design concerns:

* Open question of whether a dedicated cfg is necessary over cfg(accessible) on the from_mut method specifically, which is what is currently gated on this cfg
Repository: go
Issue: x/pkgsite: show `cmd/go` as the top entry in search result for 'go'
Labels: NeedsInvestigation,pkgsite,pkgsite/search

### What is the URL of the page with the issue?
https://pkg.go.dev/search?q=go

### Screenshot
![Screen Shot 2022-02-09 at 1 29 16 PM](https://user-images.githubusercontent.com/4999471/153266244-618a5cdc-7bd8-49c0-b64a-5e136213b177.png)

### What did you do?

search `go`


### What did you expect to see?

go command doc (https://pkg.go.dev/cmd/go)

### What did you see instead?

It's a command, so it's unlikely to see the page highly ranked in the current pkg site.
But I think `go` is special and may deserve special care.

Users can access the page with `cmd/go` query.
Repository: flutter
Issue: [Proposal] flutter tool command for renaming the project 
Labels: c: new feature,tool,c: proposal,P3,team-tool,triaged-tool

## Use case
I have often needed to rename a Flutter project, surprisingly, almost right after creating a new project. Right now, it's hard to go over all the places where the project name is used and manually change them all.

## Proposal
It would be great if there were a command for renaming the project to ensure I'm doing it correctly and quickly in all places. I understand that there might be places where the user needs to decide if they want to do the rename (like, for example, in Android java package names), so maybe having options or prompts asking the user about them would be nice.
Repository: TypeScript
Issue: Remove the error on importing a json document in esm files in `moduleResolution: nodenext`
Labels: Domain: ES Modules,dependencies

As of [today](https://github.com/nodejs/node/pull/41736) esm json module support is unflagged in node, which means our `moduleResolution: nodenext` target should probably no longer issue an error on it when `resolveJsonModule` is set. It's still appropriate to issue the error for `node12`, probably.
Repository: godot
Issue: Main toolbar menus in the Godot user interface are not expanding when clicked
Labels: bug,platform:linuxbsd,topic:rendering,topic:editor,regression

### Godot version

4.0 alpha 2

### System information

Ubuntu 21.04, AMD Ryzen Threadripper 3960X CPU, two NVIDIA RTX 2080 SUPER GPUs, native NVIDIA driver 470.86, X11, Vulkan

### Issue description

This is an issue I have noticed since the unofficial prereleases of Godot 4.0.

Basically, when I open a project in Godot, the main menu items (Scene, Project, etc) do not expand when clicked. The window's title grays sometimes, suggesting something is happening, but no menu contents appear. I have included a short video exhibiting the problem. In this video I am clicking the menus, but you will see that no menu expands:

https://user-images.githubusercontent.com/3464572/153281061-6112353b-efc5-4c7c-afae-8147f9a1475f.mp4

Since I have two graphics cards in this machine, it seems possible to me that Godot is becoming confused about where to send the menu contents. X Windows forces you to create a second screen for the second video card in order for it to be recognized correctly at boot. Nothing runs on it, nothing is displayed on it, and I don't have a monitor hooked to it, but there is a second screen going. The main display is :0.0, while the unused one is :0.1. I pasted a view from nvidia-settings:

![image](https://user-images.githubusercontent.com/3464572/153281958-2f679019-26a1-4442-ad7c-79f5c5c41e25.png)

It seems this issue might be related to #50292. I poked around through the issues but there are so many it was hard to tell if this has been reported before. I'm sorry if it is a duplicate.

### Steps to reproduce

What I did was import a project from the asset library, then open it. I see the issue whenever I click any of the menu items.

The same issue occurs when creating a new project as well.

### Minimal reproduction project

I am going to skip this step since I experience the issue in any project at all, including a brand new empty one.
Repository: opencv
Issue: OpenGL support does not turn on on linux for tegra(nvidia jetson OS) 
Labels: question (invalid tracker),category: build/install,incomplete

The -DWITH_OPENGL and -DHAVE_OPENGL flags do not lead to opencv compiling with opengl support, even though openGL is present on the system.

system: nvidia jetson nano with 4.9.253-tegra 

opencv version 4.5.5

cmake command :cmake .. -DWITH_OPENGL=ON 


output  : 
[opengl_output.txt](https://github.com/opencv/opencv/files/8035949/opengl_output.txt)

opengl version: 4.6.0 NVIDIA 32.6.1