sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: three.js
Issue: wireframe = true; Forces the drawIndexed / drawIndirectIndexed path
Labels: WebGPU

### Description

wireframe = true; Forces the drawIndexed / drawIndirectIndexed path even if the geometry does not have an index attribute. 

This is because of this function in: ```renderers/common/Geometries.js ```
```
	getIndex( renderObject ) {

		const { geometry, material } = renderObject;

		let index = geometry.index;

		if ( material.wireframe === true ) {

			const wireframes = this.wireframes;

			let wireframeAttribute = wireframes.get( geometry );

			if ( wireframeAttribute === undefined ) {

				wireframeAttribute = getWireframeIndex( geometry );

				wireframes.set( geometry, wireframeAttribute );

			} else if ( wireframeAttribute.version !== getWireframeVersion( geometry ) ) {

				this.attributes.delete( wireframeAttribute );

				wireframeAttribute = getWireframeIndex( geometry );

				wireframes.set( geometry, wireframeAttribute );

			}

			index = wireframeAttribute;

		}

		return index;

	}
```

Because of drawIndirect, I experimented with a threejs example to find the cause of the error in my app. To do this, I installed a console command in the draw function in each of the 4 possible branches (draw, drawIndirect, drawIndexed, drawIndexedIndirect) in the WebGPUBackend.js to see which path is called.
The error has nothing to do with drawIndirect or drawIndexedIndirect. It's due to wireframe = true, because wireframe = true creates indexes and this forces the indexed draw path. This applies to draw and drawIndirect in the same way. Now that's nothing critical. Since I as a user now that I know this, I can compensate accordingly on the user side. Plus, I don't think anyone else will stumble upon it any time soon. But it would be best if wirefrae = true does not change the draw / drawIndirect path desired by the user to drawIndexed / drawIndexedIndirect, because that is problematic if you don't know how to compensate for it.



### Reproduction steps

1.In WebGPUBackend.js, add an indicator to each draw path console.log("draw"), console.log("drawIndexed"), console.log("drawIndirect"), console.log(" drawIndexedIndirect") to see which branch is chosen by the system.
2. Using my codePen example locally. Once with and once without material.wireframe = true; Let it run and look in the console which draw branch is used in the backend. 
3. If a user uses drawIndirect for his unindexed geometry, the draw path change forced by wireframe = true then results in an error.



### Code

see live example

### Live example

](https://codepen.io/Spiri0/pen/zYgzgJR)

### Screenshots

_No response_

### Version

r169

### Device

_No response_

### Browser

_No response_

### OS

_No response_
Repository: godot
Issue: Existence of Static Function Prevents Access of Unrelated Static Variable
Labels: topic:gdscript,needs testing

### Tested versions

Reproducible in 4.2stable, 4.3 stable

### System information

Windows 11 - Godot 4.2stable, Godot 4.3 stable

### Issue description

I truly do not know why this is the case, but in my project the very existence of the below code causes a crash when attempting to access an unrelated static variable. This function is not called before the crash occurs.

```gdscript
class_name CardHelpers
...
static func arrow_to_target_k(origin:CardStub, target:PilotButton)->void:
	#TODO: Add color and/or texture as arguments
	var arrow:TargetArrow = load("res://engine/common/ui_scenes/target_arrow.tscn").instantiate()
	origin.add_child(arrow)
	arrow.unpack(origin.global_position, target.global_position)
```

The existence of "arrow_to_target_k" causes a crash elsewhere in the project when attempting to access a static variable.


This code:

```gdscript
class_name CardHelpers
....

static func card_by_id(id:String, origin:String)->LogicalCard:
	if origin == "pilot":
		return PilotCardLib.lib[id]
```

causes the error below:


`Invalid access to property or key 'lib' on a base object of type 'GDScript'.`

### Steps to reproduce

Hit "new game" after running this branch: https://github.com/BluntBSE/ultra_mayor_2/tree/non_crashing_example
to see intended behavior

Hit "new game" after running this branch:  https://github.com/BluntBSE/ultra_mayor_2/tree/crashing_example

to see the crash

### Minimal reproduction project (MRP)

Steps to reproduce not exactly known. Crashing/non crashing branches posted above.

_Bugsquad edit:_ Fix codeblock formatting.
Repository: rust
Issue: Codegen depends on let-variable ordering for unclear reasons
Labels: A-LLVM,A-codegen,T-compiler,I-heavy,A-panic,C-optimization

https://godbolt.org/z/Wx1rvE6vq
```rust
use std::borrow::Cow;

pub struct Error {
    message: Cow<'static, str>,
    cause: Option<Box<[u8]>>,
}
#[no_mangle]
pub fn declear_before(v: u64) -> Error {
    let s = format!("{v}");
    let mut e = Error {
        message: Cow::Borrowed(""),
        cause: None,
    };
    e.message = s.into();
    e
}
```
Declear `s` before `Error` produces better codegen than declear after.
Repository: ant-design
Issue: 网站 footer 区域的样式在 SSR 时出现样式闪烁
Labels: 📝 Documentation,Inactive,unconfirmed

`import 'rc-footer/assets/index.css';` 这段样式客户端才生效。
Repository: pytorch
Issue: Enable CUDA 12.6 CI/CD , Disable CUDA 12.1
Labels: module: cuda,triaged

### 🚀 The feature, motivation and pitch

Filing issue for enabling CUDA 12.6.2 due to an observed performance gap in PyTorch's Eager mode for plain matrix multiplications.
Confirmed that upgrading PyTorch to CTK 12.6.2 with CUBLAS 12.6.3.3 will boost the performance. 

Issue can be used to track related PRs.

Reference - https://github.com/pytorch/pytorch/pull/132202

Docker Images & Windows AMI Update
- [x] https://github.com/pytorch/pytorch/pull/138417
- [x] https://github.com/pytorch/builder/pull/2020
- [x] https://github.com/pytorch/pytorch/pull/138562
- [x] https://github.com/pytorch/pytorch/pull/138563
- [x] https://github.com/pytorch/pytorch/pull/139988
- [x] https://github.com/pytorch/test-infra/pull/5880
- [x] https://github.com/pytorch/test-infra/pull/5924

CD Update
- [x] https://github.com/pytorch/pytorch/pull/138899
- [x] https://github.com/pytorch/builder/pull/2023
- [x] https://github.com/pytorch/builder/pull/2025
- [x] https://github.com/pytorch/pytorch/pull/141433
- [x] https://github.com/pytorch/pytorch/pull/141976
- [x] https://github.com/pytorch/pytorch/pull/127925 
- [x] https://github.com/pytorch/builder/pull/2032
- [x] https://github.com/pytorch/builder/pull/2023
- [x] https://github.com/pytorch/test-infra/pull/6002
- [x] https://github.com/pytorch/test-infra/pull/5955
- [x] https://github.com/pytorch/test-infra/pull/5922
- [x] https://github.com/pytorch/pytorch/pull/141805
- [x] https://github.com/pytorch/test-infra/pull/6062

CI Updates
- [x] https://github.com/pytorch/pytorch/pull/141976 
- [x] https://github.com/pytorch/pytorch/pull/142335
- [x] https://github.com/pytorch/pytorch/pull/141110
- [x] https://github.com/pytorch/pytorch/pull/141365
- [ ] https://github.com/pytorch/pytorch/pull/140793


CUDA 12.1 Deprecation
- [x] https://github.com/pytorch/test-infra/pull/5904
- [x] https://github.com/pytorch/pytorch/pull/142856
- [x] https://github.com/pytorch/pytorch/pull/143076
- [x] https://github.com/pytorch/pytorch/pull/141271
- [ ] Update Inductor benchmarks for CUDA 12.4
- [ ] https://github.com/pytorch/pytorch/pull/145696

cc @ptrblck @msaroufim @syed-ahmed @nWEIdia @atalman @malfet 

### Alternatives

_No response_

### Additional context

_No response_
Repository: go
Issue: proposal: cmd/go: GOTOOLCHAIN=mod to use exact version of toolchain directive
Labels: Proposal

### Proposal Details

Currently, the local Go runtime determines the actual Go version to use by checking the `toolchain` directive in the `go.mod` file when `GOTOOLCHAIN=auto` is set. If the local Go runtime is newer than the version specified in the `toolchain` directive, it defaults to the local Go version. This behavior aligns with the [Go Toolchain](https://go.dev/doc/toolchain) documentation.

However, in some cases—such as in production environments—it may be necessary to enforce a specific Go runtime version, even though Go maintains strong forward and backward compatibility. For example, if the `toolchain` directive specifies `1.22.8` but the Go runtime in the container is `1.23.2`, the actual version used would be `1.23.2`. This could lead to unexpected issues if the container runtime is updated (even `toolchain` is never changed), which should sometimes be blocked to prevent unexpected factors.

While setting `GOTOOLCHAIN=<version>` is a valid solution but usually this `GOTOOLCHAIN` environment variables might be in disorder in a project; this is against the DRY principle. I believe it would be more convenient to have an option that **always** respects the version specified in the `toolchain` directive as the actual runtime version. This would allow developers to control the Go version for an application simply by modifying the version in the `toolchain` directive.

As a potential solution, how about introducing an option like `GOTOOLCHAIN=mod` to achieve this behavior?
Repository: awesome-mac
Issue: Anything LLM
Labels: addition

### 🪩 Provide a link to the proposed addition

https://anythingllm.com

### 😳 Explain why it should be added

Free Local Language Model application.   Run chatGPT type models on your local machine, without needing a subscription.

### 📖 Additional context

_No response_

### 🧨 Issue Checklist

- [X] I have checked for other similar issues
- [X] I have explained why this change is important
- [X] I have added necessary documentation (if appropriate)
Repository: ui
Issue: [bug]: Next.js init doesn't work
Labels: bug

### Describe the bug

creating new project with Next.js is broken
just following instructions here: https://ui.shadcn.com/docs/installation/next

```
✔ What is your project named? … client
✔ Creating a new Next.js project.
✔ Writing components.json.
✔ Checking registry.
⠋ Updating tailwind.config.js
Something went wrong. Please check the error below for more details.
If the problem persists, please open an issue on GitHub.

ENOENT: no such file or directory, open '/.../client/tailwind.config.js'
```


### Affected component/components

project

### How to reproduce

1. open terminal
2. run `npx shadcn@latest init -d`

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
macOS 14.1 / npm 10.9.0
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: godot
Issue: light_only in canvas_item doesn't take LIGHT_COLOR in to consideration
Labels: bug,topic:rendering,topic:2d

### Tested versions


4.3 stable

### System information

Godot v4.3.stable - macOS 15.0.1 - Vulkan (Mobile) - integrated Apple M2 Max - Apple M2 Max (12 Threads)

### Issue description


https://github.com/user-attachments/assets/51c0f1fd-3d50-4120-a3b4-305dfe6ec401

The light_only render mode only hides the sprite outside the PointLight2D area. It does not hide it inside the node where no light shines, which is what I would expect. See video attachement

If I misunderstand the render mode then please let me know and I'll close this ticket.

```
shader_type canvas_item;
render_mode light_only;
```

With the light function it's not possible to discard the sprites RGB colors based on LIGHT_COLOR, because we cannot write to the COLOR variable in the light function. And I would expect the render pipeline deal with that.

### Steps to reproduce

1. setup a PointLight2D with a light texture that does not completely cover the 2D node
2. move a sprite with a CanvasMaterial => light only or a shader with render mode light_only over the PointLight2D

### Minimal reproduction project (MRP)

It happens with a new project. You can use this texture as light source
![2d_lights_and_shadows_neutral_point_light-3](https://github.com/user-attachments/assets/8faf7b8d-dd32-4974-8ec9-58f945add682)

Godot svg can be used as node which needs the light_only render mode or CanvasItemMaterial
Repository: PowerToys
Issue: [FancyZones] Snapping unsnapped windows using Win+left/right snaps in the opposite direction
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.85.0

### Installation method

WinGet

### Running as admin

No

### Area(s) with issue?

FancyZones

### Steps to reproduce

1. Enable fancy zones with some layout.
2. Make sure that Override Windows Snap is set.
3. Open a window not fitting any zone.
4. Use Win key + left or Win key + right to snap to a zone.

### ✔️ Expected Behavior

When using Win key + left the window should snap to the leftmost zone, and when using Win key + right the window should snap to the rightmost zone.

### ❌ Actual Behavior

When using Win key + left the window snaps to the rightmost zone, and when using Win key + right the window snaps to the leftmost zone.

### Other Software

_No response_
Repository: ui
Issue: [feat]: set swipe direction for toast depending on screen size
Labels: area: request

### Feature description

Currently, the Toast component is set to use swipeDirection="right" on all screen sizes. This leads to inconsistent behaviour:

Large screen (sm+) - Everything OK:
- Toast is displayed in bottom right corner
- Toast exits to the right
- Toast can be swiped to the right

Small screen - Inconsistent
- Toast is displayed in top
- _Toast exits to the right_
- _Toast can be swiped to the right_

I think in this case the toast should instead:
- Exit to the top
- Be swiped to the top to close

That would more closely mimic how e.g. notifications on mobile devices are handled (at least on iOS you swipe them up to dismiss them).

While exiting to the top can easily be set with a few css class adjustments, the swipeDirection is set on the Provider and can not be changed this easily (as far as I can see).

### Affected component/components

Toast

### Additional Context

Additional details here...

### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues and PRs
Repository: ollama
Issue: VPTQ Model Quantization Support in Ollama
Labels: feature request

Hi all,

We recently developed a fully open-source quantization method called VPTQ (Vector Post-Training Quantization) [https://github.com/microsoft/VPTQ](https://github.com/microsoft/VPTQ) which enables fast quantization of large language models (LLMs) down to 1-4 bits. The community has also helped release several models using this method [https://huggingface.co/VPTQ-community](https://huggingface.co/VPTQ-community). I am personally very interested in integrating VPTQ into ollama/llama.cpp.

One of the key advantages of VPTQ is that the dequantization method is very straightforward, relying only on a simple lookup table.

I would like to ask for guidance on how best to support this quantization method within Ollama, even if it's on my own fork. Specifically, which approach should I take?

1.    Define a series of new models (e.g., vptq-llama3.1) using existing data types (int32, fp16), and hide the model dequantization within a separate dequant op.

2.   Define a new quantization data type (e.g., a custom lookup table data structure)?

I’d love to hear your thoughts or any suggestions on how to proceed!

Thank you!
Yang
Repository: rust
Issue: Tracking Issue for enforcing test doc comments
Labels: A-testsuite,E-hard,T-compiler,T-bootstrap,C-tracking-issue,A-compiletest

Please use the [t-compiler zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Better.20document.20the.20intent.20of.20a.20test.3F) for specific discussions or open new issues, but please feel free to post consensus updates or progress updates on this tracking issue.

Zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Better.20document.20the.20intent.20of.20a.20test.3F

### Context

Way too often, tests get added, but they don't have any included context in the form of comments. This includes things like (or rather, the lack of important information such as):

- What the test is trying to check.
- Test context:
    - Related issues (issue number for regression tests),
    - Previous implementation PRs
    - RFC / Rust Reference / external docs links (syscalls, platform APIs, DWARF standards, ISA docs, you name it)
    - When suitable, how/why the regression occurred / was reachable, how it was fixed, and how does the test exercise the implementation such that it will catch the same regression.

A good litmus test for test doc comments is: **5 years later, will I be able to determine what the test is trying to check without having to jump through a bunch of github issues/PRs via `git blame`?**

So, it might be valuable to add an automated check to enforce that every new test is checked in with a suitable test doc comment.

### Implementation steps

- [ ] 1. Briefly survey existing test suites and see what kind of doc comment style are suitable.
    - Notably, which test suites should / should not have doc comments enforced, e.g. `rustdoc-gui` and other special test suites may need special handling or exclusions.
    - Figure out a brief mechanism such that *new* tests receive the enforcement but old tests are permitted in an allowlist, and how to bless that allowlist.
- [ ] 2. File an MCP describing the previous rationale for enforcing test doc comments, as well as the concrete proposal for how it will be implemented and the proposed UX. This *may* need to be encoded as T-compiler PR/review policy so may need a full team FCP.
- [ ] 3. Implement the test doc comment enforcement mechanism, including sufficient self-test coverage.
- [ ] 4. Update rustc-dev-guide ui test walkthrough + basic test description + best practices.
- [ ] 5. Brief T-compiler/T-rustdoc teams about the new test doc comment enforcement.

### Discussions

- https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Better.20document.20the.20intent.20of.20a.20test.3F

### Unresolved questions / concerns

None yet, please update issue description as suitable.
Repository: ant-design
Issue: Button组件在低端机器下开启loading状态后无法正确阻止onClick事件
Labels: Inactive,improvement

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/jia-zai-zhong-zhuang-tai-antd-5-21-4-forked-fxf6yy?file=/demo.tsx)

### Steps to reproduce

1. 打开开发者工具的性能面板
2. 设置CPU 4x减速或更高
3. 快速点击按钮

### What is expected?

只触发一次onClick事件

### What is actually happening?

触发了多次onClick事件
![image](https://github.com/user-attachments/assets/96e1f2dd-2e59-4a9b-943c-7e6588a38b4d)

| Environment | Info |
| --- | --- |
| antd | 5.21.4 |
| React | 18 |
| System | MacOS |
| Browser | Edge 130 |

---
同时手动设置disabled属性可以避免这个问题

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: ui
Issue: [bug]: Dialog is taking over sweetalert element
Labels: bug

### Describe the bug

I have problem with dialog and sweetalert to work together. When you open dialog and you open sweetalert inside dialog, the sweetalert will be behind the dialog, even though it appears that it is in front .

I already change z-index and and it didn't work

### Affected component/components

Dialog

### How to reproduce

1. open dialog
2. Open Sweetalert inside dialog

### Codesandbox/StackBlitz link

https://codesandbox.io/p/sandbox/7mds8v

### Logs

_No response_

### System Info

```bash
Fedora 40
```


### Before submitting

- [x] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: Python
Issue: Add set matriz zero problem in array data structure.
Labels: enhancement

### Feature description

Problem: Given an m x n integer matrix matrix, if an element is 0, set its entire row and column to 0's. 
I  want to add this under hacktober fest please assign it to me
Repository: rust
Issue: function "in_external_macro” judgment is incorrect
Labels: T-compiler,C-bug,A-proc-macros,E-needs-investigation

I use the derive macro provided by the clap crate in my code, and then call the in_external_macro function in the context of a custom lint diagnostic code. The function determines that the code derived from the derive macro is local code.

I tried this code:

```rust
fn main() {
    let _a = 1;
}

use clap::Args;


#[derive(Args)]
pub struct ToFrom {
    #[arg(long = "workspace")]
    a: i32,
}
```

dependency is clap = { version = "=4.2.0", features = ["derive"] }

My lint code is: 
```rust
    fn check_block(&mut self, cx: &LateContext<'tcx>, block: &'tcx Block<'_>) {
           let res = in_external_macro(cx.sess(), block.span);
        info!("check block in_external_macro res {:?}", res);
        if res == false {
            info!("check block {:?}", block);
        }
}
```

I expected to see this happen:   I think all code generated by derived macros should belong to external macros derived from external crates.

Instead, this happened: Some of the code generated by the derived macro is considered to be local code


The error macro code is expanded as follows. 
The blocks inside the .arg function are considered native code.

```rust
                .arg({
                    #[allow(deprecated)]
                    let arg = clap::Arg::new("a")
                        .value_name("A")
                        .required(true && clap::ArgAction::Set.takes_values())
                        .value_parser({
                            use ::clap_builder::builder::via_prelude::*;
                            let auto = ::clap_builder::builder::_AutoValueParser::<
                                i32,
                            >::new();
                            (&&&&&&auto).value_parser()
                        })
                        .action(clap::ArgAction::Set);
                    let arg = arg.long("workspace");
                    let arg = arg.required(false);
                    arg
                });
```


`rustc --version --verbose`:
```
+nightly-2024-03-07
```
Repository: kubernetes
Issue: Pods support requesting resources for each container at runtime.
Labels: kind/support,sig/node,needs-triage

### What happened?

In a pod containing three containers A, B, and C, with the execution order of operators being sequential (the second one starts only after the first one completes), can we request CPU and GPU information during the operator runtime?

### What did you expect to happen?

In a pod containing three containers A, B, and C, with the execution order of operators being sequential (the second one starts only after the first one completes), can we request CPU and GPU information during the operator runtime?

### How can we reproduce it (as minimally and precisely as possible)?

In a pod containing three containers A, B, and C, with the execution order of operators being sequential (the second one starts only after the first one completes), can we request CPU and GPU information during the operator runtime?

### Anything else we need to know?

_No response_

### Kubernetes version

1.20


### Cloud provider

not cloud

### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>