sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: AudioStreamPlayer can play sound from a negative position
Labels: bug,discussion,topic:audio

### Tested versions

Reproducible in: 4.3.dev.official [df78c06]

### System information

Linux Mint 21.2 (Victoria) - X11 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3050 Laptop GPU () - 11th Gen Intel(R) Core(TM) i5-11400H @ 2.70GHz (12 Threads)

### Issue description

If call the `play` method of `AudioStreamPlayer`, there will be an incorrect loud sound. 

### Steps to reproduce

In `AudioStreamPlayer`, call the `play` method with a negative position. 

Example:
```
$AudioStreamPlayer.play(-1)
```

### Minimal reproduction project (MRP)

[AudioBug.zip](https://github.com/godotengine/godot/files/14561911/AudioBug.zip)
Repository: deno
Issue: Tests that send signals don't work on Windows
Labels: tests

Originally spotted in https://github.com/denoland/deno/pull/22757#discussion_r1518314083.

Many tests, such as the [process.off signal](https://github.com/denoland/deno/blob/670e9a9be78e15c2800541aeba62d7cba6a4d58d/tests/unit_node/process_test.ts#L239) test, involve sending signals to processes via `ChildProcess.kill` or `Deno.kill`. It turns out that windows doesn't really have an easy programmatic way of sending "signals", and so our implementations actually just [kill](https://github.com/denoland/deno/blob/670e9a9be78e15c2800541aeba62d7cba6a4d58d/runtime/ops/process.rs#L880-L902) the process. This means that a lot of the signal handling code for windows lacks unit tests.
Repository: TypeScript
Issue: Allow type narrowing to be specified as always-on or always-off
Labels: Suggestion,Awaiting More Feedback

### 🔍 Search Terms

type narrowing of functions, asserts on getters

### ✅ Viability Checklist

- [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [X] This wouldn't change the runtime behavior of existing JavaScript code
- [X] This could be implemented without emitting different JS based on the types of the expressions
- [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

Right now, properties of objects can _always_ be narrowed, whereas functions can _never_ be narrowed. As a developer, I would like to specify when functions can be narrowed, and when object properties _can't_ be narrowed.

### 📃 Motivating Example

Consider this example:
```ts
export const model = {
  get value() {
    return Math.random() > 0.5 ? 'Hello' : undefined
  },
  getValue() {
    return model.value
  }
}

if (model.value) {
  console.log(model.value.toLowerCase())
}

if (model.getValue()) {
  console.log(model.getValue().toLowerCase())
}
```
In the TypeScript playground, you can see that even though these code paths are identical in terms of output and function calls, one is narrowed and one is not. TypeScript always assumes that properties are always stable in their values between calls, and assumes that functions are always in-stable in their calls.

You can see this in the TypeScript error which does not error for the property, even though it should.



### 💻 Use Cases

1. What do you want to use this for?

I'm more concerned with the stable function case than the instable property object case. I'm building a Knockout-like observable library that lays on top of Vue. It works fine / perfectly in the Vue ecosystem, however it's TypeScript that doesn't behave here. `foo.value` is always type-narrowed, whereas `foo()` is never type-narrowed, even though I can guarantee its stability between calls. Because this behavior in TypeScript is automatic (as far as I know?), there's no way to specify which function calls are stable (and can be narrowed) and which ones are not.

2. What shortcomings exist with current approaches?

You can type narrow by assigning the returned value of the function to another variable. However, in Vue, this approach is limited when binding to templates, where `v-if` will not type-narrow a functional getter.

3. What workarounds are you using in the meantime?

A very clumsy workaround is using a Vue `computed()`, which then also type-narrows.
Repository: material-ui
Issue: [system][icons] why @emotion/react and @emotion/styled are optional dependencies?
Labels: package: system,package: icons

### Steps to reproduce

1. use `@mui/icons-material` in a package without `@emotion/react` `@emotion/styled`
2. fail to compile 

### Current behavior

Why are `@emotion/react` and `@emotion/styled` listed as optional in package.json? They are direct dependency of `StyledEngineProvider`, which is exported from MUI System

### Expected behavior

_No response_

### Context

_No response_

### Your environment

_No response_

**Search keywords**: StyledEngineProvider, @emotion/react, @emotion/styled
Repository: PowerToys
Issue: Touch-screen and Keyboard Lock Toggle
Labels: Idea-New PowerToy,Needs-Triage

### Description of the new feature / enhancement

Would like a quick Touch-screen Lock and Keyboard Lock to allow cleaning of laptop or just in general locking for passing around laptop in presentation or other. This would mean only the touchpad or mouse would be active. Could unlock on Windows Start or Multiple distant key combo if there is some emergency. This would allow locking one or both Touch-screen monitor and keyboard.

### Scenario when this would be used?

- When cleaning laptop screen.
- When using laptop for presentation or demonstration (people like to touch screen/keys)

### Supporting information

This is a feature that I have not seen on laptops previously and currently dont have one on my 2024 Lenovo laptop.
Repository: pytorch
Issue: add scatter to functional collectives 
Labels: oncall: distributed,triaged,pt_distributed_rampup

This task is to:
- add scatter to functional collectives/
- add scatter to inductor codegen

one trial we can follow https://github.com/pytorch/pytorch/pull/115263

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @fduwjj @wz337 @tianyu-l @wconstab @yf225 @chauhang
Repository: go
Issue: proposal: net: add ErrRetryableAcceptError
Labels: Proposal

### Proposal Details

Proposal: Add the following to the `net` package:

```
// ErrRetryableAcceptError indicates a Listener.Accept error may be transient,
// and that a future call to Accept may succeed. This error is usually wrapped
// in another error, and should be tested for with errors.Is(err, ErrRetryableAcceptError).
//
// Accept errors corresponding to the errno values EMFILE, ENFILE, ECONNRESET, and ECONNABORTED
// match this error.
var ErrRetryableAcceptError = errors.New("ErrRetryableAcceptError")
```

Implementation will be to add an `Is` method to `net.OpError` which performs the appropriate check.

Background/rationale:

Some of the errors returned by [`net.Listener.Accept`](https://pkg.go.dev/net#Listener.Accept) are potentially transient: While they indicate that the `Accept` call has failed, a future call may succeed.

Examples include:
* `EMFILE`: the process is out of file descriptors
* `ENFILE`: the system is out of file descriptors
* `ECONNRESET` and `ECONNABORTED`: see #6163

A server which calls `Accept` may want to ignore all these errors and call `Accept` again, probably after some backoff period. One of the uses for the deprecated `net.Error.Temporary` method is to check for these conditions, since we report all of the above as "temporary" errors.

As an example, [`net/http.Server`](https://go.googlesource.com/go/+/refs/tags/go1.22.1/src/net/http/server.go#3260) uses `net.Error.Temporary` to retry potentially-transient `Accept` errors.

With the deprecation of `net.Error.Temporary` there is no non-deprecated way to test for these conditions. `Temporary` was deprecated, not because it isn't useful to test for retryable `Accept` errors but because the `Temporary` condition was ill-defined for many other errors, conflated transient errors with timeouts, and was just generally misunderstood. (See #45729.) I propose adding `ErrRetryableAcceptError` to provide a focused and reasonable well-defined replacement for the specific use case of `Accept` loops.

As an alternative, it might be nice if `Accept` just worked and didn't require the user to check for transient errors. However, that would require changing long-established behavior, and defining correct handling of `EMFILE` (for one example) seems challenging. This proposal is less ambitious in scope.

Further references:
* #66208 
* https://groups.google.com/g/golang-nuts/c/-JcZzOkyqYI/m/xwaZzjCgAwAJ
Repository: ollama
Issue: Display latest version on ollama.com/download
Labels: ollama.com

I would be helpful to have the latest version of Ollama displayed prominently on the download page, and the download button on the homepage like `[Download Ollama (v1.23.4)]`.
Repository: yt-dlp
Issue: Extractions and requests met with "Too Many Requests" (HTTP 429) should be reattempted, instead of skipped.
Labels: enhancement,triage,core:extractor

### DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

- [X] I understand that I will be **blocked** if I *intentionally* remove or skip any mandatory\* field

### Checklist

- [X] I'm requesting a feature unrelated to a specific site
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I have **updated yt-dlp to nightly or master** ([update instructions](https://github.com/yt-dlp/yt-dlp#update-channels))
- [X] I've searched [known issues](https://github.com/yt-dlp/yt-dlp/issues/3766) and the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues **including closed ones**. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Provide a description that is worded well enough to be understood

As seen in [gallery-dl](https://github.com/mikf/gallery-dl) issue [#4910](https://github.com/mikf/gallery-dl/issues/4910), any HTTP 429 error gets treated as an extraction failure, and gives up trying to extract it again. The same program automatically handles such errors, and waits until the rate limit resets. yt-dlp however, does not.

yt-dlp should treat these errors in either two ways:
- Return an Error object (perhaps something similar to [this](https://urllib3.readthedocs.io/en/stable/reference/urllib3.exceptions.html#urllib3.exceptions.ResponseError)?)
- Automatically wait until the rate limit resets, or keep trying until a 429 error is not returned

### Provide verbose output that clearly demonstrates the problem

- [ ] Run **your** yt-dlp command with **-vU** flag added (`yt-dlp -vU <your command line>`)
- [ ] If using API, add `'verbose': True` to `YoutubeDL` params instead
- [ ] Copy the WHOLE output (starting with `[debug] Command-line config`) and insert it below

### Complete Verbose Output

_No response_
Repository: vscode
Issue: Report Issue dialog does not work for the Jupter extension
Labels: bug,issue-reporter

<!-- Please search existing issues to avoid creating duplicates. -->

Followed the [helpful instructions](https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions) for submitting a bug report. Was impressed by the Report Issue feature mentioned. This should make things easier! But, alas, the "Preview on Github" button doesn't actually do anything useful.

This may be an integration or configuration issue with how the Jupyter extension project is connected up to the generic VS Code Report Issue feature.

## Environment data

About output:

    Version: 1.87.1
    Commit: 1e790d77f81672c49be070e04474901747115651
    Date: 2024-03-06T00:21:07.287Z
    Electron: 27.3.2
    ElectronBuildId: 26836302
    Chromium: 118.0.5993.159
    Node.js: 18.17.1
    V8: 11.8.172.18-electron.0
    OS: Linux x64 5.15.0-94-generic

-   Jupyter Extension version (available under the Extensions sidebar): v2024.2.0
-   Python Extension version (available under the Extensions sidebar): v2024.2.1
-   Python and/or Anaconda version: 3.10.12
-   Type of virtual environment used (N/A | venv | virtualenv | conda | ...): None
-   Jupyter server running: Local 

## Expected behaviour

The Report Issue dialog, when the "Preview on Github" button is pressed, should preview on Github as a new issue report.

## Actual behaviour

The [new issue](https://github.com/microsoft/vscode-jupyter/issues/new/choose) page appears without any of the information I provided.

## Steps to reproduce:

1. Follow [the instructions](https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions) to use the Report Issue feature.
2. Select File On: An Extension
3. Select Extension: Jupyter
4. Fill in the details of the report.
5. Click the "Preview on Github" button.
6. End up on the [new issue](https://github.com/microsoft/vscode-jupyter/issues/new/choose) with none of the information copied into a new issue.
7. Start all over again and copy the information out of the Report Issue dialog into a manually-created issue.

## Logs

No useful output could be found in any of the obvious logs.
Repository: pytorch
Issue: [BUG] when invoking torch::manul_seed() program crashed in libtorch 2.2.1
Labels: high priority,module: crash,module: windows,module: cpp,triaged

### 🐛 Describe the bug

## code:
```c++
#include "torch/torch.h"
int main() {
    torch::manual_seed(514);
    auto heatmaps = torch::rand({1,25,64,48});
    std::cout << heatmaps << std::endl;
}
```
As the screeshot below, it was caused by accquiring lock in `ATen/Context.h:451`. According to common sense, the cpu generator was running on main thread and shouldn't has locking issue cause no others had the race, weird enough.

![image](https://github.com/pytorch/pytorch/assets/33080670/916c8071-c9ac-4a6d-a87a-8252b0f9c729)
![image](https://github.com/pytorch/pytorch/assets/33080670/21907a7f-1959-4bc7-8f1a-260a3ef4ea8f)

## more info
Here's my nvcc command:
```bash
nvcc -std=c++17 -g -G -o test_heatmap.exe test_heatmap.cpp -ltorch -ltorch_cpu -lc10
```

Those libtorch-related dynamic libraries are loaded.
```bash
Loaded 'G:\development\libtorch\lib\torch_cpu.dll'. Module was built without symbols.
Loaded 'G:\development\libtorch\lib\c10.dll'. Module was built without symbols.
Loaded 'G:\development\libtorch\lib\fbgemm.dll'. Module was built without symbols.
Loaded 'G:\development\libtorch\lib\libiomp5md.dll'. 
Loaded 'G:\development\libtorch\lib\uv.dll'. Module was built without symbols.
Loaded 'G:\development\libtorch\lib\asmjit.dll'. Module was built without symbols.
Exception thrown at 0x00007FF66DEF9FBC in test_heatmap.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
```
### Versions

```bash
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 10 Pro
GCC version: (x86_64-posix-seh-rev0, Built by MinGW-Builds project) 13.2.0
Clang version: Could not collect
CMake version: version 3.18.4
Libc version: N/A

Python version: 3.11.5 | packaged by Anaconda, Inc. | (main, Sep 11 2023, 13:26:23) [MSC v.1916 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.19045-SP0
Is CUDA available: N/A
CUDA runtime version: 11.3.58
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1050
Nvidia driver version: 545.84
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

CPU:
Architecture=9
CurrentClockSpeed=2800
DeviceID=CPU0
Family=198
L2CacheSize=1024
L2CacheSpeed=
Manufacturer=GenuineIntel
MaxClockSpeed=2801
Name=Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
ProcessorType=3
Revision=

Versions of relevant libraries:
[pip3] No relevant packages
[conda] cudatoolkit               11.3.1               h59b6b97_2    defaults
```

cc @ezyang @gchanan @zou3519 @kadeng @peterjc123 @mszhanyi @skyline75489 @nbcsm @vladimir-aubrecht @iremyux @Blackhex @cristianPanaite @jbschlosser
Repository: storybook
Issue: [Bug]: v8 error when props type uses an indexed access type
Labels: bug,react,has workaround,docgen

### Describe the bug

Error `Cannot read properties of undefined (reading 'map')` or `Unknown: [object Object]` when using an indexed access type of object or array

### To Reproduce

https://github.com/Waynenabors/default-ts/commit/d674f91ab22f31f004ba0fef1de1071e99cc3082

### System

```bash
System:
    OS: macOS 14.2.1
    CPU: (10) arm64 Apple M1 Max
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.12.1 - ~/.asdf/installs/nodejs/18.12.1/bin/node
    npm: 8.19.2 - ~/.asdf/plugins/nodejs/shims/npm <----- active
  Browsers:
    Chrome: 116.0.5845.187
    Safari: 17.2.1
  npmPackages:
    @storybook/addon-essentials: ^8.0.0 => 8.0.0 
    @storybook/addon-interactions: ^8.0.0 => 8.0.0 
    @storybook/addon-links: ^8.0.0 => 8.0.0 
    @storybook/blocks: ^8.0.0 => 8.0.0 
    @storybook/react: ^8.0.0 => 8.0.0 
    @storybook/react-vite: ^8.0.0 => 8.0.0 
    @storybook/test: ^8.0.0 => 8.0.0 
    @storybook/test-runner: ^0.16.0 => 0.16.0 
    chromatic: ^11.0.7 => 11.0.7 
    storybook: ^8.0.0 => 8.0.0
```


### Additional context

_No response_
Repository: pytorch
Issue: Look at gather + gemv performance.
Labels: module: performance,triaged,oncall: pt2,upstream triton

### 🚀 The feature, motivation and pitch

Motivated by https://www.thonking.ai/p/short-supporting-mixtral-in-gpt-fast, `gather + gemv` is the primary kernel driving mixtral perf. See the generated code here: https://pastebin.com/Hw7QEQps

Here's a microbenchmark
```python
import torch
from torch import nn
import torch.nn.functional as F
import torch.autograd as autograd
torch.set_default_device('cuda')
import torch._inductor.config

torch._inductor.config.triton.unique_kernel_names = True
torch._inductor.config.coordinate_descent_tuning = True
torch._inductor.config.assert_indirect_indexing = False

E = 8
dtype = torch.int8 # change this to bfloat16 for bfloat16 benchmarking
for D in [1024, 2048, 4096, 8192, 16384]:
    def bench(f, name=None, iters=1000, warmup=5, display=True, profile=False):
        import time
        from triton.testing import do_bench

        for _ in range(warmup):
            f()
        if profile:
            with torch.profiler.profile() as prof:
                f()
            prof.export_chrome_trace(f"{name if name is not None else 'trace'}.json")

        us_per_iter = do_bench(lambda: f())*1000
        print(f"{name}: {(1e6/us_per_iter) * 2 * D * D * dtype.itemsize / 1e9} GB/s")

        return 0

    def cuda_indexing(W, score_idxs, x):
        return W[score_idxs].to(x.dtype) @ x

    W = torch.randn(E, D, D).to(dtype=dtype)
    x = torch.randn(D, dtype=torch.bfloat16)
    score_idxs = torch.tensor([3, 5])

    compiled_cuda = torch.compile(cuda_indexing, dynamic=False)
    print(f"D={D}")
    bench(lambda: compiled_cuda(W, score_idxs, x), "compiled CUDA indexing")
```

cc: @manman-ren


### Alternatives

_No response_

### Additional context

_No response_

cc @msaroufim @ezyang @anijain2305 @chauhang @penguinwu @bertmaher @int3 @davidberard98 @nmacchioni @chenyang78 @embg @bdhirsh @zou3519
Repository: vscode
Issue: Create Compound Debug Launches Dynamically
Labels: feature-request,debug

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
I'm looking for a way to create a compound launch, but it does not require all the `launch.json` configurations to be present or required upfront.

The scenario is where a user will start a debug session, and then later starts another debug session and wants to group it with the first debug session. These other debug session can happen N times and do not have a parent child relationship. The idea would be to have a vscode.debug.* API that has a debug sessions manager that would synchronize the state of all the sessions that are in a particular group.

These processes would pause, continue, stop at the same time if even one processes hits a breakpoint.

Being able to control this group of processes's pause, stop, continue, and terminate happening at once is asked in this issue: https://github.com/microsoft/vscode/issues/137953
Repository: TypeScript
Issue: TS: duplicated imports in this case
Labels: Needs Investigation,Rescheduled

Steps to Reproduce:

1.  in our sources have a TS file that uses `import { watchFile } from 'fs';`
2. somewhere begin to use `unwatchFile`
3. use quick fix to add import
4. pick "Add import from 'fs'"

=> 🐛 you get a second import

```ts
import { watchFile } from 'fs';
import { unwatchFile } from 'fs';
```
Repository: kubernetes
Issue: Soft eviction of pods with long grace periods blocks hard evictions when under resource pressure
Labels: kind/bug,sig/node,priority/important-longterm,triage/accepted

### What happened?

When kubelet detects that it's under resource pressure, it first attempts to do soft evictions, until the hard eviction threshold is reached. When a pod is soft-evicted, it respects the configured max pod grace period seconds, and until the pod has shut down, kubelet will not attempt to soft OR hard evict another pod, even if the hard eviction threshold is reached.

As a result, one pod taking a long time to shut down can cause kubelet to run out of resources. From [this comment](https://github.com/kubernetes/kubernetes/blob/016d8b11ae250ca933fe83de312bbe7c4945cd20/pkg/kubelet/eviction/eviction_manager.go#L405) and [this comment](https://github.com/kubernetes/kubernetes/blob/016d8b11ae250ca933fe83de312bbe7c4945cd20/pkg/kubelet/eviction/eviction_manager.go#L603) this behavior seems to be by design

In our case, we saw one soft eviction take 7 hours to complete, and meanwhile, resources usage kept climbing without any automation trying to save the node. Had other pods gotten soft evicted while this pod shut down, this would not be an issue. Manual intervention prevented it from reaching hard-eviction thresholds, but had that not happened, this would have entirely exhausted the node with no automated action

### What did you expect to happen?

I would expect that kubelet would keep trying to soft evict other pods if one is taking a long time to shut down. Or at the very least, start hard evicting pods if the hard eviction threshold is reached. It could also hard-evict the pod that was soft-evicted but is taking a long time to shut down.

### How can we reproduce it (as minimally and precisely as possible)?

1. Create two pods that get scheduled to the same node that have emptyDir volumes and a prestop hook that just sleeps forever
1. Start filling up those emptyDir volumes with `dd` until soft eviction threshold is reached
1. Watch as kubelet soft-evicts one pod
1. Continue filling up the emptyDir volumes with `dd`
1. Kubelet will not evict (hard or soft) even as the resource is totally exhausted

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
Client Version: v1.27.11
Kustomize Version: v5.0.1
Server Version: v1.27.11
```

</details>


### Cloud provider

<details>
aws
</details>


### OS version

<details>

AlmaLinux9/CentOS Stream 8

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>
cri-o 1.27.0 and containerd 1.6.21 (we use a mix of both)
</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>