sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: stable-diffusion-webui
Issue: [Feature Request]: Option to disable applying image dimensions to "Resize to" parameters in Inpaint tab
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 have encountered a problem with the resolution settings in the img2img tab. Every time I click on the “Send image to img2img inpaint” button, the resolution settings are automatically set to the resolution of the image, but I want to keep my custom resolution that I have set. I have searched for a way to disable this auto adjust feature, but I could not find any option in the settings or the documentation. This is very frustrating and inconvenient for me, as I have to re-enter my custom resolution every time I want to inpaint a specific area.

Therefore, I would like to request a feature that allows me to keep my custom resolution settings for the inpainted images. It would be very helpful if you could add an option to disable the auto adjust feature. This way, inpainting would be more streamlined without the need to manually enter 1024 pixels in both output dimensions every time.

![image](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/45420556/1f149371-507e-4606-a39e-4071c863f03f)


### Proposed workflow

1. Go to Inpaint in img2img tab.
2. Select Inpaint masked mode
3. Set your desired resolution of inpainting area.
4. **Press "Keep resolution" checkbox in "Resize to"**
5. Inpaint by drawing masks and pressing ctrl+enter without any worries


### Additional information

_No response_
Repository: pytorch
Issue: Module states cannot be fully synchronized due to the DDP broadcast_buffers breaking change
Labels: triage review,oncall: distributed

### 🐛 Describe the bug

From the recent breaking change in the `2.1.0` in the https://github.com/pytorch/pytorch/pull/100729, when the `broadcast_buffers` is set to `False`, it caused the DDP to not fully synchronize the module states (i.e., only the parameter is synchronized but the buffer is being left out out-of-sync) during the DDP initialization and the final step joining. This caused some issues in the following scenarios. 
1. With the random initialization, the master process module's parameter is broadcasted but not the buffer. While we can fix this by ensuring that all ranks are initialized with the same random seed, there are however some scenarios where we still want to use a different random seed for each rank. 
2. With the checkpoint loading, previously we only needed to load the checkpoint in the master process and the states (parameters and buffers) will be broadcasted to all other processes. While we can fix this by loading the exact same checkpoint in each process, there's also a scenario in which not all processes would have direct access to the checkpoint, for example, in a multi-node configuration where only the master node has access to the checkpoint which is located in the master node locally.

Also in the DDP [documentation](https://pytorch.org/docs/stable/generated/torch.nn.parallel.DistributedDataParallel.html#torch.nn.parallel.DistributedDataParallel), it specifically states that the `broadcast_buffers` flag is used to control the buffer broadcasting at the beginning of a module forward function, but not during the initialization and module final joining. 
```
broadcast_buffers ([bool] – Flag that enables syncing (broadcasting) buffers of the module at the beginning of the forward function. (default: True)
```

The documentation states a different behavior from the new changes, and the new change also caused some issues mentioned above in the module loading in the DDP, is this an intended behavior or it's a bug? 



### Versions

2.1.0

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @wconstab @yf225
Repository: go
Issue: proposal: x/net/http2: provide hook for custom frame policers
Labels: Proposal

<!--
Our proposal process is documented here:
https://go.dev/s/proposal-process
-->

This is a followup to CVE-2023-44487/CVE-2023-39325.

The fix shipped is a [very welcome change](https://github.com/golang/go/issues/63417) and nicely caps the number of handlers in the system. However, it's still insufficient in certain cases, for example [kube](https://github.com/kubernetes/kubernetes/pull/121120) and some of our own services. It is difficult to impossible in practice to tweak MAX_CONCURRENT_STREAMS below 100 without hitting client compatibility issues, and even at 100 the rapid reset attack may incur significant resource use, especially in cases where the go server is a gateway to other heavyweight services.

A wide number of mitigations have been deployed in other stacks; a non-exhaustive summary:
- a token bucket rate limiter across all http2 frames (this has proven to be effective even against new attacks; some projects put these in place after the 2019 http2 vulnerabilities and were not affected by this latest issue), then terminating connection
- a token bucket rate limiter strictly for RST_STREAM frames, then terminating connection
- heuristics for tracking total "overhead" frames, then terminating connection
- delays in processing new frames on connections that are exhibiting unusual behavior 

The thing all these mitigations have in common is visibility into the types of frames flowing over a connection. Additionally, this level of visibility is necessary to produce metrics and get insights into what attacks are even being seen, something that is not possible with the current APIs.

Proposal is to add a single callback hook that would receive basic frame information scoped to the individual connection: frame type, frame length, and stream ID. The callback's return value may trigger termination of the connection. With this hook, all necessary metrics can be gathered and all mentioned variants of frame policers may be built. The default is unset and will have no changes to out of the box behavior.

Attached is a patch that we deployed to build our mitigation for the CVE - 
[0001-introducing-ConnectionCalmer.patch](https://github.com/golang/go/files/12884156/0001-introducing-ConnectionCalmer.patch)
Repository: go
Issue: proposal: x/net/http2: add support for configuring stream and connection flow control values
Labels: Proposal

<!--
Our proposal process is documented here:
https://go.dev/s/proposal-process
-->

Today http2.Transport has hard-coded defaults for stream and connection flow control values. Stream flow control is determined by SETTINGS_INITIAL_WINDOW_SIZE sent on the initial SETTINGS frame, currently hardcoded to 4mb. Connection flow control has an RFC default of 65,535 bytes and is further increased by sending a WINDOW_UPDATE after the initial SETTINGS frame, which http2.Transport currently issues with a value of 1gb.

Both of these settings are important when it comes to controlling how the data from different streams is requested/interleaved. Exposing these in the Transport is in line with the parameters currently exposed on http2.Server, namely MaxUploadBufferPerConnection and MaxUploadBufferPerStream.
Repository: PowerToys
Issue: Quick accent
Labels: Needs-Triage,Needs-Team-Response,Product-Quick Accent

### Description of the new feature / enhancement

Could it be possible to add the glyphs necessary for the transliteration of ancient Hebrew?

In particular these letters:

0114 Ĕ
0115 ĕ
014E Ŏ
014F ŏ
018F Ə
0259 ə
02BE ʾ
02BF ʿ
0304 (combining macron, as it occurs to me there is no coded single glyph for p̄ or P̄)
1E06 Ḇ
1E07 ḇ
1E0E Ḏ
1EOF ḏ
1E20 Ḡ
1E21 ḡ
1E24 Ḥ
1E25 ḥ
1E34 Ḵ
1E35 ḵ
1E6C Ṭ
1E6D ṭ
1E62 Ṣ
1E63 ṣ
1E6E Ṯ
1E6F ṯ



### Scenario when this would be used?

Transliteration/romanization of ancient Hebrew (or other semitic languages)

### Supporting information

_No response_
Repository: vscode
Issue: Smoketest failure "hides the toc when searching depending on the search behavior"
Labels: debt,settings-editor,engineering

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=236635&view=logs&j=4801dce2-64f3-53d6-b366-d49a1977c639&t=91c4c8b0-4e34-5230-16e7-5d930ac20e2c

I wonder if this is worth maintaining a smoketest for. Smoketests just tend to be flaky
Repository: deno
Issue: Deno task doesn't accept {}
Labels: bug,task runner

Trying to run a task with `{` or `}` fails:

```jsonc
// deno.json
{
  "tasks": {
    "slash": "echo {}",
  }
}
```

```
$ deno task slash
Task slash echo {}
error: Error parsing script 'slash'.

Caused by:
    Unexpected character.
      {}
      ~
```

It doesn't work no matter how hard I escape the braces.

The `{` and `}` are used in the bash function `find -exec {} \;` syntax.
Repository: go
Issue: x/tools/gopls: 'references' on embedded field returns refs only to field, not type
Labels: gopls,Tools

The form `struct {T}` is unique in the Go grammar in that the identifier T is both a reference (to a type) and a declaration (of a field). When gopls responds to a references query on the identifier, it chooses arbitrarily to the interpret it as a field, and does not report references to the type. I think it should report the union of both.
Repository: pytorch
Issue: [dynamo] `ConfigModule` and `config.patch` are not thread safe
Labels: triaged,oncall: pt2,module: dynamo

### 🐛 Describe the bug

Config is a global object that can be accessed concurrently by multiple threads. Hence
1. patching should be performed on thread-local values
2. (optional) modifying/reading the global copy should be based on RWLocks.

When accessing the config object, if a thread-local exists (it is patched) then use that. Else, use the global.

### Priority
low now, higher with https://github.com/pytorch/pytorch/pull/111074, when we expect a lot more patching due to `torch.compiled` callables being able to restore a previously saved config whenever you call them.


### Versions

main, https://github.com/pytorch/pytorch/pull/111074

cc @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @wconstab
Repository: kubernetes
Issue: Writable cgroup for unprivileged containers
Labels: sig/node,kind/feature,lifecycle/stale,needs-triage

### What happened?

Except for the case when the `privileged` field is enabled in a container `securityContext`, `cgroup` fs is mounted in `/sys/fs/cgroup` as read only. While this behavior is desirable for most workloads, it simply prevents further/nested containerization (e.g. docker/podman in kubernetes) inside kubernetes pods unless insecure and/or hairy and hacky ways are applied to expose writable cgroup inside an unprivileged container. As discussed in #112937 it seems that cgroup fs is mounted as is from the node/host in the case of privileged containers which is surprising to me since I thought even privileged containers are isolated in their own cgroup_namespace (i.e. just like they are in an isolated PID and network namespace)

### What did you expect to happen?

1. There should a way for unprivileged containers to enable writable cgroup.
2. At least for now privileged containers should be in their own cgroup_namespace and not see/be able to write to all cgroups of all other containers running in the same node (you can see other pods cgroups by just doing `ls /sys/fs/cgroup/kubepods.slice/XXXX`)

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

1. Run a privileged container and use `kubectl exec -it` to see all other pods cgroups
2. Run an unprivileged container and use `cat /proc/mounts`, cgroup fs is read only

### Anything else we need to know?

_No response_

### Kubernetes version

v1.28

### Cloud provider

N/A

### OS version

_No response_

### Install tools

_No response_

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

_No response_

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

_No response_
Repository: godot
Issue: Setting anchors when Control is currently as "Full rect" discards values
Labels: bug,topic:gui

### Godot version

4.1.1.stable.official [bd6af8e0e]

### System information

Godot v4.1.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Laptop GPU (NVIDIA; 31.0.15.3742) - 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz (16 Threads)

### Issue description

When the layout options for a Control-derived node are changed (e.g. Anchor presets) and the Control is currently as "Full rect" (or sometimes "Custom"), the change from Full rect to something else discards the current layout values (position, size) entirely (also affecting any child node relying on them) and set the Control size to `(0, 0)`

This happens in 4.1 but did not happen in any of Godot 3 versions. In 3.x, the wide modes (left wide, top wide, etc) would reset the size, but not the other modes. In 4.x all modes reset the size when coming from full rect.

Example:

![ui4](https://github.com/godotengine/godot/assets/28926813/4102cc3c-e027-470a-8361-60b7ea52b303)


### Steps to reproduce

- Add a Control-derived node
- Set the anchors to Full rect
- Modify the position or size at will
- Change the anchors to anything else


### Minimal reproduction project

n/a
Repository: PowerToys
Issue: Mouse Without Borders: Keyboard won't switch PC if it comes from an RDP session.
Labels: Issue-Bug,Priority-1,Product-Mouse Without Borders

### Microsoft PowerToys version

0.74.1

### Installation method

Microsoft Store

### Running as admin

No

### Area(s) with issue?

Mouse Without Borders

### Steps to reproduce

1. Open an RDP session in host.
2. Focus on RDP session. Check that keyboard is working inside RDP session.
3. Move mouse to other PC.
4. Click on a text field in second PC.
5. Try to use keyboard. The Keyboard signal will be received by the RDP session instead of the second PC.

### ✔️ Expected Behavior

After changing focus out of the RDP session, keyboard input should be sent to the second PC.

### ❌ Actual Behavior

Keyboard input stays in the RDP session. In order to send the keyboard input to the second pc one must focus outside of the RDP session but still inside the host PC. After that, one can move the mouse to the second PC and receive keyboard input in the second PC.

### Other Software

![image](https://github.com/microsoft/PowerToys/assets/4166035/b7c3e992-5bea-4bab-8c6d-c7b57db4255c)
Repository: flutter
Issue: `readAccessUrl` of the webview_flutter_wkwebview should be accessible for customization
Labels: c: new feature,p: webview,package,c: proposal,P2,team-ios,triaged-ios

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

The issue is related to WKWebView, as it requires a separate URL for resource location if we load the local HTML file.

The current implementation of the `loadFile` is the following
<img width="471" alt="image" src="https://github.com/flutter/flutter/assets/8640978/b488f7ce-bcbc-4c7f-8868-12478191711b">

Which only works for the following structure
`root/`
`....css/`
`........styles.css`
`....js/`
`........func.js`
`....index.html`

And makes it impossible to work if we have something like in the example below
`root/`
`....css/`
`........styles.css`
`....js/`
`........func.js`
`....en/`
`........index.html`
`....ua/`
`........index.html`

### Proposal

The easiest solution would be to allow the configuration `readAccessUrl` as an optional argument
![image](https://github.com/flutter/flutter/assets/8640978/4f0e9a62-cda0-405e-89bd-8f6bc499e699)

However, since this is a WKWebView-related issue,
might be a good idea to extend the WebKitWebViewController.

Something as the following, or any other way which we could use to customize the path
![image](https://github.com/flutter/flutter/assets/8640978/44255a95-7ace-4c39-97d8-fa38c5b369ce)
![image](https://github.com/flutter/flutter/assets/8640978/dad1e0d4-001e-4071-adaa-536fd0614ece)
Repository: pytorch
Issue: overloads can perhaps be more performant?
Labels: module: optimizer,triaged,module: dispatch,module: codegen

After I land the 0dim overload in #111079, foreach_add will have the following signatures, generated in the following order:
```
 static PythonArgParser parser({
    "_foreach_add_(TensorList self, Scalar scalar)",
    "_foreach_add_(TensorList self, ScalarList scalars)",
    "_foreach_add_(TensorList self, Tensor other, Scalar alpha=1)",
    "_foreach_add_(TensorList self, TensorList other, *, Scalar alpha=1)",
  }, /*traceable=*/false);
```

The order is probably due to Scalars being more performant on CUDA.

## Problem:
The whole reason I added a tensor overload is so that in the CPU path, we don't continuously rewrap tensors as we dispatch into add(...). However, the above ordering means that code like `_foreach_add_(TensorList tensors, Tensor scalar_tensor)`, where 
`scalar_tensor` could be `torch.tensor(1.0)`, the first overload will "suffice", `scalar_tensor` will get casted to a normal Scalar, and we fall back into our loop of slowness.

Instead, I'd prefer `scalar_tensor` to not get coerced at all, and that the overload that ends up getting called should be `_foreach_add_(TensorList self, Tensor other, Scalar alpha=1)`. 

## Proposal:
I wonder if there's a way to tweak the parser code to penalize for coercion. It should check all the overloads and pick the one with the smallest coercion necessary before dispatching to it. Maybe the key here is to weigh `overloaded_args`. https://github.com/pytorch/pytorch/blob/6748a14a71f235501cd050e15d1810f7a0a75dbd/torch/csrc/utils/python_arg_parser.cpp#L1655-L1660

Con: I was just made aware that this can be detrimental to dispatcher performance due to slow is_instance checks...so maybe this would not be more performant after all...

Workaround:
My workaround today is just explicitly using an alpha to force the overload to be called :)

cc @vincentqb @jbschlosser @albanD @crcrpar @ezyang @bhosmer @bdhirsh @kadeng
Repository: TypeScript
Issue: jsdoc in JS: arguments object does not infer types from the containing function
Labels: Suggestion,Awaiting More Feedback

### 🔎 Search Terms

argument object infer

### 🕗 Version & Regression Information

I see it in `next` but I'm sure it's the way it's always behaved.

### ⏯ Playground Link

https://tsplay.dev/WyQbbW

### 💻 Code

```js
/** @type {(obj: Record<PropertyKey, unknown>, property: PropertyKey, value: unknown, nonEnumerable?: boolean | null, nonWritable?: boolean | null, nonConfigurable?: boolean | null, loose?: boolean) => void} */
module.exports = function defineDataProperty(
	obj,
	property,
	value
) {
	if (!obj || (typeof obj !== 'object' && typeof obj !== 'function')) {
		throw new TypeError('`obj` must be an object or a function`');
	}
	if (typeof property !== 'string' && typeof property !== 'symbol') {
		throw new TypeError('`property` must be a string or a symbol`');
	}
	if (arguments.length > 3 && typeof arguments[3] !== 'boolean' && arguments[3] !== null) {
		throw new TypeError('`nonEnumerable`, if provided, must be a boolean or null');
	}
	if (arguments.length > 4 && typeof arguments[4] !== 'boolean' && arguments[4] !== null) {
		throw new TypeError('`nonWritable`, if provided, must be a boolean or null');
	}
	if (arguments.length > 5 && typeof arguments[5] !== 'boolean' && arguments[5] !== null) {
		throw new TypeError('`nonConfigurable`, if provided, must be a boolean or null');
	}
	if (arguments.length > 6 && typeof arguments[6] !== 'boolean') {
		throw new TypeError('`loose`, if provided, must be a boolean');
	}

	var nonEnumerable = arguments.length > 3 ? arguments[3] : null;
	var nonWritable = arguments.length > 4 ? arguments[4] : null;
	var nonConfigurable = arguments.length > 5 ? arguments[5] : null;
	var loose = arguments.length > 6 ? arguments[6] : false;
};
```

### 🙂 Expected behavior

`arguments[3]` (and 4, 5, and 6) should all have a type as defined in the function's type (in this case, `boolean | null` for the first three, and `boolean` for the fourth).

This should result in `nonEnumerable`, `nonWritable`, and `nonConfigurable` being of type `boolean | null`, and `loose` being of type `boolean`.

### 🙁 Actual behavior
Those four variables have a type of `any`.

### Additional information about the issue

This is using jsdoc in a `.js` file with allowJs/checkJs enabled.
Repository: godot
Issue: NinePatchRect shaders are broken
Labels: discussion,topic:shaders,topic:gui,topic:2d

### Godot version

v4.1.1.stable.mono.official [bd6af8e0e]

### System information

Godot v4.1.1.stable.mono - macOS 14.0.0 - Vulkan (Forward+) - integrated Apple M1 Max - Apple M1 Max (10 Threads)

### Issue description

Creating a shader for a NinePatchRect behaves rather weird. All rects are affected simoultaniously but not all in the same way. I would expect the shader to modify the NinePatchRect as 1 texture.

In the Minimal reproduction project I tried to implement a very simple top-left rounded corner with this result:
<img width="1509" alt="Screenshot 2023-10-12 at 22 23 20" src="https://github.com/godotengine/godot/assets/46522075/6778f025-ea44-47e3-8e9d-94f80faa5105">


### Steps to reproduce

### To replicate
- create a NinePatchRect with a meaningful texture and region anywhere in your project
- create a simple shader such as the one in my example and observe results

### Notes for Minimal reproduction project
- play around with the exposed shader parameter, values between 0 - 0.3 should also illustrate the issue well

### Minimal reproduction project

[NinePatchRectBug.zip](https://github.com/godotengine/godot/files/12886769/NinePatchRectBug.zip)
Repository: kubernetes
Issue: Mitigate http/2 attacks by authenticated clients
Labels: sig/network,sig/api-machinery,lifecycle/frozen,triage/accepted

https://github.com/golang/net/commit/b225e7ca6dde1ef5a5ae5ce922861bda011cfabd does not sufficiently protect us from a malicious http/2 client.  #121120 handles unauthenticated clients.  This issue tracks mitigations for authenticated clients.

pprof svg from a single client with a single connection attempting to DOS a Kube API server that has max streams set to 100 (memory usage grew to 5 GB in a few mins before it stabilized - with multiple connections the API server would have easily OOM'd):

![mem](https://github.com/golang/go/assets/7001223/f1eb9ac6-9530-4583-9f7f-8b21d02df950)

xref: https://github.com/golang/go/issues/63417#issuecomment-1758858612