sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: ollama
Issue: Embedding discrepancies vs SentenceTransformers and between Ollama Versions 
Labels: bug

### What is the issue?

I'm working on a RAG app, I'd like to simplify my stack by using ollama instead of sentence transformers but I'm observing some odd behavior from ollama embeddings. Here's what I'm seeing:

1. Output embeddings don't match sentence transformers
2. Hitting the "embd" endpoint from the api docs [here](https://github.com/ollama/ollama/blob/79d3b1e2bdfc97542a7259b0c839520d39578514/docs/api.md#generate-embeddings) returns different results than the "embeddings" endpoint described in the blog [here](https://ollama.com/blog/embedding-models)
3. Embeddings returned by different versions of ollama are different. 

To test this, I embedded the same prompt with sentence transformers, ollama/embed, and ollama/embeddings. I printed out the first 5 elements in the output vector to inspect, and calculated a cosine similarity matrix between each pair of embedding methods (results in a symmetrical matrix with 1s along the diagonal). I repeated this using all-mini-lm and nomic-embed-text. Here's the code and outputs for ollama 0.3.3 and 0.3.12

![code](https://github.com/user-attachments/assets/f0d3620f-4511-49d9-8e87-10a520bbeb62)

![ollama033_output](https://github.com/user-attachments/assets/1870367b-85b6-4fb7-9f07-adfaf80e7cba)

![ollama_0312](https://github.com/user-attachments/assets/81d61fcb-9749-4ed5-ba4a-ac4959587567)

The embeddings are pretty clearly different, both when compared to sentence transformers and between ollama 0.3.3 and 0.3.12. 

 The cosine similarity between ollama and sentence transformers is pretty close though. I also created a 3500 chunk vectorstore, once with ollama and once with sentence transformers. When I query them, I get the same chunks returned albeit in a different order. That makes me think every vector that is getting embedded is getting transformed somehow (when compared to sentence transformers), but its happening to all of them more or less equally. 

Is this expected behavior? If so, is there anywhere I can read up on what ollama is doing under the hood?


### OS

Linux

### GPU

AMD

### CPU

AMD

### Ollama version

0.3.3, 0.3.12
Repository: rust
Issue: Tracking issue for RFC 3678: Inherent items for traits
Labels: T-lang,C-tracking-issue,B-experimental

This is a tracking issue for RFC 3678: Inherent items for traits.

The feature gate for the issue is `#![feature(inherent_items_for_traits)]`.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.  They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.  A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.  Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps

- [x] Approve as lang experiment.
  - (Approved implicitly given the circumstances.)
- [ ] Accept an RFC.
  - https://github.com/rust-lang/rfcs/pull/3678
- [ ] Implement in nightly.
  - https://github.com/rust-lang/rust/pull/130802
- [ ] Add documentation to the [dev guide][].
  - See the [instructions][doc-guide].
- [ ] Add documentation to the [reference][].
  - See the [instructions][reference-instructions].
- [ ] Add formatting for new syntax to the [style guide][].
  - See the [nightly style procedure][].
- [ ] Stabilize.
  - See the [instructions][stabilization-instructions].

[dev guide]: https://github.com/rust-lang/rustc-dev-guide
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs
[edition guide]: https://github.com/rust-lang/edition-guide
[nightly style procedure]: https://github.com/rust-lang/style-team/blob/master/nightly-style-procedure.md
[reference]: https://github.com/rust-lang/reference
[reference-instructions]: https://github.com/rust-lang/reference/blob/master/CONTRIBUTING.md
[stabilization-instructions]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[style guide]: https://github.com/rust-lang/rust/tree/master/src/doc/style-guide

### Unresolved Questions

TODO.

### Related

TODO.
Repository: rust
Issue: Rustdoc ignores `no_inline` when re-exporting modules from other crates
Labels: T-rustdoc,C-bug,A-cross-crate-reexports

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

This one is going to be a bit difficult to explain, so, here's an example of a rather large workspace experiencing this bug: https://github.com/clarfonthey/bevy/tree/no-inline-bug

Essentially, if a crate `example` has a module including `no_inline` exports like so:

```rust
pub mod prelude {
    #[doc(no_inline)]
    pub use crate::{thing1, thing2};
}
```

Then rustdoc will correctly show these as re-exports in the documentation for that module, on that crate. The exports will be shown as `crate::thing1` and `crate::thing2`.

However, if you re-export that module on another crate, then you would expect these items to continue to show up as re-exports, just as `example::thing1` and `example::thing2` instead of relative to `crate::`. However, instead Rustdoc simple inlines these.

In the example given, the `bevy` crate contains `pub use bevy_internal::*` without any special `doc` attributes. You'll find that thus, `bevy::prelude` will inline all of its contents instead of showing them as re-exports, despite the fact that `bevy_internal::prelude` does show them as re-exports.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.83.0-nightly (fb4aebddd 2024-09-30)
binary: rustc
commit-hash: fb4aebddd18d258046ddb51fd41589295259a0fa
commit-date: 2024-09-30
host: x86_64-unknown-linux-gnu
release: 1.83.0-nightly
LLVM version: 19.1.0
```
Repository: pytorch
Issue: [RFC] Retiring ProcessGroupGloo's CUDA support
Labels: oncall: distributed,triaged

### 🚀 The feature, motivation and pitch

C for consensus. 

The code will still be there, and be built, and users will still be able to use it if they want to. Unless in later future we feel that a code refactorization is necessary.

But the support for such usage -- including CI, bug fixes, new features, etc -- will be stopped.

Please comment below if you have any concerns.

### Alternatives

_No response_

### Additional context

_No response_

cc @XilunWu @H-Huang @awgu @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o
Repository: ui
Issue: [bug]: Does not give proper error message when create-next fails with issue during init
Labels: bug

### Describe the bug

![image](https://github.com/user-attachments/assets/33b94ae7-2b83-48e1-9d62-96d78cd02d83)
Here the error is nextjs does not allow project name to capital letter but the output give by shadcn is not specific 

### Affected component/components

Shadcn cli

### How to reproduce

1. pnpm dlx shadcn@latest init
2. Give your project name with capital letters
Then you get vague error something went wrong; Instead it should propagate the error from nextjs cli

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Not imp
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: react-native
Issue: Issue with TextInput borderWidth style with decimal value
Labels: Component: TextInput,Needs: Triage :mag:

### Description

Textinput shows grey box at the right when the borderWidth style has a decimal number value

### Steps to reproduce

Run the react native app
create a Textinput
set the text input borderWidth style to 0.5
Notice the grey box at the right

### React Native Version

0.75.4

### Affected Platforms

Runtime - iOS

### Output of `npx react-native info`

```text
info Fetching system and libraries information...
System:
  OS: macOS 13.6.9
  CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
  Memory: 867.37 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.10.0
    path: /usr/local/bin/node
  Yarn:
    version: 4.0.2
    path: /usr/local/bin/yarn
  npm:
    version: 10.2.5
    path: /usr/local/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.15.2
    path: /usr/local/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.0
      - iOS 17.0
      - macOS 14.0
      - tvOS 17.0
      - watchOS 10.0
  Android SDK: Not Found
IDEs:
  Android Studio: 2024.2 AI-242.21829.142.2421.12409432
  Xcode:
    version: 15.0.1/15A507
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 21.0.3
    path: /usr/bin/javac
  Ruby:
    version: 3.3.0
    path: /usr/local/opt/ruby/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.3.1
    wanted: ^18.3.1
  react-native:
    installed: 0.75.4
    wanted: ^0.75.4
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false
```


### Stacktrace or Logs

```text
None
```


### Reproducer

https://snack.expo.dev/@myckhel/caa155

### Screenshots and Videos


https://github.com/user-attachments/assets/0511307f-1f6e-4205-b97e-68d15e501ac4
Repository: neovim
Issue: window-local corner separator depends on redraw order (with global statusline)
Labels: bug,ui

### Problem

When using global statusline and window-local 'fillchars', behavior of window-local corner separator depends on redraw order.

### Steps to reproduce

1. Run `nvim --clean`
2. Run `:set laststatus=3 cursorcolumn`
3. Run `:vnew`
4. Run `:new`
5. Run `:new`
6. Run `:wincmd j`
7. Run `:setlocal fillchars+=vertleft:@`, `@` appears at the first corner separator
8. Run `:wincmd k`, `@` disappears from the first corner separator
9. Run `:wincmd j`, `@` appears at both corner separators
10. Run `:wincmd j`, `@` disappears from the second corner separator

### Expected behavior

Behavior of corner separators shouldn't depend on redraw order

### Nvim version (nvim -v)

v0.11.0-dev-888+g4075e613b2

### Vim (not Nvim) behaves the same?

N/A

### Operating system/version

Arch Linux

### Terminal name/version

kitty 0.36.4

### $TERM environment variable

xterm-kitty

### Installation

build from repo
Repository: pytorch
Issue: DISABLED test_memory_snapshot_with_cpp (__main__.TestCudaMallocAsync)
Labels: module: cuda,triaged,module: flaky-tests,skipped

Platforms: linux, slow, rocm



This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_memory_snapshot_with_cpp&suite=TestCudaMallocAsync&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/30997145243).

Over the past 3 hours, it has been determined flaky in 26 workflow(s) with 78 failures and 26 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_memory_snapshot_with_cpp`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/workspace/test/test_cuda.py", line 3392, in test_memory_snapshot_with_cpp
    self.assertTrue("::rand" in str(b["frames"]))
  File "/opt/conda/envs/py_3.10/lib/python3.10/unittest/case.py", line 687, in assertTrue
    raise self.failureException(msg)
AssertionError: False is not true

To execute this test, run the following from the base repo dir:
    python test/test_cuda.py TestCudaMallocAsync.test_memory_snapshot_with_cpp

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `test_cuda_expandable_segments.py`

cc @ptrblck @msaroufim @clee2000
Repository: pytorch
Issue: DISABLED test_memory_snapshot_script (__main__.TestCudaMallocAsync)
Labels: module: cuda,triaged,module: flaky-tests,skipped

Platforms: linux, rocm, win, windows, slow



This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_memory_snapshot_script&suite=TestCudaMallocAsync&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/30998131540).

Over the past 3 hours, it has been determined flaky in 35 workflow(s) with 105 failures and 35 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_memory_snapshot_script`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/workspace/test/test_cuda.py", line 3592, in test_memory_snapshot_script
    self.assertTrue(b["frames"][0]["name"] == "foo")
IndexError: list index out of range

To execute this test, run the following from the base repo dir:
    python test/test_cuda.py TestCudaMallocAsync.test_memory_snapshot_script

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `test_cuda.py`

cc @ptrblck @msaroufim @clee2000
Repository: transformers
Issue: Implement LlamaGen for Image Generation
Labels: New model,Feature request,Vision

### Feature request

Add support for LlamaGen, an autoregressive image generation model, to the Transformers library. LlamaGen applies the next-token prediction paradigm of large language models to visual generation.

Paper: https://arxiv.org/abs/2406.06525
Code: https://github.com/FoundationVision/LlamaGen

Key components to implement:

1. Image tokenizer
2. Autoregressive image generation model (based on Llama architecture)
3. Class-conditional and text-conditional image generation
4. Classifier-free guidance for sampling

### Motivation

LlamaGen demonstrates that vanilla autoregressive models without vision-specific inductive biases can achieve state-of-the-art image generation performance. Implementing it in Transformers would enable easier experimentation and integration with existing language models.

### Your contribution

I can help by contributing to this model, and provide examples and detailed explanations of the model architecture and training process if needed.
Repository: opencv
Issue: OpenCV DNN_TARGET_NPU not supported exception in dnn target validation
Labels: question (invalid tracker),category: dnn

### System Information

OpenCV version: 4.10.0
Operating System / Platform: Ubuntu 22.04
Compiler & compiler version: Java JDK 11

### Detailed description

== OnnxModel from ==
https://github.com/opencv/opencv_zoo/blob/main/models/human_segmentation_pphumanseg/human_segmentation_pphumanseg_2023mar.onnx


== Working For ==
Dnn Backend : 2 (DNN_BACKEND_INFERENCE_ENGINE)
Dnn Target     : 1 (DNN_TARGET_OPENCL)

== Error When ==
Dnn Backend : 2 (DNN_BACKEND_INFERENCE_ENGINE)
Dnn Target     : 9 (DNN_TARGET_NPU)

Throw following Exception :

> Unknown OpenVINO target:
>     'preferableTarget == DNN_TARGET_CPU || preferableTarget == DNN_TARGET_OPENCL || preferableTarget == DNN_TARGET_OPENCL_FP16 || preferableTarget == DNN_TARGET_MYRIAD || preferableTarget == DNN_TARGET_HDDL || preferableTarget == DNN_TARGET_FPGA'
> where
>     '(int)preferableTarget' is 9
]


### Steps to reproduce

import java.io.File;
import java.util.ArrayList;
import java.util.List;

import org.opencv.core.Mat;
import org.opencv.dnn.Dnn;
import org.opencv.dnn.Net;

import hl.opencv.util.OpenCvUtil;

public class Test {
	
	public static void main(String[] args)
	{
		OpenCvUtil.initOpenCV();
		
		File fileOnnx = new File("./human_segmentation_pphumanseg_2023mar.onnx");
		Net net = Dnn.readNetFromONNX(fileOnnx.getAbsolutePath());
		net.setPreferableBackend(Dnn.DNN_BACKEND_INFERENCE_ENGINE);
		net.setPreferableTarget(Dnn.DNN_TARGET_NPU);
		
		// Run inference
		List<Mat>outputs = new ArrayList<>();
		net.forward(outputs, net.getUnconnectedOutLayersNames());

				
	}
	
}

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: go
Issue: runtime:cpu4: TestGdbAutotmpTypes failures
Labels: NeedsInvestigation,compiler/runtime

```
#!watchflakes
default <- pkg == "runtime:cpu4" && test == "TestGdbAutotmpTypes"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8735129364045440305)):

    === RUN   TestGdbAutotmpTypes
    === PAUSE TestGdbAutotmpTypes
    === CONT  TestGdbAutotmpTypes
        runtime-gdb_test.go:78: gdb version 15.0


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: vscode
Issue: Terminal search gives up after only 1000 search highlights
Labels: bug,help wanted,upstream,perf,upstream-issue-linked,terminal-find

* run a script that prints `TRIES n`
* search for regex `TRIES \d`
* scroll around a little
* :bug: search matches aren't reliable

<img width="1239" alt="Screenshot 2024-10-03 at 09 34 55" src="https://github.com/user-attachments/assets/9431e122-dbc9-4283-8c2c-3854080554a8">
Repository: ui
Issue: [bug]: tailwindcss-animate should be installed in devDependencies
Labels: bug

### Describe the bug

tailwindcss-animate should be installed in devDependencies

### Affected component/components

no

### How to reproduce

pnpx shadcn@latest init

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
macOS 15.0, pnpm 9.12.0
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: PowerToys
Issue: a shortcut that allows you open a new tab with selected text searched in google or any preferred search website
Labels: Idea-Enhancement,Needs-Triage

### Description of the new feature / enhancement

a key combination shortcut that allows you open a new tab with selected text searched in google or any preferred search website

### Scenario when this would be used?

when you look for anything in a webpage and want to search in google in a new tab

### Supporting information

any googling situation
Repository: vscode
Issue: test: waitThrottleDelayBetweenWorkUnits is flaky
Labels: bug,unit-test-failure

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=296767&view=logs&j=78322c78-e078-5e20-184d-1b2bb6aed118&t=6d18ead1-26fd-5e07-64e3-cefc56c57b3e

Also see https://github.com/microsoft/vscode/pull/230335
Repository: flutter
Issue: [iOS build] Add support for xcodebuild derivedDataPath flag 
Labels: c: new feature,platform-ios,tool,t: xcode,c: proposal,a: build,P3,team-ios,triaged-ios

### Use case

I want to run multiple parallel builds on my Mac Studio Runner machine. 
By setting `derivedDataPath` I expect to no longer use `~/Library/Developer/Xcode/DerivedData` and so avoid issue about it.

Bellow command sadly didn't work 

```console
export FLUTTER_XCODE_DERIVEDDATA_PATH=DerivedData ; flutter build ipa
```

### Proposal

Maybe same proposal as https://github.com/flutter/flutter/issues/121702 by adding an environnement variable.
Repository: excalidraw
Issue: Support angle constrained freedraw (Shift + draw straight line in discrete angles) just like with the line tool
Labels: good first issue

Holding Shift and creating a line tool constrains the line to a discrete angle. It would be ideal to have a similar functionality for freedraw elements, where when Shift is held, the freedraw drawing is straight and constrained to the same discrete angles, like with the Shift + line tool. It would mirror the behavior in Photoshop.
Repository: PowerToys
Issue: New+ is incorrectly translated to "Novità+" in Italian
Labels: Issue-Bug,Area-Localization,Needs-Triage,Issue-Translation,Product-New+

### Microsoft PowerToys version

0.85

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

New+

### Steps to reproduce

Just run PowerToys in Italian:

![image](https://github.com/user-attachments/assets/d21faf7c-d885-4231-a08b-d7bfc4dc9229)


### ✔️ Expected Behavior

**New+** should be **Nuovo+** in Italian.

### ❌ Actual Behavior

**New+** is incorrectly translated as **Novità+** in Italian.

### Other Software

_No response_
Repository: rust
Issue: Suggestion: debug-assert that the allocator returns aligned memory
Labels: C-feature-request,T-libs,A-align

If the global allocator returns unaligned memory, the standard library catches it very late. Take this code:

```rs
#[global_allocator]
static GLOBAL: AccountingAllocator<mimalloc::MiMalloc> =
    AccountingAllocator::new(mimalloc::MiMalloc);

#[repr(C, align(256))]
pub struct BigStruct { … }

fn collect() {
    assert_eq!(align_of::<BigStruct>(), 256);
    assert_eq!(size_of::<BigStruct>(), 256);
    let vec: Vec<T> = std::iter::once(BigStruct{…}).collect();
    dbg!(vec.as_ptr() as usize % std::mem::align_of::<T>()); // Sometimes prints 64
    let slice = vec.as_slice(); // panics in debug builds with:
    // 'unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null, and the total size of the slice not to exceed `isize::MAX`'
}
```

Because of [a bug in MiMalloc](https://github.com/purpleprotocol/mimalloc_rust/issues/128), the `Vec` gets non-aligned memory.
This is not discovered until `vec.as_slice` calls `slice::from_raw_parts` which has a debug-assert.

I spent a lot of time looking for this bug before I realized it was MiMalloc that was to blame.

I suggest we add a debug-assert the standard library to check that the allocator returns aligned memory, i.e. here:

https://github.com/rust-lang/rust/blob/8885239786c9efe5c6077de65536a5e092e34a55/library/alloc/src/raw_vec.rs#L442-L478

That would then report "The global allocator returned non-aligned memory", directly pointing the user at the problem, saving a lol of time for the next person.
Repository: godot
Issue: Exporting 3D projects to Raspberry Pi doesn't seem to work, ERROR: No loader found for resource: (expected type: CompressedTexture2D)
Labels: bug,platform:linuxbsd,needs testing,topic:import,topic:export

### Tested versions

4.2 and 4.3

### System information

windows on X86 and linux on arm

### Issue description

See title.

### Steps to reproduce

Just try exporting to linux on arm the app will not launch.

### Minimal reproduction project (MRP)

Take any project and export to linux on arm.