sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: With two ConfirmationDialog calls, shortly after each other, the second blocks when the first is canceled.
Labels: discussion,topic:gui

### Godot version

v4.0.2.stable.official [7a0977ce2] (also tested 4.1 RC)

### System information

Windows 10, Vulkan

### Issue description

I show two ConfirmationDialog (or AcceptDialogs) after each other, both waiting for a user response with await. The seconds is not shown if the the user cancel the first one (or click the close cross in the title)

### Steps to reproduce

Create a Node3D with a ConfirmationDialog as child.
At the next script to the Node3D:

```
extends Node3D

@onready var _confirmation_dialog: ConfirmationDialog = $ConfirmationDialog

signal on_user_action

var _confirmed: bool = false

# Called when the node enters the scene tree for the first time.
func _ready():
	_confirmation_dialog.connect("confirmed", on_confirmed)
	_confirmation_dialog.connect("canceled", on_canceled)
	
	_confirmation_dialog.dialog_text = "Test 1"
	_confirmation_dialog.popup_centered()
	await on_user_action
	_confirmation_dialog.dialog_text = "Test 2"
	_confirmation_dialog.popup_centered()
	await on_user_action


func on_confirmed():
	_confirmed = true
	_confirmation_dialog.hide()
	emit_signal("on_user_action")


func on_canceled():
	_confirmed = false
#	await get_tree().create_timer(0.02).timeout
	_confirmation_dialog.hide()
	emit_signal("on_user_action")

```

Run this and press cancel button with the first message. The second message will not be given.
It seems someting to do with a deferred action. If I uncommend the timer all goes well.

### Minimal reproduction project

[TestConfimation.zip](https://github.com/godotengine/godot/files/11896005/TestConfimation.zip)
Repository: vscode
Issue: Git - Performance Improvement: Revert Selected Ranges Should Not Replace The Entire Document
Labels: debt,git,perf,under-discussion

Currently, `revert selected ranges` applies a workspace edit that always replaces the entire document.
This does not work very well with the collapse unmodified code feature, as for a brief time the old state cannot be related to the new state (as the edit spans the entire document & diffing happens asynchronously).
It also forces the entire document to be retokenized and invalidates the bracket pair AST.

This is the code:

https://github.com/microsoft/vscode/blob/1399c189331d264ccb7d26a563d8979212163273/extensions/git/src/commands.ts#L1478-L1483

I suggest that `applyLineChanges` constructs the WorkspaceEdit directly, by only touching the changed lines.

I can help with that!

---

Thinking about it, it is probably better to remove the entire "Revert Selected Ranges" command from the git extension and make it a built-in diff editor command.
Repository: go
Issue: proposal: testing: add fields to BenchmarkResult to report errors, skips, and logs
Labels: Proposal

In reviewing the `testing` package, I noticed that it currently contains some tests that call [`testing.Benchmark`](https://pkg.go.dev/testing#Benchmark), where the benchmark function calls `Error`, `Fatal`, or `SkipNow`.
(https://cs.opensource.google/go/go/+/master:src/testing/benchmark_test.go;l=94-127;drc=cecaa25bd31622f5ae0df7fd5c8c7f02afde8715)

Those tests do not currently emit any output when run, and as far as I can tell the `testing.BenchmarkResult` type does not provide a way for them to do so. As a result, I believe that failures in calls to `testing.Benchmark` in general tend to go undetected.
```
~/go/src$ go1.21rc2 test testing -run='TestRunParallel.*' -v -count=1
=== RUN   TestRunParallel
--- PASS: TestRunParallel (0.16s)
=== RUN   TestRunParallelFail
--- PASS: TestRunParallelFail (0.00s)
=== RUN   TestRunParallelFatal
--- PASS: TestRunParallelFatal (0.00s)
=== RUN   TestRunParallelSkipNow
--- PASS: TestRunParallelSkipNow (0.00s)
PASS
ok      testing 0.178s
```

To allow users of `testing.Benchmark` to write more robust benchmarks, I propose the addition of the following fields to the `BenchmarkResult` struct:

```go
type BenchmarkResult struct {
	…
	Log []byte  // The output produced by calls to b.Log, b.Error, b.Skip, and similar during the benchmark run.
	Failed bool  // The value returned by b.Failed at the end of the run.
	Skipped bool // The value returned by b.Skipped at the end of the run.
}
```

Since these are new fields, I believe this change is strictly backward-compatible.
Repository: tensorflow
Issue: `tf.math.reduce_prod` produces wrong second-order gradient
Labels: stat:awaiting tensorflower,type:bug,comp:ops,TF 2.13

<details><summary>Click to expand!</summary> 
 
 ### Issue Type

Bug

### Have you reproduced the bug with TF nightly?

Yes

### Source

source

### Tensorflow Version

2.14.0-dev20230628

### Custom Code

Yes

### OS Platform and Distribution

Linux Ubuntu 20.04

### Mobile device

_No response_

### Python version

3.9

### Bazel version

_No response_

### GCC/Compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current Behaviour?

`tf.math.reduce_prod` produces wrong second-order gradient when the input tensor has a `0` element. 

In the following example, `d2z_dydx` should be `1`, but the output value is `0`. Note that, if we replace `z = tf.math.reduce_prod(tf.stack([x, y]))` with `z = x * y`, the assertion passes.

### Standalone code to reproduce the issue

```shell
import tensorflow as tf
x = tf.Variable(0.0)
y = tf.Variable(1.0)
with tf.GradientTape(persistent=True) as t1:
    t1.watch(x)
    t1.watch(y)
    with tf.GradientTape(persistent=True) as t2:
        t2.watch(x)
        t2.watch(y)
        z = tf.math.reduce_prod(tf.stack([x, y]))
    print('z = x * y: ', z)  
    dz_dx = t2.gradient(z, x) # dz_dx = y
    print('dz_dx: ', dz_dx)
    dz_dy = t2.gradient(z, y) # dz_dy = x
    print('dz_dy: ', dz_dy)

d2z_dx2 = t1.gradient(dz_dx, x) # d2z_dx2 = 0
print('d2z_dx2', d2z_dx2)
d2z_dxdy = t1.gradient(dz_dx, y) # d2z_dxdy = 1
print('d2z_dxdy', d2z_dxdy)
assert d2z_dxdy == 1
d2z_dydx = t1.gradient(dz_dy, x) # d2z_dydx = 1
print('d2z_dydx', d2z_dydx)
assert d2z_dydx == 1, 'd2z_dydx = {}'.format(d2z_dydx)
# AssertionError: d2z_dydx = 0.0
```


### Relevant log output

```shell
AssertionError: d2z_dydx = 0.0
```
</details>
Repository: storybook
Issue: [Bug]: Storybook 7/Angular not showing controls for argTypes
Labels: bug,has workaround,angular,needs triage

### Describe the bug

Create an Angular (16) component with an @input defined as a string type (list of appropriate values. and add a story containing argTypes for the input values matching the type ('primary', 'secondary') etc..

Now run the story and notice the argTypes are not applied to the control

```tsx
import { Meta } from '@storybook/angular';
import { HeaderComponent } from './header.component';

export default {
  title: 'HeaderComponent',
  component: HeaderComponent,
  argTypes: {
    displayClass: {
      description: 'Button display class',
      defaultValue: 'primary',
      control: {
        type: 'select',
        options: ['primary', 'secondary'],
      },
    },
    displayType: {
      description: 'Button display type',
      defaultValue: 'outline',
      control: {
        type: 'select',
        options: ['outline', 'flat', 'basic'],
      },
    },
  },
} as Meta<HeaderComponent>;

export const Primary = {
  render: (args: HeaderComponent) => ({
    props: args,
  }),
  args: {
    headerId: 'headerId-1',
    header: 'Title',
    displayClass: 'primary',
    displayType: 'flat',
    headerSize: 'med',
  },
};
```


### To Reproduce

Please see the sample mini repo to view 
https://github.com/bizappzone/min-repo-storybook/tree/main


and sample stories
https://github.com/bizappzone/min-repo-storybook/tree/main/packages/ngx-base/src/lib

### System

```shell
Environment Info:

  System:
    OS: Windows 10 10.0.19045
    CPU: (8) x64 Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz
  Binaries:
    Node: 18.15.0 - C:\Program Files\nodejs\node.EXE
    npm: 9.3.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 114.0.5735.198
    Edge: Spartan (44.19041.1266.0), Chromium (114.0.1823.58)
  npmPackages:
    @storybook/addon-a11y: ^7.0.20 => 7.0.24
    @storybook/addon-essentials: ^7.0.9 => 7.0.24
    @storybook/addon-interactions: ^7.0.20 => 7.0.24
    @storybook/addon-links: ^7.0.20 => 7.0.24
    @storybook/addon-styling: ^1.3.0 => 1.3.1
    @storybook/angular: ^7.0.9 => 7.0.24
    @storybook/blocks: ^7.0.20 => 7.0.24
    @storybook/core-common: ^7.0.9 => 7.0.24
    @storybook/core-server: ^7.0.9 => 7.0.24
    @storybook/jest: ^0.1.0 => 0.1.0
    @storybook/manager-api: ^7.0.20 => 7.0.24
    @storybook/test-runner: ^0.7.2 => 0.7.2
    @storybook/testing-library: ^0.1.0 => 0.1.0
    @storybook/theming: ^7.0.20 => 7.0.24
```


### Additional context

_No response_
Repository: godot
Issue: Godot does not recognize all buttons of a Nintendo Switch Joycon
Labels: bug,topic:input

### Godot version

v3.5.2.stable.official[170ba337a],  v4.0.3.stable.official [5222a99f5]

### System information

Linux Mint 21.1 x86_64 

### Issue description

Godot does not recognize the ZR and R button of the right joy con when assigning the buttons to an action on the input map in the project settings. The SL, ZL, L, -(minus), arrow up, arrow left of the left joycon also can't be recognized by the engine. I also tried to print the button id in the _input() function but nothing happened for the buttons I mentioned before.

However the Godot version v3.2.3.stable.custom_build from the Linux apt is able to recognize every button pressed on every joycon and everything works fine. This can be installed with sudo apt install godot3

### Steps to reproduce

func _input(event):
	for i in range(0, 20):
		if Input.is_joy_button_pressed(0, i):
			print(str(i))

### Minimal reproduction project

N/A
Repository: bitcoin
Issue: Improving fee estimation accuracy
Labels: Brainstorming,TX fees and policy

The current fee estimation algorithm suffers from a number of issues that make it hard to use in the real world:
* Because it's solely based on historical data (looking at how long mempool transactions take to confirm), it cannot react quickly to changing conditions.
* Because it's aiming to match seen behavior rather than requirement, if some non-negligible fraction of users keeps paying a certain high feerate, it may try to match that, even if unnecessary for confirmation.

There exist alternative sources of information which could mitigate some of these issues, but they are not used for various reasons:
* We could look at the feerate histogram of the current mempool, which can react much faster, though lacks information about the rate/feerate of transactions being added. It is not used, because in the presence of diverging network policy, it may give permanently and wildly wrong results. For example, a pre-taproot node won't see taproot transactions entirely, and thus miss any feerate pressure they provide. In the other direction, If local policy is more lax than the network's, our mempool may contain unconfirmable high-fee things that incorrectly are accounted for.
* We could look at the rate and feerate of transactions entering the mempool currently, rather than only account for them when they confirm. This gives better predictive value, but suffers from the same problems as the previous point when policies differ.
* We could look at the feerate of transactions in blocks, but this is trivially gameable by miners.

I wonder if it wouldn't be possible to take the mempool-based approaches into account, but subjecting them to a sanity checks based on confirmation. More concretely:
* We can look at what percentage of high-feerate mempool transactions confirm within a reasonable period of time. If that percentage is high, it's unlikely we have a significantly diverging policy from the network's aggregate policy. If it is too low, we may want to disable mempool-based fee estimation entirely.
* We can keep a counter on transactions in the mempool that tracks how often we'd have expected it to be seen in a block, but didn't. If that counter goes too high for a certain transaction, we could exclude it from feerate calculations. This can reduce issues with too lax local policy, but not the other way around.

Even with these safeguards, I don't think it's reasonable to use as a default feerate estimate (at least not for automatic feerate decisions without human intervention, like `sendtoaddress` and friends), but it could be a separately selectable estimation mode.

This issue is the result of a discussion with @Xekyo, @achow101, @adamjonas, and @mzumsande.
Repository: PowerToys
Issue: Make restarting into non-Admin mode easier for Mouse Without Borders Device Layout
Labels: Needs-Triage

### Description of the new feature / enhancement

Either one of the following:
* Add a button on the Mouse Without Borders page near "Device Layout" that allows you to more easily restart Power Toys in non-Admin mode.
OR
* Fix Device Layout to work when started in Admin.

### Scenario when this would be used?

Power Toys wants to run in Admin mode.  There's even a switch on the main General tab that allows Power Toys to default to Admin on launch.  This makes it extremely difficult for a user to restart in non-Admin mode to rearrange devices.

### Supporting information

_No response_
Repository: rust
Issue: io::Error's Display impl should not include "(os error N)" where N is a meaningless number
Labels: T-libs-api,C-feature-request,A-io

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

For a long time, `std::io::Error`'s Display impl has rendered two pieces of information: a human-readable error message (produced by C `strerror`), and the numeric value of the OS-level error code corresponding to that error message.  The problem is that OS-level numeric error codes are not meaningful in themselves.  You have to know which OS, ported to which CPU, the message came from.  Even if you do know what OS and CPU, the number is fully redundant to the human-readable error message.  So it's just noise.

Demo:

```rust
use std::io::Error;

fn main() {
    let err = Error::from_raw_os_error(libc::ENOENT);
    println!("{}", err);
    println!("{:?}", err);
}
```

_On the computer I'm writing this issue on_, this program prints

```
No such file or directory (os error 2)
Os { code: 2, kind: NotFound, message: "No such file or directory" }
```

It would be better if the first line were just

```
No such file or directory
```

or perhaps

```
No such file or directory (ENOENT)
```

Unlike the numeric error codes, the symbolic constant names from C `errno.h` are stable across OS and CPU variation, so if you want this message to include something not subject to localization that can be dropped into a search engine, _that's_ what you should be using.

(Including the numeric code in the Debug representation is fine.)
Repository: vscode
Issue: Unable to debug extensions in Codespaces desktop
Labels: bug,debug

Steps:
* Create a codespace based on a repo that contains the code for a VS Code extension (for me it was https://github.com/TylerLeonhardt/vscode-msft-todo-unofficial with the issue)
* Open the Codespace in VS Code desktop
* Build the extension
* Run & Debug the extension

Expected:

The new window (Extension Development Host) that pops open should have the dev extension loaded

Actual:

The new window (Extension Development Host) that pops open doesn’t have the dev extension loaded
Repository: pytorch
Issue: DISABLED test_conv3d_64bit_indexing_cuda (__main__.TestConvolutionNNDeviceTypeCUDA)
Labels: module: rocm,triaged,skipped

Platforms: rocm

This test was disabled because it is failing on ROCm5.5 CI upgrade. This test is also being skipped in ROCm5.4.2 upstream CI.

Copied from: https://github.com/pytorch/pytorch/issues/104348

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @jeffdaily @sunway513 @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
Repository: vscode
Issue: Git - actions in multiroot workspace show workspaces in wrong order
Labels: bug,git,papercut :drop_of_blood:

My workspace config has folders in this order
<img width="413" alt="image" src="https://github.com/microsoft/vscode/assets/323878/b14edbe3-b7b8-4da2-b3e0-c64bdc12dca5">


I run "undo last commit" and get this
<img width="391" alt="image" src="https://github.com/microsoft/vscode/assets/323878/7b66adde-5700-4847-86f7-4b378d8fdb89">

I would like these to match so I can have workspace folders in a predictable order for all commands
Repository: go
Issue: runtime: average stack size is not a fit for every application
Labels: NeedsInvestigation,compiler/runtime

In go1.19 was introduced that stack are created basen on the historical average size. Even though this has improved the landscape for our applications, we still experience issues with some of them.

To give one real example. Let's introduce a 15k cores application. Originally the profiles were showing close to 10% cpu being consumed by stack growth. If we translate this to cores that's ~1.5k cores.

<img width="225" alt="Screenshot 2023-06-28 at 11 50 07 AM" src="https://github.com/golang/go/assets/3793727/099a5068-254c-469c-8f8e-ff2382e32cdf">

The stack usage is very low (we never exceed 16M):

<img width="387" alt="Screenshot 2023-06-28 at 11 52 19 AM" src="https://github.com/golang/go/assets/3793727/80f96b4a-39a1-441e-aa31-38a6477e8715">

After adding to our metrics to publish the runtime/metrics that exposes the initial stack size we could observe that 99% of the time the stack size is set to 2KB.

By using go:linkname we were able to expose the initial stack size global variable. So what we did was to enable "gcshrinkstackoff" and disable "adaptivestackstart", to not shrink stacks and to avoid the runtime overriding our value. 

<img width="585" alt="Screenshot 2023-06-28 at 12 38 26 PM" src="https://github.com/golang/go/assets/3793727/c35a72a8-9081-4bc1-bab8-4e8bb2102b5a">

----

<img width="347" alt="Screenshot 2023-06-28 at 12 38 14 PM" src="https://github.com/golang/go/assets/3793727/a06185ea-cbe7-4c76-a3e0-1e867b0b6390">

----

<img width="420" alt="Screenshot 2023-06-28 at 12 39 18 PM" src="https://github.com/golang/go/assets/3793727/d4d82622-6c7a-44a4-8a69-d3d607f1d9ca">


Finally we ran several experiments injecting different stack sizes:

4KB
<img width="428" alt="Screenshot 2023-06-28 at 11 58 13 AM" src="https://github.com/golang/go/assets/3793727/b74eeebe-9902-4bb5-a15f-21c28849e2be">

8KB
<img width="540" alt="Screenshot 2023-06-28 at 11 58 39 AM" src="https://github.com/golang/go/assets/3793727/3b70c024-d7e3-48d4-b49a-b79428c1f6e4">

16KB
<img width="514" alt="Screenshot 2023-06-28 at 11 59 05 AM" src="https://github.com/golang/go/assets/3793727/50984068-3b73-4a5e-824f-edcfba3c0d4a">

We decided to stop at 16KB because the gains were approaching 0, but as you can see we were able to reduce copystack by 7%.

Memory went up, but it is still reasonable. From 16MB to 50MB.
<img width="405" alt="Screenshot 2023-06-28 at 12 02 57 PM" src="https://github.com/golang/go/assets/3793727/695a86b1-515f-4475-b70d-3e493594270e">

With all that said, would it be possible for the Go runtime to expose:

- A safe way to inject our own stack size (even if it is static).
- A histogram with all the stack sizes it has seen, this would helps decide what size would gives us the best results without using too much memory.

Or do you have any idea on how to implement this more safely (not requiring private linking).
Repository: stable-diffusion-webui
Issue: [Feature Request]: drag gan- drag image manipulations, and vLLM Accelerates HuggingFace Transformers By 24x- link to codes here
Labels: enhancement,extension-request

### 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 ?

Synthesizing visual content that meets users' needs often requires flexible and precise controllability of the pose, shape, expression, and layout of the generated objects. Existing approaches gain controllability of generative adversarial networks (GANs) via manually annotated training data or a prior 3D model, which often lack flexibility, precision, and generality. In this work, we study a powerful yet much less explored way of controlling GANs, that is, to "drag" any points of the image to precisely reach target points in a user-interactive manner, as shown in Fig.1. To achieve this, we propose DragGAN, which consists of two main components including: 1) a feature-based motion supervision that drives the handle point to move towards the target position, and 2) a new point tracking approach that leverages the discriminative GAN features to keep localizing the position of the handle points. Through DragGAN, anyone can deform an image with precise control over where pixels go, thus manipulating the pose, shape, expression, and layout of diverse categories such as animals, cars, humans, landscapes, etc. As these manipulations are performed on the learned generative image manifold of a GAN, they tend to produce realistic outputs even for challenging scenarios such as hallucinating occluded content and deforming shapes that consistently follow the object's rigidity. Both qualitative and quantitative comparisons demonstrate the advantage of DragGAN over prior approaches in the tasks of image manipulation and point tracking. We also showcase the manipulation of real images through GAN inversion.
https://github.com/XingangPan/DragGAN


Meet vLLM: An Open-Source LLM Inference And Serving Library That Accelerates HuggingFace Transformers By 24x
https://www.marktechpost.com/2023/06/24/meet-vllm-an-open-source-llm-inference-and-serving-library-that-accelerates-huggingface-transformers-by-24x/?fbclid=IwAR15kAGDoP7qeE4uyeZz3GQ6vMNKxYDR9eBl681v0ReeIQ1lckOLPjGWVG4

### Proposed workflow

for general ui improvements

### Additional information

not a coder sorry
Repository: pytorch
Issue: FakeTensor can't handle meta impls that perform device conversion
Labels: triaged,module: fakeTensor

Minified after finding an internal example from @suo.

```
import torch
from torch.fx.experimental.proxy_tensor import make_fx

def foo_meta(x):
    return x.to(device='cpu')

lib = torch.library.Library("test", "FRAGMENT")
lib.define("foo(Tensor x) -> Tensor")
lib.impl("test::foo", foo_meta, "Meta")

def f(x):
    return torch.ops.test.foo.default(x)

x = torch.ones(4, device='cuda')
fx_g = make_fx(f, tracing_mode='symbolic')(x)
print(fx_g.code)
```

Fails with:
```
  File "/scratch/hirsheybar1/work/pytorch/tmp3.py", line 6, in foo_meta
    return x.to(device='cpu')
  File "/scratch/hirsheybar1/work/pytorch/torch/_decomp/decompositions.py", line 1646, in _to_copy
    x = torch._prims.device_put(x, device)
  File "/scratch/hirsheybar1/work/pytorch/torch/_ops.py", line 429, in __call__
    return self._op(*args, **kwargs or {})
  File "/scratch/hirsheybar1/work/pytorch/torch/_prims/__init__.py", line 2069, in _device_put_meta
    return TensorMeta(a, device=utils.canonicalize_device(device))
  File "/scratch/hirsheybar1/work/pytorch/torch/_prims/__init__.py", line 258, in TensorMeta
    return torch.empty_strided(shape, strides, dtype=dtype, device=device)
RuntimeError: /scratch/hirsheybar1/work/pytorch/build/aten/src/ATen/RegisterCPU.cpp:5200: SymIntArrayRef expected to contain only concrete integers
```

FakeTensor treads a fine line by trying to ensure that any operators that run underneath that dispatch to meta. It looks like that doesn't work properly when performing device conversion ops inside of your meta function, like `.to()`.