sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: kubernetes
Issue: Increase recommended default RetryPeriod for LeaderElection
Labels: sig/api-machinery,kind/feature,triage/accepted

### What would you like to be added?

Review the default value of RetryPeriod for LeaderElection from current 2s to probably 5s or some values close to that.



### Why is this needed?

According to source [code](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/component-base/config/v1alpha1/defaults.go#L37-L45)

	if obj.LeaseDuration == zero {
		obj.LeaseDuration = metav1.Duration{Duration: 15 * time.Second}
	}
	if obj.RenewDeadline == zero {
		obj.RenewDeadline = metav1.Duration{Duration: 10 * time.Second}
	}
	if obj.RetryPeriod == zero {
		obj.RetryPeriod = metav1.Duration{Duration: 2 * time.Second}
	}

LeaseDuration is 15s, RenewDeadline 10s however RetryPeriod is 2s, which is way lower than former two and causing visible amount of leader election renewal requests to apiserver, which could be excessive given LeaseDuration is 15s long.

So maybe increasing it to 1/3 of LeaseDuration still gives it sufficient headroom for retry.
Repository: pytorch
Issue: [Functionalization] The inplace decompose op is meaningless
Labels: triaged,module: xla,module: functionalization

### Question:
When I use torch_xla to accelerate model training, I find the inlace op will go through PyTorch's functionalization. The inlace op will be dispatched to the python level decompose implementation registered here:https://github.com/pytorch/pytorch/blob/8f70bf7a943799b5cd870952d39f36361de4b87f/torch/_refs/__init__.py#L504. However, after the python level implementation, it will then go to the c++ level implementation:https://github.com/pytorch/pytorch/blob/8f70bf7a943799b5cd870952d39f36361de4b87f/aten/src/ATen/FunctionalTensorWrapper.cpp#L219 and the output is determined by the c++ level implementation. It seems that the output of decompose op is meaningless.
I find a pr related to the python level implementation: 
- https://github.com/pytorch/xla/pull/4158
- https://github.com/pytorch/pytorch/pull/87426

and a pr related to the c++ level implementation:
- https://github.com/pytorch/pytorch/pull/63048

And I guess when you need to use functionalization inlace op will meet this problem.

### System info:
Pytorch version:  2.2.2
torch_xla version: 2.3.0
python version: 3.10.13

### reproducible code:
```python
import torch
import torch_xla.core.xla_model as xm

dev = xm.xla_device()

tensor = torch.tensor([1.0, 2.0, 3.0])

xla_tensor_a = tensor.to(dev)
xla_tensor_b = tensor.to(dev)

xla_tensor_a.mul_(xla_tensor_b)
```
you can check the timeline or add some log in the python level and c++ level implementation
here's the timeline of mul_ op: 
![image](https://github.com/pytorch/pytorch/assets/83819142/70d4e155-53a0-44d7-9cd0-f7a50d031457)


I want to know is there any problem in this implementation? Or can someone tell me why the functionalization of Pytorch do this, thank you!

cc @bdhirsh @ezyang
Repository: PowerToys
Issue: FancyZones Editor dimensions incorrect
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.82.0

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

FancyZones Editor

### Steps to reproduce

This is really two separate but highly-related issues.

1. Dimensions shown relate to other monitor.
2. Custom Zone dimensions do not correspond to monitor dimensions.

### Dimensions shown relate to other monitor
My laptop is screen 1 in Windows and my monitor is screen 2 in Windows.  Both are running at the recommended resolution, both of which have a width of **3840**, with the laptop having a depth of **2400** and the monitor having a depth of **2160**.  Yet the top section of the FancyZones Editor shows these values inverted as shown in the following two screenshots.

![image](https://github.com/microsoft/PowerToys/assets/153158093/8691d127-d3f2-44fa-9f22-4fdd3f899431)

![image](https://github.com/microsoft/PowerToys/assets/153158093/552da91c-bac3-4aef-b872-4023b3633d99)

### Custom Zone dimensions do not correspond to monitor dimensions
I wanted to create a Custom Zone that contains a single grid zone so a window snapped to it will effectively fill the screen without being maximised.  However my use case is Remote Desktop with Smart Sizing turned on and because of the overhead of the Windows Title bar the scaling is not quite proportional and there is some dithering, so I need to reduce the width by adding a buffer zone.  (In fact I need to reduce both the height _and_ width until they're both integers to maintain the aspect ratio.)  But the dimensions shown in the FancyZones Editor for the single grid zone do not reflect the screen resolutions at all.  (Note that I turned off "Space around zones".)

If I run the Editor on the laptop screen...

![image](https://github.com/microsoft/PowerToys/assets/153158093/a7695ba5-63b2-4b74-b9c8-2cb3c1ec86da)

And if I run the Editor on the monitor...

![image](https://github.com/microsoft/PowerToys/assets/153158093/611df1f5-5568-46f4-b8b1-7714ddfe1198)

[PowerToysReport_2024-07-03-17-09-49.zip](https://github.com/user-attachments/files/16081816/PowerToysReport_2024-07-03-17-09-49.zip)


### ✔️ Expected Behavior

The FancyZones Editor would show screen 1 as 3840x2400 and screen 2 as 3840x2160 in both the overview and when creating a custom pane.


### ❌ Actual Behavior

The FancyZones Editor showed screen 1 as 3840x2160 and screen 2 as 3840x2400 in the overview, and showed screen 1 as 1920x1160 and screen 2 as 2560x1400 when creating a custom pane.


### Other Software

_No response_
Repository: vscode
Issue: WordOperations test failure on firefox
Labels: bug,editor-core

* run `yarn test-browser`
* 🐛 there are test failures for firefox

```

  8739 passing (2m)
  80 pending
  2 failing

  1) WordOperations
       cursorWordLeft - Recognize words:

      
      + expected - actual

      -|/* |これはテストです |/*
      +|/* |これ|は|テスト|です |/*
      
  AssertionError@http://localhost:58336/d93b92392c197e0dc1687e5c26f3e699/test/unit/assert.js:184:21
  fail@http://localhost:58336/d93b92392c197e0dc1687e5c26f3e699/test/unit/assert.js:231:9
  deepStrictEqual@http://localhost:58336/d93b92392c197e0dc1687e5c26f3e699/test/unit/assert.js:283:9
  @http://localhost:58336/d93b92392c197e0dc1687e5c26f3e699/out/vs/editor/contrib/wordOperations/test/browser/wordOperations.test.js:151:30
  

  2) WordOperations
       cursorWordRight - Recognize words:

      
      + expected - actual

      -/*| これはテストです|/*|
      +/*| これ|は|テスト|です|/*|
      
  AssertionError@http://localhost:58336/d93b92392c197e0dc1687e5c26f3e699/test/unit/assert.js:184:21
  fail@http://localhost:58336/d93b92392c197e0dc1687e5c26f3e699/test/unit/assert.js:231:9
  deepStrictEqual@http://localhost:58336/d93b92392c197e0dc1687e5c26f3e699/test/unit/assert.js:283:9
  @http://localhost:58336/d93b92392c197e0dc1687e5c26f3e699/out/vs/editor/contrib/wordOperations/test/browser/wordOperations.test.js:298:30
  



The followings tests are failing:
 - WordOperations cursorWordLeft - Recognize words (reason: "|/* |これはテストです |/*" deepStrictEqual "|/* |これ|は|テスト|です |/*")
 - WordOperations cursorWordRight - Recognize words (reason: "/*| これはテストです|/*|" deepStrictEqual "/*| これ|は|テスト|です|/*|")

```
Repository: ui
Issue: [bug]: Dark Mode Not Working Properly On IOS Devices
Labels: bug

### Describe the bug

I am using Next js 14 with shadcn ui, and the dark mode theme works on the web and on android devices, how ever colors don't work properly on IOS web pages "Real Device".


**/providers/theme-provider.tsx**
```javascript
"use client";

import * as React from "react";
import { ThemeProvider as NextThemesProvider } from "next-themes";
import { type ThemeProviderProps } from "next-themes/dist/types";

export function ThemeProvider({ children, ...props }: ThemeProviderProps) {
  return <NextThemesProvider {...props}>{children}</NextThemesProvider>;
}
```


**/app/layout.tsx**

```javascript
export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body className={inter.className}>
        <Provider>
          <ThemeProvider attribute="class" defaultTheme="system" enableSystem>
            <div className="min-h-screen w-full bg-background text-secondary-foreground">
              <TopLoader />
              <Toaster />
              <Header />
              <main className="p-5">{children}</main>
            </div>
          </ThemeProvider>
        </Provider>
      </body>
    </html>
  );
}
```




### - Android Device + Desktop


![4ff5b780-7320-4417-91ff-c59e854b6275](https://github.com/shadcn-ui/ui/assets/112987450/1188cfc3-abbc-4800-b242-612d0029209b)
![9e4c5b04-7504-47eb-830f-5cec4147f381](https://github.com/shadcn-ui/ui/assets/112987450/52750387-e121-464d-9aa2-d6332fd81eb3)






### - IOS Device 


![IMG_7919](https://github.com/shadcn-ui/ui/assets/112987450/e9017b6a-418b-4f21-94f3-29b8c6f542db)
![IMG_7920](https://github.com/shadcn-ui/ui/assets/112987450/7bf85c2e-2981-4a55-a412-c793d5b01a9b)


### Affected component/components

All Components

### How to reproduce

This is a first time issue.

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
IOS 17, Iphone 12 pro max,
Windows 10.
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: flutter
Issue: Ability to disable the default flinging behaviour on `Dismissible` widget 
Labels: c: new feature,framework,waiting for PR to land (fixed),c: proposal,P3,team-framework,triaged-framework

### Use case

The default flinging behaviour implemented in the `Dismissible` widget often results in undesired triggering of the dismiss action when used in a scrollable content (eg. dismissible tiles in a `ListView`)

### Proposal

Adding an optional `allowFlinging` parameter (defaulting to `true` for compatibility) that would disable the default flinging behaviour could fix this.
Repository: stable-diffusion-webui
Issue: [Feature Request]: Can I please be the one to decide if something is compatible or not?
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 ?

I understand that for the normies you want to have this nice safe space for them to get the easiest experience with the least issues.

The rest of us are not so soft, and we have discovered compatability in embeddings, loras, and everything else inbetween, that are being ignored by a default setting that I can't seem to turn off anywhere.

Can I please be the one to decide if something is compatible or not? Even if it is by an option in the settings.

Thank you

EDIT: Apparently "Always Show All Networks" is supposed to do show all Embeddings as well. It does not, The navigation for this is also very non-specific at a glance. The issue is literally the compatibility filtering, which is the term that shows up in Google Searches. We really need settings that match the terms used when we search for the problems we are having.
...and if this IS supposed to reveal Embeddings then at this point it is a Bug in the program where it does not show ALL networks.

### Proposed workflow

1. Go to Settings Tab
2. Compatibility Options
3. Compatibility Filtering for LoRA/Embeddings/LyCORiS by Checkpoint/Model Versions - On / Off


### Additional information

_No response_
Repository: godot
Issue: Main submenus are all black sometimes (XWayland windows, Nvidia)
Labels: bug,platform:linuxbsd,topic:porting

### Tested versions

- Reproducible in `main` as of https://github.com/godotengine/godot/commit/6a13fdcae3662975c101213d47a1eb3a7db63cb3
- Not reproducible in 4.3 beta 2

### System information

Godot v4.3.beta - TUXEDO OS 3 22.04.4 - Wayland - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4060 Laptop GPU - 13th Gen Intel(R) Core(TM) i7-13700H (20 Threads)

### Issue description

The main sub menus are black when first opened.
You have to hover over them and move the mouse a bit for them to show up correctly.

![Screenshot_20240703_122346](https://github.com/godotengine/godot/assets/3624853/5e0fc252-4507-42f5-96a1-0ffaa3d9da93)


### Steps to reproduce

Open any menu, by clicking on it, but do not move the mouse. It shows up blank.

Move the mouse a few times over the menu, and the items will then render correctly.

Try this with different menus (Scene, Project ...)

### Minimal reproduction project (MRP)

Not needed. This is just an editor bug.
Repository: ollama
Issue: Enable Row Split Support
Labels: feature request

For multi-gpu setups, enabling row-split can have very significant performance improvements. On my machine with 3xP40, I was able to get a speedup from ~3t/s to ~10t/s.

Unfortunately, it doesn't look like there's any way to get this flag (`-sm row`) down to llama.cpp, which should otherwise support this.

Wondering if it's possible to either add a way to pass along flags to llama.cpp, or to have an option which enables this flag. Given the massive performance improvement that it brings though, it seems like this should be possible, and not very much work to implement.

I saw that passing along flags was discussed [here](https://github.com/ollama/ollama/pull/4120#issuecomment-2094747527), but was unfortunately not implemented.
Repository: ant-design
Issue: 在 5.19 里没导出 useVariants type
Labels: Inactive,unconfirmed

### Reproduction link

[https://unpkg.com/browse/antd@5.19.0/es/form/hooks/useVariants.d.ts](https://unpkg.com/browse/antd@5.19.0/es/form/hooks/useVariants.d.ts)

### Steps to reproduce

构建 pro-components

### What is expected?

https://unpkg.com/browse/antd@5.19.0/es/form/hooks/useVariants.d.ts 没导出 Variant https://unpkg.com/browse/antd@5.18.3/es/form/hooks/useVariants.d.ts 有导出。
https://github.com/ant-design/pro-components/blob/master/packages/utils/src/compatible/compatibleBorder.ts#L2  pro-components 这里需要这个 type 构建报错了。

### What is actually happening?

构建报错

| Environment | Info |
| --- | --- |
| antd | 5.19.0 |
| React | * |
| System | macos |
| Browser | chrome |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: Can't use `vmsr` instruction in `global_asm!` on `armv7r-none-eabihf` without `codegen-units=1`
Labels: A-LLVM,O-Arm,A-inline-assembly,T-compiler,C-bug,T-libs,A-target-feature,S-waiting-on-LLVM,C-external-bug

See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/armv7r-unknown-none-eabihf.20weirdness/near/448803070 for discussion and https://github.com/ferrous-systems/armv7r-issues for a reproducer.

I tried this code:

```rust
core::arch::global_asm!(
    r#"

.section .text.startup
.global _start
.code 32
.align 0

_start:
    // Set stack pointer
    ldr r3, =stack_top
    mov sp, r3
    // Allow VFP coprocessor access
    mrc p15, 0, r0, c1, c0, 2
    orr r0, r0, #0xF00000
    mcr p15, 0, r0, c1, c0, 2
    // Enable VFP
    mov r0, #0x40000000
    vmsr fpexc, r0
    // Jump to application
    bl kmain
    // In case the application returns, loop forever
    b .

"#
);
```

In debug profile, this compiles OK. If you use release profile and force codegen-units=1, it compiles. On armv8r-unknown-none-eabihf, it compiles.

But, if the target is armv7r-unknown-none-eabihf and codegen-units != 1, you get this error:

```text
error: <inline asm>:18:5: instruction requires: VFP2
    vmsr fpexc, r0
    ^
```


### Meta

`rustc --version --verbose`:
```
rustc 1.78.0 (9b00956e5 2024-04-29)
binary: rustc
commit-hash: 9b00956e56009bab2aa15d7bff10916599e3d6d6
commit-date: 2024-04-29
host: aarch64-apple-darwin
release: 1.78.0
LLVM version: 18.1.2
```

or

```text
rustc 1.81.0-nightly (6b0f4b5ec 2024-06-24)
binary: rustc
commit-hash: 6b0f4b5ec3aa707ecaa78230722117324a4ce23c
commit-date: 2024-06-24
host: aarch64-apple-darwin
release: 1.81.0-nightly
LLVM version: 18.1.7
```

Both have the same issue.
Repository: three.js
Issue: TSL: `If` statement produces WGSL error.
Labels: TSL

### Description

I'm currently trying to port the FXAA shader to TSL. The code uses more than one `return` statement to return a color value computed in its `FxaaPixelShader()` function.

Using an `If()` statement in TSL to determine if a return is required produces a WGSL error though.

> Error while parsing WGSL: :40:3 error: return statement type must match its function return type, returned 'vec4<f32>', expected 'OutputStruct'
    return vec4<f32>( 1.0, 0.0, 0.0, 1.0 );
    ^^^^^^

I have reproduce the issue with a live example by writing a simple effect that output just two colors depending on how an if statement evaluates.



### Reproduction steps

1. Go to https://jsfiddle.net/pq2dtag3/
2. Check browser console.


### Code

```js
class CustomEffectNode extends TempNode {

	constructor() {

		super();

	}

	setup() {

		const effect = tslFn( () => {

			If( uv().x.lessThan( 0.5 ), () => {

     				return vec4( 1, 0, 0, 1 );

    			} );

			return vec4( 0, 0, 1, 1 );


		} );

		const outputNode = effect();

		return outputNode;

	}

}
```


### Live example

https://jsfiddle.net/pq2dtag3/

### Screenshots

_No response_

### Version

r167dev

### Device

Desktop

### Browser

Chrome

### OS

MacOS
Repository: neovim
Issue: Invalid: 'end_col': out of range error in treesitter/highlighter.lua
Labels: bug,needs:repro,treesitter

### Problem

Hi, I'm currently experiencing this problem in 0.10.

I'm having this error when I use tabs as for indention.
```
Error in decoration provider treesitter/highlighter.line:
Error executing lua: ...al/share/nvim/runtime/lua/vim/treesitter/highlighter.lua:337: Invalid 'end_col': out of range
stack traceback:
        [C]: in function 'nvim_buf_set_extmark'
        ...al/share/nvim/runtime/lua/vim/treesitter/highlighter.lua:337: in function 'fn'
        ...al/share/nvim/runtime/lua/vim/treesitter/highlighter.lua:210: in function 'for_each_highlight_state'
        ...al/share/nvim/runtime/lua/vim/treesitter/highlighter.lua:291: in function 'on_line_impl'
        ...al/share/nvim/runtime/lua/vim/treesitter/highlighter.lua:367: in function <...al/share/nvim/runtime/lua/vim/treesitter/highlighter.lua:361>
```

So far the languages I used that has this error are lua, javascript, and go.

Demo:

This is using Go.
https://github.com/neovim/neovim/assets/77670158/7176f902-e161-437b-a865-223780d15c09

This is for Lua.
https://github.com/neovim/neovim/assets/77670158/e949c46e-1059-49a6-adaa-3b5672857cc8

My soft fixes for this problem are disable treesitter syntax highlighting or use spaces for indention.

### Steps to reproduce

This is a treesitter/highlighter.lua problem, so I think I can't do it using ```nvim --clean```.

1. I did ```:set noexpandtab``` to use tabs for indention.
2. I typed ```<Tab><any first character>```.
3. Then error shows up after pressing the first character.

### Expected behavior

No error.

### Neovim version (nvim -v)

NVIM v0.10.0

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

No.

### Operating system/version

Linux Mint 21.3

### Terminal name/version

kitty 0.34.1

### $TERM environment variable

xterm-kitty or tmux-256color

### Installation

Downloaded the tar.gz and extracted it to ~/.local/share
Repository: vscode
Issue: [json] allow to override & replace existing schemas
Labels: feature-request,json

<!-- ⚠️⚠️ 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/No

<!-- 🪓 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: Windows 11
Steps to Reproduce:

1.  Add schema in settings.json
```json
"json.schemas": [
        {
            "fileMatch": [
                "demo.json"
            ],
            "url": "https://abgox.github.io/schema/prettier/zh-CN/.prettierrc-min.json"
        },
        {
            "fileMatch": [
                "demo.json"
            ],
            "url": "https://abgox.github.io/schema/prettier/en-US/.prettierrc-min.json"
        }
    ]
```
2.  When I edit a demo.json, it matches to two schema.
3. But，I cannot select the specified json schema !

![image](https://github.com/microsoft/vscode/assets/131574323/e173276a-5ead-4a3d-8b09-ddda03520f7d)

4. When I try to apply a given schema, it just goes to the schema page and doesn't apply it!
Repository: opencv
Issue: JS bindings for MSER are broken in 5.x
Labels: bug,category: javascript (js),community help requested

### System Information

MSER test fails:
```
 Fix test failure Expected: 7 Result: 0
```
Code: 

### Detailed description

-

### Steps to reproduce

Code: https://github.com/opencv/opencv/blob/53f51275e451a48b7f3e8150b11fe096b2d4324b/modules/js/test/test_features2d.js#L31

docker: quay.io/opencv-ci/opencv-docs-js-20.04:20240219
build command: emcmake python ../opencv/platforms/js/build_js.py js --build_test
test in browser: firefox ./bin/tests.html

### 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: pytorch
Issue: Support python attribute mutations of tensor subclass graph inputs from within __torch_dispatch__
Labels: oncall: distributed,triaged,tensor subclass,oncall: pt2,module: aotdispatch,module: pt2-dispatcher,pt2d-triage-nov2024

Filing this issue for tracking depending on user request.

Normally, the way that `setattr` on graph inputs is handled is that dynamo tracks attribute mutations on graph inputs as side effects, and replays the bytecode for them later.

However - if a tensor subclass setattr's some of its attributes from inside of `__torch_dispatch__`, dynamo will never see it and cannot preserve the side effect. This behavior is banned today under the "traceability" requirement of tensor subclasses that want to work with compile.

This is a placeholder issue to explore if / to what extent we could lift this restriction, for attributes that are part of the __tensor_flatten__ contract.

One idea: In AOTAutograd: we can stash the python id of each attribute on all subclass inputs, and check to see if any of them changed after tracing during the analysis pass. This isn't quite enough for two reasons:

(1) if running the analysis pass tweaked the attributes of one of our example inputs, then our example inputs will now be incorrect when we run the actual tracing pass with those same example inputs. We would need to unwind the attribute mutation
(2) if the new attribute is a tensor that came from a graph intermediate, we will also need to properly make it a graph output, so that we can grab it at runtime after executing the compiled graph and perform the attribute mutation in an epilogue.

cc @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o @ezyang @albanD @chauhang @penguinwu @zou3519 @yf225 @anijain2305