sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: three.js
Issue: Editor should have most of THREE's features
Labels: Enhancement,Editor

##### Description of the problem

There are several features of `THREE` that aren't accessible from the Editor. When I say accessible, I mean combination of:
* properties are not visible for editing
* objects not being able to be created
* objects not being able to be imported or exported. 

Ideally, the Editor should be capable of creating and editing most objects and features that the API contains. This issue is really more to keep track of what the Editor can and can't do currently. I'm listing features that I think the Editor would be capable of handling.

#### Cameras
- [x] `PerspectiveCamera`
- [x] `OrthographicCamera`
- [ ] ~~`ArrayCamera`~~
- [ ] ~~`CubeCamera`~~
- [ ] ~~`StereoCamera`~~
#### Core
- [x] `BufferAttribute`
- [x] `BufferGeometry`
- [ ] `Layers`
- [x] `InstancedBufferAttribute`
- [x] `InstancedBufferGeometry`
- [ ] `InstancedInterleavedBuffer` * (#16050)
- [x] `InterleavedBufferAttribute`
#### Geometry
- [x] `BoxGeometry`
- [x] `CircleGeometry`
- [x] `ConeGeometry`
- [x] `CylinderGeometry`
- [x] `DodecahedronGeometry`
- [ ] `EdgesGeometry` *
- [ ] `ExtrudeGeometry`
- [x] `IcosahedronGeometry`
- [x] `LatheGeometry`
- [x] `OctahedronGeometry`
- [x] `PlaneGeometry`
- [x] `RingGeometry`
- [ ] `ShapeGeometry`
- [x] `SphereGeometry`
- [x] `TetrahedronGeometry`
- [x] `TorusGeometry`
- [x] `TorusKnotGemetry`
- [x] `TubeGeometry`
- [ ] `WireframeGeometry` **
#### Lights
- [x] `AmbientLight`
- [x] `DirectionalLight`
- [x] `HemisphereLight`
- [x] `PointLight`
- [ ] `RectAreaLight` (#16251)
- [x] `SpotLight`
- [ ] `LightProbe`
#### Materials
- [x] `LineBasicMaterial`
- [x] `LineDashedMaterial`
- [x] `MeshBasicMaterial`
- [x] `MeshDepthMaterial`
- [x] `MeshLambertMaterial`
- [x] `MeshMatcapMaterial`
- [x] `MeshNormalMaterial`
- [x] `MeshPhongMaterial`
- [x] `MeshPhysicalMaterial`
- [x] `MeshStandardMaterial`
- [x] `MeshToonMaterial`
- [x] `PointsMaterial`
- [x] `RawShaderMaterial`
- [x] `ShaderMaterial`
- [x] `ShadowMaterial`
- [x] `SpriteMaterial`
#### Objects
- [x] `Group`
- [ ] `LOD`
- [ ] `Line`
- [ ] `LineLoop`
- [ ] `LineSegments`
- [x] `Mesh`
- [ ] `InstancedMesh`
- [x] `Points`
- [x] `SkinnedMesh`
- [x] `Sprite`
#### Textures
- [ ] `Texture` (properties not editable #13882, #15695)
- [ ] `CubeTexture` (#13880)
- [ ] `VideoTexture`
#### Misc
- [x] Animations
- [ ] Audio
- [ ] Post-Processing

\* = Serializable, but not deserializable
** = Serializable, but not as the original geometry (i.e. `WireframeGeometry` is serialized as `BufferGeometry`)

##### Three.js version

- [x] Dev
- [x] r103

##### Browser

- [x] All of them
- [ ] Chrome
- [ ] Firefox
- [ ] Internet Explorer

##### OS

- [x] All of them
- [ ] Windows
- [ ] macOS
- [ ] Linux
- [ ] Android
- [ ] iOS
Repository: storybook
Issue: Add url parameter for collapsing sidebar
Labels: feature request,core

**Is your feature request related to a problem? Please describe.**
Currently collapsing the sidebar is only available globally in the options, but not as a URL parameter. 

For instance we can embed the story in a buttons section of a docs with all the correct options and knobs selected and present in the URL. However the sidebar remains open - if we collapse it in the config - it ruins the usability of the storybook standalone not embedded in an app. 

**Describe the solution you'd like**
Ideally the selected sidebar state could be passed in the url 
designsystem.com/?path=/story/breadcrumb&sidebar-isCollapsed=true

**Describe alternatives you've considered**

- Using just the iframe as an embed: lacks the excellent knob and full canvas functionality
- Collapse the sidebar in config: makes the actual app unusable as a standalone
Repository: pytorch
Issue: Different behavior of torch.nn.MultiMarginLoss on CPU/GPU Tensors
Labels: module: cuda,module: error checking,triaged

## 🐛 Bug

According to the documentation, the input to torch.nn.MultiMarginLoss() should be:
- x (a 2D mini-batch Tensor)
- y (a 1D tensor of target class indices, **0 <= y <= x.size(1)**).

For CPU tensors, it will raise RuntimeError when target (y) is out of range, however that seems not the case for GPU tensors.
## To Reproduce

Steps to reproduce the behavior:

```
>>> a = torch.rand(3, 1)
>>> b = torch.LongTensor(3).random_(0, 5)
>>> criterion = torch.nn.MultiMarginLoss()
>>> criterion(a, b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/afs/cs.pitt.edu/usr0/miz44/opt/miniconda3/envs/pytorch_test/lib/python3.7/site-packages/torch/nn/modules/module.py", line 494, in __call__
    result = self.forward(*input, **kwargs)
  File "/afs/cs.pitt.edu/usr0/miz44/opt/miniconda3/envs/pytorch_test/lib/python3.7/site-packages/torch/nn/modules/loss.py", line 1138, in forward
    weight=self.weight, reduction=self.reduction)
  File "/afs/cs.pitt.edu/usr0/miz44/opt/miniconda3/envs/pytorch_test/lib/python3.7/site-packages/torch/nn/functional.py", line 2380, in multi_margin_loss
    return torch._C._nn.multi_margin_loss(input, target, p, margin, weight, reduction_enum)
RuntimeError: invalid argument 3: target out of range at /pytorch/aten/src/THNN/generic/MultiMarginCriterion.c:43
```
The above is the expected behavior. However, 
```
>>> criterion(a.cuda(), b.cuda())
tensor(0.4437, device='cuda:0')
```
I didn't quite understand how this value is calculated, as I suppose the behavior on CPU and GPU should be consistent?

When giving inputs with correct shape, the results on CPU and GPU tensors seem consistent.
```
>>> c = torch.rand(3, 5)
>>> criterion(c, b)
tensor(0.6158)
>>> criterion(c.cuda(), b.cuda())
tensor(0.6158, device='cuda:0')
```

## Expected behavior
A error message similar with CPU tensors should be given to warn about the unexpected input.

## Environment

Collecting environment information...
PyTorch version: 1.1.0.dev20190411
Is debug build: No
CUDA used to build PyTorch: 10.0.130

OS: CentOS Linux release 7.6.1810 (Core)
GCC version: (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
CMake version: version 2.8.12.2

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 10.0.130
GPU models and configuration:
GPU 0: GeForce GTX 1080 Ti
GPU 1: GeForce GTX 1080 Ti
GPU 2: GeForce GTX 1080 Ti
GPU 3: GeForce GTX 1080 Ti
GPU 4: GeForce GTX 1080 Ti
GPU 5: GeForce GTX 1080 Ti

Nvidia driver version: 410.79
cuDNN version: Could not collect

Versions of relevant libraries:
[pip] numpy==1.16.2
[pip] torch-nightly==1.1.0.dev20190411
[pip] torchvision-nightly==0.2.3
[conda] torch-nightly             1.1.0.dev20190411          pypi_0    pypi
[conda] torchvision-nightly       0.2.3                    pypi_0    pypi
Repository: rust
Issue: Change powerpc64 base CPU
Labels: C-enhancement,T-compiler,O-PowerPC,A-target-specs

Currently, following targets use “ppc64” as base CPU: powerpc64-unknown-linux-gnu, powerpc64-unknown-linux-musl, powerpc64-unknown-freebsd.

In LLVM, “ppc64” implies “+altivec”. This is unfortunate, because it means Rust targets are unusable on devices based on PowerPC e5500, which is fairly popular. In particular, #43610 is about QorIQ P5040 SoC using PowerPC e5500 core, and #59040 is about QorIQ T1042 SoC using PowerPC e5500 core.

Thoughts?
Repository: puppeteer
Issue: Support Electron and other content embedders
Labels: feature,chromium

## What's a "content embedder"?

Chromium codebase is organized into layers:
- `//blink` - HTML rendering engine
- `//content` - an API for browser implementers (think of it as a library that you'd use if you were to write your own browser). Things like process model are handled here; uses `//blink`.
- `//chrome` - Chromium implementation (uses `//content`).

Content-embedders are all the products that are based on `//content` layer. Chromium, Chrome Headless, ChromeCast are all different `//content` embedders.

Electron is a `//content` embedder as well.

## DevTools Protocol and content embedders

Majority of DevTools API is implemented in `//blink` and `//content`. However, certain methods are supposed to be implemented by embedders. DevTools team makes sure all the methods needed for Puppeteer operation are supported by both Chromium and Headless.

Electron is, however, missing out.

## What exactly goes wrong?

- Since version v1.5.0, when Puppeteer connects to a browser it requests all existing browser
contexts with the `Target.getBrowserContexts()` protocol method.
- Method `Target.getBrowserContexts()` is supposed to be implemented by content embedders.
- Electron doesn't implement the method, so Puppeteer connect to electron fails (#3793).

## What can be done?

**Option 1: Defer to Embedders.**

Ideally, `//content`-embedders implement all necessary DevTools protocol methods on their end. This way they'll guarantee 100% compatibility with Puppeteer API. This, however, is a major undertaking for embedders; not sure if there's any interest in this.

**Option 2: support clicking/typing/evaluation**

Alternatively, we can aim for a "good-enough" compatibility with `//content` embedders. For example, we can make sure that things like clicking, navigation, typing and evaluation work fine with electron app (and add these electron tests to our CI). These should be enough to drive many default testing and automation scenarios.

# 🚀  Vote! 

- If there's an interest in **Option 1**, please file a bug to the repository with the content embedder you'd like to be supported and ask them to implement the `Target.getBrowserContexts()` method. Plz cross-post the link here.
- If there's an interest in **Option 2**, please  👍 this issue and share your usecase.
Repository: godot
Issue: Attach Node Script dialog should be wider in order to show more of script path
Labels: enhancement,topic:editor,usability

The problem can be seen here:

<img width="532" alt="Screen Shot 2019-04-13 at 1 24 07 PM" src="https://user-images.githubusercontent.com/6002340/56079070-85828080-5def-11e9-8d59-1ec24ec76933.png">

Each time I create a new script I want to make sure it's in the right place (path) and has the correct file name. The problem is that I have to scroll the text field to the right each time to see the complete path.

It would be good if the dialog was made wider and/or resizable.
Repository: TypeScript
Issue: Additive inverse of number literals
Labels: Suggestion,Awaiting More Feedback

## Search Terms
Using unary minus on variable that is of number-literal type. Negative number literals.

## Suggestion
This is a specific case of #26382. My proposal is simply that if we apply unary minus on an expression whose type is a union of number literal types, the result should be a union of their additive inverses:
```typescript
declare var a: 1 | 2 | 3;
const b = -a; // should be -1 | -2 | -3
```

Furthermore we could add a unary minus type operator:
```typescript
-(42) === -42
-(A | B) === -A | -B
-number === number
-(not number) // error
```

Both should be very easy and uncontroversial to implement.

## Use Cases
```typescript
function compare(a: C, b: C): -1 | 0 | 1;

function reverseCompare(a: C, b: C): -1 | 0 | 1
{
  return -compare(a, b); // shouldn't throw an error
}
```

The type operator would be just for sake of completeness

## 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: AnimationPlayer: Adding Animations became more tedious in 3.1 instead of easier compared to 3.0.6 because of UI change
Labels: enhancement,discussion,topic:editor,usability

**Godot version:**
3.1 stable

**Issue description:**
Unlike the 3D workflow, the 2D workflow has no build in support to import animations from from external sources to the AnimationPlayer. https://github.com/godotengine/godot/issues/18269
While adding 2D animations to the AnimationPlayer has always been very time consuming and tedious for this reason, it has become **even more tedious** with the new AnimationPlayer UI which hides "New", "Duplicate" and "Rename" ect functionality in a drop down menu. 
![robisplash_anim_editor](https://user-images.githubusercontent.com/47016402/56081270-aeb10a00-5e0b-11e9-9e67-a2a97f8313c9.png)


In 3.0.6, these were one-click-buttons.

![32149072-2e7ada48-bcde-11e7-88bf-6f9a2500d534](https://user-images.githubusercontent.com/47016402/56081233-46fabf00-5e0b-11e9-9160-db4e3edf8ebe.png)


This is especially a problem for games with more than one directional movement.
I request to have these UI buttons back on the panel for easy one-click direct access, since this are operations that are repeated hundreds of times hiding them in a drop down does nothing but add useless complexity, wasted time and less user friendly experience. 
(Imagine you are an Animator and you have to do this full time, all day every day. I'd rather die.)
Repository: pytorch
Issue: [Caffe2] Retraining saved model
Labels: caffe2

https://github.com/caffe2/tutorials/blob/master/CIFAR10_Part2.ipynb

Above documentation is incorrect. Also, the Exporter fails if a model has Batch Norm in it. Also, following the same steps in above document for retraining a model gives a segmentation fault.

Please guide. I also posted this on PyTorch discuss but there is no response.
At least, a good working document to load model(which has Batch Norm) and retrain it would be really helpful.
Repository: TypeScript
Issue: Suggestion: shorthand for templated type to extend and default to the same type
Labels: Suggestion,Awaiting More Feedback

## Search Terms

default extends equals generics = template types is

## Suggestion

Can we have a way to declare that a templated (generic) type both `extends` and is `=` a type value without repeating the type value?

```typescript
declare function example<T extends Base = Base>(value: T): T;
```

A clean way to do this would be to allow the `is` keyword following a generic type:

```typescript
declare function example<T is Base>(value: T): T;
```

Failing that, how about omitting the first type value?

```typescript
declare function example<T extends = Base>(value: T): T;
```

## Use Cases

Generic parameters with extended and default values set to the same are a reasonable pattern:

```typescript
declare function querySelector<E extends Element = Element>(selectors: string): E | null;
```

In larger type definitions with many generics, these `extends`+`=` definitions can get a little cumbersome:

```typescript
type BitAddThree<
    A extends Bit = Bit,
    B extends Bit = Bit,
    C extends Bit = Bit
> =
    [A, B, C] extends [0, 0, 0] ? [0, 0] :
    // etc. etc.
    [Bit, Bit, Bit];
```

## Examples

```typescript
declare function querySelector<E is Element>(selectors: string): E | null;
declare function querySelector<E extends = Element>(selectors: string): E | null;
```

```typescript
type BitAddThree<A is Bit, B is Bit, C is Bit> = // ...
type BitAddThree<A extends = Bit, B extends = Bit, C extends = Bit> = // ...
```

## 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: rust
Issue: Add CLI argument to set favicon URL
Labels: T-rustdoc,C-feature-request,A-rustdoc-ui,A-CLI
Repository: godot
Issue: AnimationPlayer: adding keys to Method Track has become unintuitive and complicated
Labels: enhancement,discussion,topic:editor,usability


**Godot version:**
3.1 stable

**Issue description:**
When you want to add a keyframe to an empty Call method track, you will get to a window saying "select method"

This is not what I want. I want to add a keyframe not a select a method. Even if you already wrote a function in your script, you cannot select it this way. Searching your function won't work unless you saved your script.

Inserting a key should be one click and not force me to follow 5 different and very specific steps first. Stuff like I have to first write the function into the script. Maybe I want to think about that later. Maybe I want to change that on the fly and now think about timing the placement of keyframes.

It's a massive step backwards from the 3.0.6 Call Func track in terms of usability. There I could just press the little small + at the end of the track and it would create a keyframe for me. The same functionality worked on other tracks, so I did not need to learn it I already knew. I would like to have that plus back. 
![32149072-2e7ada48-bcde-11e7-88bf-6f9a2500d534](https://user-images.githubusercontent.com/47016402/56086241-a92ae280-5e52-11e9-8ab8-59ad15de09dc.png)


**Steps to reproduce:**
New Animation > New Method track > RMB click > add key
Repository: godot
Issue: Autocompletion doesn't work if other scene is opened
Labels: bug,topic:editor,confirmed

**Godot version:**
3.1 stable

**OS/device including version:**
Windows 7 x64

**Steps to reproduce:**

**_Prerequisite_**: 2 scenes, one of them should have at least one node

Ex.:
```
- Scene 1
	- Node
- Scene 2
```

1. Create script for Scene 1,
2. While Scene 1 tab is opened start typing `$` / `get_node("` in _ready

**_Intermediate result_**: autocompletion suggest you Node. Fine.

3. Change scene tab to Scene 2,
4. Repeat step 2

**_Result_**: no autocompletion list 

**_Expected_**:  autocompletion list with Node

**Minimal reproduction project:**
[test14042019.zip](https://github.com/godotengine/godot/files/3077141/test14042019.zip)

![bug14042019](https://user-images.githubusercontent.com/1552169/56090035-c6889c80-5ea4-11e9-9d92-4183296b9eff.gif)
Repository: pytorch
Issue: add stable distribution in torch.distributions
Labels: module: distributions,feature,low priority,triaged

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->
Add stable distribution in torch.distributions
## Motivation
I would like to get a pdf of stable distribution on GPU. So far, I have to transfer to Numpy and use Scipy to do that and transfer back to tensor on GPU. This process becomes a bottleneck of my code.
<!-- 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 -->

## Pitch
Add stable distribution in torch.distributions
<!-- A clear and concise description of what you want to happen. -->

## Alternatives
No
<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

## Additional context
N/A
<!-- Add any other context or screenshots about the feature request here. -->
Repository: opencv
Issue: LineIterator pos() overflows when coordinates and/or base data type is large
Labels: bug,category: imgproc,affected: 3.4

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

Please:

* Read the documentation to test with the latest developer build.
* Check if other person has already created the same issue to avoid duplicates. You can comment on it if there already is an issue.
* Try to be as detailed as possible in your report.
* Report only one problem per created issue.


This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => 3.4
- Operating System / Platform => Windows 64 Bit
- Compiler => gcc 5.4.0

##### Detailed description

<!-- your description -->
The `pos()` function of `LineIterator` (from the `imgproc` module) returns incorrect result under certain conditions due to integer overflow.

Specifically, `p.y * step` can potentially overflow `int` when either or both of the constituents are large
https://github.com/opencv/opencv/blob/46353564353e0e6c6d82a47f52283957ddd37e8b/modules/imgproc/include/opencv2/imgproc.hpp#L4746

##### Steps to reproduce

```.cpp
// Pardon the weird example.. it's from a specific use case from my work which was how i discovered this bug
Mat testImg = Mat::zeros(21481, 72320, CV_8UC2);
LineIterator testIt(testImg, Point(63894,21163), Point(63895, 21162));
for(int i = 0; i < testIt.count; ++testIt, i++ ) {
  Point p = testIt.pos();
  cout << i << ": " << p << endl;
}
```
<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
Repository: rust
Issue: async/await: cannot move out of captured variable in an `Fn` closure
Labels: A-closures,T-compiler,A-async-await,AsyncAwait-Triaged,requires-nightly,fixed-by-async-closures

Hello,
recently faced with strange behavior, please comment, is this a bug, or not?
Compiler version: 1.35.0-nightly 2019-04-12 99da733f7f38ce8fe684

```rust
#![feature(futures_api, async_await, await_macro)]

use std::future::Future;

struct Task<T> {
    task: T,
}

impl<T> Task<T>
where
    T: Fn(),
{
    fn new(task: T) -> Self {
        Self { task }
    }

    fn execute(&self) {
        (self.task)();
    }
}

struct AsyncTask<T> {
    task: T,
}

impl<T, F> AsyncTask<T>
where
    T: Fn() -> F,
    F: Future<Output = ()>,
{
    fn new(task: T) -> Self {
        Self { task }
    }

    async fn execute(&self) {
        await!((self.task)());
    }
}

fn main() {
    let string = "Hello, World!".to_string();
    let _task = Task::new(move || {
        println!("{}", string);
    });

    let string = "Hello, World!".to_string();
    let _async_task = AsyncTask::new(async move || {
        println!("{}", string);
    });
}
```

~~([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=28a27aa660e7ed576b8893ab389026e5))~~
([Updated Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=8d1f9f3ac5ece51ed6ead2da96e9aa44)

Errors:

```
   Compiling playground v0.0.1 (/playground)
error[E0507]: cannot move out of captured variable in an `Fn` closure
  --> src/main.rs:47:52
   |
46 |       let string = "Hello, World!".to_string();
   |           ------ captured outer variable
47 |       let _async_task = AsyncTask::new(async move || {
   |  ____________________________________________________^
48 | |         println!("{}", string);
49 | |     });
   | |_____^ cannot move out of captured variable in an `Fn` closure

error: aborting due to previous errors

For more information about this error, try `rustc --explain E0507`.
error: Could not compile `playground`.

To learn more, run the command again with --verbose.

```