sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: Async iteration over tcp stream produces more chunks
Labels: net,stream

### Version

20.12, 22

### Platform

Microsoft Windows NT 10.0.19045.0 x64

### Subsystem

_No response_

### What steps will reproduce the bug?

Below are two examples of code that read data from a TCP stream. 
In the first example, data is read using the for-await iteration approach, resulting in 2731 chunks. In contrast, the latest approach employs the stream.on('data') listener and retrieves 1835 chunks.
 
 For-await listing:
 ```js
import { createServer, Socket } from 'node:net'
import { Readable } from 'node:stream'

const server = createServer(socket => {
  const stream = Readable.from(numbers())
  stream.pipe(socket)
})
server.listen(3000, '127.0.0.1')

const client = new Socket()
client.connect(3000, '127.0.0.1')

const data = []
for await (const chunk of client) data.push(chunk)
console.log(data.length) // 2731 chunks
// console.table(data.map(({ length }) => length))
console.log(Buffer.concat(data).length)
client.destroy()
server.close()

async function* numbers (max = 10_000_000) {
  for (let i = 0; i < max; i++) yield i.toString()
}

```

event-based listing:
```js
import { createServer, Socket } from 'node:net'
import { Readable } from 'node:stream'

const server = createServer(socket => {
  const stream = Readable.from(numbers())
  stream.pipe(socket)
})
server.listen(3000, '127.0.0.1')

const client = new Socket()
client.connect(3000, '127.0.0.1')

const data = []
client.on('data', chunk => data.push(chunk))
client.on('end', () => {
  console.log(data.length) // 1835 chunks
  // console.table(data.map(({ length }) => length))
  console.log(Buffer.concat(data).length)
  client.destroy()
  server.close()
})

async function* numbers (max = 10_000_000) {
  for (let i = 0; i < max; i++) yield i.toString()
}

```

### How often does it reproduce? Is there a required condition?

Always

### What is the expected behavior? Why is that the expected behavior?

Both for-await and on('data') should produce equal number of chunks.

### What do you see instead?

for-await produce more chunks

### Additional information

_No response_
Repository: PowerToys
Issue: Enlarge Expansion Menu Items from Dropdown Menus
Labels: Needs-Triage

### Description of the new feature / enhancement

When a user puts their mouse on a dropdown menu item that itself has a sub-menu (ie: in Notepad.exe, the VIEW dropdown menu has an item called "ZOOM" which itself has three submenu items: Zoom In, Zoom Out, and Restore Default Zoom.) I would like to suggest that the primary menu (in this case, the "ZOOM" menu) ENLARGE as the user is on it and moving their mouse to the right. This would allow people who have hand tremors a wider margin to "shake" their mouse before the menu item they are trying to navigate gets deselected.

### Scenario when this would be used?

People with problems moving their mouse/trackball fluidly, people with Parkinsons, etc... It would also be a big benefit where some menu items themselves are HUGE! For example, if a menu item is the name of a file (with a path)...
Recent files ->
-> C:\Users\AUser\Documents\SomeProgramImUsing\SomeFileISaved v1 ->
-> C:\Users\AUser\Documents\SomeProgramImUsing\SomeFileISaved v2 ->
-> C:\Users\AUser\Documents\SomeProgramImUsing\SomeFileISaved v3 ->
-> C:\Users\AUser\Documents\SomeProgramImUsing\SomeFileISaved v4 ->
and maybe those sub-menu items are specific components IN the file. (This happens sometimes in software where the "save file" contains subfiles, like a 3d program where the "recent" file is a scene, and the subfile is the scene's 3d objects.)



### Supporting information

This time, I made two videos! :)
![Dropdown Drag - Jittery](https://github.com/microsoft/PowerToys/assets/13816091/54fd459b-19b6-4b46-83e1-f3dc48f16364)
![Dropdown Drag - Unjittery](https://github.com/microsoft/PowerToys/assets/13816091/dcc5ee90-e544-4455-81d2-18fdfe240a4d)

The amount of dropdown (whether it's just another 5 pixels for a minor margin, or a full 50 pixels for a huge margin of shake) could be left up to the user via settings or in the Registry.

Also, this feature could be activated based on either time that the mouse is on the menu (ie: trigger after 100ms, 50ms, 1000ms, etc...) OR it could be triggered based on once the computer has determined that the mouse is moving more RIGHT than anywhere else (within a specified amount of time.)

One final no
Repository: godot
Issue: changing root type of inherited scene breaks reference without generating a warning
Labels: bug,enhancement,topic:core,topic:editor

### Tested versions

- reproducible in 4.2.1 stable

### System information

nixos unstable

### Issue description

When changing the root type of a inherited scene, it breaks the inheritance without generating a warning. This causes the inherited nodes to no longer be displayed yellow in the editor and it causes resources like 3D-models to be stored in the scene file, witch is undesirable when using git.

Godot now gives warnings to prevent certain actions that break inheritance, like renaming objects in the scene tree.

This issue could be resolved by adding that safeguard for this case too.

I would however much prefer being able to change the structure of inherited scenes a bit, as this is the only workaround I know to having to use .res files.
(.res files right now are unusable with git due to #68672)

### Steps to reproduce

1. Add a 3D Model to your Godot Project (I tested this with .gltf files)
2. Create a inherited scene from a 3D Model
3. change the type of the root node

### Minimal reproduction project (MRP)

N/A
Repository: flutter
Issue: Gather Swift Package Manager analytics
Labels: platform-ios,tool,platform-mac,P2,team-ios,triaged-ios

Some analytics we may want to consider gathering:
* How many users have Swift Package Manager enabled
* How many users are using [only Swift Packages vs only CocoaPods vs both](https://github.com/flutter/flutter/blob/3e399c1578b3f1199c2cb068d808738ad704698c/packages/flutter_tools/lib/src/macos/darwin_dependency_management.dart#L86-L97)
Repository: pytorch
Issue: [export] linalg ops after core aten decomposition
Labels: module: decompositions,oncall: export

### 🐛 Describe the bug

linalg ops are still in the graph after the default core aten decomposition. Since exported graph should only contain core aten ops, should we add the linalg decomp to the default decomp table?

repro
```
import torch

class M(torch.nn.Module):
    def forward(self, x):
        return torch.linalg.vector_norm(x)
    
ep = torch.export.export(M(), (torch.rand(3,3),))
print(ep) # linalg_vector_norm in the graph
ep = ep.run_decompositions(torch._decomp.get_decompositions([torch._ops.ops.aten.linalg_vector_norm]))
print(ep) # need to explicitly decomp the linalg ops
```

cc @SherlockNoMad @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4 @qihqi

### Versions

torch                     2.4.0a0+git9466335
Repository: flutter
Issue: Proposal for safer `setState`
Labels: framework,c: proposal,P3,team-framework,triaged-framework

### Use case

I frequently need to write code like:

```dart
  onTap: loadingProfileView
      ? null
      : () async {
          setState(() {
            loadingProfileView = true;
          });
          try {
            await openOtherUserProfileView(
              userId: profileThumbInfo.userId,
            );
          } finally {
            safeSetState(() {
              loadingProfileView = false;
            });
          }
        },
```

I have to use a safer version of `setState`, which I call `safeSetState`, after the async delay, because the widget may not be mounted, which causes an exception to be thrown.

### Proposal

Here is my code for `safeSetState`:

```dart
import 'package:flutter/material.dart';
import 'package:flutter/scheduler.dart';

extension SafeUpdateState on State {
  void safeSetState(void Function() updaterFunction) {
    void callSetState() {
      // Can only call setState if mounted
      if (mounted) {
        // ignore: invalid_use_of_protected_member
        setState(updaterFunction);
      }
    }

    if (SchedulerBinding.instance.schedulerPhase ==
        SchedulerPhase.persistentCallbacks) {
      // Currently building, can't call setState -- add post-frame callback
      SchedulerBinding.instance.addPostFrameCallback((_) => callSetState());
    } else {
      callSetState();
    }
  }
}
```

In general, it would be great if `setState` could be called from anywhere without negative consequences. (For this reason, I also made it possible to call `safeSetState` during `build`, even though I know that is bad practice.)

Could the behavior of the regular `setState` be updated to handle these cases, e.g. to simply fail silently if the widget is no longer mounted?
Repository: kubernetes
Issue: Improve the jitter value for kubelet's serviceAccountToken projected volume source
Labels: kind/bug,sig/auth,triage/accepted

The current jittering logic in [kubelet token_manager](https://github.com/kubernetes/kubernetes/blob/dd68c5f2409fec7176e6172d6f9d97bd6447c4da/pkg/kubelet/token/token_manager.go#L42) refreshes the token once it has 20% of its lifetime remaining, with 10 seconds of jitter.

Experimentally, this doesn't seem to be enough to really blunt spikes of refresh requests that come from many workloads having a synced refresh.  This can occur when:

* A large deployment is scaled up.  All the new replicas will have synced-up refresh traffic.
* A kubelet restarts.  Because kubelet only holds the tokens in an in-memory cache, it will need to acquire new tokens for all pods on the node after it restarts.  After that, all of the pods will have synced-up refresh traffic.

As an example, here's serviceaccount/token API traffic from a real cluster.  Note how there is a repeating spike every 48 minutes, which is what we would expect from the "refresh after 80%" logic, and the default setting of token lifetime for 1 hour.  Effective jittering logic would be noticeably smoothing these peaks.

We should increase the `maxJitter` value.  Perhaps 5 minutes would be a good value.

![image](https://github.com/kubernetes/kubernetes/assets/1017202/133a6c5c-5a6b-4ad1-a1e8-ffb29fae3059)

/sig auth
/kind bug
Repository: rust
Issue: Suboptimal error message when matching on a tuple struct using a private constructor
Labels: A-diagnostics,T-compiler

### Code

```Rust
pub mod foo {
    pub struct Foo(u8);
}

pub fn bar(foo: Option<foo::Foo>) {
    match foo {
        // Some(foo::Foo{..}) => println!("Foo"),
        Some(foo::Foo(..)) => println!("Foo"),
        None => println!("No Foo"),
    }
}
```


### Current output

```Shell
Compiling playground v0.0.1 (/playground)
error[E0603]: tuple struct constructor `Foo` is private
 --> src/lib.rs:8:19
  |
2 |     pub struct Foo(u8);
  |                    -- a constructor is private if any of the fields is private
...
8 |         Some(foo::Foo(..)) => println!("Foo"),
  |                   ^^^ private tuple struct constructor
  |
note: the tuple struct constructor `Foo` is defined here
 --> src/lib.rs:2:5
  |
2 |     pub struct Foo(u8);
  |     ^^^^^^^^^^^^^^^^^^^
help: consider making the field publicly accessible
  |
2 |     pub struct Foo(pub u8);
  |                    +++

For more information about this error, try `rustc --explain E0603`.
error: could not compile `playground` (lib) due to 1 previous error
```


### Desired output

```Shell
Compiling playground v0.0.1 (/playground)
error[E0603]: tuple struct constructor `Foo` is private
 --> src/lib.rs:8:19
  |
2 |     pub struct Foo(u8);
  |                    -- a constructor is private if any of the fields is private
...
8 |         Some(foo::Foo(..)) => println!("Foo"),
  |                   ^^^ private tuple struct constructor
  |
note: the tuple struct constructor `Foo` is defined here
 --> src/lib.rs:2:5
  |
2 |     pub struct Foo(u8);
  |     ^^^^^^^^^^^^^^^^^^^
help: consider making the field publicly accessible
  |
2 |     pub struct Foo(pub u8);
  |                    +++
help: consider matching via `{ .. }` braces instead of the constructor
  |
8 |         Some(foo::Foo { .. }) => println!("Foo")
  |                       ++++++

For more information about this error, try `rustc --explain E0603`.
error: could not compile `playground` (lib) due to 1 previous error
```


### Rationale and extra context

I've used Rust for a while, and I just discovered that this is an option that lets you match on tuple structs with private fields. It would be great if the compiler could recommend this as a solution.

### Other cases

```Rust
If the `foo::Foo` comes from an external dependency, it does not suggest making the field publicly accessible (makes sense, since you likely can't change the dependency), but no suggestions are provided. I think it's more important to include my proposed new help text in that case, so a solution is provided, but still net beneficial in the above case.
```


### Rust Version

```Shell
Using [the Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021)'s current nightly release:

1.80.0-nightly (2024-04-29 a8a1d3a771850e1e364e)

(sorry, I don't know how to get the playground to show the full verbose version output)
```


### Anything else?

_No response_
Repository: pytorch
Issue: Profiler Kineto Config:  Warning: Failed to recover relationship between all profiler and kineto events: 51361 vs. 0  reassociated. (function reassociate)
Labels: oncall: profiler

### 🐛 Describe the bug

when enabling `kineto__tensor_core_insts` or `dram__bytes_read.sum`, the pytorch profiler outputs this warning and the trace becomes unusable. I have even tried adding the following profiler config below to a sample toy model and still outputs this error
```python
 Warning: Failed to recover relationship between all profiler and kineto events: 51361 vs. 0  reassociated. (function reassociate)
```

i see this warning msg comes from this function but no obvious how to debug it
https://github.com/pytorch/pytorch/blob/ca0f070065e8bf4575107ccdecd6785dea6d9010/torch/csrc/profiler/collection.cpp#L943

## reprod

```python
from torch.profiler import profile, schedule, tensorboard_trace_handler

tracing_schedule = schedule(skip_first=5, wait=5, warmup=2, active=2, repeat=1)
trace_handler = tensorboard_trace_handler(dir_name=f"./trace/", worker_name=f"rank_{int(os.environ['LOCAL_RANK'])}")

with torch.profiler.profile(
        activities=[torch.profiler.ProfilerActivity.CUDA, torch.profiler.ProfilerActivity.CPU],
        schedule = tracing_schedule,
        on_trace_ready = trace_handler,
        profile_memory = True,
        record_shapes = True,
        with_stack = True,
        experimental_config=torch.profiler._ExperimentalConfig(
            profiler_metrics=[
                "kineto__tensor_core_insts",
                "dram__bytes_read.sum",
            ],
            profiler_measure_per_kernel=False
        ),
    ) as prof:
```

### Versions

torch==2.3.0
NVIDIA Driver: 535
HGX H100 SXM

cc @robieta @chaekit @aaronenyeshi @guotuofeng @guyang3532 @dzhulgakov @davidberard98 @briancoutinho @sraikund16 @sanrise
Repository: ollama
Issue: Support IPEX-LLM
Labels: model request

Will add IPEX-LLM support default
Repository: pytorch
Issue: H100 Max Autotune Compilation Significantly Slower than A100
Labels: triaged,oncall: pt2,module: inductor

### 🐛 Describe the bug

Repro:

```
import torch
from torch import device

def forward(self, primals_1: "bf16[9717, 128]", primals_2: "bf16[9717, 128]", primals_3: "bf16[9717, 128]", primals_4: "bf16[9717, 128]", primals_5: "bf16[9717, 128]", primals_6: "bf16[9717, 128]", primals_7: "bf16[9717, 128]", primals_8: "bf16[9717, 128]", primals_9: "bf16[9717, 128]", primals_10: "bf16[512, 1152]"):
    # File: /dev/shm/uid-0/90dc6b0c-seed-nspid4026561410_cgpid16784548-ns-4026561407/first/modules/embedding/user_embedding_arch.py:1150 in run_event_and_aggregation_module, code: pooled_user_embeddings = torch.cat(
    cat: "bf16[9717, 1152]" = torch.ops.aten.cat.default([primals_1, primals_2, primals_3, primals_4, primals_5, primals_6, primals_7, primals_8, primals_9], 1);  primals_1 = primals_2 = primals_3 = primals_4 = primals_5 = primals_6 = primals_7 = primals_8 = primals_9 = None

    # File: /dev/shm/uid-0/90dc6b0c-seed-nspid4026561410_cgpid16784548-ns-4026561407/hpc/torchrec/models/ads/uhm/uhm_inline_cvr_7x.py:202 in forward, code: x_reshaped = torch.reshape(
    view: "bf16[9717, 9, 128]" = torch.ops.aten.reshape.default(cat, [-1, 9, 128])

    # File: /dev/shm/uid-0/90dc6b0c-seed-nspid4026561410_cgpid16784548-ns-4026561407/torch/nn/modules/linear.py:116 in forward, code: return F.linear(input, self.weight, self.bias)
    permute: "bf16[1152, 512]" = torch.ops.aten.permute.default(primals_10, [1, 0]);  primals_10 = None

    # No stacktrace found for following nodes
    mm_default_3: "bf16[9717, 512]" = torch.ops.aten.mm.default(cat, permute)
    return mm_default_3

from torch._dynamo.debug_utils import aot_graph_input_parser

kwargs = aot_graph_input_parser(forward)

from torch._inductor.utils import fresh_inductor_cache

import time
s = time.time()
with fresh_inductor_cache():
    torch.compile(forward, mode='max-autotune')(**kwargs)

out = time.time()
print("OUTPUT", out - s)
````

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @bdhirsh @anijain2305 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @muchulee8 @ColinPeppler @amjames @desertfire @htyu 

### Versions

triton pin: 45fff310c891f5a92d55445adf8cc9d29df5841e

This takes around 100s on h100 and 12s on a100.
Repository: TypeScript
Issue: Iterators/Generators, next(), and unsafe yield statement types
Labels: Needs Investigation

### Acknowledgement

- [X] I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

### Comment

### 🔎 Search Terms
iterator generator yield next

### 🕗 Version & Regression Information
Current behaviour has existed since 3.6.0.

----

With upcoming changes to iterators, I wonder whether it might be worth quickly revisiting the behaviour of the `next()` iterator method as applied to generators.

As discussed at #30790, when interacting with iterators manually, the compiler will always consider it valid if `next()` is called with zero-arity, even if `TNext` is of a type that cannot be void/undefined. The rationale for allowing this is that the iterator interface also has to be assignable by generators, where any parameter passed to the first call to `next()` gets thrown away, so it should be valid to allow the parameter to be absent.

This does have some type safety implications as originally discussed, but this also causes a related problem with the type of the `yield` statement in generators, which I don't think has ever been raised before:

```ts
function *g(): Generator<null, string, number> {
  const a = yield null; // const a: number
  return a.toString(16);
}

const it = g();
it.next();
it.next(); // TypeError: a is undefined
```

The function signature of `next()` allows the second call to be made without a parameter, but the compiler assumes that the type of the `yield` expression will always be `TNext`, and never be undefined. Although it violates the semantic intention of the generator signature, it seems like `yield` potentially returning undefined is a forced possibility if `next()` always allows calls with zero parameters, which was discussed previously and considered necessary.

Even if there's no alternative way to define `next()`, I wonder if the question of how to handle the types of `yield` expressions specifically needs considering. Flags pertaining to iterator type safety are in the 5.6 milestone, and I wonder whether it's worth considering a similar thing here.

related: #58243
Repository: terminal
Issue: No longer use Command.Name for disambiguation
Labels: Product-Terminal,Issue-Task,Area-CodeHealth

# Description of the new feature/enhancement
Once #17162 merges, we will have unique `ActionID`s for command disambiguation. This means we no longer need to use `Command.Name` for disambiguation and should update the following accordingly: `Command`, `ActionMap`, `SettingsEditor`, `CommandPalette`

# Proposed technical implementation details (optional)
Any location where we use `Command.Name` to disambiguate commands we should be using their IDs instead
Repository: godot
Issue: NavigationAgent3D: Calling GetNextPathPosition during WaypointReached signal causes infinite recursion
Labels: documentation,topic:navigation

### Tested versions

-Reproducible in: v4.1.stable.mono.official [970459615], v4.2.stable.official [46dc27791], v4.2.2.stable.mono.official [15073afe3], v4.3.dev5.mono.official [89f70e98d]
-Not reproducible in: v4.0.stable.mono.official [92bee43ad]

### System information

Godot v4.2.2.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated AMD Radeon RX 6900 XT (Advanced Micro Devices, Inc.; 31.0.21001.45002) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)

### Issue description

Connecting a method to the waypoint_reached signal of a NavigationAgent3D and calling navigation_agent.get_next_path_position() in said method causes an infinite recursion on the line that calls get_next_path_position().

For example, connecting the below method would cause a crash, but only if getPositionOnReach is set to true
```gdscript
func reached(_details: Dictionary):
	if getPositionOnReach:
		print(navigation_agent.get_next_path_position())
	else:
		print("No path position")
```

As a workaround, you can call "await get_tree().process_frame" before get_next_path_position() is called and it will work as expected.

This issue seems to have been introduced in v4.1.

I tested in v4.2 non-mono and it had the same error as well.

### Steps to reproduce

1. Create a NavigationAgent3D class like at the bottom of [this page in the docs](https://docs.godotengine.org/en/stable/tutorials/navigation/navigation_introduction_3d.html)
2. Connect a method to the navigation_agent.waypoint_reached signal which calls navigation_agent.get_next_path_position()
3. Play the scene and get the error "Stack overflow (stack size: 1024). Check for infinite recursion in your script"

In C# there are no errors; the build opens, freezes for a moment, then closes itself.

In the MRP, I have included separate scenes for C# and GDScript. The GDScript scene can be run without a .NET build as far as I can tell, but I wanted to include C# specifically since there is no error shown for the crash which made it much more difficult to debug.

### Minimal reproduction project (MRP)

[Navigation3D MRP.zip](https://github.com/godotengine/godot/files/15172457/Navigation3D.MRP.zip)
Repository: deno
Issue: 045_proxy is flaky
Labels: flaky

https://github.com/denoland/deno/actions/runs/9081191835/job/24954446773

```
---- run::_045_proxy stdout ----
command D:\a\deno\deno\target\debug\deno.exe run -L debug --allow-net --allow-env --allow-run --allow-read --reload --quiet run/045_proxy_test.ts
command cwd D:\a\deno\deno\tests\testdata
OUTPUT
Proxy server listening on http://localhost:4555/
error: Uncaught (in promise) AssertionError: Values are not equal.


    [Diff] Actual / Expected


-   1
+   0

  throw new AssertionError(message);
        ^
    at assertEquals (file:///D:/a/deno/deno/tests/util/std/assert/assert_equals.ts:52:9)
    at testFetch (file:///D:/a/deno/deno/tests/testdata/run/045_proxy_test.ts:47:3)
    at eventLoopTick (ext:core/01_core.js:168:7)
    at async file:///D:/a/deno/deno/tests/testdata/run/045_proxy_test.ts:116:1

OUTPUT
thread 'run::_045_proxy' panicked at tests\integration\run_tests.rs:237:1:
```