sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: Updates to ms-terminal terminal type in terminfo to 1.4 from 0.2
Labels: Area-VT,Product-Terminal,Product-Meta,Issue-Task

In #8291 it was noted that the [`ms-terminal`](https://invisible-island.net/ncurses/terminfo.src.html#tic-ms-terminal) record in the terminfo database dates from version 0.2 of Windows Terminal.  We are now on version 1.4.  So let's construct a list of _concrete and specific_ amendments to the 0.2 `ms-terminal` record that match the current behaviour of Windows Terminal.

Here's what I can see so far:
* `Se=\E[2 q` and `Ss=\E[%p1%d q` &mdash; Windows Terminal supports DECSCUSR (#4734)
* [`xterm+256setaf`](https://invisible-island.net/ncurses/terminfo.src.html#tic-xterm_256setaf) &mdash; Windows Terminal supports indexed colour.  Perhaps instead [`xterm+indirect`](https://invisible-island.net/ncurses/terminfo.src.html#tic-xterm_indirect) which also contains the `RGB` capability, because Windows Terminal supports direct colour too, although that does change the semantics of colours 8 to 255.

Furthermore:
* What, if anything, needs to be fixed to get the problem in #6733 to go away?  Windows Terminal has REP now, so [`ansi+rep`](https://invisible-island.net/ncurses/terminfo.src.html#tic-ansi_rep) should be alright now.
* Is IRM supported yet?  (#1947)  Otherwise `rmir@` and `smir@` are needed.
* What do we need for `XM`?  (#8291)

Note that this is _not_ #2958 . This is _not_ about Microsoft creating its own terminfo record, but is rather about what can be passed along to Thomas Dickey for updating the Dickey terminfo database from Windows Terminal 0.2 to 1.4.
Repository: TypeScript
Issue: Labeled maps, set and records
Labels: Suggestion,Awaiting More Feedback

## Suggestion

Following on the idea of [labeled tuples](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-0.html#labeled-tuple-elements) and parameter names, would it be possible to label `Map`, `Set` and `Record`?

## Use Cases

It would help to communicate the intent of the different parts.

## Examples

`Map<tabId: number, annotationCount: number>`
`Record<tabId: number, annotationCount: number>`
`Set<tabId: number>`

## Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [ ] This wouldn't change the runtime behavior of existing JavaScript code
* [ ] This could be implemented without emitting different JS based on the types of the expressions
* [ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [ ] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: [dataloader] Worker threads to print the signal they received before they die
Labels: module: dataloader,triaged,enhancement

Usually, this indicates problems with leaking memory (https://github.com/pytorch/pytorch/issues/13246) or some problems with ulimit and number of open files. If possible, it would be good if they printed something before they die (if possible in Linux):

Relevant code locations:
https://github.com/pytorch/pytorch/blob/master/torch/utils/data/_utils/worker.py#L134
https://github.com/pytorch/pytorch/blob/2b221a95997b00dcc166918f752b2ad8e921eb15/torch/csrc/DataLoader.cpp#L90

cc @SsnL @VitalyFedyunin @ejguan
Repository: pytorch
Issue: [JIT] Optimization pass in profiling executor to fold away conditional branches
Labels: oncall: jit

## 🚀 Feature

With profiling information, we should be able to remove conditional branches based on profiling information, including tensor ranks, device and boolean ivalue, e.t.c..

## Motivation

Conditional branches creates hierarchies that prevents us to exploit fusion opportunities, because currently fusion is limited to operations within the same block. With profiling executor, we should be able to fold away many conditional branches but unfortunately we don't have any passes to do that.

Two concrete examples that we are currently facing:

1. autodiff `dropout` contains many branches that stops us from fusing dropout with following operations. Which is a very common pattern.

https://github.com/pytorch/pytorch/blob/49f0e5dfeb64a928c6a2368dd5f86573b07d20fb/torch/csrc/jit/runtime/symbolic_script.cpp#L1083-L1111

2. python definition of `linear` layer has conditional eager fusion on gemm that kills the opportunity to fuse bias-add to following operations.

https://github.com/pytorch/pytorch/blob/49f0e5dfeb64a928c6a2368dd5f86573b07d20fb/torch/nn/functional.py#L1663-L1671

## Pitch

We can/should lift the checks of branching conditions to an earlier stage through exploiting profiling information. Things like tensor rank / device / training flag doesn't change often, if at all. This would greatly simplifies control flow and expose more fusion opportunities.

## Alternatives

A simpler WAR would be to remove the control flow in the graph. In the two examples mentioned above, we can:
1). For autodiff dropout, incorporate conditional variable as parameters of composite operation. e.g. a specialized `dropout_cuda` node that takes `train` as an argument;
2). For `torch.nn.linear`, maybe hide the eager mode fusion from JIT. Branch for `bias` is tricky and I don't have an easy solution.

## Additional context

Our investigation start from #45519.

cc @gmagogsfm
Repository: pytorch
Issue: [JIT] Constant folding on no-op `aten::mul`
Labels: oncall: jit

## 🚀 Feature

We are seeing the following pattern in optimized graphs:
```
  %73 : int = prim::Constant[value=1]()
  %86 : Tensor = aten::mul(%0, %73)
```
We should be able to realize that this is an no-op and fold away `%86` when it's safe to do so.

## Motivation

The issue showed up when we were comparing eager vs jit and were observing an extra PW kernel in JIT. Upon further investigation we located this:

https://github.com/pytorch/pytorch/blob/49f0e5dfeb64a928c6a2368dd5f86573b07d20fb/torch/csrc/jit/runtime/symbolic_script.cpp#L1231-L1241

With `grad_output * alpha`, for a simple add where `alpha == 1`, the multiplication ended up as an extra kernel that does nothing. Comparing to autograd in eager, where we avoid this no-op multiplication via `maybe_multiply`: 

https://github.com/pytorch/pytorch/blob/49f0e5dfeb64a928c6a2368dd5f86573b07d20fb/tools/autograd/derivatives.yaml#L167-L169

## Pitch

In the example above, it should be easy to identify the pattern (where `%2` being an intermediate tensor)
```
%1 : int = prim::Constant[value=1]()
%2 : Tensor = aten::mul(%0, %1)
```
If we can move user of `%2` right after the op and confirm that it does not writeTo/alias `%2`, it is safe for us to fold away this no-op multiplication.

cc @gmagogsfm
Repository: pytorch
Issue: [JIT][PE] Profiling Executor should re-profile `DifferentiableGraph`
Labels: oncall: jit

## 🚀 Feature

Profiling Executor should re-profile the forward graph of `DifferentiableGraph`

## Motivation

`differentiate` pass modifies the profiled graph into forward graph in `DifferentiableGraph`. This resulted in missing profiling information in the new graph. This is causing issue in codegen, which requested certain Tensor to be profiled and assumed access to profiling information.

e.g. in the code snippet below, `dropout` node is expanded to a group of nodes in `DifferentiableGraph` and no intermediate tensor in the expanded groups are getting profiled.

https://github.com/pytorch/pytorch/blob/49f0e5dfeb64a928c6a2368dd5f86573b07d20fb/torch/csrc/jit/runtime/symbolic_script.cpp#L1083-L1111

## Additional context

I have a toy PR that tries to use `GraphExecutor` instead of `Code` to run forward graph #47434. It's breaking the world since I blindly disabled `runDiffGraphPasses`, which I should probably only turn off the fusion pass there. But It could be more subtle than that and I might be poking the wrong thing.

cc @gmagogsfm
Repository: youtube-dl
Issue: Youtube thumbnails get converted from webp to jpeg, make it optional please
Labels: request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2020.11.17. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Search the bugtracker for similar feature requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a feature request
- [x] I've verified that I'm running youtube-dl version **2020.11.17**
- [x] I've searched the bugtracker for similar feature requests including closed ones


## Description

<!--
Provide an explanation of your issue in an arbitrary form. Please make sure the description is worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient. Provide any additional information, suggested solution and as much context and examples as possible.
-->

When I use _--list-thumbnails_ I get:
`4   1920   1080   https://i.ytimg.com/vi_webp/abcdefghijk/maxresdefault.webp`

But when I use _--write-thumbnail_ and _--embed-thumbnail_ I get this:
`[ffmpeg] Converting thumbnail "Some youtube video (abcdefghijk).webp" to JPEG`

But I want the original WEBP image please. Make the conversion optional please.
Repository: go
Issue: x/build: consider opting-in to longtest builders by default for cmd/go changes, if/when they're under 15 min
Labels: Builders,NeedsInvestigation,GoCommand

(I have a feeling @bcmills may have already filed an issue for this, but I couldn't find it. Maybe it was a comment instead.)

With the progress made on https://github.com/golang/go/issues/37439#issuecomment-723413000 recently, it seems we can speed up longtest SlowBots to run in under 15 minutes or so. If that can be done, what is your preference on enabling longtest builders by default for changes that touch the `go` command? CC @bcmills, @jayconrod, @matloob.

In either case, we need to wait for #37439 to be completed first, and give it a little time to see if that on its own is sufficient. But I wanted to create a tracking issue to start gathering feedback eagerly.

I'm also looking for feedback on:

- If this is something we want to do, would you prefer that "cmd/go" changes are determined by the commit subject having the "cmd/go" path present (which is up to the author), or by looking whether any files in src/cmd/go directory are modified?

Also CC @golang/release.
Repository: godot
Issue: Antialiasing only works via plugin draw overlays in GLES3, doesn't work in other cases (neither at run-time nor editor)
Labels: bug,topic:rendering,topic:2d

**Godot version:**
3.2.4 beta 8dde60d13
Somewhat similar to #38872.

**OS/device including version:**
Windows 10
NVIDIA GeForce GTX 750 Ti (driver version 26.21.14.3648)
GLES3

**Issue description:**
This seems to happen with any kind of geometry drawing where `antialiasing` property/parameter is exposed:

### `draw_line`

![godot_line_antialiasing](https://user-images.githubusercontent.com/17108460/99404658-914ff600-28f4-11eb-8a52-647fc7402ba4.png)

### `draw_colored_polygon`

![godot_polygon_antialiasing](https://user-images.githubusercontent.com/17108460/99404674-944ae680-28f4-11eb-816c-e8d3679a4cd8.png)

Antialiasing works fine in GLES2 (both in editor and at run-time). Tried with batching on and off, same results.

**Steps to reproduce:**
This does not work:
```gdscript
tool
extends Node2D

var points = [Vector2(90, 100), Vector2(100, 230), Vector2(250, 200), Vector2(300, 105)]

func _draw():
	for i in points.size() - 1:
		draw_line(points[i], points[i + 1], Color.white, 1.0, true)

#	draw_colored_polygon(points, Color.white, [], null, null, true)
```
This works:
```gdscript
tool
extends EditorPlugin

var points = [Vector2(90, 100), Vector2(100, 230), Vector2(250, 200), Vector2(300, 105)]

func _enter_tree():
	update_overlays()

func handles(object):
	# To trigger `forward_canvas_draw_over_viewport`
	return object is Node2D

func forward_canvas_draw_over_viewport(overlay):
	# Same as in main.gd
	for i in points.size() - 1:
		overlay.draw_line(points[i], points[i + 1], Color.white, 1.0, true)

#	overlay.draw_colored_polygon(points, Color.white, [], null, null, true)
```

**Minimal reproduction project:**
[draw_antialiased_gles3.zip](https://github.com/godotengine/godot/files/5554246/draw_antialiased_gles3.zip)
Repository: go
Issue: runtime: work.cycles should consider integer overflow
Labels: NeedsDecision,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel +13f59a65 Sat Nov 7 10:28:10 2020 +0800 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
not test


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/taoqy/.cache/go-build"
GOENV="/home/taoqy/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/taoqy/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/taoqy/go"
GOPRIVATE=""
GOPROXY="https://goproxy.io"
GOROOT="/home/taoqy/cc/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/taoqy/cc/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build557590123=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

```go
package main

import (
        "fmt"
        "runtime"
        _ "unsafe"
)

type Work struct {
        _ [400 - 96]byte

        // cycles is the number of completed GC cycles, where a GC
        // cycle is sweep termination, mark, mark termination, and
        // sweep. This differs from memstats.numgc, which is
        // incremented at mark termination.
        cycles uint32

        // Timing/utilization stats for this cycle.
        stwprocs, maxprocs                 int32
        tSweepTerm, tMark, tMarkTerm, tEnd int64 // nanotime() of phase start

        pauseNS    int64 // total STW time this cycle
        pauseStart int64 // nanotime() of last STW

        // debug.gctrace heap sizes for this cycle.
        heap0, heap1, heap2, heapGoal uint64
}

//go:linkname work runtime.work
var work Work

func main() {
        work.cycles = ^uint32(0) - 3
        runtime.GC()
        fmt.Println(work.cycles)
        runtime.GC()
        fmt.Println(work.cycles)
        runtime.GC()
        fmt.Println(work.cycles)
}

```



### What did you expect to see?
exit normally.


### What did you see instead?
```
4294967293
4294967294
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [wait for GC cycle]:
runtime.GC()
        /home/taoqy/cc/go/src/runtime/mgc.go:1162 +0xa5
main.main()
        /tmp/wgc/main2.go:41 +0x105
```
Repository: vue
Issue: Enable performance measuring in production, at the user's request
Labels: feature request

### What problem does this feature solve?
Similar to devtools, `Vue.config.devtools` is enabled by default for development and disabled by default for production.  However, the developer can choose to override that behavior (for example, for debugging) by manually setting `Vue.config.devtools = true`.  However, this same lenience is not afforded to `Vue.config.performance`.  Even if explicitly enabling it, the developer's setting will be overridden by Vue in production.

### What does the proposed API look like?
This proposed solution brings `Vue.config.performance` in line with `Vue.config.devtools`, by disabling it by default in production, but gives the developer the ability to explicitly enable it; for example, for debugging performance issues.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: godot
Issue: .global_transform.basis.get_euler() returns data not useable for .rotation
Labels: discussion,topic:core

**Godot version:**
3.2.3.stable (Steam)

**Issue description:**
I ask meshinstance for .global_transform.basis.get_euler() to use for rotation while spawning new mesh with fading material
The current mesh (cube) seems return proper data. But his nearby-translated child (the stick) returns incorrect data.
![ezgif-3-882bcd353b0b](https://user-images.githubusercontent.com/41639190/99413060-6cfd1500-2906-11eb-8b5e-9b5c935c2afc.gif)

**Steps to reproduce:**
1) ask displaced children around for their .global_transform.basis.get_euler()
**update: 1-a) CHILD MUST BE SCALED!!**
2) use that value for .rotation of other objects

**Minimal reproduction project:**
[origineuler.zip](https://github.com/godotengine/godot/files/5554603/origineuler.zip)
Repository: pytorch
Issue: quantization - document get_default_qconfig
Labels: oncall: quantization,triaged

## 📚 Documentation

See https://discuss.pytorch.org/t/get-default-qconfig-appears-in-docs-but-not-in-api-reference/103010.  We should make sure this is documented and easy to discover.

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @jgong5 @Xia-Weiwen @leslie-fang-intel @dzhulgakov @vkuzo
Repository: flutter
Issue: Retry Xcode build on "unable to attach DB: unable to initialize database (database is locked)"
Labels: tool,t: xcode,P2,team-tool,triaged-tool

```
    ** BUILD FAILED **
Xcode's output:

↳
error: unable to attach DB: unable to initialize database (database is locked)
note: Using new build system
note: Building targets in parallel
note: Planning build
note: Constructing build description
Could not build the precompiled application for the device.
Error launching application on iPhone.
```
The "unable to initialize database" should kick off a retry.
https://github.com/flutter/flutter/blob/91b82347af8a565b5aed241024c49611b83ac13b/packages/flutter_tools/lib/src/ios/mac.dart#L514-L519
Repository: pytorch
Issue: JIT should not force users to write ugly code
Labels: oncall: jit,TSUsability

Writing code for JIT is currently incredibly unpleasant, because it inherently wants you to split logic that belongs to the same function/module to different places. For example, take a look at the following two extremely common patterns:

1. Jittable parts of a (partially jittable) function has to be broken into a separate function. (Or, equivalently, put the non-jittable parts into a python autograd fn, a workaround from @t-vi . )
    ```py
    def myfunc(x, y):
      ... input_check(x, y)
      z = _myfunc1(x, y)
      ... some non-jittable parts: e.g., io/error check
      return _myfunc2(x, y, z)
  
    @torch.jit.script
    def _myfunc1(x, y): ...
  
    @torch.jit.script
    def _myfunc2(x, y): ...
    ```

2. A scripted module has to break modularity. Users must **at creation time** script it, unlike the scripted functions. From the design perspective, sure you have to have a callable to script. However, from a UI perspective, users can never have modular code that works on both modules that should be jitted and modules that should not, unless they do the following hacks: 
    ```py
    class ModuleToScript(nn.Module):
        _should_script = True
       ...

    class ModuleNotToScript(nn.Module):
        _should_script = False
       ...

    def create_module(cls, ...):  # NB: users should *ONLY* use this to create module
        m = cls(...)
        if cls._should_script:
           m = torch.jit.script(m)
        return m
    ```

3. Tracing has similar issues.


The current JIT behavior is not "wrong" per se.  However, it really leads to bad coding patterns once you want to write some flexible code, to the extent that it feels actively working against you. And flexibility is really the thing that makes all us use PyTorch for research.

It also does not help that JIT UX improvement issues are almost never worked on: https://github.com/pytorch/pytorch/issues/29092, https://github.com/pytorch/pytorch/issues/29177, https://github.com/pytorch/pytorch/issues/16293, https://github.com/pytorch/pytorch/issues/40914

Related to 2: https://github.com/pytorch/pytorch/issues/25066

Finally, I have two solution proposals. They may not be viable, but are nice from UX perspectives. 
- To solve 1: Have a way to annotate that "this part of the function should only be run in python". E.g., `with torch.jit.script.pure_python(): ....`
- To solve 2: Have a class decorator like `torch.jit.script.register_module` which would script automatically after creation. 

cc @gmagogsfm
Repository: go
Issue: cmd/compile: missed add+load combination opportunity
Labels: Performance,NeedsInvestigation,compiler/runtime

```
func f(a []int) int {
	s := 0
	for _, x := range a {
		s += x
	}
	return s
}
```
Generates for the inner loop
```
		MOVQ	(AX)(DX*8), SI
		INCQ	DX
		ADDQ	SI, BX
		CMPQ	CX, DX
		JGT	16
```
There's no reason we couldn't do `ADDQ (AX)(DX*8), BX` instead of the MOVQ/ADDQ combo.

There's actually code that does this combining optimization in the compiler, but it doesn't trigger. The difficulty is that the combined ADDQ instruction will clobber its input, so we don't combine when the non-load argument to the ADDQ is used somewhere else (see `rewrite.go:canMergeLoadClobber`). In this case the other use of BX is at the return statement. But that use shouldn't stop the optimization from happening, as it is in a separate branch. At the actual point where we're doing the optimization, the old value of BX is dead.
Repository: flutter
Issue: ButtonStyle merge does not merge
Labels: framework,f: material design,has reproducible steps,found in release: 3.3,found in release: 3.6,team-design,triaged-design

In my example, https://gist.github.com/NebulaFox/172e7ac344370935b3d12b8aa5fc0400, I have defined a default/base style for `ElevatedButton`, which is styled based on the `_toggle` property of the state class. When using the `merge` method to change the base style, it appears the style is not being merged in.

**Expected results:** <!-- what did you want to see? -->

The button should toggle between two different styles

**Actual results:** <!-- what did you see? -->

No change in style

```
[✓] Flutter (Channel beta, 1.23.0-18.1.pre, on Mac OS X 10.14.6 18G6032 x86_64,
    locale en-GB)
    • Flutter version 1.23.0-18.1.pre at /usr/local/flutter
    • Framework revision 198df796aa (5 weeks ago), 2020-10-15 12:04:33 -0700
    • Engine revision 1d12d82d9c
    • Dart version 2.11.0 (build 2.11.0-213.1.beta)
```