sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: electron
Issue: Docs: Missing some properties in AuthenticationResponseDetails
Labels: bug :beetle:,status/confirmed,component/webcontents,component/app

### Preflight Checklist

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

### Electron Version

33.3.0

### What operating system(s) are you using?

Windows

### Operating System Version

Windows 11

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

![Image](https://github.com/user-attachments/assets/7f12dd31-002d-4221-add4-75f03ce9589a)

```ts
  interface AuthenticationResponseDetails {
    url: string;
    pid: number;
    isMainFrame: boolean;
    // ....
  }
```

### Actual Behavior

```ts
  interface AuthenticationResponseDetails {
    url: string;
    pid: number;
  }
```

### Testcase Gist URL

_No response_

### Additional Information

_No response_
Repository: opencv
Issue: fastNlMeansDenoisingMulti does not support 16 bit values
Labels: bug

### System Information

OpenCV version: 4.10.0
Operating System / Platform: All
Compiler & compiler version: All

### Detailed description

The documentation for [fastNlMeansDenoisingMulti](https://docs.opencv.org/4.10.0/d1/d79/group__photo__denoise.html#ga723ffde1969430fede9241402e198151) states that it should support 16 bit values.
The [implementation](https://github.com/opencv/opencv/blob/3d91d75f1a48dbba46f8cb7f264485a37e6102a2/modules/photo/src/denoising.cpp#L244) however, enforces 8 bit values even though the underlying code supports 16 bit.

A fix is available in [my branch](https://github.com/opencv/opencv/compare/4.x...dchansen:opencv:nlMeansFix)

### Steps to reproduce

1. Run fastNlMeansDenoisingMulti with a 16 bit image. 
2. Get error

### 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
- [ ] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: vscode
Issue: Show Primary Side Bar in new empty window when Activity Bar position not Default
Labels: feature-request,file-explorer,layout,workbench-views

#226027 originally raised this. The fix for it by @benibenj (#227677) was subsequently reverted by #230919 because it caused a regressions, particularly when the restored workspace had had its Primary Side Bar hidden at time of closing.

The current behaviour means that extensions using the `viewsWelcome` contribution point to add "getting started" aids to the empty Explorer view can no longer help the user.

When a new window is opened and isn't restoring a previous workspace plus its state, please make sure that the Explorer view is visible (whichever container it is in), either unconditionally or else at least if it had been visible when VS Code was previously closed.
Repository: ollama
Issue: Add stop word  
 to qwq models
Labels: bug

### What is the issue?

The [qwq models](https://ollama.com/library/qwq) currently go into an infinite loop. 
The reasons for this appears that the model outputs 
 at the end of its response, but ollama does not handle this as a stop word. The model therefore continues with hallucinations and goes into infinite loop. 

Tested locally that the issue was resolved by using a custom model file containing
```
FROM qwq:latest
# Adding additional stop as otherwise the qwq model goes into an infinite loop
PARAMETER stop 

```



### OS

Windows

### GPU

Nvidia

### CPU

Intel

### Ollama version

0.4.7
Repository: rust
Issue: Tracking Issue for spurious mingw CI failures
Labels: T-compiler,O-windows-gnu,T-bootstrap,T-infra,C-tracking-issue,A-CI,CI-spurious-fail-mingw

The spurious `mingw` failures might be *related* to #127883, but for the purpose of tracking, we should delineate the two general categories separately to avoid conflating them.

Please feel free to update specific classifications of kinds of spurious `mingw` failures.

### Known problems

- https://github.com/rust-lang/rust/issues/108227


### Misc

Label: https://github.com/rust-lang/rust/labels/CI-spurious-fail-mingw
Repository: rust
Issue: Meta tracking issue for spurious CI failures
Labels: T-compiler,T-bootstrap,A-spurious,T-infra,C-tracking-issue,A-CI,S-tracking-forever

This is a (meta) tracking issue intended to make it easier to find the specific spurious CI failure issues.

## Platform-specific

- https://github.com/rust-lang/rust/issues/127883; https://github.com/rust-lang/rust/labels/CI-spurious-fail-msvc
- https://github.com/rust-lang/rust/issues/134351; https://github.com/rust-lang/rust/labels/CI-spurious-fail-msvc
- https://github.com/rust-lang/rust/issues/133958; https://github.com/rust-lang/rust/labels/CI-spurious-fail-mingw
- https://github.com/rust-lang/rust/issues/134220; https://github.com/rust-lang/rust/labels/CI-spurious-x86_64-apple-SIGSEGV-SIGILL 

## Runner-specific

- https://github.com/rust-lang/rust/issues/97669

## Known problems

### LLVM

- https://github.com/rust-lang/rust/issues/109624
- https://github.com/rust-lang/rust/issues/110290

### Pointer provenance ABA lockless queue test failures

- ABA pointer provenance lockless queue test failures due to #121950 in the miri test suite, https://github.com/rust-lang/rust/labels/CI-ABA-ptr-provenance-lockless-queue-fail

### Linkers

#### `rust-lld` can sometimes crash quite often

- https://github.com/rust-lang/rust/issues/128286

## Networking failures

- https://github.com/rust-lang/rust/issues/40474

## Bot troubles

- https://github.com/rust-lang/rust/issues/43535

## Possible mitigation approaches

- https://github.com/rust-lang/rust/issues/134472

## Others

- Suspected cosmic bitflips or faulty memory cell: https://github.com/rust-lang/rust/pull/136084#issuecomment-2614238643
Repository: material-ui
Issue: [docs] add examples of testing with mui with react-testing-library
Labels: docs

### Related page

https://mui.com/material-ui/guides/testing/

### Kind of issue

Unclear explanations

### Issue description

I already spend a day trying to figure out what is a good way to write tests with mui. From docs:

> For example, when rendering a TextField your test should not need to query for the specific Material UI instance of the TextField but rather for the input, or [role="textbox"].

Okay, I should query for role=textbox, but I am not sure how I would test some mui components without data-testid. For example, password and confirm password. I can't really get first input without exact specifying exact label. Should I do it? Or should I use data-testid then? I understand that mui is not about testing, but still it can save so much time for those that are developing with mui if there was at least one example for reference.

### Context

I have a form with different submit schemas and it relatively big. It consists of 6 steps (sign up, email confirmation, 4 other steps for company creation specific to our business). Just sign-up step with firebase is around 300 lines of code, so I am trying to write tests for it to ensure I wouldn't break anything in the future.

For form itself we use, zod with react-hook-form + firebase for user authentication. We also use next and next-intl for internalization

**Search keywords**: testing mui jest vitest react-testing-library rtl @testing-library/react
Repository: langchain
Issue: HuggingFaceEndpoint returning buggy responses and prompt template back
Labels: 🤖:bug,investigate

### Checked other resources

- [X] I added a very descriptive title to this issue.
- [X] I searched the LangChain documentation with the integrated search.
- [X] I used the GitHub search to find a similar question and didn't find it.
- [X] I am sure that this is a bug in LangChain rather than my code.
- [X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

### Example Code

```
llm = HuggingFaceEndpoint(
    repo_id= 'meta-llama/Llama-3.1-8B-Instruct',
    huggingfacehub_api_token=api_token
)
```

```
llm_chain = (
    {
        "context": lambda inputs: retrieve_context(inputs['question'], inputs['vector']),
        "question": RunnablePassthrough()
    }
    | PromptTemplate(
        template=BASE_TEMPLATE,
        input_variables=["context", "question"]
    )
    | llm
    | StrOutputParser()
)

llm_chain.invoke({ 'question': user_query, 'vector': vector })
```

### Error Message and Stack Trace (if applicable)

As you can see in langsmith, it returned this output.

<img width="344" alt="image" src="https://github.com/user-attachments/assets/0cdf266f-4f63-4537-ab75-ef9b61cfdda9">


### Description

I'm using HuggingFaceEndpoint for inference to avoid storing model on my local machine, and I've noticed it gives buggy responses quite a few times. I'm using it for a RAG and a lot of times it just returns back the entire base prompt template inside 
...
. And as seen in screenshot attached, it returned "
" in a loop until max tokens limit reached.

### System Info

System Information
------------------
> OS:  Darwin
> OS Version:  Darwin Kernel Version 22.4.0: Mon Mar  6 21:00:17 PST 2023; root:xnu-8796.101.5~3/RELEASE_X86_64
> Python Version:  3.12.6 (main, Sep  6 2024, 19:03:47) [Clang 15.0.0 (clang-1500.1.0.2.5)]

Package Information
-------------------
> langchain_core: 0.3.19
> langchain: 0.3.7
> langchain_community: 0.3.7
> langsmith: 0.1.143
> langchain_huggingface: 0.1.2
> langchain_text_splitters: 0.3.2
> langchainhub: 0.1.21

Optional packages not installed
-------------------------------
> langgraph
> langserve

Other Dependencies
------------------
> aiohttp: 3.11.4
> async-timeout: Installed. No version info available.
> dataclasses-json: 0.6.7
> httpx: 0.27.2
> httpx-sse: 0.4.0
> huggingface-hub: 0.26.2
> jsonpatch: 1.33
> numpy: 1.26.4
> orjson: 3.10.11
> packaging: 24.2
> pydantic: 2.9.2
> pydantic-settings: 2.6.1
> PyYAML: 6.0.2
> requests: 2.32.3
> requests-toolbelt: 1.0.0
> sentence-transformers: 3.3.1
> SQLAlchemy: 2.0.35
> tenacity: 9.0.0
> tokenizers: 0.20.3
> transformers: 4.46.3
> types-requests: 2.32.0.20241016
> typing-extensions: 4.12.2
Repository: tauri
Issue: [bug] libarchive.13.dylib' (no such file),
Labels: type: bug,platform: macOS,status: needs triage

### Describe the bug

dyld[82730]: Library not loaded: /opt/homebrew/opt/libarchive/lib/libarchive.13.dylib
  Referenced from: <3A92023B-E694-3FA1-B4FC-5056A4F353A7> /Users/suzhiwei/Documents/gitsource/fom/src-tauri/target/release/omg-ff
  Reason: tried: '/opt/homebrew/opt/libarchive/lib/libarchive.13.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/libarchive/lib/libarchive.13.dylib' (no such file), '/opt/homebrew/opt/libarchive/lib/libarchive.13.dylib' (no such file)

### Reproduction

_No response_

### Expected behavior

_No response_

### Full `tauri info` output

```text
> omg-ff@0.1.0 tauri
> tauri info


[✔] Environment
    - OS: Mac OS 15.0.1 x86_64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: 1.81-x86_64-apple-darwin (default)
    - node: 20.11.1
    - pnpm: 8.6.11
    - yarn: 1.22.22
    - npm: 10.2.4

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - @tauri-apps/api : 2.1.1
    - @tauri-apps/cli : 2.1.0

[-] Plugins
    - tauri-plugin-fs 🦀: 2.1.0
    - @tauri-apps/plugin-fs : not installed!
    - tauri-plugin-dialog 🦀: 2.0.4
    - @tauri-apps/plugin-dialog : 2.0.1
    - tauri-plugin-shell 🦀: 2.0.2
    - @tauri-apps/plugin-shell : 2.0.1

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: vscode
Issue: Need a Sort Order Option for Source Control
Labels: feature-request,scm

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

Hello,
I would like the files and folders in the Source Control panel to be displayed in the same order as configured in the Explorer's Sort Order settings. Currently, there doesn't seem to be an option to control the sort order of files and folders in the Source Control panel.

![Image](https://github.com/user-attachments/assets/bfb6c7ca-251f-4423-95be-64790bafcfd1)
Repository: rust
Issue: Tracking Issue for `bool::select_unpredictable`
Labels: T-libs-api,C-tracking-issue

Feature gate: `#![feature(select_unpredictable)]`

This is a tracking issue for `bool::select_unpredictable`, which selects between two values and hints to the optimizer that it should try to generate branchless code.

### Public API

```rust
impl bool {
    /// Returns either `true_val` or `false_val` depending on the value of
    /// `condition`, with a hint to the compiler that `condition` is unlikely
    /// to be correctly predicted by a CPU’s branch predictor.
    pub fn select_unpredictable<T>(self, true_val: T, false_val: T) -> T;
}
```

### Steps / History

- [x] ACP: https://github.com/rust-lang/libs-team/issues/468
- [ ] Implementation: https://github.com/rust-lang/rust/pull/133964
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

### Unresolved Questions

- This should be `const`, right?

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: pytorch
Issue: torch.tensor.to(‘cuda’) so slow in jetson orin
Labels: module: cuda,triaged,module: jetson

Here is my code of running an ViT inferrence.
`for i in range(100):
        s_time0 = time.time()
        image = Image.open(image_file).convert('RGB')
        print('open img time:',int((time.time() - s_time0) * 1000))
        s_time = time.time()
        
        image_tensor = process_anyres_image(
                image, model.image_processor, grid_points, False, False
            )
        print('process time:',int((time.time() - s_time0) * 1000))
        s_time = time.time()
        image_tensor = torch.from_numpy(image_tensor)
        print('array to tensor time:',int((time.time() - s_time0) * 1000))
        s_time = time.time()
        image_tensor = image_tensor.to('cuda', dtype=torch.float16)
        print('to gpu time:',int((time.time() - s_time0) * 1000))
        s_time = time.time()
        tokens = model(image_tensor)  # torch.Size([1, 3, 224, 224])
        endtime = time.time()
        print('forward time:',int((endtime - s_time) * 1000))
        print('total:',int((endtime - s_time0) * 1000))
        print('-----------------------')`

And the output is like this.
![image](https://github.com/user-attachments/assets/c4f8bf32-8084-4c61-818f-ec214e8e35e9)
It seems like tensor.to(‘cuda’) cost much time except first two times.

Here is the information of machine.
![image](https://github.com/user-attachments/assets/3a67b961-b2f1-49a8-ad3c-dc4a70a1fd7d)
And version of pytorch.
![image](https://github.com/user-attachments/assets/3dad0436-e5a6-4ba3-996f-2a74a74801f6)


cc @ptrblck @msaroufim @eqy @puririshi98
Repository: langchain
Issue: `InMemoryRateLimiter` does not work with `BaseLLM` child classes
Labels: 🤖:bug

### Checked other resources

- [X] I added a very descriptive title to this issue.
- [X] I searched the LangChain documentation with the integrated search.
- [X] I used the GitHub search to find a similar question and didn't find it.
- [X] I am sure that this is a bug in LangChain rather than my code.
- [X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

### Example Code

The `InMemoryRateLimiter` is not used when passed to a child class of `BaseLLM` (e.g. `VertexAI`). It is only used for child classes of `BaseChatModel` (e.g. `ChatVertexAI`). Additionally, no exception is raised when passing `InMemoryRateLimiter` to `BaseLLM`. 
```python
from langchain_core.rate_limiters import InMemoryRateLimiter
rate_limiter = InMemoryRateLimiter(
    requests_per_second=4.5, 
    check_every_n_seconds=0.5, 
    max_bucket_size=280,  
)

from langchain_google_vertexai import ChatVertexAI, VertexAI
chat = ChatVertexAI(
    model_name="gemini-1.0-pro", rate_limiter=rate_limiter
) # Rate limiter will get used by this object
llm = VertexAI(
    model_name="gemini-1.0-pro", rate_limiter=rate_limiter
) # Rate limiter will not get used by this object
```

### Error Message and Stack Trace (if applicable)

N/A

### Description

The `InMemoryRateLimiter` is not used when passed to a child class of `BaseLLM` (e.g. `VertexAI`). It is only used for child classes of `BaseChatModel` (e.g. `ChatVertexAI`). Additionally, no exception is raised when passing `InMemoryRateLimiter` to `BaseLLM`. From what I can tell, this is not discussed anywhere in the documentation, so will likely cause confusion for many users.

From further investigation, I found that there is no use of `InMemoryRateLimiter` in the constructor of `BaseLLM`: https://github.com/langchain-ai/langchain/blob/master/libs/core/langchain_core/language_models/chat_models.py#L207

but there is in the constructor of `BaseChatModel`: 
https://github.com/langchain-ai/langchain/blob/master/libs/core/langchain_core/language_models/llms.py#L292

### System Info

System Information
------------------
> OS:  Linux
> OS Version:  #1 SMP Debian 5.10.226-1 (2024-10-03)
> Python Version:  3.10.15 | packaged by conda-forge | (main, Sep 30 2024, 17:51:04) [GCC 13.3.0]
Repository: godot
Issue: Error `Cannot get class ''. Parameter "obj" is null.` under specific conditions
Labels: topic:gdscript,needs testing

### Tested versions

- Reproducible in: v4.3.stable.official [77dcf97d8]

### System information

Windows 10 and Ubuntu 20.04.6 - Compatibility renderer

### Issue description

I encountered this bug while making [my game](https://github.com/OgGhostJelly/Zombie-BurgerZ) and [this](https://github.com/OgGhostJelly/Zombie-BurgerZ/commit/e6c37a912ecf8d6a1ca74b40c4157c82377bdbc9#diff-76682f3289631b5dee833f7ddebba25fa0541aea3fffca458c8c925fa528e347) is the commit that started causing the errors, more specifically it seems the changes to `player.gd` and `gun.gd` are what caused it. If you try to select the smg in the shop it will segfault. The bug is now fixed in the later commits, I fixed it by replacing `preload` with `load` but I'm unsure why that worked.

### Steps to reproduce

- Download the attached Godot project
- Run it normally and see how there are no errors
- Export it into the .exports folder inside the project, it MUST be exported into that folder or else the bug won't appear. (not sure why, maybe something to do with the filename having a special character in it)
- Run the project in the terminal and see how there are now errors appearing in the exported version

### Minimal reproduction project (MRP)

The MRP is my game with all the code unrelated to the bug stripped away
[bug.zip](https://github.com/user-attachments/files/18045954/bug.zip)
Repository: go
Issue: x/pkgsite: automate trivial package removal requests
Labels: pkgsite,Friction

This is a reminder issue for a future team friction fixit week: we could reduce toil significantly by automating pkgsite removal requests.

Right now, the pkgsite removal process  requires users to file an issue requesting the removal of a package from pkgsite. Our triage person handles this request by (1) verifying some form of ownership for the relevant paths, and (2) sending an internal CL to exclude the paths from pkgsite. We get a steady stream of these requests, on the order of a few a week. They are almost all trivial, but still a source of interrupts and toil. Additionally, sometimes it takes several days (or even more than a week) to get to them, which is not a great experience for the requester.

We have considered completely changing the removal process to be more self-service, but one of the goals of the current process is to preserve an audit log, and github issues are (for better or worse), the canonical audit log for changes to the Go project.  We thought that module retractions would be a self-service way to remove content from pkgsite, but they only hide packages from search. Also, in the common case the repo has been deleted, so retractions are onerous on authors. For this reason, retractions do not seem to have reduced the number of removal requests we receive.

We could keep the current process, and reduce most of the toil, with automation:

1. Find pkgsite removal issues. Extract the requested path(s) to remove.
2. Check for ownership. It may suffice to check that the requester is the owner of repos containing the paths, though in some cases we need to check for organization membership.
3. Send an internal auto-submit CL to the tools team to process the removal.
4. Comment and close the issue.
Repository: electron
Issue: Transparency true makes the electron window flash when interacting with some other windows
Labels: platform/windows,bug :beetle:,has-repro-gist,33-x-y

### Preflight Checklist

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

### Electron Version

33.0.0

### What operating system(s) are you using?

Windows

### Operating System Version

10.0.22631

### What arch are you using?

x64

### Last Known Working Electron version

26.0.0

### Expected Behavior

A window should be visible at all times with transparency enabled and alwaysOnTop true when we interact with other windows after focusing into an electron window, it should not flash/vanish.

It used to work before version 26, and doesn't work in any version after that.



### Actual Behavior

When clicking away from the window it vanishes, and the visibility event does not get triggered, chrome profiler shows the window is always there only on the actual desktop does it vanish. 
To reproduce, first, click on the transparent window and bring it into focus, and then click on some other window, it vanishes.
I saw this happening by clicking on a WPF window or some text editors like IntelliJ.

You will be able to continuously reproduce it if you interact with another window which also has alwaysOnTop true.

### Testcase Gist URL

https://gist.github.com/ImrozKhan21/d5944d0d4867aa3a18c0a2556c44f2c8

### Additional Information

_No response_