sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: Cannot override Cascadia Code
Labels: Area-Fonts,Issue-Bug,Product-Terminal

# Environment

Win32NT 10.0.18362.0
Windows Terminal version: 0.5.2681.0

# Steps to reproduce

Download the latest install of Windows Terminal from the Microsoft Store.
Install a new version of Cascadia Code (attached) via the font menu.
Open Windows Terminal.
Set Font Family in Preferences to “Cascadia Code”.
Observe that glyphs present in the older version appear (it appears that the newer font is used as a fallback for the previously-missing glyphs).  

# Expected behavior

Windows Terminal should use a normal process to install Cascadia Code so that it can be uninstalled or replaced as new versions of Cascadia Code are released. 

# Actual behavior

<img width="581" alt="WindowsTerminal" src="https://user-images.githubusercontent.com/8460297/65842898-8a76b600-e2e3-11e9-9142-92263f48e853.png">
Note here that the older version of the font is being used for glyphs present in the older version, but the newer font is being used for glyphs only present in the newer version. 


Windows Terminal appears to have a ‘back-end’ way of installing the font file that is inaccessible and cannot be overriden even when installing through the Font Menu, or a Font manager (such as FEX). 


In VS Code, the newer version of the font is ignore entirely in favor of the older version installed by Windows Terminal. 

[CascadiaCode.ttf.zip](https://github.com/microsoft/terminal/files/3668355/CascadiaCode.ttf.zip)
Repository: pytorch
Issue: The Gather problem in DataParallel: dimension are not matched.
Labels: triaged,module: data parallel

## 🚀 Feature
Enabling User to control which inputs should be scattered to different GPUs. 

## Motivation
torch.nn.DataParrallel is a very useful tool for multi-GPU application with pytorch. However, during my application, a strange bug is that my model works well with single GPU but fails in multi-GPUs by: 
**RuntimeError: Gather got an input of invalid size: got [24, 10, 448，448], but expected [24, 11, 448，448] (gather at /pytorch/torch/csrc/cuda/comm.cpp:239**
My input size is [48,3,448,448], and two GPUs are used. Thus, it is ok to split 24 images into each gpu, but it is strange why exists 10 and 11 channels?

After debug, the problem is found out:
![image](https://user-images.githubusercontent.com/37262007/65848474-d293e800-e378-11e9-94a6-6d19a924a09f.png)
The self.embed_arr is an input semantic labels, whose size is [21,300].
self.embed_arr will affect the image feature channels.
Under single GPU setting, each image will meet a same self.embed_arr, thereby having the same image channels.
However, under multi-GPUs settings, self.embed_arr will be split into multi-parts, e.g., [10,30] and [11,30], thereby leading to different image channels and a bug during feature gathering.
( If self.embed_arr has a  size of [20,300], this problem will not appear, and I may think that the bad performance is attributed to my algorithm, which is terrible!)

## Solution
An alternative solution is to duplicate the input so that the scattered inputs in each GPU is the same:
![image](https://user-images.githubusercontent.com/37262007/65848944-e04a6d00-e37a-11e9-86ed-13ff8d081891.png)

## Suggest
So, I suggest pytorch to add a function that can ontrol which inputs should be scattered to different GPUs.
Repository: TypeScript
Issue: Conditional types fail to distribute in properties of mapped types
Labels: Docs

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.7.0-dev.20190928

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** conditional mapped property union

**Code**

```ts
type NullifyStrings<T> = T extends string ? null : T
type NullifyStringsInPropsWorking<T> = { [K in keyof T]: NullifyStrings<T[K]> }
type NullifyStringsInPropsBroken<T> = { [K in keyof T]: T[K] extends string ? null : T[K] }

type TestType = { a: number | string }
// { a: number | null }
type WorkingReplaceProps = NullifyStringsInPropsWorking<TestType>
// { a: string | number }
type BrokenReplaceProps = NullifyStringsInPropsBroken<TestType>
```

**Expected behavior:**
`NullifyStringsInPropsWorking` and `NullifyStringsInPropsBroken` should be functionally identical - expanding the `NullifyStrings` type alias in `NullifyStringsInPropsWorking` results in the same definition as `NullifyStringsInPropsBroken`.

**Actual behavior:**
`NullifyStringsInPropsWorking` and `NullifyStringsInPropsBroken` have different behaviour - `BrokenReplaceProps` has type `{ a: string | number }` instead of the expected `{ a: number | null }`.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior --> [Link](https://www.typescriptlang.org/play/?ts=Nightly#code/C4TwDgpgBAcgrgGwQSwGYgMrAE7IHYDmAzgDwAqAfFALxRlQQAewEeAJkVETvgVAPxQ8iBFABcdALAAoUJFgi0mHoSIBJPAAVsAezBEA6juwBrXuSq0A3lADaAaSj4oJiCB2o6AXQnwkSrFxVcgcvKgBfGTloPxR0QN51LV19ACFdVzwLGigbByc8FzcPbwkyUIZmVg4uFT5BYSRxOgrI6SjwaDIIbjJOnJsAQwlhAFsAIwhsKAAfWqC+NoB6JdyoYaE4CanZzaa26KgjU14AJQgwBEGAYwhtPU5aWIC6pPv9Y7NCch7gPsgKDIVmsNtwFrsxpNpgd+ukdJlzpcbncUo8FP54q8NO8iHDMj9ep0KEA)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->

#28339, but seems to be different.

#22945 mentions

> Since type aliases are equivalent to writing the expansion inline [...]

but that is not the case here.
Repository: PowerToys
Issue: [FZ Editor] allow manual coordinates (absolute and relative)
Labels: Idea-Enhancement,FancyZones-Editor,FancyZones-Layouts,Product-FancyZones,Priority-3

# Summary of the new feature/enhancement

Sizing of custom zones in editor by dragging mouse is a little bit coarse (hit and miss) in terms of getting close to edges of screen symmetrically and allowing window edges of multiple zones to line up neatly. Some possible solutions are suggested for consideration.

# Proposed technical implementation details (optional)

1. Perhaps have an option for the editor to snap to a grid of user specified n pixels.

2. Perhaps have optional ability to input window dimension and position directly in both absolute terms (n x n pixels) and in terms of percentage of screen width and height.
Repository: rust
Issue: Less codegen parallelism than expected with `-C codegen-units=16`
Labels: A-codegen,I-compiletime,T-compiler

This is the output of `cargo build -Z timings` for Servo, on a 14 cores / 28 threads machine, filtered with "Min unit time" at 10 seconds.

**Edit:** with Rust `nightly-2019-09-28`

![a4fd0099519ccbda2e31718d46f1ff0e546886d6](https://user-images.githubusercontent.com/291359/65858292-dcf8b680-e365-11e9-8689-80c52a34fbcc.png)

For most of codegen for the `script` crate only 3 to 4 threads seem to be CPU-bound, leaving other cores idle, despite [`codegen-units=16` being the default](https://github.com/rust-lang/rust/blob/134004f74db3b4626bde37cc068d9ae6dedd2d38/src/librustc/session/mod.rs#L971). (Results are similar if I specify it explicitly.)

Shouldn’t CPU usage be much closer to `min(ncpu, codegen-units)`?
Repository: pytorch
Issue: torch::NoGradGuard no_grad get wrong  when I use batchsize!=1
Labels: module: cpp,triaged

## ❓ Questions and Help

### Please note that this issue tracker is not a help form and this issue will be closed.

We have a set of [listed resources available on the website](https://pytorch.org/resources). Our primary means of support is our discussion forum:

- [Discussion Forum](https://discuss.pytorch.org/)

I used jit to convert the model,and then I use C++ to predict. But I found that when I use 
torch::NoGradGuard no_grad;
batch_size!=1.
will get wrong like this:
![image](https://user-images.githubusercontent.com/29307135/65860800-945cef80-e39d-11e9-8f47-dc1acff81599.png)



cc @yf225
Repository: terminal
Issue: Propagate palette changes on the legacy console through ConPTY w/ OSC 4
Labels: Help Wanted,Product-Conpty,Area-VT,Issue-Task

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

<!--
This bug tracker is monitored by Windows Terminal development team and other technical folks.

**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.

If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible.

-->

# Environment

```Windows 10 latest build
Windows build number: Microsoft Windows [Versione 10.0.18362.356]
Windows Terminal version (if applicable): 0.5.2681.0

Any other software?
FiveM CitizenFX collective GTA Modification server Build
```
# Steps to reproduce

using the library Colorful.Console in a c# project the output color in console is different from the color requested and in the original CMD color is correctly interpreted

# Expected behavior

i expect colors to be shown correctly

# Actual behavior

Colors are not correctly shown

![image](https://user-images.githubusercontent.com/4005518/65869243-5ac6bd00-e37a-11e9-937c-a7c0b6b3d1b4.png)

![image](https://user-images.githubusercontent.com/4005518/65869414-b3965580-e37a-11e9-8f89-cfb0c62bd299.png)
Repository: go
Issue: net/http: TimeoutHandler hides panic after timeout
Labels: NeedsInvestigation

If `TimeoutHandler`'s inner handler panics after the timeout, the panic is discarded:
https://play.golang.org/p/GT7lVCBu163

This happens because [after the timeout](https://github.com/golang/go/blob/4faf8a8dc44555c4fdbe4fb108f42144e58ae6b1/src/net/http/server.go#L3254), `TimeoutHandler.ServeHTTP` doesn't wait for the inner handler to complete, and anything on `panicChan` is lost.
I understand that waiting for the inner handler would partly defeat the purpose of `TimeoutHandler`. If waiting is not acceptable, perhaps the docs should warn about dropped panics.

Also, `timeoutWriter.Push` panics if called after the timeout:
https://play.golang.org/p/-AZj5t-ViyJ
(Not sure if this should be a separate issue.)

This happens because `timeoutWriter.Push` may call the underlying `Push` after or concurrently with the completion of `TimeoutHandler.ServeHTTP` (after which `http2responseWriter.rws` is set to nil).
Of course the panic is not logged for the reason already mentioned.
Repository: vue-element-admin
Issue: Lots of deprecated packages
Labels: enhancement :star:

input 
```sh
$ git clone https://github.com/PanJiaChen/vue-element-admin.git
$ cd vue-element-admin
$ npm install 
```

output
```
npm WARN deprecated runjs@4.4.2: This project has been renamed to 'tasksfile'. Install using 'npm install tasksfile' instead.
npm WARN deprecated microcli@1.3.3: This project has been renamed to @pawelgalazka/cli . Install using @pawelgalazka/cli instead
npm WARN deprecated nomnom@1.8.1: Package no longer supported. Contact support@npmjs.com for more info.
npm WARN deprecated microargs@1.1.2: This project has been renamed to @pawelgalazka/cli-args. Install using @pawelgalazka/cli-args instead
npm WARN deprecated kleur@2.0.2: Please upgrade to kleur@3 or migrate to 'ansi-colors' if you prefer the old syntax. Visit <https://github.com/lukeed/kleur/releases/tag/v3.0.0\> for migration path(s).
npm WARN deprecated circular-json@0.3.3: CircularJSON is in maintenance only, flatted is its successor.
npm WARN deprecated left-pad@1.3.0: use String.prototype.padStart()
```
Repository: flutter
Issue: SSL configuration
Labels: c: new feature,tool,a: first hour,P2,team-tool,triaged-tool

Please add **SSL** configuration like in **npm** _ssl-strict_. i can't access https://pub.dartlang.org/api/packages/cupertino_icons or any other package while running command **flutter packages get** in project directory. but when i access via browser it's letting me smoothly.
Repository: rust
Issue: Two recursive trait strategies. Only one compiles.
Labels: A-type-system,A-trait-system,A-associated-items,T-compiler,T-types

## Overview

I made an example to define a list in type level, and wrote two ways to recursively insert a new typed key into the list. The complete example is in the gist link.
https://gist.github.com/jerry73204/364c4b61d884c1150807cdcc9357890d

In brief, the first way is to define a vanilla recursive trait like this. Then, impl cases on _found the key_ termination step and _not the key_ non-terminating step. It compiles and works.
```rust
pub trait Insert<NewKey, Target, Cnt>
where
    Cnt: Counter,
    Self: TList,
    Self::Output: TList,
{
    type Output;
}

impl<...> Insert<NewKey, Target, Current> for Cons<Target, Tail> ... {...}
impl<...> Insert<NewKey, Target, Next<Index>> for Cons<NonTarget, Tail> ... {...}
```

The second strategy is less straightforward. It defines a `Functor` trait such that any types with this trait works as type operator, which output is `<SomeType<Args> as Functor<Input>>::Output`.

Similarly, we define termination and non-terminating steps. However, it ends in `overflow evaluating` error.
```rust
pub struct InsertFunctor<NewKey, Target, Index>
where
    Index: Counter,
{
    _phantom: PhantomData<(NewKey, Target, Index)>,
}
impl<...> Functor<Cons<Target, Tail>> for InsertFunctor<NewKey, Target, Current> ... {...}
impl<...> Functor<Cons<NonTarget, Tail>> for InsertFunctor<NewKey, Target, Next<Index>> ... {...}
```

## Thoughts
In my naive observation, both ways have identical signatures in impl blocks. I would expect both compile or fail with same error. So I'm wondering what leads to the error, and the logic behind it.

If you're asking why functor indirection, I'm working on type level DSTs in a [little project](https://github.com/jerry73204/rust-type-freak), which allows users to wrap their own functor to apply on lists.

Edit:
Setup:
- rustc: 1.40.0-nightly
- cargo: 1.39.0-nightly 
- OS: Arch Linux
Repository: godot
Issue: Multi-threading debugger errors when using large loops
Labels: discussion,topic:core

**Godot version:** 3.11
**OS/device including version:**
Intel Core i7-4790K CPU
16GB ram
Windows 8.1 64bit

**Steps to reproduce:**
Main scene:
```
extends Spatial
var threadScene = load("res://Thread.tscn")

func _ready():
	print("ESC to cancel test. Check debugger for errors.")

func _input(event):
	if Input.is_action_pressed('exit'):
		get_tree().quit()

func _process(delta):
	var newThread = threadScene.instance()
	add_child(newThread)
	newThread.begin()
```
Thread scene:
```
extends Node
var thread = Thread.new()

func begin():
	thread.start(self, "_thread_function")

func _thread_function(userdata):
	var threadData = []
	for i in 100000:
		threadData.append(0)
	call_deferred("waitForCompletion")
	return threadData

func waitForCompletion():
	var data = thread.wait_to_finish()
	queue_free()
```
**Minimal reproduction project:** [Isolate Bug.zip](https://github.com/godotengine/godot/files/3670516/Isolate.Bug.zip)

**Issue description:**
If you let this run for a while (can take anywhere from 0-30 seconds) the debugger will fill with errors and lock up the game.

The time it takes to generate the errors is inconsistent and so is the amount of errors.
With this code I couldn't get the errors to appear at 50000 loops but it does appear at 100000 loops. To produce these errors I was originally using Vector3s in dictionaries (for terrain gen) but it looks like arrays have the same issue. In my game I get the errors using as little as 15000 loops but there's a lot more other stuff going on so I think it's about the intensity of the process.

This is the usual error:
```
E 0:00:02:0793   Condition ' len < 4 ' is true. returned: ERR_INVALID_DATA
  <C Source>     core/io/marshalls.cpp:108 @ decode_variant()

E 0:00:02:0793   Condition ' err != OK ' is true. Continuing..:
  <C Source>     core/script_debugger_remote.cpp:692 @ _poll_events()
```

But I've also seen this on occasion:
```
E 0:00:12:0153   Condition ' (type & 0xFF) >= Variant::VARIANT_MAX ' is true. returned: ERR_INVALID_DATA
  <C Source>     core/io/marshalls.cpp:113 @ decode_variant()

E 0:00:12:0154   Condition ' err ' is true. returned: err
  <C Source>     core/io/marshalls.cpp:487 @ decode_variant()

E 0:00:12:0155   Condition ' err ' is true. returned: err
  <C Source>     core/io/marshalls.cpp:531 @ decode_variant()

E 0:00:12:0155   Condition ' err != OK ' is true. Continuing..:
  <C Source>     core/script_debugger_remote.cpp:692 @ _poll_events()

E 0:00:12:0307   Condition ' var.get_type() != Variant::ARRAY ' is true. Continuing..:
  <C Source>     core/script_debugger_remote.cpp:693 @ _poll_events()
```

I don't know what any of this means. I am unable to use multi-threading as it currently is (the errors are freezing my game). Your help is appreciated.
Repository: kubernetes
Issue: Scheduler does not prioritize volume sizes
Labels: kind/bug,sig/scheduling,sig/storage,lifecycle/frozen

**What happened**:
With `volumeBindingMode: WaitForFirstConsumer`, scheduler does not take PV sizes into account when scheduling a Pod that can run anywhere and PVC that can find several available pre-provisioned PVs with various sizes.

**What you expected to happen**:
Scheduler tries to find as small PV as possible.

**How to reproduce it (as minimally and precisely as possible)**:
Let's have these PVs (each on a different node):
```
kind: PersistentVolume
apiVersion: v1
metadata:
  name: vol1
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 10Gi
  hostPath:
    path: /srv/vol1
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - ip-10-0-134-206

---

kind: PersistentVolume
apiVersion: v1
metadata:
  name: vol2
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 2Gi
  hostPath:
    path: /srv/vol2
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - ip-10-0-169-29
```

A PVC asking for 1GiB is randomly bound to `vol1` or `vol2`. It should prefer `vol2`.

**Anything else we need to know?**:
[Volume topology scheduling design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/volume-topology-scheduling.md)  mentions `PrioritizeVolumes` priority function, it seems it has never been implemented.

**Environment**:
- Kubernetes version (use `kubectl version`): 1.16.1
Repository: create-react-app
Issue: Global .scss declarations (variables etc...) without ejecting
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?
Yes, currentlly it isn't possible to globally load `.scss` files without needing them to be imported in _every_ `.scss` files. 

This issue is merely a duplicate of #5920 and the corresponding comment https://github.com/facebook/create-react-app/issues/1619#issuecomment-438755957.

### Describe the solution you'd like
Vue solves it by allowing the user to intercept the config-chain and prepending sass content into every .scss file like that (Snipped from `vue.config.js`):
```js
css: {
    loaderOptions: {
        sass: {
            // Global scss
            prependData: '@import "@/scss/_main.scss";'
        }
    }
},

... more config stuff
```


It's now possible to use the [prependData](https://github.com/webpack-contrib/sass-loader#prependdata) option for `css-loader` to allow this (I guess this wasn't possible back then - but now it is). Though I'm not sure how to realize that via `create-react-app-2` (I'm new to react)

### Describe alternatives you've considered
The only alternative is to import your "global" `.scss` file every time.
Repository: go
Issue: x/crypto/ssh/terminal: terminal.ReadPassword doesn't work when using Bash for Windows (from Git installation)
Labels: help wanted,OS-Windows,NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12.5 windows/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\mrausc\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\mrausc\go
set GOPROXY=
set GORACE=
set GOROOT=C:\MyProgs\Go
set GOTMPDIR=
set GOTOOLDIR=C:\MyProgs\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=X:\swda\play\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\mrausc\AppData\Local\Temp\go-build325358090=/tmp/go-build -gno-record-gcc-switches

</pre></details>

### What did you do?

<pre>
func main() {
	_, err := terminal.ReadPassword(int(os.Stdin.Fd()))
	fmt.Println(err)
}
</pre>


### What did you expect to see?
no echo of password


### What did you see instead?
"The handle is invalid."
Repository: rust
Issue: 1.38 regression ? proc-macro derive panicked if there is r# in front of the attribute name
Labels: A-attributes,P-medium,A-macros,T-compiler,regression-from-stable-to-stable

I have a macro and it defines an attribute called "async".  When I use it, I add r# in front of it. I have this : 

```
#[cowrpc(r#async)]
struct Handshake {
...
}
```

Since 1.38.0, it fails with 

```
error: proc-macro derive panicked
 --> src/cow/den_server_iface.rs:3:10
  |
3 | #[derive(CowRpcIface)]
  |          ^^^^^^^^^^^
  |
  = help: message: "r#async" is not a valid ident

error: proc-macro derive panicked
```

It was building without any error before. What is different with 1.38?