sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: pnpm build does not detect @types/react nor @types/node even tho they're defined (vercel deploy) 
Labels: create-next-app,bug,TypeScript

### Link to the code that reproduces this issue

https://github.com/Huilensolis/next-js-typescript-is-broken

### To Reproduce

1. create new project on vercel
2. select `pnpm install` as the install command
3. deploy
4. see console errors

### Current vs. Expected behavior

logs:
```bash
Detected `pnpm-lock.yaml` version 9 generated by pnpm 9
Running "install" command: `pnpm install`...
Lockfile is up to date, resolution step is skipped
Packages: -3
---
devDependencies:
- @types/node 20.11.5
- @types/react 18.2.48
- @types/react-dom 18.2.18

- encoding 0.1.13
Done in 924ms
Detected Next.js version: 14.2.4
Running "pnpm run build"
> @ build /vercel/path0
> next build
  ▲ Next.js 14.2.4
  - Experiments (use with caution):
    · instrumentationHook
   Creating an optimized production build ...
 ✓ Compiled successfully
   Linting and checking validity of types ...
It looks like you're trying to use TypeScript but do not have the required package(s) installed.
Please install @types/react and @types/node by running:
	pnpm install --save-dev @types/react @types/node
If you are not trying to use TypeScript, please remove the tsconfig.json file from your package root (and any TypeScript files in your pages directory).
```

### Provide environment information

this is my local environment, where `pnpm run build` works just fine. the issue only happens deploying on vercel (haven't tried other hosting)

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Thu, 28 Mar 2024 17:06:35 +0000
  Available memory (MB): 11707
  Available CPU cores: 4
Binaries:
  Node: 18.18.0
  npm: 9.8.1
  Yarn: 1.22.22
  pnpm: 9.0.6
Relevant Packages:
  next: 14.2.4 // Latest available version is detected (14.2.4).
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: N/A
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

create-next-app, TypeScript

### Which stage(s) are affected? (Select all that apply)

Vercel (Deployed)

### Additional context

this issue pointed before https://github.com/vercel/next.js/issues/36201
this does not happened on local, but only deploys on vercel (haven't tried other hosting providers)
Repository: godot
Issue: Behavior of `String::num` causes parse error for large float fields in Godot inspector
Labels: discussion,topic:core

### Tested versions

- Reproducible in 3.5.3.stable.official, 4.2.1.stable.official, 4.3.beta (4ab8fb809)

### System information

Godot v4.3.beta (4ab8fb809) - macOS 14.0.0 - GLES3 (Compatibility) - Apple M1 - Apple M1 (8 Threads)

### Issue description

- Entering a float in plain decimal notation greater than the maximum signed integer into a float field in the inspector causes an error and sets the field to the maximum signed 64-bit integer instead -- this is a separate issue relating to GDScript's way of parsing floats.
- It's possible to enter large values into float fields in the inspector using scientific notation (e.g. by typing `1e100` into the field), but when clicking off the field this is converted into a long series of digits (e.g. `10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104`). This is stored properly.
- If you click back into the field and then back off, the field tries to parse its current text (a sequence of digits larger than the maximum signed 64-bit integer), throws an error, and sets the field to a float representation of the maximum signed 64-bit integer.

I assume a similar thing would happen with `SpinBox`, but I haven't tested this.

All of the individual steps of this (error for parsing absurdly large strings of digits; stringifying a float as a series of digits) make a lot of sense, but the result is that clicking on and off of a field changes the value, which feels like a bug.

I can think of a few possible solutions:
- Show absurdly large numbers in the inspector with scientific notation -- this has the advantage of being human-readable and gdscript-parseable and there seems to be a way of stringifying floats using scientific notation seeing as that's how large floats seem to be stored in the save file format. However, this seems like more of a new feature than a bugfix.
- Fix the way GDScript parses floats.
- Change something about how `EditorSpinSlider` works so that clicking on and off of something never changes its value.

### Steps to reproduce

1. Create a script with an exported `float` field (no range hint).
2. In the inspector, click on the field and type in `1e+100`.
3. Click off of the field to confirm. The field should now say `10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104`.
4. Click on the field again to edit it. Don't type anything.
5. Click off of the field. An error should show in the Output section, and the field is set to `9223372036854775807`.

### Minimal reproduction project (MRP)

[float-bug.zip](https://github.com/user-attachments/files/16043294/float-bug.zip)
(v4.2.1.stable.official, I think)
Repository: godot
Issue: "Input.use_accumulated_input = false" not working
Labels: needs testing,topic:input

### Tested versions

Reproducible: v4.3.beta2.official [b75f0485b]

### System information

Godot v4.3.beta2 - macOS 14.5.0 - Vulkan (Forward+) - integrated Apple M2 Pro - Apple M2 Pro (10 Threads)

### Issue description

Disables input accumulation, but input events are still called together every frame.

### Steps to reproduce

Set the maximum fps to 1 and print the time in the input callback. When the key is pressed continuously, the printed time is repeated within each frame. This prevents getting the exact time of the input in Godot.

### Minimal reproduction project (MRP)

[new-game-project.zip](https://github.com/user-attachments/files/16043456/new-game-project.zip)
Repository: neovim
Issue: Diff: `foldclose` and `wrap` don't sync
Labels: enhancement,folds,diff

### Problem

In `'diff'` mode:

1. When a diff fold (containing equivalent lines) closes due to `foldclose` and cursor movement, it only closes in the current buffer. Yet this does work properly when the fold is explicitly closed instead (which will close it in all diff buffers).

2. Soft-wrapped lines are not compensated for in other diff-buffers where they are not soft-wrapped (or when they are soft-wrapped as well, but take up fewer screen rows).

   For example, notice how the screen lines are not properly vertically-aligned until `set nowrap` (2nd image):

<img width="1560" alt="Screenshot 2024-06-30 at 3 30 06 AM" src="https://github.com/neovim/neovim/assets/45028928/c56dcc79-1fad-4af4-aa9e-0cb1108aae4d"><br />

<img width="1553" alt="Screenshot 2024-06-30 at 3 29 56 AM" src="https://github.com/neovim/neovim/assets/45028928/b642f2bd-02c2-4cdf-a44f-898a925a872d"><br />

GitHub soft-wrapping both sides:

<img width="817" alt="Screenshot 2024-07-01 at 2 30 19 AM" src="https://github.com/neovim/neovim/assets/45028928/cc06b544-a0bf-490d-8352-968ac0c6cf54"><br /><br />

3. In diff mode, having only 1 window scroll when using the mouse is kinda annoying, but I guess this is intended behavior when the scrolled window isn't the current window.

---

Both of these issues cause the diffed buffers to become out-of-sync visually (vertical splits in particular).

### Expected behavior

1. The automatic closing of folds due to `foldclose` should sync across all diff buffers, just like `zc` does.

2. For any line that takes up less screen rows than the `max()` of all respective lines in other diffed buffers, empty virtual or wrapped lines should be added underneath that line (kinda like how is done on GitHub.com's side-by-side diff when code lines are soft-wrapped). This also means that sometimes extra diff "filler" lines need to be added to a set/hunk of diff filler lines.

   These extra screen lines/rows should inherit the same highlighting as the line they are applied to, just like how is done currently for soft-wrapping. The result is that the lines will be synced and line-up visually.
Repository: rust
Issue: Tracking Issue for anonymous pipe API
Labels: T-libs-api,C-tracking-issue,disposition-merge,finished-final-comment-period,F-anonymous_pipe

This is a tracking issue for the ACP rust-lang/libs-team#375 .
The feature gate for the issue is `#![feature(anonymous_pipe)]`.

```rust
// std::pipe

fn pipe() -> io::Result<(PipeReader, PipeWriter)>;

struct PipeReader {...}
struct PipeWriter {...}

impl PipeReader {
    fn try_clone(&self) -> io::Result<Self>;
}

impl PipeWriter {
    fn try_clone(&self) -> io::Result<Self>;
}

impl Read for &PipeReader
impl Read for PipeReader
impl Debug for PipeReader
impl From<PipeReader> for Stdio

impl Write for &PipeWriter
impl Write for PipeWriter
impl Debug for PipeWriter
impl From<PipeWriter> for Stdio

// unix {
impl AsFd for PipeReader
impl AsRawFd for PipeReader
impl FromRawFd for PipeReader
impl IntoRawFd for PipeReader
impl From<PipeReader> for OwnedFd
impl From<OwnedFd> for PipeReader

impl AsFd for PipeWriter
impl AsRawFd for PipeWriter
impl FromRawFd for PipeWriter
impl IntoRawFd for PipeWriter
impl From<PipeWriter> for OwnedFd
impl From<OwnedFd> for PipeWriter
// }

// windows {
impl AsHandle for PipeReader
impl AsRawHandle for PipeReader
impl FromRawHandle for PipeReader
impl IntoRawHandle for PipeReader
impl From<PipeReader> for OwnedHandle
impl From<OwnedHandle> for PipeReader

impl AsHandle for PipeWriter
impl AsRawHandle for PipeWriter
impl FromRawHandle for PipeWriter
impl IntoRawHandle for PipeWriter
impl From<PipeWriter> for OwnedHandle
impl From<OwnedHandle> for PipeWriter
// }
```

### Steps

- [x] Implement the ACP #127153
- [x] Enable `std::io::copy` specialisation #128303
- [x] Adjust documentation #133986 ([see instructions on rustc-dev-guide][doc-guide])
- [x] Move pipe API into `std::io` #135583
- [ ] Stabilization PR #135822 ([see instructions on rustc-dev-guide][stabilization-guide]) 

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

### Implementation history

 - #127153
 - #128303
Repository: ollama
Issue: Add Basic Networking Tools to Docker Image for Health Checks
Labels: feature request

Hi! Would it be possible to include one or two network command packages like `ping`, `netcat`, or `curl` in the Docker image? This would allow folks who want to query the health check endpoint using `docker compose` or similar tools to do so without needing to create a custom `Dockerfile`.

I get that y'all are [hesitant](https://github.com/ollama/ollama/pull/1909) about adding a `HEALTHCHECK` command directly to the Dockerfile since it's not standard in any of Docker's official images. But at least with these packages, anyone wanting to set up a health check for their containers can do so more easily.

I'd be happy to open a PR for this if you think it's a good idea.

Thanks!
Repository: godot
Issue: Extra border in editor documentation tooltips due to nested panels
Labels: enhancement,usability,topic:gui

### Tested versions

- v4.3.beta.custom_build [b75f048]

### System information

Godot v4.3.beta - Arch Linux 6.9.6-zen1 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1650 (nvidia; 550.90.07) - Intel(R) Core(TM) i5-10300H CPU @ 2.50GHz (8 Threads)

### Issue description

![tooltip-issue](https://github.com/godotengine/godot/assets/132811907/90d989b6-5930-4d68-a086-6f231c6116a6)
*That's what happens...*

### Steps to reproduce

1. Use the editor theme that has bigger tooltip borders (e.g. [Minimal Theme](https://github.com/passivestar/godot-minimal-theme)).
2. Hover anything that has offline documentation.

### Minimal reproduction project (MRP)

Non-sense.
Repository: tauri
Issue: [bug] Inconsistent render order
Labels: type: bug,status: needs triage

### Describe the bug

I'm trying to render a transparent tauri webview on top of wgpu but I'm running into some inconsistencies between platforms. On macOS everything works correctly, but on iOS the wgpu surface is rendered on top of the the webview instead. I'm not sure which is the correct behavior but that it differs between targets seems like a bug to me.

### Reproduction

https://github.com/johanholmerin/tauri-v2-wgpu/tree/mobile

Compare `cargo tauri dev` and `cargo tauri ios dev`

### Expected behavior

macOS:
![macos](https://github.com/tauri-apps/tauri/assets/7433263/bb948242-cf0a-4313-8ab7-d515fc7e3322)



iOS:

(webview is rendered underneath wgpu)
![ios](https://github.com/tauri-apps/tauri/assets/7433263/a0b6a1aa-2fae-400c-9e95-e392275d3b9e)



### Full `tauri info` output

```text
[✔] Environment
    - OS: Mac OS 14.5.0 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.79.0 (129f3b996 2024-06-10)
    ✔ cargo: 1.79.0 (ffa9cf99a 2024-06-03)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.12.2
    - pnpm: 8.6.12
    - yarn: 1.22.22
    - npm: 10.5.0

[-] Packages
    - tauri [RUST]: 2.0.0-beta.22
    - tauri-build [RUST]: 2.0.0-beta.17
    - wry [RUST]: 0.40.1
    - tao [RUST]: 0.28.1
    - tauri-cli [RUST]: 2.0.0-beta.20
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 2.0.0-beta.20

[-] App
    - build-type: build
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: ui
Issue: [bug]: button i giving error
Labels: bug

### Describe the bug

https://ui.shadcn.com/docs/components/combobox in this url, In last section of form 
![image](https://github.com/shadcn-ui/ui/assets/66185332/93f90c30-91c9-4911-9cc8-fe58f00a893f)
when click a select langugae it gives this error Application error: a client-side exception has occurred (see the browser console for more information).

### Affected component/components

combobox

### How to reproduce

1. go to : https://ui.shadcn.com/docs/components/combobox 
2. In last selection select langugae .
3. see this error Application error: a client-side exception has occurred (see the browser console for more information).

### Codesandbox/StackBlitz link

https://ui.shadcn.com/docs/components/combobox

### Logs

_No response_

### System Info

```bash
windows 11, dell computer, chrome latest version
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: stable-diffusion-webui
Issue: [Feature Request]: extra auth for extensions tab , settings tab or any tabs
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 ?

extra auth for extensions tab , settings tab or any tabs
so we can share webui for other ppl, but also avoid they change settings

### Proposed workflow

1. Go to .... 
2. Press ....
3. ...


### Additional information

_No response_
Repository: vscode
Issue: The cursor and mouse not consistent!
Labels: bug,linux,editor-core

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.90.2
- OS Version: ubuntu 20.04

Steps to Reproduce:

Sorry, I do not know how to reproduce. It just come up again and again. It is really annoying. If you want to know what the bug look like, pls look at [this video](https://x.com/i/status/1807340067134026039).
Repository: opencv
Issue: A better implementation for clahe algorithm with a small change in redistribution process. Its not a coding problem.
Labels: bug,category: imgproc,needs investigation

### System Information

Not a coding problem

### Detailed description

In the **CLAHE** algorithm, users input cliplimit to truncate histogram of image tiles, and then the truncated pixels are redistributed to the histogram of the tile. 

In opencv's implementation, there are two rounds of redistribution: the first round distributes a number of pixels that is divisible by histSize (int redistBatch = clipped / histSize; histSize commonly becomes 256 or 65536), and the second round handles the residual that is not divisible (int residual = clipped - redistBatch * histSize; int residualStep = MAX(histSize / residual, 1);).

The issue arises in the second round of redistribution. In opencv's implementation, the step size for the second round is rounded down to an integer type. Lets take a look at the diagrams as an example. I draw lut (Look-Up Table)  and histogram of same tile in two diagrams using matlab.

In the "distribution with int step" diagram (which is the opencv case), 47,320 pixels still need to be distributed among 65,536 grayscale levels in the second round redistribution. Due to the rounding down, the step size for the second round is floor(65536/47320)=1, so the later grayscale levels from 47,320 to 65,536 are not allocated, which causes the lut to have lower slope during this range of grayscale levels, resulting in the image **becoming brighter and increasing the number of overexposed pixels** after mapping.

In the "distribution with float step" diagram (which is my improved way), I redistribute with a step size of 65536/47320=1.385, which ensures a more smoothed lut and thus a better mapping.

This issue is more pronounced in images with high bit numbers, especially 16 bit image. However, people usually process 8 bit images, which may be the reason why it is not yet reported in the past.

Simply changing the step logic during the second round redistribution from 'int' to 'float' will resolve this issue.

I checked the opencv's opencl code and cv-cuda code, this issue also exist.

<img width="1053" alt="0_65535_1_1_float" src="https://github.com/opencv/opencv/assets/126048685/46526944-3548-4bb6-a007-f40270f907ad">
<img width="1055" alt="0_65535_1_1_int" src="https://github.com/opencv/opencv/assets/126048685/1b212803-7483-4f22-ab57-e1dbc8d11041">


### Steps to reproduce

Sry, Im not a good programmer. I cannot provide test code.

I hope the description and diagrams can fully illustrate my point.

### Issue submission checklist

- [X] I report the issue, it's not a question
- [ ] 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: kubernetes
Issue: Graduate RotateKubeletServerCertificate
Labels: kind/cleanup,sig/node,sig/auth,lifecycle/rotten,needs-triage

This feature is in beta since 1.12

https://github.com/kubernetes/kubernetes/blob/d902351c991a68fa76de9935a485afeb1f780c11/pkg/features/kube_features.go#L658-L665

and seems really simple to graduate and remove it

```sh
$ grep -r RotateKubeletServerCertificate {cmd,pkg,test,staging}
cmd/kubelet/app/options/options.go:     fs.BoolVar(&c.ServerTLSBootstrap, "rotate-server-certificates", c.ServerTLSBootstrap, "Auto-request and rotate the kubelet serving certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. Requires the RotateKubeletServerCertificate feature gate to be enabled, and approval of the submitted CertificateSigningRequest objects.")
pkg/kubelet/kubelet.go:         if kubeCfg.ServerTLSBootstrap && utilfeature.DefaultFeatureGate.Enabled(features.RotateKubeletServerCertificate) {
pkg/kubelet/apis/config/types.go:       // certificate signing requests. The RotateKubeletServerCertificate feature
pkg/kubelet/apis/config/validation/validation_test.go:          name: "specify ServerTLSBootstrap without enabling RotateKubeletServerCertificate",
pkg/kubelet/apis/config/validation/validation_test.go:                  conf.FeatureGates = map[string]bool{"RotateKubeletServerCertificate": false}
pkg/kubelet/apis/config/validation/validation_test.go:          errMsg: "invalid configuration: serverTLSBootstrap true requires feature gate RotateKubeletServerCertificate",
pkg/kubelet/apis/config/validation/validation.go:       if kc.ServerTLSBootstrap && !localFeatureGate.Enabled(features.RotateKubeletServerCertificate) {
pkg/kubelet/apis/config/validation/validation.go:               allErrors = append(allErrors, fmt.Errorf("invalid configuration: serverTLSBootstrap %v requires feature gate RotateKubeletServerCertificate", kc.ServerTLSBootstrap))
pkg/features/kube_features.go:  RotateKubeletServerCertificate featuregate.Feature = "RotateKubeletServerCertificate"
pkg/features/kube_features.go:  RotateKubeletServerCertificate: {Default: true, PreRelease: featuregate.Beta},
pkg/generated/openapi/zz_generated.openapi.go:                                                  Description: "serverTLSBootstrap enables server certificate bootstrap. Instead of self signing a serving certificate, the Kubelet will request a certificate from the 'certificates.k8s.io' API. This requires an approver to approve the certificate signing requests (CSR). The RotateKubeletServerCertificate feature must be enabled when setting this field. Default: false",
staging/src/k8s.io/kubelet/config/v1beta1/types.go:     // certificate signing requests (CSR). The RotateKubeletServerCertificate feature
```

/kind cleanup
/sig auth
/sig node