sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: kubernetes
Issue: API client can't recover when tcp-reset happens
Labels: kind/bug,area/client-libraries,sig/api-machinery,priority/important-longterm,lifecycle/frozen

client-go verison is 9.0.0

1. get endpoints use CoreV1 from api server is ok, set timeout 5s
2. apply iptables rule `sudo iptables -A INPUT -s k8scluter -p tcp -j REJECT --reject-with tcp-reset`
3. wait about 15s
4. remove iptables rule 

after that, client-go can't communicate with api-server,  always get `Get https://xxx/api/v1/namespaces/prod/endpoints/aaa?timeout=5s: context deadline exceeded`
Repository: PowerToys
Issue: Grouping Taskbar Icons
Labels: Idea-New PowerToy,Product-Tweak UI Design

# Summary of the new feature/enhancement

I want to be able to group taskbar icons. 

# Proposed technical implementation details (optional)

By example, I have Chrome, Firefox, Edge and Opera in my taskbar. I want to group them in only one icon "Browsers". When I click (or hover? can be an option), then appears a menu with these 4 icons, then I can click and open my desired browser. It will clean my taskbar, I can group related icons as well.
Repository: pytorch
Issue: Detaching a distribution's `log_prob` to block gradients only w.r.t its parameters
Labels: module: distributions,triaged

## 🚀 Feature
It would be quite useful to have the general ability, to compute a 'detached' `log_prob` for any distribution; i.e. blocking all gradient computation w.r.t that distribution's parameters (but not the value), _without_ resorting to the alternative of constructing an instance of that distribution with explicitly detached parameters.

cc: @fritzo (a late request following our conversation at icml :slightly_smiling_face: )

## Motivation
This would be particularly useful for a variety of stochastic variational inference approaches [1,2], which seek to avoid the _score-function gradient_ component of the estimators, by either ignoring it entirely [1] or by _doubly reparameterising_ the estimator [2] to include it in a form that avoids the larger variance of the score-function gradient estimator.

[1] [Sticking the Landing: Simple, Lower-Variance Gradient Estimators for Variational Inference](https://arxiv.org/abs/1703.09194)
[2] [Doubly Reparameterized Gradient Estimators for Monte Carlo Objectives](https://arxiv.org/abs/1810.04152)

## Pitch
The idea is to have an operation that allows a `log_prob` call to block gradient computation w.r.t the _parameters_, while gradients w.r.t the _value_ still get computed. Simply detaching the entire `log_prob` computation will not satisfy this requirement.

``` python
import torch
import torch.distributions as dist

params = torch.zeros(3,2), torch.ones(3,2)  # mu, sigma
pz = dist.Normal(*params)
z = pz.rsample()
# hypothetical setup
lpz = pz.log_prob(z, detached_params=True)  # or some similar form
loss = -lpz
```

## Alternatives

While one solution for this is to just create a new instance of the distribtuion in question with pre-detached parameters, for more complex models (as in those used with Pyro), this can get hairy quite quickly.

``` python
import torch
import torch.distributions as dist

params = torch.zeros(3,2), torch.ones(3,2)  # mu, sigma
params_ = tuple(p.detach() for p in params)
pz = dist.Normal(*params)
pz_ = dist.Normal(*params_)
z = pz.rsample()
lpz = pz_.log_prob(z)  # note: using pz_ to score
loss = -lpz
```

It also doesn't seem to be feasible to wrap the existing `log_prob` method, as there does not appear to be a way to access all the parameters of an arbitrary distribution---with a view to detaching them when required.

cc @vincentqb @fritzo @neerajprad @alicanb @vishwakftw
Repository: pytorch
Issue: [Feature request] modified Cholesky decomposition
Labels: high priority,triaged,enhancement,module: linear algebra

It would be useful to have a modified Cholesky decomposition implemented in PyTorch.

This allows one to perform Cholesky decomposition on singular covariance matrices.
A work-around is to add a small multiple of identity matrix and run `torch.cholesky`, but that adds an extra hyper-parameter that user needs to tune.

One implementation is here:
http://faculty.washington.edu/mforbes/doc/pymmf/_build/_generated/api/mmf.math.linalg.cholesky.cholesky_.html



cc @ezyang @gchanan @zou3519 @vishwakftw @SsnL @jianyuh
Repository: PowerToys
Issue: Alt+Drag or Windows+Drag to move windows
Labels: Help Wanted,Idea-New PowerToy,Product-Window Manager

### Summary of the new feature/enhancement
Moving windows using the mouse relies on hitting a small target, especially on high-resolution screens.  Add an option to move entire windows by alt-dragging or windows-dragging them, anywhere on the window except perhaps the resize area.

### Proposed technical implementation details
Stefan Sundin has done great work on AltDrag: https://stefansundin.github.io/altdrag/ .  With permission, I'd use this as an initial reference.

Alt+Drag or Windows+Drag could be implemented as part of FancyZones, activated with a toggle.
Repository: rust
Issue: Ambiguity between type ascription and absolute paths
Labels: A-parser,T-lang

I am not sure, but I think the following program should be valid:

```rust
type X = ();

fn main() {
    let ():::X = ();
}
```

It currently fails with

```
error: expected identifier, found `:`
 --> /home/matklad/tmp/main.rs:4:13
  |
4 |     let ():::X = ();
  |             ^ expected identifier
```

because we don't try to decompose `::` token. 

I am not sure what should be the behavior of 

```rust
type X = ();

fn main() {
    let Y:::X = ();
}
```

but I lean towards allowing it as well, looks like it requires only constant look-ahead to handle.

Anyway, `rg ':::' --type rust` shows that we don't have a test here.

@petrochenkov what are your thoughts on this?
Repository: kubernetes
Issue: High system load/CPU utilization with trivial liveness and readiness exec probes
Labels: kind/bug,priority/backlog,sig/node,help wanted,triage/accepted

**What happened**:
Using trivial probes significantly contributes to CPU/system load.

**What you expected to happen**:
Trivial probes should be performant

**How to reproduce it (as minimally and precisely as possible)**:

1. Create a cluster (minimal reproduction done on an m5.large ec2 instance, creating a single node cluster via kubeadm with a deployment specifying a 2 pod replica scheduled on the single node. Reproduction steps are available for more complex setups)
2. Measure system load/CPU utilization
3. Deploy the following deployment
```
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    k8s-app: diagnostic
  name: diagnostic
  namespace: default
spec:
  progressDeadlineSeconds: 600
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: diagnostic
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        k8s-app: diagnostic
    spec:
      containers:
      - name: diagnostic
        image: ubuntu:18.04 
        command:
        - /bin/bash
        - -c
        - touch /tmp/healthy; sleep 3600
        imagePullPolicy: IfNotPresent
        readinessProbe:
          exec:
            command:
              - cat
              - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 2
          failureThreshold: 120

        livenessProbe:
          exec:
            command:
              - cat
              - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 2 
          failureThreshold: 120
      restartPolicy: Always
      nodeSelector:
        node-role.kubernetes.io/master: ""
      tolerations:
      - operator: "Exists"
```
4. Remeasure system load/CPU utilization

**Anything else we need to know?**:
Included is a screenshot. The beginning shows the node in "steady state" without the deployment running. This is at about 10% utilization. The first blip is deploying a similar deployment with no probes specified, still at 10%. The second blip is deploying a similar deployment but with just the livenessprobe specified, this is about 17%. The third blip is deploying the provided deployment with both liveness and readiness probes specified, this is about 34%. 

![probe-cpu-util](https://user-images.githubusercontent.com/902943/64458045-4a485d00-d0c2-11e9-81ab-70b8ae5ca0b9.png)


Further testing shows that CPU utilization scales linearly with pod replica size.


**Environment**:
- Kubernetes version (use `kubectl version`): 1.15.3
- Cloud provider or hardware configuration: AWS (m5.large)
- OS (e.g: `cat /etc/os-release`): Ubuntu 18.04.3
- Kernel (e.g. `uname -a`): 5.0.0-25-generic
- Install tools: kubeadm 1.15.3
- Network plugin and version (if this is a network-related bug): VPC CNI v1.5.3 (reproduced with kuberouter as well)
- Others: Docker 18.09.2
Repository: go
Issue: runtime: lock cycle between mheap_.lock and gcSweepBuf.spineLock
Labels: NeedsInvestigation,compiler/runtime

As the title says, there's a runtime lock cycle between `mheap_.lock` and `gcSweepBuf.spineLock`. The cycle is effectively of the following form:

On one thread:
1. `(*mheap).alloc_m` (which runs on the system stack) allocates a span and calls in `(*gcSweepBuf).push`.
1. `(*gcSweepBuf).push` acquires the spine lock.

Meanwhile on another thread:
1. `deductSweepCredit` (on a g's stack) calls into `sweepone`, then `(*mspan).sweep`.
1. `(*mspan).sweep` calls into `(*gcSweepBuf).push`.
1. `(*gcSweepBuf).push` acquires the spine lock.
1. `(*gcSweepBuf).push` calls into either `persistentalloc` or `unlock`.
1. In the prologue of either of these function, a stack growth is triggered which acquires `mheap_.lock`.

Note that `(*gcSweepBuf).push` would have the potential for self-deadlock in the `alloc_m` case, but because it runs on the system stack, stack growths won't happen.

This must be an extremely rare deadlock because `git` history indicates that it's been around since 2016 and we've never received a single bug report (AFAICT). With that being said, if we want any sort of automated lock cycle detection, we need to fix this.

It's unclear to me what the right thing to do here is. The "easy" thing would be make `(*gcSweepBuf).push` run on the system stack, that way it'll never trigger a stack growth, but this seems wrong. It feels better to instead only acquire `spineLock` after `mheap_.lock`, but this may not be possible. My concern is that the allocated span's `sweepgen` could end up skewed with respect to the `gcSweepBuf` it's in, but I haven't looked closely at the concurrency requirements of the relevant pieces.

CC @aclements
Repository: pytorch
Issue: [jit] `random` module support
Labels: oncall: jit,triaged,jit-backlog

This is used in MaskRCNN (specifically `random.choice`), we could implement the subset of `random` that's not covered in `torch` already

cc @suo
Repository: PowerToys
Issue: Suggested PowerToy: Move windows partially outside of screen by hitting screen border with mouse
Labels: Idea-New PowerToy,Product-Window Manager,Product-Mouse Utilities

# Summary of the new feature/enhancement

This is a feature ("Auto Scroll") available by ThinkVantage Tools (from Lenovo), which can (unfortunately) only be installed on Lenovo/IBM machines, but I think there is no technical limitation of doing so (all you really need is a mouse hook). I'd like to have this part of PowerToys so I can use it on every machine I have. In my experience it is very unintrusive and sometimes really helpful.

When you have a focused movable window that is partially outside the screen (or the bounding box of all screens in case there is more than one) and you move your mouse (with no mouse button pressed) to the border of the screen and "continue moving", the window will move in. So if you try to move the mouse 10 more pixels against the border, the window will move 10 more pixels into the screen (but the mouse pointer remains at the same absolute position on the screen). If you continue trying to move the mouse, eventually the whole window will be visible and the feature automatically "turns off" (as the precondition of having a window partially outside the screen is no longer valid).

When moving the mouse into a corner of the screen, you can simulteneously move the window both horizontally and vertically.

# Proposed technical implementation details (optional)

You will probably need a mouse hook to be able to detect mouse movement that does not move the cursor. Plus some winapi calls like SetWindowPos or SetWindowPlacement to move the window around, and GetForegroundWindow and GetWindowRect GetWindowLong to find out which window has focus, where it is on screen, and whether it is movable. But I guess you at Microsoft know better what API is available anyway :)
Repository: flutter
Issue: default Xcode project requires a tripwire to defeat timestamp analysis
Labels: tool,a: build,P3,team-tool,triaged-tool

(Hypothetically the iOS project has the exact same issue)

The macOS Xcode project requires us to unconditionally touch a file after flutter assemble and list this as an input In order to defeat the timestamp analysis.

While the set of input/output files is complete, the flutter build also depends on the current configuration (build mode, target file). Thus within a configuration, the timestamp analysis will skip the script phase and it will be correct. Changing configurations would require a clean, since xcode thinks that the script phase is still safe to skip.

This isn't an issue with the flutter assemble caching, as long as the flutter tool is invoked it will correctly determine whether the build can be skipped or not. The tripwire file allows us to delegate to this caching strategy instead.
Repository: rust
Issue: Tracking Issue for Cross Compiling Doctests
Labels: T-rustdoc,A-cross,B-unstable,C-tracking-issue,A-doctests,requires-nightly

This is an issue to track the functionality added by [PR#60387](https://github.com/rust-lang/rust/pull/60387), and also by extension [this PR](https://github.com/rust-lang/cargo/pull/6892) in cargo. 

PR#60387 adds three options to rustdoc:
   + `--enable-per-target-ignores` which adds a compiletest-like mechanism for ignoring platform on a substring basis (eg `ignore-foo`)
   + `--runtool` and `--runtool-arg` for specifying an external program and its arguments, to which the compiled doctest binary will be passed as the final argument

The companion PR adds a flag to cargo for enabling this feature as well as cross-compiling doctests and parsing runtool tokens from a `.cargo/config`. 

Eventually another PR for `x.py` can either enable this unconditionally or add a flag for testing the extensive documentation in the standard library on other platforms.

This solves cargo issue [#6460](https://github.com/rust-lang/cargo/issues/6460)
Repository: PowerToys
Issue: Keyboard shortcut for switching between windows of the same program
Labels: Help Wanted,Idea-New PowerToy,Product-Window Manager

Windows currently does not have a shortcut for switching between windows of the same program/app. On Mac it is <kbd>CMD</kbd> + <kbd>`</kbd>. I think it should be supported on Windows out of the box, but maybe adding it in PowerToys would be faster?

Right now the alternative is to install a third-party tool called [Easy Window Switcher](https://neosmart.net/EasySwitch/).
Repository: PowerToys
Issue: Maximize/Full Screen window within a zone (virtual monitor)
Labels: Idea-Enhancement,Product-Window Manager,Product-FancyZones

Maximize window within the zone

Maximizing the window currently maximizing it to the whole desktop. It would be useful if it has the ability to maximize within the zone
Repository: bitcoin
Issue: policy: allow RBF descendant carveout whenever conflicts exist, not just when number of conflicts == 1
Labels: Brainstorming,TX fees and policy

Comments left over from #16421.

From aj:

> Can't we actually cope with merging packages this way too though? If you've got a tx that has parents A, B, C; and that conflicts with tx's X (parent A) and Y (parent B), then beforehand you had:

> ```
> ..., A, X, [children X]
> ..., B, Y, [children Y]
> ```

> (maybe some tx's were descendants of both X and Y, but it's worse if there weren't any like that) and afterwards you have:

> ```
> ..., A, tx
> ..., B, tx
> ```

> You don't have C in the mempool because that would fail the "replacement-adds-unconfirmed" test later.

> So you know tx's ancestor checks pass, because they're actually worked out; you know A,B's ancestor checks pass because they don't change, tx's descendant check is trivial, and you know A,B and all their parent's descendant checks passed, because they did so when X and Y were there -- as far as sizes go, if they were all at their limit, then the max size for tx is the minimum of the descendant sizes of each tx that was replaced.

> So I think you could replace the `setConflicts.size() == 1` test with:

>```
> if (!setConflicts.empty()) {
>    auto conflict = setIterConflicting.begin();
>    assert(conflict != setIterConflicting.end());
>    uint64_t bump = (*conflict)->GetSizeWithDescendants();
>    while(++conflict != setIterConflicting.end()) {
>        bump = std::min(bump, (*conflict)->GetSizeWithDescendants());
>    }
>    nLimitDescendants += 1;
>    nLimitDescendantSize += bump;
> }
> ```

From sipa
> I haven't thought hard about the effect on potential DoS issues this policy change may have.
Repository: flutter
Issue: A Cupertino widget that has the option to disable user interaction should be disabled and turn gray when its route is no longer the current route
Labels: framework,a: fidelity,f: cupertino,f: routes,c: proposal,P2,team-design,triaged-design

Most noticeable when an action sheet / share sheet / alert view pops up.
The behavior can be observed on iOS 12 so it's not an iOS 13 feature. But the new iOS modal does make it more noticeable when one drags the current route down to dismiss it.

### Gif (may take a while to load):
![disabled](https://user-images.githubusercontent.com/31859944/64823018-32158980-d56b-11e9-8bee-4c7ab925b774.gif)

Maybe related: https://github.com/flutter/flutter/issues/2222
Repository: pytorch
Issue: (PyTorch1.1 and 1.2) RuntimeError: Can't detach views in-place. Use detach() instead
Labels: module: autograd,module: optimizer,triaged,enhancement

In my code, run `optimizer.zero_grad()`, there is an error here:

```
File "/home/backend/.local/lib/python3.6/site-packages/torch/optim/optimizer.py", line 164, in zero_grad
    p.grad.detach_()
RuntimeError: Can't detach views in-place. Use detach() instead
```
Should I modify `detach_()` to `detach()` here?

cc @ezyang @gchanan @zou3519 @SsnL @albanD @vincentqb
Repository: PowerToys
Issue: [FancyZones] swap window location between zones when drag and dropping windows on each other (or using keyboard)
Labels: Idea-Enhancement,FancyZones-Dragging&UI,Product-FancyZones

PowerToys FancyZones: swap window location between zones when drag and dropping windows on each other.
for example i'm using a 3 column zone. i want it to act like this so that when i drag the window from the right side and drop it on the left zone, the locations of the windows swap with each other automatically.

I added a diagnostic file and recreated the issue/requests for this Feedback: https://aka.ms/AA6079y
Repository: PowerToys
Issue: [Shortcut Guide] When the taskbar autohides the guide doesn't show the numbers
Labels: Idea-Enhancement,Product-Shortcut Guide

<!--
**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.
-->

# Environment

```
Windows build number: [run "ver" at a command prompt] Microsoft Windows [Version 10.0.18975.1000]
PowerToys version: 0.11.0
PowerToy module for which you are reporting the bug (if applicable): ShortCut Guide
```

# Steps to reproduce

<!-- A description of how to trigger this bug. -->
Enable automatic hiding of the taskbar in the taskbar settings ->
![image](https://user-images.githubusercontent.com/5251028/64476715-e8a3f380-d192-11e9-9c80-e8293fa3099d.png)

Press and Hold the Windows Key to show the guide, two scenario's can happen:
- If the taskbar is hidden, no numbers are shown
- If the taskbar is closing (because the ShortCut Guide is opening), sometimes a `0` can be seen but only a `0`

# Expected behavior

<!-- A description of what you're expecting, possibly containing screenshots or reference material. -->
I expected two things;
- It shows the taskbar with the numbers -> so it unhides the taskbar so it can show the numbers
- It keeps the taskbar hidden but shows the program icons with the corresponding numbers -> so a lite version of the taskbar, instead of showing the full one

# Actual behavior

<!-- What's actually happening? -->
One of the two earlier mentioned scenario's:
- If the taskbar is hidden, no numbers are shown
- If the taskbar is closing (because the ShortCut Guide is opening), sometimes a `0` can be seen but only a `0`

# Screenshots

<!-- If applicable, add screenshots to help explain your problem. -->
Scenario 1: Shows noting:
![Screenshot (27)](https://user-images.githubusercontent.com/5251028/64476796-a29b5f80-d193-11e9-94a0-7967e2d19bad.png)

Scenario 2: Or shows a `0`:
![Screenshot (28)](https://user-images.githubusercontent.com/5251028/64476807-bf379780-d193-11e9-88c0-278bf5af2ecf.png)

Just a quick note -> Even when a programs holds the taskbar constanly open (the icon turns orange) if you press and hold the windows key to open the ShortCut Guide -> it will close/hide the taskbar and show the `0` as in Scenario 2
Repository: PowerToys
Issue: Default custom layouts for FancyZones
Labels: Idea-Enhancement,FancyZones-Layouts,Product-FancyZones

# Summary of the new feature/enhancement
I would love to see the following layouts for FancyZones

1. left zone 2/3 of the screen and right zone 1/3 of the screen
2. left zone 1/3 of the screen and right zone 2/3 of the screen
3. left zone 2/3 of the screen and right zone 1/3 of the screen, the right zone is spit horizontally into two zones:
![FancyZones_Custom_Layout](https://user-images.githubusercontent.com/8037790/64477445-ec884380-d19b-11e9-8ae1-22b0e2f61922.png)

I am using the layout number 3 (WQHD monitor) and it really helps me a lot organizing my windows.
Repository: rust
Issue: Compiler spuriously infers data needs to be borrowed as mutable
Labels: A-borrow-checker,T-compiler,C-bug

All credits are due to [this SO question](https://stackoverflow.com/questions/57828602/what-is-rusts-borrow-checker-really-complaining-about-here). This code is tried:

```rust
fn selection_sort(collection: &mut Vec<&mut String>) {
    for i in 0..collection.len() {
        let mut least_element = i;
        for j in (i + 1)..collection.len() {
            if collection[j] < collection[least_element] {
                least_element = j;
            }
        }

        collection.swap(least_element, i);
    }
}
```

I expect it to compile. Instead, `rustc` complains that the data needs to be borrowed as mutable, which is incorrect:

```bash
error[E0596]: cannot borrow data in a `&` reference as mutable
 --> src/lib.rs:5:32
  |
5 |             if collection[j] < collection[least_element] {
  |                                ^^^^^^^^^^^^^^^^^^^^^^^^^ cannot borrow as mutable
  |
  = help: trait `IndexMut` is required to modify indexed content
```

This happened on `rustc-1.37.0`, `beta-1.38.0` and `nightly-1.39.0`.
Repository: scrcpy
Issue: Key bindings for scroll
Labels: feature request

Key bindings for scrolling will be a great addition. At present, it hard to drag or scroll using touch pad on laptops.