sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Add 'validator' handler at Form level to support cross field validation logic
Labels: a: text input,c: new feature,framework,f: material design,c: proposal,P3,team-design,triaged-design

### Use case

Most non trivial form data entry requirements will include the validation of data across multiple input fields.   Currently, there is no simple and effective way of adding form level validation using the Flutter 'Form' and 'xxxxxFormField' widgets. 

### Proposal

Add a 'validator' handler at the 'Form' widget level.

The validator method would be passed an array of global key objects,  representing the global keys set up for each data input form field.  Like... 

`Function String? (List<GlobalKey> keys);`
Repository: TypeScript
Issue: Can't assign to partial of intersection with mapped type over generic
Labels: Help Wanted,Possible Improvement

### 🔎 Search Terms

"mapped type", "mapped generic type", "intersection", "partial"

### 🕗 Version & Regression Information

Current version of Typescript, not sure if it's a regression

### ⏯ Playground Link

_No response_

### 💻 Code

Simple to reproduce:

```ts
type X = 'a' | 'b' | 'c'
const foo = <T extends X>() => {
    const result: Partial<{d:number} & {[P in T]: boolean}> = {
       // error: Type '{ d: number; }' is not assignable to type 'Partial<{ d: number; } & { [P in T]: boolean; }>'
        d: 1
    }
}
```


### 🙁 Actual behavior

I get an error

### 🙂 Expected behavior

I am able to use this type in general; I expect to be able to use a partial of it as well. The only thing I've found that satisfies the type is an empty object

### Additional information about the issue

_No response_
Repository: tauri
Issue: [feat] platform/arch-specific resources
Labels: type: feature request,priority: 2 medium,scope: bundler

### Describe the problem

In additional to executable files, static/dynamic library files are also platform & arch dependent. Need a way to embed external binaries for other extentions such as: .dll, .so,  beside executable files.

### Describe the solution you'd like

Support externalBin setup as following:
```
"externalBin": [
    "binaries/my-sidecar"
]
```
And in additional:
```
"externalBin": [
    {path: "binaries/my-sidecar-dll", ext: "dll"}
]
```

### Alternatives considered

_No response_

### Additional context

_No response_
Repository: ollama
Issue: reGPT and mGPT model support
Labels: model request

Please add the following models: 

- https://huggingface.co/ai-forever/ruGPT-3.5-13B
- https://huggingface.co/ai-forever/mGPT-13B
Repository: storybook
Issue: [Bug]: docs iframe width doesn't fill container in centered layout
Labels: bug,good first issue,help wanted,addon: docs,block: other,sev:S3

### Describe the bug

When using `centered` layout and `inlined: false` for docs story, the iframe inside docs preview has a fixed width (~320px) and does not fill its container.

```ts
{
  layout: 'centered',
  docs: {
    story: {
      inline: false
    }
  }
}
``` 

If the component width is greater than 320px, the iframe overflows and scrollbars are displayed.

<img width="960" alt="image" src="https://github.com/storybookjs/storybook/assets/29512354/10d83593-4159-495d-8972-4b1db6d7c963">



### To Reproduce

https://stackblitz.com/edit/github-qsqk9f?file=src%2Fstories%2FButton.stories.ts

### System

```bash
Storybook Environment Info:

  System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.18.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.4.2 - /usr/local/bin/npm <----- active
    pnpm: 8.10.5 - /usr/local/bin/pnpm
  npmPackages:
    @storybook/addon-essentials: ^8.0.0-alpha.5 => 8.0.0-alpha.6 
    @storybook/addon-interactions: ^8.0.0-alpha.5 => 8.0.0-alpha.6 
    @storybook/addon-links: ^8.0.0-alpha.5 => 8.0.0-alpha.6 
    @storybook/addon-onboarding: ^1.0.10 => 1.0.10 
    @storybook/blocks: ^8.0.0-alpha.5 => 8.0.0-alpha.6 
    @storybook/react: ^8.0.0-alpha.5 => 8.0.0-alpha.6 
    @storybook/react-vite: ^8.0.0-alpha.5 => 8.0.0-alpha.6 
    @storybook/test: ^8.0.0-alpha.5 => 8.0.0-alpha.6 
    storybook: ^8.0.0-alpha.5 => 8.0.0-alpha.6
```


### Additional context

_No response_
Repository: godot
Issue: Body_Exited Signal incorrectly triggering between CollisionPolygon2D Segments despite build mode being "Solids"
Labels: topic:physics,needs testing,topic:2d

### Tested versions

v4.1.stable.official [970459615]

### System information

Godot v4.1.stable - macOS 13.5.2 - Vulkan (Forward+) - integrated Intel(R) Iris(TM) Plus Graphics 655 - Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz (8 Threads)

### Issue description

Player is detected as leaving the area when they are still within the same CollisonPolygon2D. The exited signal for this only triggers when the player 'undos' within the top portion of this puzzle, which happens to be the only area where the polygon shape segments are pure rectangles. The player can undo in other sections of the puzzle without the exited signal triggering.

The exited signal should only trigger if the player is stepping outside of the entire collision area. 

### Steps to reproduce

Walk the player around using WASD or arrow keys. You have a move count and will need to recharge by stepping on the lightning bolt tiles. At anytime, you can undo by pressing "Q". In the first part of the puzzle, everything should work as intended, however once you get to the last stretch (as shown in this screenshot & video) undoing your player will cause the puzzle to deactivate because the body_exited signal is triggered. This only happens if the player is undone between the colored segments in this section. 

https://github.com/godotengine/godot/assets/60891368/211625a3-9cf4-46d7-9633-8b0980833cdc

![Screenshot 2023-12-30 at 11 15 13 AM](https://github.com/godotengine/godot/assets/60891368/9b3e470d-2fe3-4d08-a772-9dd47c6cdc21)

Currently I am able to work around this by setting up a function to check when the player is being 'undone' and then checking when that is false within the body_exited signal before executing any other code. This should be fine for my project but it still doesn't solve the fact that the exited signal is being triggered here in general. 



### Minimal reproduction project (MRP)

[ISSUE_12302023.zip](https://github.com/godotengine/godot/files/13798612/ISSUE_12302023.zip)
Repository: stable-diffusion-webui
Issue: [Feature Request]: Remove gallery view form the generation result display
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Currently there are three ways to display result images.
First the grid view. 
Second, the gallery view, accessed by pressing on an image in grid view.
Third, the full screen view, accessed by pressing on an image in gallery view.

But the full screen view displays images better than the gallery view.
I propose to remove the gallery view, and make the full screen viewer accessible directly from the grid view selection.
This would solve various scaling issues the gallery view currently has.

Also, the grid view should get settings for image height and image width for the grid slots. Currently asymmetrical images are cropped. Gallery height should not influence the size of the grid slots, but only how many images fit into the gallery window, before scrolling is needed.

### Proposed workflow

1. Generate a batch of images
2. See the grid view of generated images by default
3. Click on an image to access full screen viewer
4. Press X to leave full screen viewer to quickly navigate to another picture using the grid mode.
5. Generate a new batch of images

### Additional information

Here some screenshots and more detailed notes:

Default grid view with fresh install looks fine. Easy navigation possible by scrolling the grid.
![Default Grid View](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/147339248/b022fac0-af0f-48b0-8cd3-2d2a5b266747)

Cropping issues for asymmetrical images in grid view. The image should be scaled down until it fits completely into the grid slot. Similar with how windows file explorer displays images.
![Grid mode cropping](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/147339248/6a7c34a2-5507-4c13-adf7-9736e0981d22)

Gallery height currently works somewhat, but in grid mode it looks strange. The gallery size should not change image display size in grid mode, but display more or less images instead.
![Gallery height grid mode](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/147339248/f5a3e3b3-3c56-4d64-be41-a8b807fa6893)

Gallery view I want to remove. Grid view with additional grid slot size settings can fully replace it in combination with the full screen viewer.
![Gallery mode](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/147339248/f1fbff32-6617-49a7-b527-7dae1aa8898e)

Full screen viewer
![Full Screen viewer](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/147339248/4662781f-eb8e-4155-9450-8c20ff0aa12a)
Repository: ollama
Issue: 💡 Idea/Suggestion: Rich API Documentation
Labels: documentation,feature request,api

Hello @jmorganca.

First of all, thank you for your amazing work! 🤩 I have been using Ollama for a while now and I'm really enjoying it.

I was wondering if we could introduce a API documentation website (right from GitHub using GH Pages). Along with this we could also have a GitHub action workflow setup to auto-build and deploy the API documentation when a release is created.

I think it would be greatly helpful for someone to get started with basics (including setup, how and why Ollama is used, etc) and then progressively navigate through the documentation to explore more and try more advanced stuff via a more user-friendly UI.

I was thinking if I could setup a skeleton structure for the documentation using [docusaurus](https://docusaurus.io/). That way, we can have well structured comprehensive API documentation such as [this](https://amithkoujalgi.github.io/ollama4j/docs/intro).

Let me know what you think. Thanks!
Repository: ollama
Issue: Placeholder text in `ollama run` doesn't hide when composing text with candidate dialog
Labels: bug,windows

I'm not sure how fixable this is, but I thought I'd still create an issue!

<img width="509" alt="Screenshot 2023-12-30 at 12 28 43 PM" src="https://github.com/jmorganca/ollama/assets/251292/ac1e779f-7fc4-4471-ae38-035681bf78a2">


Source: https://x.com/LucasChatGPT/status/1741091234507276632?s=20
Repository: godot
Issue: GDScript::Geometry2D.segment_intersects_segment() returns null on valid intersection point
Labels: bug,topic:core,needs testing

### Tested versions

v4.3.dev1.official [9d1cbab1c]

### System information

Godot v4.3.dev1 - Windows 10.0.19045 - GLES3 (Compatibility) - Quadro K1000M () - Intel(R) Core(TM) i7-3740QM CPU @ 2.70GHz (8 Threads)

### Issue description

Geometry2D.segment_intersects_segment() returns null as a result although a valid intersection point exists.

1st segment has a starting point exactly residing on 2nd segment.
2nd segment is vertical.

Swapping from with to hence exchanging the start point with the end point leads to correct result.

I expect Geometry2D.segment_intersects_segment() to always return the same result regardless of the order of start and end points of segments given.

### Steps to reproduce

Geometry2D.segment_intersects_segment(from_a, to_a, from_b, to_b) returns null for
	var from_a := Vector2(585, 95)
	var to_a := Vector2(581, 98)
	var from_b := Vector2(585, 105)
	var to_b := Vector2(585, 45)

Correct result is (585, 95).

Proof via swapping from_b with to_b:
Geometry2D.segment_intersects_segment(from_a, to_a, to_b, from_b) returns (585, 95).

### Minimal reproduction project (MRP)

[segment_bug.zip](https://github.com/godotengine/godot/files/13798925/segment_bug.zip)
Repository: TypeScript
Issue: Intersection, Union depends on type variable instantiation order
Labels: Suggestion,In Discussion

### 🔎 Search Terms

generic type variable intersection union order

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about Generics


### ⏯ Playground Link
[Workbench Repro](https://www.typescriptlang.org/dev/bug-workbench/?ts=5.4.0-dev.20231230#)

### 💻 Code

```ts repro
type Union<A, B> = A | B
type UnionAny<T> = Union<T, any>
type UnionUnknown<T> = Union<unknown, T>

// these should all be the same type but are respectively: any, any, unknown 
type UA0 = Union<unknown, any>
//   ^?
type UA1 = UnionAny<unknown>
//   ^?
type UA2 = UnionUnknown<any>
//   ^?

type Intersect<A, B> = A & B
type IntersectAny<T> = Intersect<T, any>
type IntersectNever<T> = Intersect<never, T>

// these should all be the same type but are respectively: never, any, never
type AN0 = Intersect<never, any>
//   ^?
type AN1 = IntersectAny<never>
//   ^?
type AN2 = IntersectNever<any>
//   ^?

```

### 🙁 Actual behavior

The types `UA0`, `UA1` are resolved as `any` and `UA2` is resolved as `unknown`. These all map down to the same union of `unknown` and `any`, so should all be the same type.

The types `AN0`, `AN2` are resolved as `never` and `AN1` resolved as `any`. These all map down to be the intersection of `any` and `never`, so should all be the same type.

### 🙂 Expected behavior

I expect `UA0`, `UA1` and `UA2` to resolve as the same type (probably `any`, but preferably `unknown`)
I expect `AN0`, `AN1` and `AN2` to resolve as the same type (probably `never`)

### Additional information about the issue

_No response_
Repository: pytorch
Issue: `test_autograd_dense_output_addmm` fails if matrix sizes are square
Labels: module: sparse,triaged

### 🐛 Describe the bug

For example, if one adds `((2, 2), (2, 2), (2, 2), False),` option to sample_inputs_addmm, test will start to fail with:
```
2023-12-30T01:10:54.4934201Z ________ TestSparseCSRCPU.test_autograd_dense_output_addmm_cpu_float64 _________
2023-12-30T01:10:54.4934895Z Traceback (most recent call last):
2023-12-30T01:10:54.4935452Z   File "test_sparse_csr.py", line 2827, in test_autograd_dense_output_addmm
2023-12-30T01:10:54.4936040Z     output.backward(covector)
2023-12-30T01:10:54.4936864Z   File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/torch/_tensor.py", line 513, in backward
2023-12-30T01:10:54.4937720Z     return handle_torch_function(
2023-12-30T01:10:54.4938628Z   File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/torch/overrides.py", line 1606, in handle_torch_function
2023-12-30T01:10:54.4939602Z     result = mode.__torch_function__(public_api, types, args, kwargs)
2023-12-30T01:10:54.4940824Z   File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/torch/testing/_internal/common_utils.py", line 1315, in __torch_function__
2023-12-30T01:10:54.4941746Z     r = func(*args, **kwargs)
2023-12-30T01:10:54.4942511Z   File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/torch/_tensor.py", line 522, in backward
2023-12-30T01:10:54.4943252Z     torch.autograd.backward(
2023-12-30T01:10:54.4944074Z   File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/torch/autograd/__init__.py", line 267, in backward
2023-12-30T01:10:54.4944857Z     _engine_run_backward(
2023-12-30T01:10:54.4945743Z   File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/torch/autograd/graph.py", line 681, in _engine_run_backward
2023-12-30T01:10:54.4946915Z     return Variable._execution_engine.run_backward(  # Calls into the C++ engine to run the backward pass
2023-12-30T01:10:54.4948107Z RuntimeError: sparse_addmm_sparse_backward: unsupported combination of layouts, grad: Strided, mat1: Strided, mat2: SparseCsr
```

### Versions

Nigthly, 2.2

cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer @jcaip
Repository: rust
Issue: Malformed coverage data when using llvm-cov
Labels: T-compiler,C-bug,A-code-coverage

I tried to fuzz our substrate runtime but getting error:
```
error: Failed to load coverage: 'target/x86_64-unknown-linux-gnu/coverage/x86_64-unknown-linux-gnu/release/main': Malformed coverage data
```

<details>
<summary>How to reproduce (on our large repo)</summary>

```bash
git clone --branch av/rust-1.76-support https://github.com/gear-tech/gear.git
cd gear
git checkout 849dbb301c751c951754b73b39a50a02e7296bef

cd utils/runtime-fuzzer

mkdir -p fuzz/corpus/main
dd if=/dev/urandom of=fuzz/corpus/main/fuzzer-seed-corpus bs=1 count=350000

# Run fuzzer for at least for 3 minutes and then press Ctrl-C to stop fuzzing.
cargo fuzz run \
    --release \
    --sanitizer=none \
    main \
    fuzz/corpus/main \
    -- \
        -rss_limit_mb=8192 \
        -max_len=450000 \
        -len_control=0

cargo fuzz coverage \
    --release \
    --sanitizer=none \
    main \
    fuzz/corpus/main \
    -- \
        -rss_limit_mb=8192 \
        -max_len=450000 \
        -len_control=0

HOST_TARGET=$(rustc -Vv | grep "host: " | sed "s/^host: \(.*\)$/\1/")
cargo cov -- show target/$HOST_TARGET/coverage/$HOST_TARGET/release/main \
  --format=text \
  --show-line-counts \
  --Xdemangler=rustfilt \
  --instr-profile=fuzz/coverage/main/coverage.profdata \
  --ignore-filename-regex=/rustc/ \
  --ignore-filename-regex=.cargo/ &> fuzz/coverage/main/coverage.txt
```
</details>

### Meta
`rustc --version --verbose`:
```
rustc 1.77.0-nightly (3cdd004e5 2023-12-29)
binary: rustc
commit-hash: 3cdd004e55c869faa2b7b25efd3becf50346e7d6
commit-date: 2023-12-29
host: x86_64-unknown-linux-gnu
release: 1.77.0-nightly
LLVM version: 17.0.6
```
Repository: pytorch
Issue: [MPS] `sort` incorrectly handles 'negative' NaNs
Labels: triaged,module: mps

### 🐛 Describe the bug

`torch.sort` fails to treat `-torch.nan` as the largest value on MPS

```
>>> t = torch.tensor([1.0, -torch.nan])
>>> t.sort()
torch.return_types.sort(
values=tensor([1., nan]),
indices=tensor([0, 1]))
>>> t.to('mps').sort()
torch.return_types.sort(
values=tensor([nan, 1.], device='mps:0'),
indices=tensor([1, 0], device='mps:0'))
```

To my understand, `-torch.nan` should be treated the same as `torch.nan`, since after all they are both just NaNs, so the cpu implementation is correct while the MPS implementation is not. The cpu implementation is also consistent with `np.sort` behavior. My guess is that there is a hidden sign bit associated to NaN that fails to be ignored when sorting on MPS.

### Versions

```
Collecting environment information...
PyTorch version: 2.1.2
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.5.1 (arm64)
GCC version: Could not collect
Clang version: 12.0.0 (clang-1200.0.32.28)
CMake version: version 3.26.0
Libc version: N/A

Python version: 3.9.16 (main, Mar  1 2023, 12:19:04)  [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-13.5.1-arm64-arm-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

CPU:
Apple M1 Pro

Versions of relevant libraries:
[pip3] numpy==1.25.2
[pip3] torch==2.1.2
[conda] numpy                     1.25.2                   pypi_0    pypi
[conda] torch                     2.1.2                    pypi_0    pypi
```

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr
Repository: pytorch
Issue: Python version inconsistency between Linux and Windows in the getting started
Labels: module: docs,triaged

### 📚 The doc issue

For some reason on Linux Python 3.11 is allowed where as on Windows up to Python 3.10. Is this dependency intended? Perhaps https://pytorch.org/blog/pytorch-2-1/ should be a bit more explicit about the current Python version support progress.
- [Linux getting started](https://pytorch.org/get-started/locally/#linux-python)
- [Windows getting started](https://pytorch.org/get-started/locally/#windows-python)


### Suggest a potential alternative/fix

1. If this is intentional than no fix is needed
2. If this is a mistake change Windows Python version or Linux Python version

cc @ezyang @gchanan @zou3519 @kadeng @svekars @brycebortree
Repository: godot
Issue: Collision Layer not Rotating Upon Rotation of Tile in 2d
Labels: bug,topic:physics,topic:2d

### Tested versions

Reproducible in 4.2.1-stable

### System information

Godot v4.2.1.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; 31.0.15.3770) - 12th Gen Intel(R) Core(TM) i5-12400F (12 Threads)

### Issue description

Whenever I rotate a tile before placing it, the rotation is not applied to the collision layer, leading to CharacterBody2ds being able to go through portions of the tile that are meant to have collision, while not being able to go through areas where the collision layer should not be applied. In the video, the left side had a normal tile, and the right side had a rotated tile.

Video of Issue
https://github.com/godotengine/godot/assets/142550397/0422618e-79c6-4191-95d8-26e440edc1ce

Photo of Editor showing collision layer placement
https://github.com/godotengine/godot/assets/142550397/125f096a-5c9e-44a4-a119-c905c1433410

### Steps to reproduce

In a 2d node, create a tileset with a tile that is larger than 1 grid unit. Add collision to that tile using a collision layer. Rotate and place that tile on the game area, and add a player with the ability to move around the game area. Attempt to move the player through the tile on all sides.

### Minimal reproduction project (MRP)

[Godot rotation bug.zip](https://github.com/godotengine/godot/files/13799321/Godot.rotation.bug.zip)