sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Custom icons size in group editor is not standardized 
Labels: bug,topic:editor,good first issue

### Tested versions

- Reproducible in v4.2.2.stable.official [15073afe3]

### System information

Windows 11 Godot v4.2.2.stable.official [15073afe3]

### Issue description

When assigning nodes inside group editor the sizes of custom icons are equal to the original picture size instead of being standardized to match other editor icons. Example screenshot:
![obraz](https://github.com/godotengine/godot/assets/40697587/e64e4d6f-3ea3-4033-9810-088759e1676e)


 Edit: Important to add I saw similar issues with other parts of editor which has been fixed since, so I'm guessing group editor just wasn't caught before, but it might not be too difficult to use the code that was used for inspector part of UI before.

### Steps to reproduce

1. Create a scene with some nodes that have custom editor icons that are normally bigger than standard editor icons
2. Go to Node tab and select Groups category
3. Press Manage groups
4. Write a group name and press add
5. See that both list nodes not in group and nodes in group show the original size of custom icons which can be large instead of being similar to standard editor icon sizes, making using group editor difficult

### Minimal reproduction project (MRP)

N/A
Repository: godot
Issue: create_server does not create LISTEN socket
Labels: bug,topic:multiplayer

### Tested versions

- Reproducible in 4.2.2.stable, 4.0.stable

### System information

Godot v4.3.dev6.mono - Fedora Linux 38 (Workstation Edition) - Wayland - Vulkan (Forward+) - dedicated AMD Radeon RX 580 Series (RADV POLARIS10) () - AMD Ryzen 7 3700X 8-Core Processor (16 Threads)

### Issue description

CreateServer() does not create a listen socket as it should. I have tried with versions 4.2.2, 4.0, on different computers and on GD only builds, but it concluded with same results. It also returns OK. Therefore I can't connect to the server.

To check what ports are listen I'm running command ```sudo netstat -tulpn``` and result of this command is this:
```
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:34861         0.0.0.0:*               LISTEN      13920/godot         
tcp        0      0 127.0.0.1:6006          0.0.0.0:*               LISTEN      13920/godot         
tcp        0      0 127.0.0.1:6007          0.0.0.0:*               LISTEN      13920/godot         
tcp        0      0 127.0.0.1:6005          0.0.0.0:*               LISTEN      13920/godot         
udp6       0      0 :::6969                 :::*                                14069/godot         <------- this should marked as LISTEN
```

Console is clear and it does not give any errors

### Steps to reproduce

1. Create a new project with a scene
2. Attach GD script
3. In _Ready method write this:
```
var peer = ENetMultiplayerPeer.new()
peer.create_server(6969)
multiplayer.multiplayer_peer = peer
```
4. Run project
5. Check for listen ports

### Minimal reproduction project (MRP)

[reproduction project.zip](https://github.com/godotengine/godot/files/15444680/reproduction.project.zip)
Repository: TypeScript
Issue: CommonJS globals permitted for ES module builds with no compiler error.
Labels: Suggestion,Awaiting More Feedback

### 🔎 Search Terms

nodenext, module, __dirname

### 🕗 Version & Regression Information

Version 5.4.5

### ⏯ Playground Link

_No response_

### 💻 Code

**package.json**
```json
"type": "module"
```
**tsconfig.json**
```json
{
  "compilerOptions": {
    "module": "NodeNext"
  },
  "include": ["src"]
}
```
**file.ts**
```ts
console.log(__dirname)
```


### 🙁 Actual behavior

No compiler error, but this causes a runtime error in Node:

```
ReferenceError: __dirname is not defined in ES module scope
```

### 🙂 Expected behavior

That the compiler issues an error similar to the inverse situation.

For example, when targeting CommonJS:

**package.json**
```json
"type": "commonjs"
```

**file.ts**
```ts
console.log(import.meta.dirname)
```

The compiler issues the following error:

```
error TS1470: The 'import.meta' meta-property is not allowed in files which will build into CommonJS output.
```

### Additional information about the issue

Perhaps there is a good reason for this that I'm not understanding, but I would think `tsc` should issue an error or warning for any syntax that would produce a runtime error.

Here is a more complete example: https://github.com/knightedcodemonkey/tsc-module-globals

* `npm install`
* `npm run esm` (note no compile error but the output causes a runtime error)
* `npm run cjs` (note there _is_ a compile error)
Repository: godot
Issue: LTO for web builds failing: attempt to add bitcode file after LTO (`htonl.o`)
Labels: bug,platform:web,topic:buildsystem,confirmed

### Tested versions

Current master [be56cab58c056c074d1e02cd0b38641204e39f41]

### System information

Windows 10; Tested with emsdk 3.1.59 and 3.1.53

### Issue description

I am encountering the following error when trying to compile with `lto=full` for wasm:
```
wasm-ld: error: C:\Users\Me\Documents\emsdk\upstream\emscripten\cache\sysroot\lib\wasm32-emscripten\lto\libc-debug.a(htonl.o): attempt to add bitcode file after LTO (htonl)
```

[full output.txt](https://github.com/godotengine/godot/files/15445084/full.output.txt)


### Steps to reproduce

Clone Godot source
Set up web compilation requirements
Run:
```
scons p="web" arch="wasm32" target="template_release" optimize="size" lto="full" deprecated="no" disable_3d="yes" vulkan="no" use_volk="no" openxr="no" minizip="no" brotli="no" graphite="no" threads="no" javascript_eval="no" modules_enabled_by_default="no" module_gdscript_enabled="yes" module_freetype_enabled="yes" module_text_server_adv_enabled="no" module_text_server_fb_enabled="yes"
```

### Minimal reproduction project (MRP)

see above
Repository: rust
Issue: unused_associated_type_bounds are usable and useful
Labels: A-diagnostics,T-compiler

### Code

```Rust
pub trait AssocOptOut {
    type Foo where Self: Sized;
    fn foo(&self) -> Self::Foo where Self: Sized;
}

impl<T: Default> AssocOptOut for Box<dyn AssocOptOut<Foo = T>> {
    type Foo = T;
    fn foo(&self) -> Self::Foo {
        T::default()
    }
}
```


### Current output

```Shell
warning: unnecessary associated type bound for not object safe associated type
 --> src/lib.rs:6:54
  |
6 | impl<T: Default> AssocOptOut for Box<dyn AssocOptOut<Foo = T>> {
  |                                                      ^^^^^^^ help: remove this bound
  |
  = note: this associated type has a `where Self: Sized` bound. Thus, while the associated type can be specified, it cannot be used in any way, because trait objects are not `Sized`.
  = note: `#[warn(unused_associated_type_bounds)]` on by default
```


### Desired output

```Shell
warning: associated type bound for not object safe associated type
 --> src/lib.rs:6:54
  |
6 | impl<T: Default> AssocOptOut for Box<dyn AssocOptOut<Foo = T>> {
  |                                                      ^^^^^^^ help: remove this bound
  |
  = note: this associated type has a `where Self: Sized` bound. Thus, while the associated type can be specified, the trait objects itself does not define the associated type (as trait objects are not `Sized`).
  = note: `#[warn(not_object_safe_associated_type_bounds)]` on by default
```


### Rationale and extra context

`<dyn AssocOptOut as AssocOutput>::Foo` is not defined and cannot be used in any way.

However, the *specified associated type* can still be used, as demonstrated by the blanket implementation for `Box<dyn AssocType<Foo = T>>`.

Moreover, it is *useful,* as now `Box<dyn AssocOptOut<Foo = String>>` implements `AssocOptOut`, for example.

(So ideally the warning could be renamed.  Or if enough use-cases emerge, made `allow` or change in scope.)

### Other cases

_No response_

### Rust Version

[Playground,](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=f29750210ac7dae6dc607304f0defa48) all channels.

```
Stable channel: Build using the Stable version: 1.78.0

Beta channel: Build using the Beta version: 1.79.0-beta.6 (2024-05-23 66eb3e404b81e916f5e6)

Nightly channel: Build using the Nightly version: 1.80.0-nightly (2024-05-24 36153f1a4e3162f0a143)
```


### Anything else?

The lint was introduced in #112319.
Repository: angular
Issue: Input valid/invalid pseudo states classes not updated as expected
Labels: workaround1: obvious,area: forms,forms: ControlValueAccessor

### Which @angular/* package(s) are the source of the bug?

forms

### Is this a regression?

Yes

### Description

When using the Reactive Forms and Validators, I would expect the input valid/invalid pseudo-state classes to be updated accordingly, but this is not the case.

When you check the reproduction link we may notice that the input pseudo state is always valid unless we use the HTML attribute.

Nevertheless, the input ng classes are properly updated. This leads to inputs having the `.ng-invalid` class but still responding to the `:valid` pseudo-state class which breaks the styling based on those classes.

### Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/stackblitz-starters-wjqt7b?file=src%2Fmain.ts

### Please provide the exception or error you saw

```true
No exceptions or errors.
This issue can only be noticed visually when styles differ from one state to another.
```


### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 17.3.8
Node: 18.20.3
Package Manager: npm 10.2.3
OS: linux x64

Angular: 17.3.10
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1703.8
@angular-devkit/build-angular   17.3.8
@angular-devkit/core            17.3.8
@angular-devkit/schematics      17.3.8
@angular/cli                    17.3.8
@schematics/angular             17.3.8
rxjs                            7.8.1
typescript                      5.3.3
zone.js                         0.14.6
```


### Anything else?

Not sure but I remember it working in a previous version. Also, still present in Angular v18.
Repository: ollama
Issue: Llama.cpp now supports distributed inference across multiple machines.
Labels: feature request

Llama.cpp now supports distribution across multiple devices to boost speeds, this would be a great addition to Ollama 


https://github.com/ggerganov/llama.cpp/tree/master/examples/rpc

https://www.reddit.com/r/LocalLLaMA/comments/1cyzi9e/llamacpp_now_supports_distributed_inference/
Repository: stable-diffusion-webui
Issue: [Bug]: Checkpoint isnt working and the lora are empty
Labels: bug-report

### Checklist

- [ ] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [ ] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

I have a checkpoint download it but when i click to swap to it the process starts but then it instantly switches back to v1-5-pruned-emaonly.safetensors, the lora dont load either even though i downloaded them, i do have the civitai extension thats how i was getting the checkpoint and loras

### Steps to reproduce the problem

try to swap checkpoints and the loras are empty, but they do show the names of the lora but cant select them or anything

### What should have happened?

the checkpoint should switch and i should have lora

### What browsers do you use to access the UI ?

_No response_

### Sysinfo

[sysinfo-2024-05-26-03-09.json](https://github.com/AUTOMATIC1111/stable-diffusion-webui/files/15445919/sysinfo-2024-05-26-03-09.json)


### Console logs

```Shell
There is no logs to this its just the problem i decribed
```


### Additional information

_No response_
Repository: neovim
Issue: Surprising behaviour of default 0.10 color scheme groups: `Added`, `Changed`, `Delimiter`, `Operator`, `Removed` and `@variable`
Labels: enhancement,documentation,highlight

### Problem

I realise that there are already quite a few issues on here about the new default colorscheme, some of which touch on the surprising behaviour of `hi clear` in version 0.10. However, I'm opening this to discuss a specific set of surprises that I encountered, as a colorscheme maintainer, after upgrading to 0.10, and my suggestions for remedial changes. I am sympathetic to the desire for a new default colorscheme and appreciate the efforts being done here, but feel that there is at least a mismatch between the documentation and the current behaviour.

After upgrading to v0.10, I had to add the following links to my colorscheme, to restore the intended look:
- `hi! link Added DiffAdd`
- `hi! link Changed DiffChanged`
- `hi! link Delimiter Special`
- `hi! link Operator Statement`
- `hi! link Removed DiffDelete`
- `hi! link @variable Identifier`

This is due to the fact that my colorscheme uses the common defensive initialisation technique of setting `hi clear` before defining its own highlights. Because this sets the highlights back to their defaults, I am expecting that those defaults follow `:h group-name`. However, after 0.10, the above groups were not linked to basic groups from `:h group-name`, and instead had distinct RGB settings. My questions are:

### Expected behavior

- Why is `Added` not linked to `DiffAdd`? Is there any value in having these as distinct RGB definitions? Can the new default theme not simply set `DiffAdd` highlights?
- Ditto, but for `Changed` and `Removed`
- If it is really necessary to have `Delimiter` and `Operator` as distinct highlights by default, this change should be reflected in `:h group-name`, with those names being singled out instead of nested under `Special` and `Statement` by default
- **Most surprisingly, why is `@variable` not linked to e.g. `Identifier`?** This change in particular means that any colorscheme which sets `hi clear` and fails to set a `@variable` highlight (which is again not documented in `:h group-name`) will inherit the default colorscheme RGB value for large portions of any treesitter-highlighted code

As it stands right now, I'm unclear if the goal is to completely overhalul `group-name`, or if support for Vim8 themes is still intended. In any case, it would be good to document which group names a colorscheme maintainer must, at minimum, define after `hi clear`.
Repository: vscode
Issue: minimap does not show markers in .vue files
Labels: feature-request,editor-minimap


![Screenshot 2024-05-26 at 4 59 24 pm](https://github.com/microsoft/vscode/assets/50306702/3c197fe9-8f25-4efd-a259-6c97ae4d894e)
Type: <b>Bug</b>

Create a file with the .vue extension .
In in the script section add comment // MARK: - this is a test
The heading does not show in the mini map.
It works fine in any file with the .js extension

VS Code version: Code 1.89.1 (dc96b837cf6bb4af9cd736aa3af08cf8279f7685, 2024-05-07T05:14:32.757Z)
OS version: Darwin arm64 23.2.0
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Apple M2 Max (12 x 24)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|3, 3, 3|
|Memory (System)|32.00GB (1.57GB free)|
|Process Argv|--crash-reporter-id a1b77e41-2e9c-4f6d-b7f7-39cfae48e1bd|
|Screen Reader|yes|
|VM|0%|
</details><details><summary>Extensions (22)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-gcode-syntax|app|0.7.7
vscode-eslint|dba|2.4.4
vscode-deno|den|3.37.1
sync-scroll|dqi|1.3.1
EditorConfig|Edi|0.16.4
prettier-vscode|esb|10.4.0
copilot|Git|1.195.0
copilot-chat|Git|0.15.2
vscode-docker|ms-|1.29.1
debugpy|ms-|2024.6.0
python|ms-|2024.6.0
vscode-pylance|ms-|2024.5.1
remote-containers|ms-|0.362.0
cpptools|ms-|1.20.5
vscode-speech|ms-|0.8.0
vsliveshare|ms-|1.0.5918
material-icon-theme|PKi|5.3.0
platformio-ide|pla|3.3.3
excalidraw-editor|pom|3.7.4
LiveServer|rit|5.7.9
volar|Vue|2.0.10
vscode-todo-highlight|way|1.0.5


</details>
<!-- generated by issue reporter -->
Repository: next.js
Issue: When a page and layout exist, the page does not rise to the top unless the view height value of the page is greater than 100.
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://github.com/seung-juv/next-js-scroll-bug

### To Reproduce

1. clone the project and runs it.
2. on the main page, scroll down to the end and enter test.
<img width="1300" alt="image" src="https://github.com/vercel/next.js/assets/46600342/45485007-9146-4426-946d-34e3c8c0e080">
3. can see that the scroll is down.
<img width="1710" alt="image" src="https://github.com/vercel/next.js/assets/46600342/6d599e12-aa79-4307-be7d-0381e27992df">
4. When you go to the test2 page, you can see that the scroll is up.
<img width="1708" alt="image" src="https://github.com/vercel/next.js/assets/46600342/c280dcd3-25cf-4fa1-a569-3538448b8107">

Based on this phenomenon, if the height value of the page does not exceed 100vh, you can see that the scroll is maintained.

### Current vs. Expected behavior

Based on this phenomenon, if the height value of the page does not exceed 100vh, you can see that the scroll is maintained.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:19:05 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T8112
  Available memory (MB): 24576
  Available CPU cores: 8
Binaries:
  Node: 20.11.1
  npm: 10.2.4
  Yarn: 1.22.22
  pnpm: 8.10.2
Relevant Packages:
  next: 14.3.0-canary.82 // Latest available version is detected (14.3.0-canary.82).
  eslint-config-next: N/A
  react: 19.0.0-rc-f994737d14-20240522
  react-dom: 19.0.0-rc-f994737d14-20240522
  typescript: 5.4.5
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Navigation

### Which stage(s) are affected? (Select all that apply)

next dev (local), next start (local)

### Additional context

If you have layout in appdir, it seems that all phenomena are reproducible.
Repository: pytorch
Issue: `store_param_remainders` from Apex DistributedFusedAdam
Labels: oncall: distributed,module: optimizer,triaged

### 🚀 The feature, motivation and pitch

https://github.com/NVIDIA/apex/blob/a7de60e57f0534266841e1733262601ad76aaa74/apex/contrib/optimizers/distributed_fused_adam.py#L361C9-L361C31

In DistributedFusedAdam, if the model's computation dtype is bf16 and weights are f32, the optimizer can store [bf16 bits] and [remaining mantissa] separately, which together reconstruct the f32 master weights.

Upside: This may make all-gathering weights faster in FSDP, since there's no cast needed.
Downside: During the optimizer step, when the full f32 weights are needed, the bf16 and mantissa must be glued together then re-split.

The relevant [CUDA code path is here](https://github.com/NVIDIA/apex/blob/a7de60e57f0534266841e1733262601ad76aaa74/apex/contrib/csrc/optimizers/multi_tensor_distopt_adam_kernel.cu#L288), which reconstructs f32 for the optimizer, then splits it to bf16 + remainders.

### Alternatives

_No response_

### Additional context

_No response_

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @wconstab @yf225 @chauhang @d4l3k @vincentqb @jbschlosser @albanD @janeyx99 @crcrpar
Repository: bitcoin
Issue: show error "could not sign any more inputs" when sign PSBT for multisig
Labels: Wallet,PSBT

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

show error "could not sign any more inputs" when sign PSBT for multisig

### Expected behaviour

will sign succ and broadcast.

1. descriptor wallet in testnet
3. [create 2/3 multisig wallet and operation](https://github.com/bitcoin/bitcoin/blob/master/doc/multisig-tutorial.md)
4. failed if create unsigned using GUI
5. succ if using walletprocesspsbt/sendrawtransaction RPC
6. I've search the internet, "could not sign any more inputs" is all about pass phrase, is not my issue.

### Steps to reproduce

1. create unsigned using GUI in a 2/3 multisig wallet, copy
2. load PSBT from clipboard in a signer wallet
3. PSBT operation window, and show "Transcation has 1 unsigned inputs"
4. click "sign TX", show error "could not sign any more inputs"

### Relevant log output

_No response_

### How did you obtain Bitcoin Core

Compiled from source

### What version of Bitcoin Core are you using?

Bitcoin Core version v27.0.0

### Operating system and version

MacOS 14.4.1

### Machine specifications

_No response_
Repository: excalidraw
Issue: Request for adding shortcuts for changing the stroke width of elements
Labels: enhancement,freedraw

Haha sorry that I'm making another issue again, I just made one yesterday but this one is quite confusing to me. So it's really annoying to keep changing the stroke size because they're very inconsistent throughout the different elements, what I mean is the 2nd option for stroke width is medium sized on arrows but when I get the brush it is ABSOLUTELY HUGE. 
![image](https://github.com/excalidraw/excalidraw/assets/170816583/4b2965a9-5b3b-45da-9a36-47398d221df8)
Like this is the same stroke width used for both elements and there is a pretty bizzare difference between the 2 I feel like we all can see. 

It would be better if the stroke width was more consistent througout the elements or if for some reason the creator wanted there to be a differece, then it would be very helpful to have a shortcut to change the stroke width. There is already a shortcut for changing the font size but I don't understand why that's not the case for the stroke width since I'm pretty sure the font size doesn't really matter all that much since you can drag to increase the size of text but you can't drag to increase or decrease the thickness of an element (which is good) so yeah.

sorry for issuing another request but I just want excalidraw to get better so it can get ever more popular and I can proudly recommend it to all of my friends :)
Repository: ui
Issue: [bug]: "edit in v0" button is layer above navigation bar in /blocks page
Labels: bug

### Describe the bug

![Screenshot 2024-05-26 141728](https://github.com/shadcn-ui/ui/assets/114948140/3e35d357-a8ea-4b32-9a64-8a46351e8c7c)

When in New York style mode when scrolled ``Edit in v0`` button goes over the navbar.

### Affected component/components

Button

### How to reproduce

1. Go to https://ui.shadcn.com/blocks
2. Scroll down till you see blocks
3. Change the style form default to New York.
5. Scroll further down slowly till the ``Edit in v0`` button (which is in top right of the block example) gets close to the navigation bar.
6. You can see the ``Edit in v0`` button is one layer above the navigation bar while rest of the block in under.

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Browsers tested: Chrome, Brave, Edge.
System: Windows 11 Home
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues