sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Reliable initialization of keyboard and pointer bindings 
Labels: a: text input,a: desktop,a: mouse,P2,team-text-input,triaged-text-input

We should review the messaging mechanism of various bindings (keyboard and pointer) and make them reliable. The current process, where the embedding blindly sends events to the framework, might cause message loss at initialization and state instability, especially during hot restarts.

## Analysis

Take keyboard as an example. Currently, when the app is started,
1. The Flutter view creates both a keyboard manager and a dart VM.
2. The keyboard manager immediately starts listening to system key events and send messages through the embedder API, `FlutterSendKeyEvent`.
3. It takes a short while for the dart VM to boot and run through all static statements, such as assigning a listener to the framework API `onKeyData`.
4. If a key event happens between the creation of the keyboard manager and the initialization of the framework, since the listener is still null, the message is lost.
 
Since the keyboard system only sends events, not the entire state, packet losses are critical and lead to state instability.

Now, we have managed to alleviate this issue by making the keyboard system send messages through the binary messenger to make use of the message buffer (https://github.com/flutter/engine/pull/29795). But the message buffer only has a depth of 1, and it's not difficult to reproduce a case that overflows the buffer (https://github.com/flutter/flutter/issues/89748). We can increase the buffer, but that only makes the problem "harder" to occur, not impossible.

The same problem is also found in the pointer event system (https://github.com/flutter/flutter/pull/102453#issuecomment-1117898221). We decided to temporarily alleviate this problem by relaxing the assertions.

Moreover, if the framework decides to reconstruct the keyboard manager or pointer manager, there is no way to synchronize the states.

## Proposal

There are two options to fix this issue.

1. **Send states, not deltas.** By always sending the entire keyboard/pointer state on every change, state stability is _guaranteed_, and the 1-depth message buffer can be used as intended. However these states can get really big. The user might smash the keyboard, pressing 30 keys at the same time, which becomes 60 `uint64`s per message, and the framework also needs to compare the state difference to figure out events.
2. **Initiate messaging/synchronization by framework.** The framework will send an establishment message when it first assigns a listener, and the engine will reply this message with a full state. This method complicates the API protocol, but keeps the followup messages light.

Both of the two options will possibly be a breaking change to the current embedder API.
Repository: pytorch
Issue: Inconsistent results between Pow and Float Pow with their numpy references for complex types
Labels: triaged,module: complex,module: NaNs and Infs

### 🐛 Describe the bug

Added numpy references to Pow and Float_Pow Opinfos. For `torch.complex64`, `torch.complex128` test_reference_numerics - (small, large, extremal) were skipped do to errors of the form: `Greatest absolute difference: nan at index`. 

Followed from working on these issues: #76483, #74279
### Versions

Not version specific 

cc @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @nikitaved
Repository: pytorch
Issue: Feature requests for optimizer overlapping
Labels: high priority,triage review,oncall: distributed,module: ddp,module: fsdp

### 🚀 The feature, motivation and pitch

After chatting with users who are interested in using optimizer overlap with DDP (and eventually FSDP) have a couple of feature requests:

1. Support an argument `set_grads_to_None`, as users would like to simply pass in this flag which will make their calls to optimizer.step() functionally a noop, instead of manually having to either to this themselves on their gradients or removing their optimizer step, and 
2. Add a getter to expose the fully initialized fused optimizer on the DDP / FSDP module. This is required for things like learning late schedulers that take the optimizer as a ctor argument, as well as for use with things such as torchrec's `KeyedOptimizer` which wraps a vanilla torch.optim.Optimizer, as well as additional usability for things such as optimizer checkpointing. 
3. Compatibility with LR schedulers.

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @gchanan @zou3519 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: next.js
Issue: nextjs Failed to load env TypeError: Cannot read properties of undefined (reading 'split')
Labels: Upstream

### Verify canary release

- [X] I verified that the issue exists in Next.js canary release

### Provide environment information

Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64
    Binaries:
      Node: 16.13.1
      npm: 7.24.2
      Yarn: 1.22.15
      pnpm: 6.11.0
    Relevant packages:
      next: 12.1.7-canary.1
      react: 17.0.2
      react-dom: 17.0.2

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

Executing on local laptop

### Describe the Bug

On starting next with the command npm run dev ("dev": "next")  the error message is show:
error - Failed to load env from /Users/path/.env.development.local TypeError: Cannot read properties of undefined (reading 'split')

The simple .env file has
SH_API_BASEURL='http://localhost:3010/api/v1'
NEXT_PUBLIC_SH_API_BASEURL = 'http://localhost:3010/api/v1'
NEXTAUTH_URL=http://localhost:3000
SECRET_COOKIE_PASSWORD=someText
NEXTAUTH_SECRET=AY_PqQ/gmFH6L@:z{szxm.2;~xN:RfD;Rwb`%c/$,/$sometext
JWT_SIGNING_PRIVATE_KEY=\&/$someText

If I remove the $ from the keys the .env file will load so the issue is when there is $ in the keys. As this was possible in 12.0.6 it should be possible in the current version.

### Expected Behavior

Next 12.0.6 is able to load the .env file without an issue but the current fails to load the .env.
I expect 12.1.16 or 12.1.7-canary.1 to be able to parse the .env file with $ in the value


### To Reproduce

To reproduce run npm i next
Repository: neovim
Issue: Hang when passing string containing NUL byte to nvim_set_keymap()/nvim_replace_termcodes()
Labels: bug,api

### Neovim version (nvim -v)

From v0.5.1 to HEAD

### Vim (not Nvim) behaves the same?

N/A

### Operating system/version

Arch Linux

### Terminal name/version

kitty 0.25.0

### $TERM environment variable

xterm-kitty

### Installation

any

### How to reproduce the issue

1. Run `nvim --clean`
2. Type `:lua vim.api.nvim_set_keymap('', 'foo', '\0', {})` or `:lua vim.api.nvim_replace_termcodes('\000', true, true, true)` and press Enter

### Expected behavior

No hang

### Actual behavior

Nvim hangs with increasing CPU usage.
Repository: pytorch
Issue: Object-base collectives create tensors at unexpected devices
Labels: high priority,oncall: distributed,better-engineering,module: c10d

### 🐛 Describe the bug

torch.distributed.gather_object (and similar object based collectives) rely on default Tensor pickling behavior of deserializing tensors to their original devices.

I ran into this issue when using ShardedTensor::gather as it leads to all processes occupying all GPUs.

This causes deadlocks on test/distributed/_shard/checkpoint/test_file_system_checkpoint.py -- test_load_rowwise_to_colwise and test_load_with_different_shard_plan.

Those deadlocks only happens on the VMs used by PyTorch CI (M60).

This behavior is quite surprising as the docs sort of imply that gathered tensors would all land `torch.cuda.current_device()`.


The following script will print this on a 4 GPU host:
`[0] :: cuda:0 cuda:1 cuda:2 cuda:3`


```python
import random
import torch.multiprocessing as mp

import torch
import torch.distributed as dist
import traceback

def run(rank):
    dst = 0
    obj = { "x": torch.rand(10).cuda(rank) }

    gather_list = [None] * dist.get_world_size()
    dist.gather_object(
        obj,
        gather_list if rank == dst else None,
        dst=dst)

    if rank == dst:
        devices = " ".join(str(l["x"].device) for l in gather_list)
        print(f"[{rank}] :: {devices}")

def worker(rank, init_method, world_size):
    init_comms(init_method, rank, world_size)
    try:
        run(rank)
    except BaseException as e:
        print(f"[{rank}] :: raised {e}")
        traceback.print_last()
    destroy_comms()

def init_pg(init_method, rank, world_size):
    torch.distributed.init_process_group(
        backend="nccl",
        world_size=world_size,
        rank=rank,
        init_method = init_method
    )
    torch.cuda.set_device(rank)

def init_comms(file_name, rank, world_size):
    init_pg(file_name, rank, world_size=world_size)

def destroy_comms():
    dist.barrier()
    dist.destroy_process_group()

if __name__ == "__main__":
    print("main")
    port = random.randint(10000, 20000)
    init_method = f"tcp://localhost:{port}"
    world_size = torch.cuda.device_count()

    mp.spawn(
        fn=worker,
        args=(init_method,world_size),
        nprocs=world_size,
        join=True,
    )
```

### Versions

main

cc @ezyang @gchanan @zou3519 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: angular
Issue: DevTools: Add links to components, directives, and lifecycle hooks in the profiler
Labels: feature,area: devtools

### Description

We display some components in the profiler view (under Parent Hierarchy). Right now they are just a visual indication of the parent hierarchy for each component. Let's convert these into links so that clicking them automatically opens the component definition in the browser's source code inspector.
<img width="843" alt="Screen Shot 2022-05-04 at 10 12 50 PM" src="https://user-images.githubusercontent.com/39253660/166854661-366e7272-afc0-450c-8beb-f91e98e22a48.png">

We can also detect when the "Method" column matches an Angular lifecycle hook (ngDoCheck in the example below) and convert the text into a link that automatically inspects the lifecycle method for the component in the browser source code inspector
<img width="840" alt="Screen Shot 2022-05-04 at 10 14 40 PM" src="https://user-images.githubusercontent.com/39253660/166854774-0451132c-1958-49d9-b4e8-b702f61da5b9.png">

Lets mimic the existing inspect functionality for the profiler. You can see examples of inspect in action by clicking the code icon when a component has been selected in the directive explorer (top right)

<img width="342" alt="Screen Shot 2022-05-04 at 10 20 52 PM" src="https://user-images.githubusercontent.com/39253660/166855210-dde354bd-78ff-4ca4-bc6c-a1c6978ca580.png">
Repository: deno
Issue: Improve `DNS.resolveDns()` record types supported.
Labels: feat,public API,tests,runtime

Since Deno uses the `trust-dns` library to resolve DNS, we should make it support all record types that the library supports, eg. We may need to change the test suite in order to make the test suite more virtual, such as having multiple `A` and `NS` records.

Reference : [Trust DNS RecordTypes](https://docs.rs/trust-dns-proto/0.21.2/trust_dns_proto/rr/record_type/enum.RecordType.html)


Tasks:
- [x] #14373
- [x] #14695 
- [ ] Record Types
- [x] #14534

*This is a long-term issue, please **do not** open PR which will close this issue.*
Repository: pytorch
Issue: PrimTorch binary refs do not handle CUDA + CPU scalar tensors correctly
Labels: triaged,module: primTorch

### 🐛 Describe the bug

```
import torch
import torch._refs as ref

print(torch.add(torch.randn(2, device='cuda'), torch.randn(())))
print(ref.add(torch.randn(2, device='cuda'), torch.randn(())))
```

gives

```
tensor([0.7217, 0.5864], device='cuda:0')
Traceback (most recent call last):
  File "a.py", line 5, in <module>
    print(ref.add(torch.randn(2, device='cuda'), torch.randn(())))
  File "/private/home/ezyang/pytorch-tmp/torch/_refs/__init__.py", line 716, in add
    result = prims.add(a, b)
  File "/private/home/ezyang/pytorch-tmp/torch/_prims/__init__.py", line 173, in _prim
    meta(*args, **kwargs)
  File "/private/home/ezyang/pytorch-tmp/torch/_prims/__init__.py", line 202, in _elementwise_meta
    utils.check_same_device(*args, allow_cpu_scalar_tensors=True)
  File "/private/home/ezyang/pytorch-tmp/torch/_prims/utils.py", line 314, in check_same_device
    raise RuntimeError(msg)
RuntimeError: Tensor on device cpu is not on the expected device cuda:0!
```

The CPU scalar tensor behavior in stock ATen is intentional and we need to replicate it.

### Versions

master

cc @ezyang @mruberry @ngimel
Repository: PowerToys
Issue: [Run] Instantly reposition search
Labels: Idea-Enhancement,Product-PowerToys Run,Needs-Triage

### Description of the new feature / enhancement

Quickly reposition the search window around an invisible 9-position grid using the modifier key(s) used for invocation together with the arrow keys. For example, if search is invoked with Alt-Space (default), pressing Alt-Down-Arrow would move the window to the bottom-center of the screen. Follow with Alt-Right Arrow to move it to the bottom-right. This could be performed without releasing the modifier key. For example, with the Alt key held down, pressing Space, Left-Arrow, Up-Arrow would invoke Run and move the window to the top-left of the screen.

For a system with multiple-displays, pressing the modifier key(s) and arrow key at the edge and in the direction of the adjacent display would enter the 9 position grid on that display.

### Scenario when this would be used?

I'm often invoking search to use with content located in the middle area of the screen, e.g., numbers to include in a calculation. Being able to quickly relocate the window would significantly improve the convenience of the tool.

### Supporting information

There have been several requests for the ability to move the search window and remember the last location. Many of these have been merged into #4576 and subsequently closed. To be able to quickly reposition the window with one or two additional keystrokes may be an acceptable alternative to other proposed methods.
Repository: rust
Issue: Tracking Issue for windows_process_extensions_main_thread_handle
Labels: T-libs-api,C-tracking-issue,A-process

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(windows_process_extensions_main_thread_handle)]`

This is a tracking issue for a new `main_thread_handle(&self)` function on a new ChildExt trait for windows.
The winapi function used to create a process on windows returns a [structure](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/ns-processthreadsapi-process_information) that has both a main thread handle and a process handle. std currently [discards](https://github.com/rust-lang/rust/blob/ddb7fbe8434be481607ae199fe2aee976ee2fc2e/library/std/src/sys/windows/process.rs#L341) the thread handle, but that handle can be useful when resuming a process that was created as suspended since that is usually done with [ResumeThread](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-resumethread). Finding that thread from the process handle can be a bit convoluted, so it'd be nice if std exposed it on a windows-specific extension trait.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// std::process

pub trait ChildExt: Sealed {
    #[unstable(feature = "windows_process_extensions_main_thread_handle", issue = "96723")]
    fn main_thread_handle(&self) -> RawHandle;
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [X] Implementation: https://github.com/rust-lang/rust/pull/96725
- [ ] Final comment period (FCP)
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->
Repository: flutter
Issue: [web] Support CMD+Mouse Click shortcut to open link in new tab
Labels: platform-web,p: url_launcher,package,c: proposal,a: mouse,P2,team-web,triaged-web

Please add the support for **CMD+Left Mouse Click** shortcut to open the web link in the new tab to the Link widget to url_launcher package.
Repository: kubernetes
Issue: As a user I want to be able to restrict IP families to some pods
Labels: sig/network,kind/feature,triage/accepted

### What would you like to be added?

In dual stack cluster ,  all the pods have both Ipv6 and Ipv4 interfaces. However there would be scenarios where user does not to enable dual stack for all the pods . So basically the ask is to restrict IP families to certain POD.  We should be able to specify certain pods to operate in single stack only i.e. either IPv4 or IPv6 only.  The address family of a Pod defaults to the address family of the first cluster-cidr IP range (configured via the --cluster-cidr flag to the kube-apiserver).. 


One of possible way to indicate in the pod spec is shown below

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
ipFamilyPolicy: [PreferDualStack , SingleStack, DualStack]
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

### Why is this needed?

This would prevent legacy apps /Pod/ single stack pod to operate securely without unintended opening holes on additional interfaces. This would prevent developer unintended support for secondary IP families and thereby helping secure deployment.
Repository: PowerToys
Issue: PowerRename - Make option for apply and close when enter is pressed
Labels: Idea-Enhancement,Product-PowerRename,Area-User Interface

### Description of the new feature / enhancement

Currently if enter is pressed, nothing happens. Before the redesign pressing enter would apply and close. It would be great if that could be an option in the settings.

### Scenario when this would be used?

When renaming files with PowerRename.

### Supporting information

_No response_
Repository: pytorch
Issue: Multiprocessing DataLoader hangs on exception inside iterator when using a simple queue and a producer thread
Labels: module: multiprocessing,module: dataloader,triaged

### 🐛 Describe the bug

I'm using a thread to read data from a pipe which can only be accessed by a single thread (hence the quirky setup). So the thread reads data continuously from the stream, and inserts the data frames into a multiprocessing SimpleQueue as they become available.

Then I have an `IterableDataset` that has access to this queue, and tries to read the data frame and then do some "heavy" processing on the data. I use a multiprocessing `DataLoader`.

However if something happens to raise an exception inside an dataset instance during the dataloader iteratator iteration the **python main process hangs after printing the exception rather than exiting as I would expect**. I think this is a bug, unless you can spot to multiprocessing mistake in my code example below.

I stumbled upon this ticket but I don't know it it's related: https://github.com/pytorch/pytorch/issues/48666

### Minimal example
```python
import threading
import time

import torch
import torch.multiprocessing as mp
from torch.utils.data import IterableDataset, DataLoader

class ProducerThread(threading.Thread):
    def __init__(self):
        super().__init__()
        self.queue = mp.SimpleQueue()

    def run(self):
        while True:
            data = '...'
            time.sleep(0.01)
            self.queue.put(data)


class Dataset(IterableDataset):
    def __init__(self, queue):
        self.queue = queue

    def __iter__(self):
        while True:
            data = self.queue.get()
            data = self.process(data)

            yield data

    def process(self, data):
        raise RuntimeError()


if __name__ == '__main__':
    batch_size = 4
    num_workers = 3
    producer = ProducerThread()
    dataset = Dataset(producer.queue)
    dataloader = DataLoader(dataset, batch_size, num_workers=num_workers)

    producer.start()
    for batch in dataloader:
        pass
```

### Versions

Collecting environment information...
PyTorch version: 1.10.2
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.2.1 (arm64)
GCC version: Could not collect
Clang version: 13.0.0 (clang-1300.0.29.30)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.6 (default, Feb 15 2022, 14:18:12)  [Clang 13.0.0 (clang-1300.0.27.3)] (64-bit runtime)
Python platform: macOS-12.2.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.10.2
[pip3] torchvision==0.11.3
[conda] Could not collect

cc @VitalyFedyunin @SsnL @ejguan @NivekT
Repository: flutter
Issue:  Consider not using `callback_mutex_` in `VsyncWaiter` if possible.
Labels: engine,P3,team-engine,triaged-engine

In the current implementation, `callback_mutex_` is used to ensure thread safety when accessing `callback_` or `secondary_callbacks_` in `VsyncWaiter`. However, in most platform implementations, `VsyncWaiter::FireCallback` is called on the UI thread, which means that `callback_` and `secondary_callbacks_` will only be accessed on the UI thread. It seems that we can ignore `callback_mutex_` in this case.