sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: MultiplayerSynchronizer node order is significant
Labels: documentation,topic:network

### Godot version

4.0.2.stable

### System information

Ubuntu 22.04

### Issue description

While trying to recreate the multiplayer scene replication code as demonstrated in https://godotengine.org/article/multiplayer-in-godot-4-0-scene-replication/ I discovered that the order of the MultiplayerSynchronizer nodes is significant. If the player input synchronizer (that sends input to the server) appears **before** the player position synchronizer (that sends position from server to clients) then the replication fails. The other way around it works.

In the failing configuration, it appears that the `player` property on the Player node spawned on the connecting client does not get set, which leads to the multiplayer authority not being set on the player input.

Notably, I tried changing the node order on the example project in the article linked above and that does **not** replicate this bug. The primary difference is that my project is 2D and the example is 3D.

### Steps to reproduce

1. Run two instances of the attached project.
2. Press "Host" in the first instance.
3. Note that the arrow keys allow the player square to move.
4. Press "Connect" in the second instance.
5. Note that the arrow keys fail to move the player square to move in the second instance but that the first instance continues to work/move and that the position is replicated to the second instance.
6. Stop the project and swap the order of the two MultiplayerSynchronizer instances under the Player node.
7. Repeat steps 1-5 but note that the second instance now allows the player square to move.

### Minimal reproduction project

[godot_4_multiplayer.zip](https://github.com/godotengine/godot/files/11189154/godot_4_multiplayer.zip)
Repository: transformers
Issue: Add SwiftFormer
Labels: New model

### Model description

'SwiftFormer' paper introduces a novel efficient additive attention mechanism that effectively replaces the quadratic matrix multiplication operations in the self-attention computation with linear element-wise multiplications.  A series of models called 'SwiftFormer' is built based on this, which achieves state-of-the-art performance in terms of both accuracy and mobile inference speed. Even their small variant achieves 78.5% top-1 ImageNet1K accuracy with only 0.8 ms latency on iPhone 14, which is more accurate and 2× faster compared to MobileViT-v2.

I would like to add this model to Huggingface.

### Open source status

- [X] The model implementation is available
- [X] The model weights are available

### Provide useful links for the implementation

Paper: https://arxiv.org/abs/2303.15446
Original code and weights: https://github.com/Amshaker/SwiftFormer 
Author: @Amshaker
Repository: terminal
Issue: {Freeway-Bug}[Expand drop down]: Tooltip information of the profiles is getting truncated at 200% zoom.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11ySev3

### Windows Terminal version

1.18.902.0

### Windows build number

23031.1000

### Other Software

Test environment:
OS: Version 22H2 (OS build 23031.1000)
Application: Windows Terminal
Screen reader: Narrator

### Steps to reproduce

Pre-requisite:
Apply the resize using following path.
Settings>Accessibility>Display>Display resolution>Change display resolution to '1280 x 720>Keep changes>Drag the 'Text size' slider to '200%'>Apply>Re-open the application.

Repro steps:

1. Open the 'windows terminal' application.
2. Log in with valid credentials.
3. Follow the above-mentioned pre-requisite step.
4. Now expand the dropdown control using 'Ctrl+Shift+j' (Key may varies from user to user).
5. Navigate among the options present for the expanded dropdown.
6. Observe the issue.

User experience:
Users with low vision rely on zooming features for navigation will feel difficulty in understanding the tooltip information, if tooltip gets truncated at 200% zoom.

Guideline reference:
https://www.w3.org/TR/WCAG21/#resize-text

Attachment:
[Tooltip info is getting truncated on applying resize..zip](https://github.com/microsoft/terminal/files/11189756/Tooltip.info.is.getting.truncated.on.applying.resize.zip)


### Expected Behavior

Complete tooltip information, which is appearing in 100% zoom should visible properly even after applying 200% zoom.

### Actual Behavior

Some part of tooltip information is getting truncated for the profiles, on applying 200% zoom.
Repository: PowerToys
Issue: Remaping L-CTRL to L-WIN makes R-ALT behave like WIN+ALT, making keyboard manager unusable for Norwegians.
Labels: Issue-Bug,Product-Keyboard Shortcut Manager,Needs-Triage

### Microsoft PowerToys version

0.69.0

### Installation method

GitHub

### Running as admin

No

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

Enable keyboard manager
Open mapping window
Set L-CTRL key to be mapped to L-WIN key
(bonus stepp, but unecesary: Set L-WIN key to be mapped to L-CTRL key)
Close mapping window
Open Notepad
Select the text field
Set keyboard language to Norwegian(NNO or NB)
Press R-ALT+4

### ✔️ Expected Behavior

On a norwegian keyboard, pressing R-ALT+4 should result in a "$"-symbol

### ❌ Actual Behavior

It behaves as if ALT+WIN+4 is pressed

It opens up right click menue for the 4 item on the taskbar.

### Other Software

_No response_
Repository: stable-diffusion-webui
Issue: [Bug]: return the black squares alltime in ubuntu and docker
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

Graphics card:AMD 6650XT
OS:ubuntu 20.04.6 LTS
docker version:    23.0.3
uname -r: 5.15.0-69-generic
no matter what tags are entered, the result is black squares.

### Steps to reproduce the problem

1. enter the school tag
2. click generate
3. return black squares....

### What should have happened?

if i enter the tag is school,it can return the school picture.

### Commit where the problem happens

Commit hash: a9fed7c364061ae6efb37f797b6b522cb3cf7aa2

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

Linux

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

Mozilla Firefox

### Command Line Arguments

```Shell
docker exec -it stable-diffusion bash -c "cd /dockerx/stable-diffusion-webui && source venv/bin/activate && REQS_FILE='requirements.txt' HSA_OVERRIDE_GFX_VERSION=10.3.0 python launch.py --lowvram --disable-nan-check --precision full --no-half"
```


### List of extensions

no

### Console logs

```Shell
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
stable-diffusion
Python 3.9.5 (default, Nov 23 2021, 15:27:38) 
[GCC 9.3.0]
Commit hash: a9fed7c364061ae6efb37f797b6b522cb3cf7aa2
Installing requirements for Web UI

Launching Web UI with arguments: --lowvram --disable-nan-check --precision full --no-half
No module 'xformers'. Proceeding without it.
Loading weights [6ce0161689] from /dockerx/stable-diffusion-webui/models/Stable-diffusion/v1-5-pruned-emaonly.safetensors
Creating model from config: /dockerx/stable-diffusion-webui/configs/v1-inference.yaml
LatentDiffusion: Running in eps-prediction mode
DiffusionWrapper has 859.52 M params.
Applying cross attention optimization (Doggettx).
Textual inversion embeddings loaded(0): 
Model loaded in 14.0s (load weights from disk: 0.4s, create model: 0.4s, apply weights to model: 12.7s, load VAE: 0.5s).
Running on local URL:  http://127.0.0.1:7860

To create a public link, set `share=True` in `launch()`.
Startup time: 19.8s (import gradio: 1.9s, import ldm: 0.9s, other imports: 1.4s, load scripts: 0.3s, load SD checkpoint: 14.1s, create ui: 1.1s).
100%|███████████████████████████████████████████| 20/20 [02:11<00:00,  6.57s/it]
Total progress: 100%|███████████████████████████| 20/20 [02:04<00:00,  6.24s/it]
Closing server running on port: 7860████████████| 20/20 [02:04<00:00,  6.60s/it]
Restarting UI...
Running on local URL:  http://127.0.0.1:7860

To create a public link, set `share=True` in `launch()`.
Startup time: 1.5s (list extensions: 0.2s, create ui: 1.1s).
100%|███████████████████████████████████████████| 20/20 [02:13<00:00,  6.66s/it]
Total progress: 100%|███████████████████████████| 20/20 [02:06<00:00,  6.33s/it]
Total progress: 100%|███████████████████████████| 20/20 [02:06<00:00,  6.73s/it]
```


### Additional information

_No response_
Repository: storybook
Issue: [Bug]: Able to see methodsClass and propertiesClass in angular storybook
Labels: bug,angular

### Describe the bug

Is there any way we can avoid compodoc methodsClass and propertiesClass from being shown in the ui

### To Reproduce

_No response_

### System

_No response_

### Additional context

_No response_
Repository: rust
Issue: a static library is not linked properly to a required system library
Labels: A-linkage,C-bug

### Problem

I created a crate as a static library named `libaries_askar.a`. When I create an Xcode project that uses this library, build fails with the following error:
```
Undefined symbols for architecture x86_64:
  "_SCDynamicStoreCopyComputerName", referenced from:
      whoami::platform::devicename_os::hfd1ed897939614da in libaries_askar.a(whoami-3e3bd00337b8ac7e.whoami.50980d84-cgu.12.rcgu.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

I could resolve this link error by importing SystemConfiguration framework in a swift file of my app.
```swift
#if os(macOS)
import SystemConfiguration
#endif
```


### Steps

1. Create a crate that depends on the "whoami" crate.
2. Build the crate as a static library.
3. Create an xcframework of the library.
4. Create a Swift package and add the xcframework as a binary target dependency.
5. Build the package.

### Possible Solution(s)

_No response_

### Notes

- I only tested this on macOS, not on iOS.
- I'm not sure if this is a bug or not.

### Version

```text
cargo 1.67.1 (8ecd4f20a 2023-01-10)
release: 1.67.1
commit-hash: 8ecd4f20a9efb626975ac18a016d480dc7183d9b
commit-date: 2023-01-10
host: x86_64-apple-darwin
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0 (sys:0.4.59+curl-7.86.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.2.1 [64-bit]
```
Repository: terminal
Issue: {Freeway-Bug}[Terminal]: Narrator is staying silent, when focus is on 'Empty line', while navigating in the editor using 'Ctrl+arrow keys' in scan mode.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11ySev3

### Windows Terminal version

1.18.902.0

### Windows build number

23031.1000

### Other Software

Test environment:
OS: Version 22H2 (OS build 23031.1000)
Application: Windows Terminal
Screen reader: Narrator

### Steps to reproduce

Repro steps:

1. Open the 'windows terminal' application.
2. Log in with valid credentials.
3. Open 'Windows PowerShell' tab.
4. Turn on narrator using 'Ctrl+Windows+Enter' keys & toggle to scan mode using 'Capslock+Space' key.
5. Navigate in the editor using 'Ctrl+Arrow keys'.
6. Observe the issue.

User experience:
Users who rely on screen readers will get confused here, if screen reader stays silent for the empty line while navigating via 'Ctrl+Arrow keys' in the editor.

Guideline reference:
https://www.w3.org/TR/WCAG21/#info-and-relationships

Attachment:
[Screen reader is staying silent for empty line in the editor..zip](https://github.com/microsoft/terminal/files/11190853/Screen.reader.is.staying.silent.for.empty.line.in.the.editor.zip)


### Expected Behavior

Screen reader should narrate as 'blank' for the empty lines, while navigating in the editor via 'Ctrl+Arrow keys'.

Note:
1.Screen reader is not narrating as 'Blank' for the empty 'Name' field present for the 'Default' settings.

### Actual Behavior

Screen reader is staying silent & not narrating anything for the empty line, while navigating in the editor via 'Ctrl+Arrow keys'.
Repository: rust
Issue: Link directly from the README to rustc-dev-guide
Labels: A-docs,A-contributor-roadblock

### Location

https://github.com/rust-lang/rust/blob/fcb2a3665f691f567dbb359899687d6344c72944/README.md#L10-L12

https://github.com/rust-lang/rust/blob/e6989d2959ee8ecc81c2e6fb3622d91108772a99/CONTRIBUTING.md#L11-L21

### Summary

Right now, there's a lot of steps involved in finding useful info about how to build the compiler (if you're not following the steps in the README, which are intended for distros). For example, to find how to test the standard library, you'd have to go from the README -> CONTRIBUTING -> https://rustc-dev-guide.rust-lang.org/ -> notice "Testing the compiler" in the sidebar and realize it might be relevant to the standard library too. We should improve several of these steps, but the easiest one is to link directly to the rustc-dev-guide from the README.

Unfortunately, CONTRIBUTING.md still has some information that's not on the top-level "Getting Started" page in the dev-guide; in particular, rustc-dev-guide doesn't link to std-dev-guide until way down in "other places to find information": https://rustc-dev-guide.rust-lang.org/about-this-guide.html?highlight=std-dev-guide#other-places-to-find-information. We should make this more prominent, and then we can update the README to link directly.

cc https://rust-lang.zulipchat.com/#narrow/stream/122652-new-members/topic/testing.20library.2Fcore
Repository: stable-diffusion-webui
Issue: [Bug]: Folder name encoding issue (?)
Labels: asking-for-help-with-local-system-issues

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

I've been in the process of installing all the necessary programs on win10 and have followed the instructions all the way up to: "Double click webui-user.bat" 

when I double click it the prompt runs until it reaches "installing gfpgan" and then shows the following 
![image](https://user-images.githubusercontent.com/130379621/230923979-fd9a4fa0-c3c4-4b05-8d03-7d153acf670a.png)


### Steps to reproduce the problem

1. Go to stable-diffusion-webui
2. Press webui-user.bat
3. Then the text writes this: 
![image](https://user-images.githubusercontent.com/130379621/230924280-2bc86b51-840a-4de8-8a48-4efdf7bd6957.png)



### What should have happened?

I'm not an expert at this stuff to say the least so I am sticking closely to the installation instructions, I believe the installation of the different packages should have gone through until I'd receive the local URL to use to activate the program.

### Commit where the problem happens

Can't find it

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

Windows

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

Google Chrome

### Command Line Arguments

```Shell
Not sure what this means. The file I'm using is "webui-user.bat" as per the installation video.
```


### List of extensions

Reader mode
Behind the overlay

### Console logs

```Shell
![image](https://user-images.githubusercontent.com/130379621/230924280-2bc86b51-840a-4de8-8a48-4efdf7bd6957.png)

I can't seem to provide the full one cause this is as far back as my prompt can go back
```


### Additional information

Thank you guys very much! Appreciate the help
Repository: stable-diffusion-webui
Issue: [Bug]: Inpaint canvas is broken
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

When trying to use inpaint, only a part of the image is shown. Img2Img and Inpaint sketch are not affected.

### Steps to reproduce the problem

1. Generate an image 
2. Press send to inpaint
3. Get the broken result
4. Press img2img in the txt2img tab and get a correct result
5. Press send to inpaint sketch in the img2img tab and get a correct result


### What should have happened?

The inpaint canvas should be working.

### Commit where the problem happens

22bcc7be

### What platforms do you use to access the UI ?

Linux

### What browsers do you use to access the UI ?

Mozilla Firefox

### Command Line Arguments

```Shell
No
```


### List of extensions

controlnet, tagcomplete, openpose

### Console logs

```Shell
none relevant
```


### Additional information

Working inpaint sketch tab:
![Screenshot_20230410_165407](https://user-images.githubusercontent.com/1482341/230927443-8bdfd07e-a6d2-4d13-b984-399f55e82d36.png)

Not working inpaint tab:
![Screenshot_20230410_165414](https://user-images.githubusercontent.com/1482341/230927449-df9258be-3054-4658-b0ec-ac7835b0b8df.png)
Repository: storybook
Issue: [Documentation]: Add section that describes how to add descriptions to components
Labels: documentation

### Describe the problem

I was testing out autodocs (worked like a charm), but wanted to add more details. I vaguely remembered I could write some comments somewhere, but didn't see anything about it in 7.0 docs. I did end up looking at some example components and stories and worked out what I needed.

I would like to see three additions to the docs so other folks don't struggle with this:
1. Show how to add descriptions to a component
2. Show how to add descriptions to props/interface
3. Show how to add descriptions to individual stories

Thank you!


### Additional context

_No response_
Repository: go
Issue: proposal: cmd/internal/codesign: Extend mach-O codesigning with entitlements 
Labels: Proposal

Hi everyone,

Not sure if this is would actually need to be a *proposal*, since it only changes an *internal* API but I would like to extend the functionality of the `cmd/internal/codesign` package. Currently, it only performs basic codesigning of (macOS) mach-O binaries. However, on macOS, the code signing process also includes additional meta-data, for example so called *entitlements*. I would like to extent the currently code signing code to make it possible to create Go binaries with entititlements (and possibly other code signing features).

One could argue, that for such use-cases `codesign` should or can be used. While this is true, there are two points that speak in favour:

1. The Go pipeline is already there; so why not extend it to include more advanced features? The code signing process seemed pretty stable over the last years, so not much maintenance should be expected
2. While you can use `codesign` in the final steps of preparing an executable, it is cumbersome to use in `go test`. A good example for such a workaround is the current way tests are working in delve for the (slightly broken) native Go frontend. An external Go script is compiling the test binary and signs it with `codesign`, making in-place debugging very hard.

I already made myself familiar with the code in `cmd/internal/codesign` and would like to implement these changes in a PR.

I have not yet discussed how to actually read the entitlements (maybe from an ENV?), I would like to focus on extending the code sign functionality first.
Repository: go
Issue: proposal: cmd/go: enhance `go version` to check if running latest revision of Go
Labels: Proposal,GoCommand

The Go ecosystem lacks a standard way to check whether a system is running the latest revision of the current `{major}.{minor}` version of Go available.

[https://go.dev/dl/?mode=json](https://go.dev/dl/?mode=json) already provides a machine-readable (JSON) list of all the currently supported versions, but integrating it into a toolchain often requires complex scripts with external dependencies (e.g. curl, jq). 

It seems like something the `go` command should handle in a consistent way.

My proposal is to extend `go version` with a new `check` command as following:

With no parameters, it would check whether the system is running the latest revision of the current major version installed.

```sh
> go version check
Running the latest revision of Go 1.20 (go1.20.3 darwin/arm64).
(code 0)
```

With a `--latest` flag, it would check whether the system is running the latest major release of Go.

```sh
> go version check --latest
Go 1.20 is available → https://tip.golang.org/doc/go1.20
(code 1)
```

Ideally, this would also serve warnings for out-of-support versions:

```sh
> go version check
Go 1.18 is no longer supported (go1.18.10 darwin/arm64).
(code 1)
```
Repository: neovim
Issue: Extend store_session_globals to store dictionaries
Labels: enhancement

### Problem

Currently, only strings and numbers can be stored as global variables in session files. It would be more convenient to store dictionaries without encoding and decoding them. If there is any interest, I would be happy to contribute to this.

### Expected behavior

Dictionaries containing numbers/strings/dictionaries would be saved in vimscript format directly.
Repository: godot
Issue: Pen/stylus input is not responsive enough for hand writing
Labels: discussion,topic:input

### Godot version

v4.0.stable.official [92bee43ad]

### System information

Windows 11, Lenovo Yoga 7i (14'' Intel), Lenovo Digital Pen 2

### Issue description

I'm making a simple productivity app in Godot that needs to support hand writing via pen/stylus.

When I write slowly, the writing is displayed accurately. However, when I write at my normal handwriting speed, which involves my pen coming on and off the screen several times per second, the writing is not displayed accurately.

Here is an example of me writing an "H" slowly:
![image](https://user-images.githubusercontent.com/12731832/230958437-f6ab170d-6c5a-46a9-9aa8-8170e31a187a.png)

And a log of all the input events:
[SlowH.txt](https://github.com/godotengine/godot/files/11192530/SlowH.txt)


Here is an example me writing an "H" at normal handwriting speed:
![image](https://user-images.githubusercontent.com/12731832/230958494-185d5bea-cbfe-422d-a374-702161795784.png)

And a log of all the input events:
[FastH.txt](https://github.com/godotengine/godot/files/11192532/FastH.txt)

There's a few odd things I've noticed about the fast "H" log.

1. There are only InputEventMouseMotion events, no InputEventMouseButton events.
2. There are many InputEventMouseMotion events with identical positions but different pressures.

### Steps to reproduce

1. Make a new project
2. Set the main scene as a single control node.
3. Attach the following script.
4. (optional) uncomment `print(event)` to see a log of all the input events.
5. Run the project.
6. Try writing something quickly with a pen/stylus.
7. Try writing the same thing but slowly.

```
extends Control

var stroke : Line2D


func _ready() -> void:
	Input.use_accumulated_input = false # issue occurs whether this is true or false
	start_stroke()


func _input(event: InputEvent) -> void:
	# uncomment the print statement to see a log of events
	# print(event)
	if event is InputEventMouseMotion:
		var event_mouse_motion := event as InputEventMouseMotion
		if event_mouse_motion.pressure <= 0 && stroke.points.size() > 1:
			start_stroke()
		if event_mouse_motion.pressure > 0:
			stroke.add_point(event_mouse_motion.position)
		
		
func start_stroke() -> void:
	var new_stroke := Line2D.new()
	add_child(new_stroke)
	new_stroke.owner = self
	stroke = new_stroke
```

### Minimal reproduction project

N/A