sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: 3.2. Object disappearing when using the scrollwheel outside of running window Visibility Rect
Labels: bug,topic:rendering,needs testing,topic:2d,topic:particles

**Godot version:** 3.2 beta4

**OS/device including version:** Win7

**Issue description:**
When using the mouse scrollwheel outside of the running window, particles disappear. Moving the mouse back into the window area causes the particles to reappear. The scrollwheel has no affect if mouse is inside the running window. There is no input map assigned to the mouse scrollwheel. No code using the scrollwheel scancode. The issue is present when running the project from the editor as well as when running the exported project.
![particles_scrollwheel](https://user-images.githubusercontent.com/47016402/71607561-a73cb700-2b7a-11ea-9e9e-a74ee7a79c48.gif)


**Steps to reproduce:**
Run the minimal project and scroll inside vs outside the running window. Edit: Scroll beyond the Visibility Rect!

**Minimal reproduction project:**
[particle_test_scrollwheel.zip](https://github.com/godotengine/godot/files/4011745/particle_test_scrollwheel.zip)

Godot4 Beta4 MRP: 
[scrollwheel_visibility_test.zip](https://github.com/godotengine/godot/files/9984247/scrollwheel_visibility_test.zip)
Repository: flutter
Issue: Equivalent of `InkWell` in Cupertino style
Labels: c: new feature,platform-ios,framework,a: fidelity,f: cupertino,customer: crowd,c: proposal,P2,team-design,triaged-design

We already have `InkWell` widget for tap effect in material style. Is there any equivalent in Cupertino style?

Example here: https://developer.apple.com/design/human-interface-guidelines/ios/images/Gestures_Tap.mp4

After tapping the **Sounds & Haptics** section, its background color turns into gray immediately.
Repository: electron
Issue: Remove the size limit of picture in picture video popout
Labels: enhancement :sparkles:

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

### Problem Description
Electron 7 enabled the ability to toggle picture in picture (pip) mode for videos. It works great but the resulting popout has a a maximum size limitation (around 1/3 of screen). I think that this limitation impacts potential use of this functionality. For instance you cannot move video to another screen and use it's full size.

### Proposed Solution
Remove the maximum size limitation and allow the user to set any video size.
Repository: storybook
Issue: Reduce size of react-syntax-highlighter dependency
Labels: ui,performance issue

When built, the manager + preview are around 2.6 MB excluding the user's code. Even for a development tool, this is quite a hefty amount. 

I've been investigating different ways this can be reduced, and by far the largest contributor to the bundle size is `react-syntax-highlighter`. It's an astronomical 1.2 MB 😲 https://bundlephobia.com/result?p=react-syntax-highlighter@12.2.1  

This is a picture of just the manager, broken down into dependencies by size: 
![Screen Shot 2019-12-31 at 4 50 01 PM](https://user-images.githubusercontent.com/11994993/71626711-e4429100-2bee-11ea-924f-9766bb2b05c4.png)

`highlight.js` and `refractor` are both dependencies of `react-syntax-highlighter`, and as you can see the configuration for many different languages is loaded.

The docs explain the size can be reduced by using a [light build](https://github.com/conorhastings/react-syntax-highlighter#light-build) or an [async build](https://github.com/conorhastings/react-syntax-highlighter#async-build).

The async build looks ideal and doesn't introduce breaking changes, but I don't know if you guys want to include dynamic imports in storybook. The light build can also work, but might require the user to load the languages or provide configuration of languages to include.

I'm happy to work on this if this is something you guys want.
Repository: vscode
Issue: Diff editor: Differentiate unimportant differences
Labels: feature-request,diff-editor

I would like the ability to differentiate unimportant/minor differences in the diff editor. This is somewhat related to #43026, except this is not only about whitespace and ideally _ignore_ should only be one of the ways this differentiation is used (e.g. different coloring). Obviously the semantics for what's "unimportant" is subjective and/or language-dependent. You might be able to use the language grammar (or new semantic API) to determine this in addition to some user configurability. **Beyond Compare** allows this differentiation based on a grammar with user configurability, and it's very useful.

The following are some examples of unimportant differences:

- Whitespace in a whitespace-insensitive language
- Case in a case-insensitive language
- Comments
- Strings?
Repository: pytorch
Issue: Need a launch utility for Distributed RPC framework.
Labels: triaged,better-engineering,module: rpc

We need a launch utility similar to what we have for DDP: https://github.com/pytorch/pytorch/blob/master/torch/distributed/launch.py to easily launch multiple RPC workers on the same host. We could either reuse the same utility and extend it to support the Distributed RPC Framework as well.


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528 @jjlilley
Repository: flutter
Issue: Need better documentation for DrawShadow (what is elevation?)
Labels: engine,d: api docs,P3,team-engine,triaged-engine

Neither the Dart side [`Canvas.drawShadow`](https://github.com/flutter/engine/blob/eb05391962fb74e0152d6bb9827abdf341113de5/lib/ui/painting.dart#L4018) nor the engine side [`Canvas::drawShadow`](https://github.com/flutter/engine/blob/eb05391962fb74e0152d6bb9827abdf341113de5/lib/ui/painting/canvas.cc#L413), i.e. [`flutter::PhysicalShapeLayer::DrawShadow`](http://34.94.103.149/classflutter_1_1_physical_shape_layer.html#ac5d99b79c8a24ca58446d601af248db9) have *any* information on how **`elevation`** works exactly and I could also not find out what values do what exactly at different scales etc.  
The only thing I can say for sure is that the Flutter web implementation of the method behaves completely different than the native version.

## Needs better documentation

I think that better documentation for this function is needed in general, but more specifically I would like to know how `elevation` works exactly - from the native code I would have concluded that values from `0` to `600` make sense because [the light source is positioned at `z = 600`](http://34.94.103.149/namespaceflutter.html#af5a46f83182e00e27bf950417af3ea2b), however, that does not exactly line up with my experiments in native (I gave up on web behavior).  
Additionally, it would be useful to know where the light source is positioned - I would assume that it is positioned at `(0, 0, 600 * dpr)`, but I have no idea at this point.
Repository: go
Issue: encoding/gob: permit registering duplicate names
Labels: NeedsInvestigation,FeatureRequest

In go1.9, type aliases were introduced. The purpose of type aliases is to permit the movement of types from one location to another. This implies:
1) that the _real_ name of the type can change over time
2) that there can be _multiple_ names for the exact same Go type

The use of type aliases interacts poorly with gob-encoded data stored on disk that represent interface values as `gob` was a developed in an era where there was one-to-one relationship between types and names.

Consider the following examples.

At some point in the past, we [gob-encoded is stored on disk using something like](https://play.golang.org/p/dt0pW47u17P):
```go
type Rect struct { ... }
func (r Rect) Area() int { ... }
type Any struct {
	Shape interface{ Area() int }
}

func main() {
	gob.Register(Rect{})

	var b bytes.Buffer
	e := gob.NewEncoder(&b)
	e.Encode(Shape{Rect{2, 5}})
	
	// assume that b is stored on disk
	fmt.Printf("%q\n", b.String())
}
```

On the decoder side, [this works fine with code like](https://play.golang.org/p/GXlOGbcTGvy):
```go
type Rect struct { ... }
func (r Rect) Area() int { ... }
type Any struct {
	Shape interface{ Area() int }
}

func main() {
	// Assume that the contents of r is loaded from disk as created by:
	// https://play.golang.org/p/dt0pW47u17P
	r := strings.NewReader(...)

	gob.Register(Rect{})

	d := gob.NewDecoder(r)
	v := new(Shape)
	fmt.Println(d.Decode(v)) // got nil; works as expected
}
```

At some point in the future, [suppose we move `Rect`, now decoding fails](https://play.golang.org/p/6vu43aUdTm-):
```go
type Rect = Rect2 // this is now a type alias to a different name
type Rect2 struct { ... }
func (r Rect2) Area() int { ... }
type Any struct {
	Shape interface{ Area() int }
}

func main() {
	// Assume that the contents of r is loaded from disk as created by:
	// https://play.golang.org/p/dt0pW47u17P
	r := strings.NewReader(...)

	gob.Register(Rect{})

	d := gob.NewDecoder(r)
	v := new(Shape)
	fmt.Println(d.Decode(v)) // got `gob: name not registered for interface: "main.Rect"`, expected nil
}
```

The problem is that the full type name is encoded in the gob wire data. Trying to decode the data at a later date does not know about the movement of the type due to type aliases.

Given that problem, one would think that you could just use `gob.RegisterName` to manually register the old name:
```go
gob.RegisterName(Rect{})
gob.RegisterName("main.Rect", Rect{})
```
However, that panics with:
```
panic: gob: registering duplicate names for main.Rect2: "main.Rect2" != "main.Rect"
```

I propose the following changes:
1) That `gob` be better documented about the interaction of type aliases and serialization of interface values.
2) That `gob.RegisterName` be relaxed to permit duplicate names. However, this can cause confusion in the implementation as to which name to use when marshaling. Alternatively, we could add a `gob.RegisterAlias` that makes it clear that the duplicate names are aliases.
Repository: go
Issue: cmd/compile: teach prove about incrementing, len, and overflow
Labels: Performance,NeedsInvestigation,compiler/runtime

I have some hot code that looks approximately like this:

```go
func f(a []int, i int) int {
	for i < len(a) && a[i] != 0 {
		i++
	}
	return i
}
```

The generated code has a bounds check on every iteration. This is because `i` might be negative. We can rule that out up front:

```go
func f(a []int, i int) int {
	if i < 0 {
		panic("bad")
	}
	for i < len(a) && a[i] != 0 {
		i++
	}
	return i
}
```

This could should be able to go without a bounds check. `i` cannot be negative at the beginning. In order to become negative, it must overflow. However, it cannot overflow: It is being incremented, so it must reach `len(a)` before overflowing, in which case we exit the loop before evaluating `a[i]`.

(I actually know a priori in my code that `i` is not negative; I'd be tempted to use #30582 here. I could also switch to `i` being a uint, which does remove the bounds check, but it makes other things in the real code a bit awkward.)

I don't know how hard it is to teach prove about this case.

cc @zdjones @rasky @randall77
Repository: vue
Issue: serverPrefetch rejection with no value creates broken response
Labels: improvement,has workaround

### Version
2.6.11

### Reproduction link
[http://sorry-no-can-do.com](Sorry, I don't have time to setup a reproduction case for SSR, that's not a 5 minute thing).







### Steps to reproduce
1. Use SSR
2. Add a `serverPrefetch` with `return Promise.reject()`

### What is expected?
An error to occur due to the rejection in `serverPrefetch`

### What is actually happening?
No error occurs, but the rendered result will not contain the component with the bad `serverPrefetch`.

---
Currently, rejecting a promise in `serverPrefetch` with no value will create a broken response from SSR. By broken I mean that no error will occur with `renderToString`, so it looks like it was successful, but the rendered DOM may be missing components, including the root component all together.

This is because the rejection value from `serverPrefetch` is wired straight through to the `done` callback on `render`, but that callback only considers an error to have occurred if a value is provided. Due to this straight wiring, any `serverPrefetch` which rejects without a value will allow rendering to continue, but will skip the rendering of the component on which the error occurs. If that's the root component, the rendered result has no element for hydration to use in the rendered result, which means there's no way for the client to recover. For a real-life example of this, see vuejs/vue-apollo#901.

Here's the relevant code, the `done` callback for `render`:

https://github.com/vuejs/vue/blob/42fdf3f8378e5dc379808a4fa67b39c4a74ae191/src/server/create-renderer.js#L84-L87

And where the rejection value from `serverPrefetch` is wired through:

https://github.com/vuejs/vue/blob/42fdf3f8378e5dc379808a4fa67b39c4a74ae191/src/server/render.js#L65

A fix could be as easy as expanding that `catch` to check for `err` and provide a default value if one is not provided. I'm punting on what that default would be, so I'm opening this as an issue rather than a PR.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: TypeScript
Issue: Missing syntax error for destructuring with private names
Labels: Bug

<!-- 🚨 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 the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.8.0-dev.20191228

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
class C{
    #prop = 1;
    method() {
        const { #prop/*1*/: prop } = this;
        ({ #prop/*2*/: this.#prop } = this);
    }
}
```

**Expected behavior:**

Error at `/*1*/` and `/*2*/` since this syntax is not (yet) allowed. https://github.com/tc39/proposal-class-fields/issues/4

Thanks to @dragomirtitian for pointing this out.

**Actual behavior:**

No error.

**Playground Link:** https://www.typescriptlang.org/play/?ts=3.8.0-dev.20191228&ssl=7&ssc=2&pln=1&pc=1#code/MYGwhgzhAEDCDeAoaLoGIAOAnA9h6AvNAIwDcyqAtgKYAuAFjgCYAUAlNEqt9MDgHYRandNjwAuaGPwBfQtAYBLCOR6oW8UbgySlEAHSZt0OUT1tVqGYhlA

**Related Issues:**  #35934 #35935 #35936
Repository: pytorch
Issue: DataLoader: Segmentation Fault (core dumped)
Labels: high priority,needs reproduction,module: crash,module: dataloader,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

## To Reproduce

Steps to reproduce the behavior:

1. python train.py
1.

```
dataloader = DataLoader(
                                   dataset,
                                   batch_size=1,
                                   num_workers=0,
                                   pin_memory=True)
for index, item in enumerate(dataloader):
```

## Expected behavior
train
<!-- A clear and concise description of what you expected to happen. -->

## Environment
Please copy and paste the output from our
[environment collection script](https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py)
(or fill out the checklist below manually).

You can get the script and run it with:
```
wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py
```

 - PyTorch Version (e.g., 1.0):
 - OS (e.g., Linux):
 - How you installed PyTorch (`conda`, `pip`, source):
 - Build command you used (if compiling from source):
 - Python version:
 - CUDA/cuDNN version:
 - GPU models and configuration:
 - Any other relevant information:

PyTorch version: 1.1.0
Is debug build: No
CUDA used to build PyTorch: 10.0.130

OS: Ubuntu 16.04.6 LTS
GCC version: (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
CMake version: version 3.5.1

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 9.0.176
GPU models and configuration: GPU 0: GeForce RTX 2080 Ti
Nvidia driver version: 430.50
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.4
/usr/local/lib/libcudnn.so.7

Versions of relevant libraries:
[pip3] numpy==1.16.4
[conda] _pytorch_select           0.2                       gpu_0    defaults
[conda] blas                      1.0                         mkl    https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free
[conda] cuda100                   1.0                           0    pytorch
[conda] cuda90                    1.0                  h6433d27_0    pytorch
[conda] mkl                       2018.0.3                      1    defaults
[conda] mkl-service               1.1.2            py37h90e4bf4_5    defaults
[conda] mkl_fft                   1.0.6            py37h7dd41cf_0    defaults
[conda] mkl_random                1.0.1            py37h4414c95_1    defaults
[conda] pytorch                   1.1.0           py3.7_cuda10.0.130_cudnn7.5.1_0    pytorch
[conda] torchvision               0.3.0           py37_cu10.0.130_1    pytorch

## Additional context

<!-- Add any other context about the problem here. -->


cc @ezyang @gchanan @zou3519 @SsnL @VitalyFedyunin
Repository: pytorch
Issue: Allow using digits in names of named tensors
Labels: triaged,enhancement,module: named tensor

## 🚀 Feature

Currently you cannot use digits in names of tensors. Please allow digits, so that `torch.randn(64, 64, 4, 4, names=("height", "width", "channel_0", "channel_1"))` works rather than throwing an error

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

I am studying machine learning models which are hybrid between neural networks and tensor networks. When working with tensor networks, we have a lot of tensors with a lot of dimensions. Sometimes we have multiple dimensions corresponding to, say, channels. Or sometimes, for example in tensor train, we have a lot of bond dimensions, which come in pairs. For example, in the model I am currently working on, at some point I have an intermediate representation of a batch of images as 4 tensors, for which I want dimensions to have the following semantically meaningful names:

```
#core_0 has shape ('batch', 'height', 'width', 'out_quantum_0', 'bond_0', 'bond_1'),
#core_1 has shape ('batch', 'height', 'width', 'out_quantum_1', 'bond_1', 'bond_2'),
#core_2 has shape ('batch', 'height', 'width', 'out_quantum_2', 'bond_2', 'bond_3'),
#core_3 has shape ('batch', 'height', 'width', 'out_quantum_3', 'bond_3', 'bond_0')
```

These 4 tensors represent a tensor by using matrix tensor ring format (or, as physicists call it, matrix product operator). What I want to do with it next is I plug into an einsum expression (`pytorch.einsum` or `opt_einsum.contract`) like this:
```
opt_einsum.contract(
    core_0, core_0.names,
    core_1, core_1.names,
    core_2, core_2.names,
    core_3, core_3.names,
    ["batch", *(f"out_quantum_{i}" for i in range(4)), "height", "width"], # these are dimension names of the resulting tensor
    backend="torch",
    optimize="optimal"
```

Right now pytorch named tensors don't allow digits in names, so instead of writing `core_0.names` in the snippet above, I have to keep names with digits somewhere else instead of as pytorch names.

Currently my workarounds due to lack of this feature are to:

1. Store names not as `tensor.names`, but separately; or
2. Implement `digits_to_words` and `words_to_digits` functions and use them to convert `quantum_55` to `quantum_fivefive` and vice versa.

## Pitch

Please allow digits without any restrictions in dimensions names. If you wonder what you should when you have a dimension `0` and a dimension `"0"`, I suggest treating them as different names.

This feature will help
* Tensor decompositions folk. These techniques are used for compression, acceleration, and regularization of neural networks.
* Tensor network folk.

## Alternatives

If you think allowing names like `"1"` may confuse people, forbid names which don't have any symbols but digits.

Another, perhaps even better, alternative is to allow arbitrary immutable hashable objects as names.

cc @zou3519
Repository: TypeScript
Issue: Infer type when object coerced to string if toString explicitly defined
Labels: Suggestion,Awaiting More Feedback

## Search Terms

coercion toString computed properties

## Suggestion

Infer type when object coerced to string if `toString` explicitly defined

## Examples

Would be nice if the following would be allowed

```typescript
const action = {
  type: 'foo',
  toString() { return this.type }
} as const;

const reducerHandler = {
  [action]: () => { } // Currently errors: A computed property name must be of type 'string', 'number', 'symbol', or 'any'.
}
```

[Playground](https://www.typescriptlang.org/play/index.html#code/MYewdgzgLgBAhsKBLcMC8MDeAoGMoCeADgKYBcMA5AGYgiUA0u+IAylAE5JgDmAFAEosMDiSgBXDmHwALJBAB0hUjAC+2VfAgxQkKAG5s2XdBEkAJuOAkOACThhzAGxvoszANoJk4ALoVBdAA+YXV1Y3AIEBcFJxB+UUtrOwdnGwF9IA)

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: godot
Issue: GPU memory leak in editor
Labels: bug,topic:rendering,topic:editor,confirmed

**Godot version:** 3.1.2.stable.official

**OS/device including version:** Linux 64b

**Issue description:**
GPU memory in editor is not being released after closing files in which graphical resources are used (possibly related to `AnimatedSprite`).

Example (sequential), values are GPU memory measured by `nvidia-smi`:
* in project manager: **429MiB**
* after opening project with empty scene: **618MiB**
* after opening scene with animation: **918MiB**
* after closing scene with animation and waiting 10 seconds: **918MiB** (results sometimes wary slightly, e.g. sometimes I got 961MiB, but that's still much higher compared to 618MiB)

**Steps to reproduce:**
* Create a new scene with `AnimatedSprite`
* Check GPU mem - baseline
* Create new frames in inspector
* Copy non-tiny animation files (e.g. 200 of PNGs each ~1MB) to project
* Drag and drop to animation (bottom panel)
* Check GPU mem (should be higher for Godot editor process)
* Close scene
* Check GPU mem - doesn't go back to baseline

**Minimal reproduction project:**
Well, not very minimal when judging by size :smile:. It's too big for GH, so I had to upload it somewhere else: https://mega.nz/#!sAI0VKQI!QAW42ZeR-IjHjBeCDmhLH_9Gr7wi83oy3GjFWMmK7HM