sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: excalidraw
Issue: FR: drag and drop multiple .excalidrawlib from OS file explorer should import all files, not only one
Labels: enhancement

Drag and drop multiple .excalidrawlib files from the OS file explorer into excalidraw. Only one of the libraries will get imported.
It would be nice if all the libraries would get imported.

see the related issue raised on the obsidian-excalidraw issue list: [#744](https://github.com/zsviczian/obsidian-excalidraw-plugin/issues/744)
Repository: neovim
Issue: nvim_buf_set_text in insert mode should update dot repeat
Labels: bug,api,needs:discussion,insert-mode

### Neovim version (nvim -v)

NVIM v0.8.0-dev+141-g55187de11

### Vim (not Nvim) behaves the same?

N/A

### Operating system/version

N/A

### Terminal name/version

N/A

### $TERM environment variable

N/A

### Installation

N/A

### How to reproduce the issue

Given the following steps in lua:

```lua
vim.api.nvim_buf_set_text(0, 0, 0, 0, 0, {'one'})
vim.api.nvim_input('ciw')
vim.api.nvim_buf_set_text(0, 0, 0, 0, 0, {'two'})
vim.api.nvim_input('<Esc>u')
vim.api.nvim_input('.')
```

### Expected behavior

The buffer contains "two".




### Actual behavior

The buffer is empty (the ciw was repeated, but not the insertion).

`nvim_buf_set_text` should only update dot repeat if the change is in one continuous region (someone typing or deleting). The changes should be accumulated until there is a discontunity.

Essentially, if `start == end` (insertion), or `replacement == [""]` (deletion), dot-repeat should accumulate just like `nvim_input` in insert mode. 

## Background
This is very important for vscode-neovim to improve reliablility and remove significant workarounds and bloat. 
https://github.com/vscode-neovim/vscode-neovim/pull/992

Vscode handles typing in insert mode, and then sends document changes to nvim via `nvim_buf_set_text` or `nvim_buf_set_lines`. However, because neovim does not properly record dot repeat, a workaround is currently needed that opens a scratch buffer, replays the changes by typing, and then returns to the original buffer.
Repository: neovim
Issue: inccommand: vim.cmd behaves differently in preview callback
Labels: bug,inccommand

### Neovim version (nvim -v)

NVIM v0.8.0-dev-779-g7ebcb9b33

### Vim (not Nvim) behaves the same?

N/A

### Operating system/version

Linux Mint 20.2

### Terminal name/version

Kitty 0.15

### $TERM environment variable

xterm-kitty

### Installation

appimage

### How to reproduce the issue

- `nvim --clean test.lua`
- Paste the following code and source the file with `:luafile %`:
```lua
vim.api.nvim_create_user_command("Norm", "", {
  preview = function(_, _, _)
    vim.cmd("norm f~ifoo")
    return 2
  end,
})
```
- Move to the first line
- Type `:Norm`

### Expected behavior

The text in the buffer should not change.

### Actual behavior

`foo` is inserted into the buffer at the current cursor position even though there is no `~` character on the first line. This behavior deviates from the default behavior of `f` and does not occur when running `vim.cmd("f~ifoo")` directly.

This issue was initially reported here: https://github.com/smjonas/live-command.nvim/issues/6

@famiu
Repository: pytorch
Issue: Add a new argument `check_inf=True` (by default) or check_pos_inf / check_neg_inf to anomaly mode
Labels: module: autograd,triaged,enhancement

should if also have a new argument `check_inf=True` (by default) or check_pos_inf / check_neg_inf for symmetry with nan? (minor)

_Originally posted by @vadimkantorov in https://github.com/pytorch/pytorch/issues/83481#issuecomment-1215925856_

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: storybook
Issue: Ability to change react folder
Labels: feature request,needs triage

**Is your feature request related to a problem? Please describe**
We are using storybook in a monorepo with a lot of packages that export react components. A common way to develop in this monorepo is link each package in the monorepo in a consumer application, but when linking a component that uses hooks we run into an error because there are two instances of react running in the application: the one in the application itself and the one in the monorepo. A solution to this is install react with an alias in the package.json: we put `"react-alias": "npm:react@^16.14.0"` and then in the tests we create an alias to map `react` to `react-alias`. We did the same for storybook webpack config overrides, however when running the storybook it is not able to resolve `react/package.json` that is imported by `@storybook/ui`.

**Describe the solution you'd like**
The above problem could be solved if we can override the path where it tries to import react with a configuration field. Could be something like `reactAlias: 'react-alias'` 

**Describe alternatives you've considered**
An alternative solution we considered is to create a symbolic link from `node_modules/react` to `node_modules/react-alias` before starting storybook and remove it after exit. The problem with this is cross operating systems compatibility.

**Are you able to assist to bring the feature to reality?**
yes
Repository: pytorch
Issue: I have the same issue as @samgelman on my MacOS.
Labels: triaged,module: macos,module: openmp,module: third_party

I have the same issue as @samgelman on my MacOS. 

Notably 1.10.1, 1.11.0 works fine but 1.10.2 and 1.12.1 shows:
```
OMP: Error #15: Initializing libiomp5.dylib, but found libomp.dylib already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://www.intel.com/software/products/support/.
Abort trap: 6
```
One observation is that both 1.10.1 and 1.11.0 also come with `libuv` installation, which might have made the difference.

The workaround `KMP_DUPLICATE_LIB_OK=TRUE` causes a segfault.

Below is a working env:
```
python3 -mtorch.utils.collect_env
Collecting environment information...
PyTorch version: 1.10.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.5 (x86_64)
GCC version: Could not collect
Clang version: 12.0.0 (clang-1200.0.31.1)
CMake version: Could not collect
Libc version: N/A

Python version: 3.8.13 (default, Mar 28 2022, 06:16:26)  [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
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] mypy-extensions==0.4.3
[pip3] numpy==1.21.5
[pip3] torch==1.10.1
[conda] blas                      1.0                         mkl  
[conda] mkl                       2021.4.0           hecd8cb5_637  
[conda] mkl-service               2.4.0            py38h9ed2024_0  
[conda] mkl_fft                   1.3.1            py38h4ab4a9b_0  
[conda] mkl_random                1.2.2            py38hb2f4e1b_0  
[conda] mypy_extensions           0.4.3            py38hecd8cb5_1  
[conda] numpy                     1.21.5           py38h2e5f0a9_3  
[conda] numpy-base                1.21.5           py38h3b1a694_3  
[conda] pytorch                   1.10.1                  py3.8_0    pytorch
```

_Originally posted by @yuanmao in https://github.com/pytorch/pytorch/issues/78490#issuecomment-1217134036_

cc @malfet @albanD
Repository: rust
Issue: fetch_max broken for atomici8 and atomici16 on some targets.
Labels: A-LLVM,O-Arm,T-compiler,C-bug,A-atomic

The rust atomic crate was recently uploaded to Debian, unfortunately on a number of Debian architectures it's tests failed.

```
---- tests::atomic_i16 stdout ----
thread 'tests::atomic_i16' panicked at 'assertion failed: `(left == right)`
  left: `-25`,
 right: `30`', src/lib.rs:448:9
```

```
---- tests::atomic_i8 stdout ----
thread 'tests::atomic_i8' panicked at 'assertion failed: `(left == right)`
  left: `-25`,
 right: `30`', src/lib.rs:428:9
```

The debian architectures where it failed and the corresponding rust architectures are listed below.

armel -> armv5te-unknown-linux-gnueabi
mips64el -> mips64el-unknown-linux-gnuabi64
mipsel -> mipsel-unknown-linux-gnu
powerpc -> powerpc-unknown-linux-gnu


My guess is that this is a bug in fallback code used when the architecture does not natively support 8 and 16 bit atomics.

I produced the following testcase to confirm this was not a problem in the atomic crate, but instead an issue in either the compiler or the standard library. I tested this on Debian armel.

```rust
use std::sync::atomic::Ordering::SeqCst;
use std::sync::atomic::AtomicI8;
use std::sync::atomic::AtomicI16;
use std::sync::atomic::AtomicI32;
fn main() {
    let a = AtomicI8::new(30);
    println!("{}",a.fetch_max(-25,SeqCst));
    println!("{}",a.load(SeqCst));
    let a = AtomicI16::new(30);
    println!("{}",a.fetch_max(-25,SeqCst));
    println!("{}",a.load(SeqCst));
    let a = AtomicI32::new(30);
    println!("{}",a.fetch_max(-25,SeqCst));
    println!("{}",a.load(SeqCst));
}
```

I expected this to print 30 six times, but the second and fourth lines of the output are instead -25, this shows fetch_max is not being implemented correctly for AtomicI8 and AtomicI16 (but is being implemented correctly for AtomicI32).

I've only tested this with Debian's rustc so far, I may try to test with upstream rustc but this is complicated by the fact that I don't think upstream offers binaries for armv5te-unknown-linux-gnueabi

### Meta
`rustc --version --verbose`:
```
rustc 1.59.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: armv5te-unknown-linux-gnueabi
release: 1.59.0
LLVM version: 13.0.1
```
Repository: yt-dlp
Issue: Site based configuration 
Labels: enhancement,core:extractor

### DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

- [X] I understand that I will be **blocked** if I remove or skip any mandatory\* field

### Checklist

- [X] I'm requesting a feature unrelated to a specific site
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I'm running yt-dlp version **2022.08.14** ([update instructions](https://github.com/yt-dlp/yt-dlp#update)) or later (specify commit)
- [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)

### Provide a description that is worded well enough to be understood

I’m looking for a way to define a config with site based rules, rather than three or four separate configs per site. Using ini, this might look like:
```ini
[global]
proxy: "127.0.0.1:3500"

[music.youtube.com]
format: 22
output: "/home/user/Music/%(title)s.%(ext)s"

[youtube.com]
format: 140
embed-subtitles: True

etc
```
It doesn’t necessarily have to be ini, but I think being able to define site specific rules in a config would be much handier. 

### Provide verbose output that clearly demonstrates the problem

- [ ] Run **your** yt-dlp command with **-vU** flag added (`yt-dlp -vU <your command line>`)
- [ ] Copy the WHOLE output (starting with `[debug] Command-line config`) and insert it below

### Complete Verbose Output

NA
Repository: pytorch
Issue: OpenJDK libtorch_cpu.so stack guard warning
Labels: oncall: java

### 🚀 The feature, motivation and pitch

When deploying a pytorch model using JavaCPP presets for pytorch + libtorch 1.10.2, java `17.0.3+7-Ubuntu-0ubuntu0.20.04.1` emits the following warning: 
```
OpenJDK 64-Bit Server VM warning: You have loaded library /mnt/lib/cache/org.bytedeco.pytorch-1.10.2-1.5.7-linux-x86_64.jar/org/bytedeco/pytorch/linux-x86_64/libtorch_cpu.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
```
I reported this in https://github.com/bytedeco/javacpp-presets/issues/1208 but it's apparently caused by the way libtorch is built, not by JavaCPP. 

Shouldn't pytorch be built with stack guard? 

The answer may well be 'no', but it would be great to understand better 'why' in that case. Thanks!

### Alternatives

Ignore the warning. 

### Additional context

https://stackoverflow.com/questions/1629685/when-and-how-to-use-gccs-stack-protection-feature
Repository: flutter
Issue: [Windows] LiveWidgetController occasionally handles events 6ms early
Labels: a: tests,framework,c: performance,platform-windows,a: desktop,P2,team-windows,triaged-windows

## Details

This is a continuation of [109323](https://github.com/flutter/flutter/issues/109323) which has been worked around.

On Windows, the `LiveWidgetController.handlePointerEventRecord` method occasionally seems to handle events up to 6ms early. This was found while running the `"Input event array on LiveWidgetController"` test in `live_widget_controller_test.dart`. Specifically, it seems to be consistent after the `"matchesGoldenFile calls update on comparator if autoUpdateGoldenFiles is true"` test.

I've not yet confirmed whether this can be replicated with tests locally, or if it's related to the specific machines/processes in the test CI pipelines.

When this is traced and resolved, the assert in the `"Input event array on LiveWidgetController"` test should be returned to `diff.inMilliseconds > -1`.

**Target Platform:** Windows
Repository: go
Issue: wiki: WebAssembly wiki page is out of date
Labels: Documentation,NeedsFix,arch-wasm

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What is the URL of the page with the issue?

https://github.com/golang/go/wiki/WebAssembly

### What is your user agent?

It doesn't matter.

<!--
You can find your user agent here:
https://www.google.com/search?q=what+is+my+user+agent
-->



### Screenshot

N/A

<!--
Please paste a screenshot of the page.
-->



### What did you do?

N/A

<!--
If possible, provide a recipe for reproducing the error.
-->



### What did you expect to see?

More up to date wiki page for wasm.

### What did you see instead?

Last update to the wiki page seems to be with go 1.12.
Repository: terminal
Issue: Use a binary tree/heap to represent panes
Labels: Help Wanted,Area-TerminalControl,Product-Terminal,Issue-Task,Area-CodeHealth

# Problem

The `Pane` class acts simultaneously as the data model to represent actual panes and as splits which contain nothing but exactly 2 child panes and a split ratio / direction. In a sense `Pane` represents both a leaf and internal nodes in a binary tree simultaneously. Member functions of `Pane` iterating through that tree are complex and make changes difficult (#13306), as iteration happens almost exclusively via recursion, making retaining state cumbersome.

# Proposal

Let's implement a binary heap class that works independently of `Pane`. This would allow us to use regular text-book algorithms for its implementation. Internal nodes of the heap would retain split ratios and directions and leaf nodes of the heap contain `shared_ptr<Pane>` references. Traversal/iteration would also be simplified. This separate heap would be cheap to clone, allowing us to implement things like UI state persistence (#13306) more easily.
Repository: godot
Issue: BoneAttachment3D serializes bone_idx after bone_name: the index is off when skeleton changes and model is reimported
Labels: bug,topic:import,topic:3d

### Godot version

v4.0.alpha.custom_build [2475393f2]

### System information

Windows 10, GLES3, NVidia RTX 3080

### Issue description

If you have a BoneAttachment3D attached to a bone, on an imported .blend file, then you change the blend file to add or remove a bone such that the index of the bone it's attached to changes, the attachment will be on the incorrect bone but will display the correct bone name.

Not sure if this happens with BoneAttachment in Godot 3.

The tscn file stores both a bone_idx and bone_name, so it should be possible to, on reimport, find the correct bone by name if the bone idx doesn't match the one with the name.

### Steps to reproduce

- Create attachment on a blender file you've imported with multiple bones.
- Remove or add bones to the armature forcing the indexes to change.
- Note that your attachment is attached to a different bone than it states.

### Minimal reproduction project

Here's a .blend file that reproduces the issue.  Add main_character.blend to your scene, attach to "head" or "hand_r", then copy main_character_after.blend to main_character.blend and note the attachments become broken.

... well, "something went really wrong" when I tried to attach it.

Edit: After editing a comment, apparently I can edit this with the correct text (hopefully).  Here's the .blend files to reproduce this.

[character_bone_index_problem.zip](https://github.com/godotengine/godot/files/9378494/character_bone_index_problem.zip)
Repository: go
Issue: cmd/gofmt: Trailing newline in comments is removed since 1.19
Labels: NeedsDecision,early-in-cycle

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.19 darwin/arm64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

```
$ go env
GOARCH="arm64"
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOOS="darwin"
GOVERSION="go1.19"
```

### What did you do?

I saved an existing file that had a dense and detailed comment followed by a dense and detailed function signature, that contained a deliberate trailing newline to separate the last paragraph from the function's signature to improve readability:

```go
package yep

// Sed facilisis diam vulputate, lobortis lacus vel, volutpat mi. In quis dolor ac nisi
// volutpat dictum sed at lorem. Curabitur sodales diam a porttitor congue. Quisque diam
// sem, porta ac interdum consectetur, ornare consectetur quam. Sed imperdiet tincidunt
// turpis, at consectetur purus ullamcorper et. Curabitur egestas turpis at mauris
// sollicitudin convallis.
//
// In pulvinar purus nec lacus pulvinar placerat sit amet scelerisque elit. Donec tortor
// ante, laoreet ac congue at, facilisis vitae nulla. Vestibulum porta ultrices augue, ut
// hendrerit odio tincidunt id. In interdum sagittis neque, egestas placerat turpis luctus
// et. Sed fringilla purus a vehicula euismod. Phasellus ut lorem non quam aliquam tempus.
// Aliquam a dapibus ex. Maecenas erat purus, facilisis vitae elit at, aliquam eleifend.
//
func DoStuff[K comparable, V ~int64 | ~uint64](key K, value V) (stuff Stuff err error) {
    // ...
}
```


### What did you expect to see?

I expected to see the final newline in the comment body preserved.


### What did you see instead?

The final newline was removed:

```go
// Sed facilisis diam vulputate, lobortis lacus vel, volutpat mi. In quis dolor ac nisi
// volutpat dictum sed at lorem. Curabitur sodales diam a porttitor congue. Quisque diam
// sem, porta ac interdum consectetur, ornare consectetur quam. Sed imperdiet tincidunt
// turpis, at consectetur purus ullamcorper et. Curabitur egestas turpis at mauris
// sollicitudin convallis.
//
// In pulvinar purus nec lacus pulvinar placerat sit amet scelerisque elit. Donec tortor
// ante, laoreet ac congue at, facilisis vitae nulla. Vestibulum porta ultrices augue, ut
// hendrerit odio tincidunt id. In interdum sagittis neque, egestas placerat turpis luctus
// et. Sed fringilla purus a vehicula euismod. Phasellus ut lorem non quam aliquam tempus.
// Aliquam a dapibus ex. Maecenas erat purus, facilisis vitae elit at, aliquam eleifend.
func DoStuff[K comparable, V ~int64 | ~uint64](key K, value V) (stuff Stuff err error) {
    // ...
}
```

I'd really like to see the old behaviour restored here as function signatures like the one in my example can be crowded out by the last line of the preceding paragraph.
Repository: material-ui
Issue: [Menu] Component appear far from their original position when the zoom style is applied
Labels: bug 🐛,component: menu

### Order ID 💳

48778

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### The problem in depth 🔍

**Current behavior :** 
The pagination component appears far from its original position when the zoom style is applied like the screenshots below from my local computer.

- Here is the condition before the zoom style applied (height dimension > 500px)
![Capture](https://user-images.githubusercontent.com/103932140/184792028-bca18b65-3a99-48d7-99e1-1aae4ef9b54f.PNG)


- Here is the condition after the zoom style applied (height dimension < 500px)
![Capture](https://user-images.githubusercontent.com/103932140/184791810-5f2eb62b-05e5-4358-a588-af449a05ddb3.PNG)

**Expected behavior :**
The pagination component appeasr from its original position whether the zoom style is applied or not.

**Steps to reproduce :** 
Steps:
1. Run the codesandbox above
2. Test the appearance of the pagination components
3. The case appears

**Context :** 
What I want to do is to apply the zoom property on smaller screen sizes so I create this code :
- apply no zoom style to the body and some container components
- apply the zoom style to all component contents

The zoom style is only applied for specific screen sizes (code from my local computer) :

```
// 1.176470588 = 1 / 0.85

'@media only screen and (max-height: 820px)': {
  'body': {
    zoom: 0.85,
  },
  '.zoom': {
    zoom: 0.85,
  },
  '.no-zoom': {
    zoom: 1.176470588,
  },
}
```

Here is the codesandbox demo : https://codesandbox.io/s/mui-floating-issues-lsimnx

I also have almost the same problem, but this problem occurs in some components like Menu and Tooltip. I've raised this issue in [here](https://github.com/mui/material-ui/issues/32777), but haven't found a solution yet. I hope you can help solve this problem, thank you.


### Environment 

<details>
  <summary>Dependencies</summary>

```
"dependencies": {
  "@emotion/react": "^11.9.0",
  "@emotion/styled": "^11.8.1",
  "@mui/icons-material": "^5.6.2",
  "@mui/lab": "^5.0.0-alpha.63",
  "@mui/material": "^5.7.0",
  "@mui/styles": "^5.7.0",
  "@mui/x-data-grid": "^5.10.0",
  "@mui/x-data-grid-pro": "^5.10.0",
  "@testing-library/jest-dom": "^5.16.1",
  "@testing-library/react": "^12.1.2",
  "@testing-library/user-event": "^13.5.0",
  "react": "^17.0.2",
  "react-dom": "^17.0.2",
  "react-router-dom": "^6.2.1",
  "react-scripts": "5.0.0",
  "web-vitals": "^2.1.3"
},
```
</details>
Repository: pytorch
Issue: KL-divergence of two Generalized Dirichlet distributions
Labels: module: distributions,feature,triaged

### 🚀 The feature, motivation and pitch

Thank you for your great contribution. Could you please add KL-divergence of two Generalized Dirichlet distributions? 
A very clear of its derivation can be found in equation 11 of this paper: [https://www.sciencedirect.com/science/article/abs/pii/S003132031830311X?via%3Dihub]
[KL-Divergence.pdf](https://github.com/pytorch/pytorch/files/9355461/KL-Divergence.pdf)
.

### Alternatives

_No response_

### Additional context

_No response_

cc @fritzo @neerajprad @alicanb @nikitaved