sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: excalidraw
Issue: Feature Request Excalidraw+ - Allow a workspace or collection between different billing accounts
Labels: Excalidraw+

My understanding of the billing setup today in Excalidraw+, assumes there is one entity billed for all users in the workspace.
This makes sense for scenario where a company pays for all the users.

However, there is scenario where Excalidraw+ is used by different individuals who want to collaborate. But paid respectively by all of them. It would be nice in such a scenario, as those people are working together often to either have a common workspace or at least a common collection.
So that members of that workspace or collection can see all the scenes in there.
Even if they are not all on same billing account. Just Excalidraw+ customers.
Repository: neovim
Issue: Update tests to use default color scheme
Labels: enhancement,test

### Problem

Not all Neovim specific tests are adapted to work with the new default color scheme, instead simply setting `colorscheme vim` to keep the old expected output. This inconsistency might lead to unnecessary confusion when writing tests.

### Expected behavior

All tests are rewritten to expect the output under the default colorscheme and no longer need to explicitly set a colorscheme.
Repository: godot
Issue: Popup window remains visible after alt+tab from editor in x11
Labels: bug,platform:linuxbsd,topic:porting

### Tested versions

- Reproducible in: 4.3.dev (f91db3dc5), 4.0.4-stable

### System information

Godot v4.3.dev (f91db3dc5) - Ubuntu 20.04.6 LTS (Focal Fossa) - X11 - GLES3 (Compatibility)

### Issue description

When alt-tab from the editor while having an open PopupMenu object, this Window remains visible, overlaying other windows unrelated to the editor. Might be related to https://github.com/godotengine/godot/issues/85403?
![Before-alt-tab](https://github.com/godotengine/godot/assets/7302227/4f82044b-6e96-4882-a48a-444b1df81c10)
![After-alt-tab](https://github.com/godotengine/godot/assets/7302227/b5f17a77-f7ce-4c74-a0d8-6d962305c16e)


### Steps to reproduce

- Create a new project
- Add a PointLight2D Node (although any node with a PopupMenu will work)
- Open the Texture options (also works with the Script options, at the bottom)
- Alt + Tab to another window that "replaces" the IDE

### Minimal reproduction project (MRP)

[test-project.zip](https://github.com/godotengine/godot/files/15186666/test-project.zip)
Repository: go
Issue: x/net/quic: Signal `unsupported` for key-update interop test
Labels: Proposal

### Proposal Details

Based on https://interop.seemann.io/, go-x-net doesn't seem to support key updates. Please signal this to the runner by returning `unsupported` for this interop test case.
Repository: PowerToys
Issue: The "Peek" function does not always work
Labels: Idea-Enhancement,Product-Peek

### Description of the new feature / enhancement

"Peek" preview function does not work when opening the browser from the browser or other programs

### Scenario when this would be used?

When you want to download or upload an image and for that a small explorer window opens and I want to quickly see the images in that folder but the Peek function does not work

### Supporting information


https://github.com/microsoft/PowerToys/assets/133511742/b0621cc6-0537-4182-9ec6-023d7cdfb252
Repository: godot
Issue: Wrong normal over floor edge, no floor detected (2D)
Labels: bug,topic:physics,needs testing,topic:2d

### Tested versions

- Reproduclibe in: 4.2.1 and 4.3-dev6

### System information

Debian GNU/Linux 12.5

### Issue description

Collisions between the edges of rectangle shapes are obviously wrong. An object falling and being stopped by an edge can't have a normal pointing to one side (in the X axis). All movements and shape edges are parallel to axes. In this case, any object stopping another object from falling has to be floor and have a normal pointing up.

In the example project, the floor isn't detected at first for several frames, then it starts being detected. It stops the object from falling from the start though.

### Steps to reproduce

Try the MRP with "visible collision shapes" on to be able to see anything. Run the project and see the movement of the objects in the window and the messages in the console output.

### Minimal reproduction project (MRP)

[collision_normal_test.zip](https://github.com/godotengine/godot/files/15186895/collision_normal_test.zip)
Repository: pytorch
Issue: torch.multinomial raises no error when sampling from zero weight and replacement=False.
Labels: triaged,actionable,topic: docs

### 🐛 Describe the bug

As in the [example](https://pytorch.org/docs/stable/generated/torch.multinomial.html), torch.multinomial should raise an error.

If errors are not raised to block developers, it will happen that the wrong index samples are used to train the model without knowing it, like me.

Here is the code I executed:
```python
import torch
print("git_version =", torch.version.git_version)
print("torch_version =", torch.version.__version__)
weights = torch.tensor([0, 10, 3, 0], dtype=torch.float)
a = torch.multinomial(weights, 2, replacement=False)
b = torch.multinomial(weights, 4, replacement=False)
print(a)
print(b)
```


I get the output:
```
git_version = 39901f229520a5256505ec24782f716ee7ddc843
torch_version = 2.2.2+cpu
tensor([1, 2])
tensor([2, 1, 0, 3])
```


### Versions

Here is the version I'm using:`torch_version=2.2.2+cpu`
Repository: rust
Issue: HashMap struct key with `'static` lifetime screws with return lifetime using methods like `.get()`
Labels: A-lifetimes,A-collections,T-libs-api,C-bug

I'm not sure what words to use to actually describe (or search for a dupe) this issue, so I'll just post it here and hope that it makes more sense to you guys (and sorry if it is a dupe; I'm almost sure it would be)!

So basically, if I write this code:

```rust
use std::collections::HashMap;

#[derive(PartialEq,Eq,Hash)]
struct Key<'a> {
    key: &'a str
}

struct Foo {
    types: HashMap<Key<'static>, String>,
}

impl Foo {
    fn resolve<'this, 'a>(
        &'this self,
        key: &'a str,
    ) -> Option<&'this String> {
        self.types.get(&Key { key })
    }
}
```

I get back this error:

```rust
error: lifetime may not live long enough
  --> src/lib.rs:17:9
   |
13 |     fn resolve<'this, 'a>(
   |                -----  -- lifetime `'a` defined here
   |                |
   |                lifetime `'this` defined here
...
17 |         self.types.get(&Key { key })
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ method was supposed to return data with lifetime `'this` but it is returning data with lifetime `'a`
   |
   = help: consider adding the following bound: `'a: 'this`
```

Despite the fact that `HashMap::get()` returns the values with a lifetime of self, and nothing to do with the key provided. 

However, this _does_ work:

```rust
use std::collections::HashMap;

#[derive(PartialEq,Eq,Hash)]
struct Key<'a> {
    key: &'a str
}

struct Foo {
    types: HashMap<&'static str, String>,
}

impl Foo {
    fn resolve<'this, 'a>(
        &'this self,
        key: &'a str,
    ) -> Option<&'this String> {
        self.types.get(key)
    }
}
```

Removing the `struct` indirection when defining the key type seems to make things happy!

## Background

The above is a minimal reproduction of the issue I ran into, but the reason I ran into it is because I want to have something like:

```rust
use std::collections::HashMap;

struct Foo {
    types: HashMap<(String,String), String>,
}

impl Foo {
    fn resolve<'this, 'a>(
        &'this self,
        key1: &'a str,
        key2: &'a str,
    ) -> Option<&'this String> {
        self.types.get(&(key1, key2))
    }
}
```

In other words, I want to be able to borrow more than 1 value to lookup some owned key in the hashmap. I went down the route of trying `struct Key<'a> { a: Cow<'a,str>, b: Cow<'a,str>` and then `HashMap<Key<'static>, String>`, but this led me to bumping up against this odd lifetime issue :)

Any pointers would be amazingly welcome!
Repository: godot
Issue: Access fault in `TextServerAdvanced::_shape_substr`
Labels: bug,needs testing,crash,topic:gui

### Tested versions

- does happen since upgrading to 4.2.2 
- did not happen in 4.2.1

### System information

Windows 10, Godot 4.2.2, Vulkan

### Issue description

I haven't found a way to reliably reproduce this issue yet. However I now had multiple crashes in `TextServerAdvanced::_shape_substr`. Here is a stack trace and all other information I think might be useful to determine what is going on:
The string in question: `Polyluminescent Undulating Infusion[s] (Teal) [86068]`

Exception:
![grafik](https://github.com/godotengine/godot/assets/11277588/7674b19b-27ec-4c9c-beac-a67237c26bbf)

Stacktrace:
![grafik](https://github.com/godotengine/godot/assets/11277588/875a23bc-91e2-4459-84ab-dc0d04b851ad)

Locals in the last good stack location:
![grafik](https://github.com/godotengine/godot/assets/11277588/dc47c13b-9a0d-45ae-a24a-b59e8b5af57c)
![grafik](https://github.com/godotengine/godot/assets/11277588/533d726b-61b4-4008-9d08-2bb3f1d36bb8)


### Steps to reproduce

-

### Minimal reproduction project (MRP)

-
Repository: vscode
Issue: Notebook background broken after vscode restart
Labels: bug,freeze-slow-crash-leak,notebook

The whole notebook background is gray. I think after I relaunched vscode, but I don't have a specific repro. Please, feel free to close if this is not actionable. 


https://github.com/microsoft/vscode/assets/16353531/3206a7ec-f7ff-43df-99da-fb5c40c8ad0b

The dev console contains which must be relevant: 

```
  ERR Error: Notebook too large to backup
    at o.snapshot (notebookEditorModel.ts:282:12)
    at async h.backup (storedFileWorkingCopy.ts:816:14)
    at async workingCopyBackupTracker.ts:189:21
```
Repository: pytorch
Issue: Support for Kolmogorov-Arnold Networks (KANs)
Labels: module: nn,triaged

Proposal for adding support for Kolmogorov-Arnold Networks (KANs) in PyTorch. KANs are a promising alternative to traditional Multi-Layer Perceptrons (MLPs) and offer potential advantages in terms of accuracy, scaling, and interpretability.

KANs are inspired by the Kolmogorov-Arnold representation theorem and have a fundamentally different structure compared to MLPs. Instead of having fixed activation functions on nodes (neurons) and linear weights, KANs have learnable activation functions on edges (weights), and every weight parameter is replaced by a univariate function parameterized as a spline.

### Additional context

[KAN: Kolmogorov–Arnold Networks](https://arxiv.org/pdf/2404.19756), The paper was submitted on 30th April,2024 by researchers from Massachusetts Institute of Technology, California Institute of Technology, Northeastern University, The NSF Institute for Artificial Intelligence and Fundamental Interactions.

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: node
Issue: `Readable.flatMap` concurrency isn't working as expected
Labels: stream

### Version

v22.0.0

### Platform

Darwin Moshes-MBP.localdomain 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:44 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6000 arm64

### Subsystem

stream

### What steps will reproduce the bug?

Run this code:

```js
const { Readable } = require('node:stream');
const { setTimeout } = require('node:timers/promises');

const start = Date.now();
const base = Readable.from([1, 2, 3, 4, 5], { highWaterMark: 100 });
const mapped = base.flatMap(async function * (x) {
  await setTimeout(1000);
  yield x * 2;
}, { concurrency: 200 });

(async () => {
  for await (const chunk of mapped) {
    console.log({ chunk }, Math.floor((Date.now() - start) / 1000));
  }
})();
```

### How often does it reproduce? Is there a required condition?

allways

### What is the expected behavior? Why is that the expected behavior?

since `concurrency` is set to 200 - I expect all the chunks to be emitted together, however there is a second between each chuck:

```
{ chunk: 2 } 1
{ chunk: 4 } 2
{ chunk: 6 } 3
{ chunk: 8 } 4
{ chunk: 10 } 5
```

### What do you see instead?

```
{ chunk: 2 } 1
{ chunk: 4 } 2
{ chunk: 6 } 3
{ chunk: 8 } 4
{ chunk: 10 } 5
```

### Additional information

when running similar code using `Readable.map` the concurrency works as expected:

```js
const { Readable } = require('node:stream');
const { setTimeout } = require('node:timers/promises');

const start = Date.now();
const base = Readable.from([1, 2, 3, 4, 5], { highWaterMark: 100 });
const mapped = base.map(async function(x) {
  await setTimeout(1000);
  return x * 2;
}, { concurrency: 200 });

(async () => {
  for await (const chunk of mapped) {
    console.log({ chunk }, Math.floor((Date.now() - start) / 1000));
  }
})();
```

results in 
```
{ chunk: 2 } 1
{ chunk: 4 } 1
{ chunk: 6 } 1
{ chunk: 8 } 1
{ chunk: 10 } 1
```
Repository: neovim
Issue: Lua/stdlib: behavior of global vs local "enable" (and other config)
Labels: enhancement,needs:decision,needs:discussion,lua,options

### Problem

[vim.diagnostic.enable(nil)](https://github.com/neovim/neovim/blob/e778e0116198470ba037b9426f4ff7fa5cb7f880/runtime/lua/vim/diagnostic.lua#L2046-L2053) and [vim.lsp.inlay_hint.enable(nil)](https://github.com/neovim/neovim/pull/28543) both actively override any buffer-local flags that were previously set by `enable(..., {bufnr=...}`. 

That seems a bit "destructive". I tend to think that global enable() should act like a gate: 

- if globally enabled, then defer to the buffer-local flag
- if globally disabled, don't check the buffer-local flag

IOW: buffer-local "enable" flag has precedence unless the feature is globally disabled.

### Expected behavior

Need a clear pattern for all such modules to follow. This may have implications for other kinds of "config" besides mere "enablement".

The behavior of vim *options* (`:help global-local`, ignoring other kinds of option scopes) would imply that the global setting is only the "default", and any buffer-local setting should always override the global default.
Repository: deno
Issue: `cargo r --features __runtime_js_sources test` fails
Labels: bug,cli

commit: 56ba7f3c233fcf8c9478314956c70725179ed16f

`cargo r --features __runtime_js_sources test` fails on the deno repo

```
error: Unsupported scheme "ext" for module "ext:core/mod.js". Supported schemes: [
    "data",
    "blob",
    "file",
    "http",
    "https",
]
    at file:///workspace/deno/cli/js/40_test.js:3:35
```
Repository: storybook
Issue: [Bug]: Configuration options don't seem to get passed on to vitest
Labels: bug,documentation,portable stories

### Describe the bug

A couple of my interaction tests are failing due to Unhandled Errors caused by an upstream dependency I'm using.

The output of the interaction test kindly suggests the following:

```
Unhandled Errors
Found 1 unhandled error while running the play function. This might cause false positive assertions. Resolve unhandled errors or ignore unhandled errors with setting the test.dangerouslyIgnoreUnhandledErrors parameter to true.
```

After reading this, I tried adding the following snippet into my `.storybook/main.ts` configuration:
```
  viteFinal: async (config, ...rest) => {
    const extraConfig = {
      test: {
        dangerouslyIgnoreUnhandledErrors: true,
      },
    };

    if (storybookConfig.viteFinal) {
      return mergeConfig(
        storybookConfig.viteFinal(config, ...rest),
        extraConfig,
      );
    }
    return mergeConfig(config, extraConfig);
  }
```

However, the exception is still thrown (and the interaction test still states that I need to set the `test.dangerouslyIgnoreUnhandledErrors` param).

Is this expected? Are parameters passed through to vitest?

### To Reproduce

-

### System

```bash
System:
    OS: macOS 14.2.1
    CPU: (8) arm64 Apple M2
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.11.1 - ~/.nvm/versions/node/v20.11.1/bin/node
    Yarn: 4.1.0 - ~/.nvm/versions/node/v20.11.1/bin/yarn <----- active
    npm: 10.2.4 - ~/.nvm/versions/node/v20.11.1/bin/npm
    pnpm: 8.3.0 - /opt/homebrew/bin/pnpm
  Browsers:
    Chrome: 124.0.6367.94
    Safari: 17.2.1
```


### Additional context

Relates to: https://github.com/xyflow/xyflow/issues/2461
Repository: pytorch
Issue: [typing] Make arguments to `__getitem__`/`__setitem__`/ etc. positional only.
Labels: module: typing,triaged

### 🚀 The feature, motivation and pitch

A strict type checker will complain when overwriting `__getitem__` with a different argument:

```python
from torch.utils.data import Dataset

class MyDatasets(Dataset):
    def __getitem__(self, key, /) -> int:
        return 0
```

Gives: `Parameter 2 mismatch: base parameter "index" is keyword parameter, override parameter is position-only` when checking with `pyright`.

Note: most type-checkers support the white lie that if the parent class defines `__getitem__(self, index)`, then a subclass could do `__getitem__(self, key)`, despite this not being type save. This could change in the future as more libraries adopt positional only parameters.

### Additional context

Such changes are backward-compatibility braking if a caller tries to execute something like `A.__getitem__(self=self, index=index)`.

cc @ezyang @malfet @xuzhao9 @gramster
Repository: vscode
Issue: Workspace Trust - Restricted mode is stuck to a specific path
Labels: bug,workspace-trust

I noticed that regardless of which of my GitHub repositories I open, I always see the "Restricted Mode" indicator in the bottom left. When I click it, it always displays the same path (/myusername/myrepositoryname) when it asks me if I want to trust the folder - even if I am in a different repository. Here is a screenshot:
![Screenshot 2024-05-02 084703](https://github.com/microsoft/vscode/assets/30597447/5b0c45df-021b-44b3-8b82-571dcab2c420)


Version: 1.88.1
Commit: e170252f762678dec6ca2cc69aba1570769a5d39
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0
Embedder: vscode.dev

<!-- generated by web issue reporter -->
Repository: ollama
Issue: Error: do encode request: Post "http://127.0.0.1:39207/tokenize": EOF
Labels: bug

### What is the issue?

Hello,
I downloaded the Q4KM model from https://huggingface.co/LiteLLMs/French-Alpaca-Llama3-8B-Instruct-v1.0-GGUF/tree/main/Q4_K_M
renamed locally to French-Alpaca-Llama3-8B-Instruct-v1.gguf
Modelfile:
`FROM "./French-Alpaca-Llama3-8B-Instruct-v1.gguf"`
ollama create frll3 -f ./Modelfile
```
transferring model data 
creating model layer 
using already created layer sha256:08941f7a82566ca0116881e211330eae5838c20146132ed8fb9de46b6f5ea54b 
writing layer sha256:9f194159c3b80adee4448e1a1d380df743363881d417b5e9841e9611f884c155 
writing manifest 
success 
```
ollama run frll3
`>>> hi`
`Error: do encode request: Post "http://127.0.0.1:39207/tokenize": EOF`

But `ollama run llama3` works fine, I can discuss with it, no error. I have a 3060 (12GB VRAM)

Is it because of the model? The renaming? the Makefile?
Thanks

### OS

Linux

### GPU

Nvidia

### CPU

Intel

### Ollama version

0.1.32
Repository: godot
Issue: Tilemap framerate drops significantly above a certain threshold of tiles
Labels: bug,topic:rendering,confirmed,topic:2d,performance

### Tested versions

Tested in 4.3dev6 and 4.2.stable (reproducible in both)

### System information

Godot v4.3.dev6 - Windows 10.0.22631 - Vulkan (Forward+) - integrated AMD Radeon(TM) Graphics (Advanced Micro Devices, Inc.; 31.0.21912.14) - AMD Ryzen 5 5500U with Radeon Graphics (12 Threads)

### Issue description

`Tilemaplayer` (and `Tilemap` in 4.2) seems to drop your frame rate after reaching a specific tile threshold. Specifically, frame rate stays at a consistent 1000fps with 145 tiles (120 tiles in 4.2) in a scene. 2 tiles above that, the frame rate begins to drop between 60-70fps occasionally, and after 1 more, the frame rate stays at 60-70fps

https://github.com/godotengine/godot/assets/42086815/c961b951-697a-4187-adfe-4171e9cf47c3



### Steps to reproduce

Create a `tilemaplayer` and draw 145 tiles (120 tiles in 4.2) to achieve the unaffected frame rate
draw 1 or 2 more tiles to achieve the occasional frame drops (consistent with both versions)
draw another tile to achieve the fully affected fps which has been dropped significantly


### Minimal reproduction project (MRP)

[Tilemap_bug.zip](https://github.com/godotengine/godot/files/15188841/Tilemap_bug.zip)
Repository: angular
Issue: Angular SSG: Incompatibility between withXsrfConfiguration( ) (HttpClient) & Relative Paths in SSG
Labels: area: server,area: common/http

### Which @angular/* package(s) are the source of the bug?

common

### Is this a regression?

Yes

### Description

- My backend API resides at `api.domain.com`

- I'm using the path `//api.domain.com/api/product` for fetching data within the Angular app. This approach is necessary because **withXsrfConfiguration()** doesn't function correctly with absolute paths (e.g., https://api.domain.com/api/product).

- While this relative path ( `//api.domain.com/api/product` ) works properly during runtime, it fails to resolve correctly during **SSG** build time. This results in no data for the product prerendered page.

- Interestingly, **absolute paths do work during SSG**, but they **prevent the use of withXsrfConfiguration**, which is crucial for Cross-Site Request Forgery (CSRF) protection.

- Is there a known workaround to address the incompatibility between withXsrfConfiguration and relative paths in SSG in Angular 17.

- Also, if we use proxies and have a relative URL like `/api/product`, this might work with withXsrfConfiguration but not in SSG.

### Conclusion

- Relative URLs like `// (protocol-relative) and / (root-relative)` work with withXsrfConfiguration but not in SSG and Absolute URLs work in SSG but not with withXsrfConfiguration.

### Please provide a link to a minimal reproduction of the bug

_No response_

### Please provide the exception or error you saw

_No response_

### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 17.3.2
Node: 21.7.1 (Unsupported)
Package Manager: npm 10.5.2
OS: win32 x64

Angular: 17.3.1
... animations, cdk, common, compiler, compiler-cli, core, forms
... material, platform-browser, platform-browser-dynamic
... platform-server, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1703.2
@angular-devkit/build-angular   17.3.2
@angular-devkit/core            17.3.2
@angular-devkit/schematics      17.3.2
@angular/cli                    17.3.2
@angular/ssr                    17.3.2
@schematics/angular             17.3.2
rxjs                            7.8.1
typescript                      5.2.2
zone.js                         0.14.3
```


### Anything else?

_No response_