sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Editable subobjects issue
Labels: bug,topic:editor

**Godot version:**
<!-- If thirdparty or self-compiled, specify the build date or commit hash. -->

Godot 3.0 Beta 2

**OS/device including version:**
<!-- If graphics related, specify also GPU model and drivers. -->

Windows 10 64bit
Intel i7 6700k
MSI GeForce GTX 1060 (6GB)
16 GB RAM DDR4
Z170 Gaming Pro (Mainborad)

**Issue description:**
<!-- What happened, and what was expected. -->

If changed a included (linked) scene in the editor node tree to "editable subobjects" and change something (for example a animatedSprite to another animation) and after that changing the included (linked) scene back to "NOT editable subobjects" then the editor keeps the changed animation (if not restarting) and ingame it is showing the default animation which isn´t changed.

**Steps to reproduce:**

1. Create a new scene and use a "KinematicBody2D" as root node
2. Add a "animatedSprite" Node as a child to the "KinematicBody2D"
3. Add two animations (simple two different pictures with an animation-name)
4. Save that scene for example  as "charakter" or something
5. Create another new scene and use a "Node2D" as root node 
6. add the created "charakter" scene two times as a child to the current "Node2D"
7. activate on both included charakter scenes the "editable subobjects" option (rightclick on the charakter scene on the nodetree)
8. Change the default animation from the "animationSprite" to the other animation (to see a difference)
9. Deactivate the "editable subobjects" on only one included scene
10. The changes are still there on both nodes in the editor but not ingame when the scene is started

**Minimal reproduction project:**
<!-- Optional but greatly speeds up debugging. You can drag and drop a zip archive to upload it. -->
[EditableSubobjectIssue.zip](https://github.com/godotengine/godot/files/1584559/EditableSubobjectIssue.zip)


- [ ] I searched the existing [GitHub issues](https://github.com/godotengine/godot/issues?utf8=%E2%9C%93&q=is%3Aissue+) for potential duplicates.
Repository: rust
Issue: Function pointer docs may need updating
Labels: C-enhancement,P-medium,T-compiler

We may need documentation updated for function pointers when used in enums. I won't pretend I understand half of what's written here, but here's the log from IRC (#rust_beginners) where we debugged this issue:

1. [Rust Playground (`Sharlin`)](https://play.rust-lang.org/?gist=d25cb785bee399efe590293ab2c1a44a&version=stable)
2. [Rust Playground (`spear2`)](https://play.rust-lang.org/?gist=0cfe1a8e458fa50d5223054f7ff7298c&version=stable])

```
Sharlin    :: vermiculus: okay... wtf [1]

vermiculus :: Sharlin: Right!?

Sharlin    :: what makes fns with ref arguments not implement Ord or
              anything

vermiculus :: I 100% need the argument to be mutable, but I can't have it be
              mutable without being a ref, and apparently it's choking on the ref

spear2     :: maybe it has to do with the reference having an implicit lifetime?

vermiculus :: ...Ok the '100%' is not completely true, but it's the cleanest option

Sharlin    :: spear2: indeed it seems to be

spear2     :: [2]

vermiculus :: spear2: now there's a topic I still don't understand half or less

Sharlin    :: this is definitely something that should be documented in the fn docs :D

vermiculus feels useful :D

spear2     :: vermiculus: the way i understand it, every reference has an associated
              lifetime, but most of the time it can be 'inferred' and you don't see it

Sharlin    :: so this is about that higher ranked trait bound thingie

vermiculus :: spear2: that's the extent of my understanding as well; I get tripped up
              trying to 'infer' the lifetime myself (effectively seeing what the
              compiler would see)

Sharlin    :: `Bar(fn(&i32))` is actually `Bar(for<'a> fn(&'a i32))`

Sharlin    :: which means the fn is not an ordinary function pointer but a higher
              something

vermiculus :: spooky

vermiculus :: that makes me wonder if this behavior is intentional or if there's a
              more explicit means to express this idea

vermiculus :: throwing that explicit lifetime parameter is making the rest of the
              compiler go a little nutty -- wanting lifetime parameters for *everything* :(

Sharlin    :: yeah

Sharlin    :: so it goes
```
Repository: rust
Issue: Avoid path to macro-generated extern crate in error messages
Labels: C-enhancement,A-diagnostics,T-compiler,WG-diagnostics

```rust
use serde::Deserialize;

// Expands to:
//
// const _IMPL_DESERIALIZE_FOR_S: () = {
//     extern crate serde as _serde;
//     impl<'de> _serde::Deserialize<'de> for S { /* ... */ }
// }
#[derive(Deserialize)]
struct S;

fn main() {
    // Requires S: serde::Serialize.
    serde_json::to_string(&S);
}
```

The message as of rustc 1.24.0-nightly (c284f8807 2017-12-24):

```
error[E0277]: the trait bound `S: _IMPL_DESERIALIZE_FOR_S::_serde::Serialize` is not satisfied
  --> src/main.rs:16:5
   |
16 |     serde_json::to_string(&S);
   |     ^^^^^^^^^^^^^^^^^^^^^ the trait `_IMPL_DESERIALIZE_FOR_S::_serde::Serialize` is not implemented for `S`
   |
   = note: required by `serde_json::to_string`
```

In this case it would be more desirable for the error message to refer to `serde::Serialize` rather than `_IMPL_DESERIALIZE_FOR_S::_serde::Serialize`. The extern crate means that the user's Cargo.toml includes the `serde` crate under `[dependencies]`, so showing `serde::Serialize` as the path seems reasonable.

I understand that `serde::Serialize` could be ambiguous if the user's crate includes `mod serde` at the top level. For now we could ignore that case and show `serde::Serialize` anyway, or treat it as a special case and not show `serde::Serialize` if they have a `mod serde`. The special case would go away with https://github.com/rust-lang/rfcs/pull/2126 by showing `crate::serde::Serialize`.

Fixing this would be valuable in allowing us to reinstate the lint against unused extern crate by addressing the usability issue reported in #44294.

Mentioning @pnkfelix who worked on #46112.
Repository: rust
Issue: rustdoc-tool does not build with --enable-llvm-link-shared
Labels: A-linkage,T-rustdoc,C-bug

Seems to be missing a `-L` flag:
```
  = note: /usr/bin/ld: cannot find -lLLVMX86Disassembler
          /usr/bin/ld: cannot find -lLLVMX86AsmParser
          /usr/bin/ld: cannot find -lLLVMX86CodeGen
...
```
Any ideas on fixing this?
Repository: youtube-dl
Issue: Support request for thoptv.stream
Labels: site-support-request

## Please follow the guide below

- You will be asked some questions and requested to provide some information, please read them **carefully** and answer honestly
- Put an `x` into all the boxes [ ] relevant to your *issue* (like this: `[x]`)
- Use the *Preview* tab to see what your issue will actually look like

---

### Make sure you are using the *latest* version: run `youtube-dl --version` and ensure your version is *2017.12.23*. If it's not, read [this FAQ entry](https://github.com/rg3/youtube-dl/blob/master/README.md#how-do-i-update-youtube-dl) and update. Issues with outdated version will be rejected.
- [x] I've **verified** and **I assure** that I'm running youtube-dl **2017.12.23**

### Before submitting an *issue* make sure you have:
- [x] At least skimmed through the [README](https://github.com/rg3/youtube-dl/blob/master/README.md), **most notably** the [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones

### What is the purpose of your *issue*?
- [ ] Bug report (encountered problems with youtube-dl)
- [x] Site support request (request for adding support for a new site)
- [ ] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

---


---


```

...
<end of log>
```

---
Website: http://thoptv.stream/
Single video: http://thoptv.stream/live/travelxp-hd-english/

### If the purpose of this *issue* is a *site support request* please provide all kinds of example URLs support for which should be included (replace following example URLs by **yours**):
- Single video: https://www.youtube.com/watch?v=BaW_jenozKc
- Single video: https://youtu.be/BaW_jenozKc
- Playlist: https://www.youtube.com/playlist?list=PL4lCao7KL_QFVb7Iudeipvc2BCavECqzc

Note that **youtube-dl does not support sites dedicated to [copyright infringement](https://github.com/rg3/youtube-dl#can-you-add-support-for-this-anime-video-site-or-site-which-shows-current-movies-for-free)**. In order for site support request to be accepted all provided example URLs should not violate any copyrights.

---
Repository: opencv
Issue: Access Violation error in cuvidCtxLockCreate when using cuda 9
Labels: bug,priority: low,category: gpu/cuda (contrib)

<!--
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).

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)
- OpenCV => 3.4.0
- Operating System / Platform => Windows 10 Pro 64 Bit and Windows 10 Educational 64 Bit
- Compiler => Visual Studio 2015
- Cuda => 9.0.176
- Nvidia card => GTX 1080 Ti  and GeForce 940MX 

##### Detailed description
I have built OpenCV with Cuda 9 and now when i try to play video using ` cv::cudacodec::VideoReader` i get a Access violation error inside `VideoReaderImpl` on [this line](https://github.com/opencv/opencv/blob/047764f476e429e0ff63f9e23f7ac96f59539356/modules/cudacodec/src/video_reader.cpp#L99)

![error](https://user-images.githubusercontent.com/3811164/34339350-fe9cff6c-e998-11e7-88a8-2487d3a001dd.jpg)

But it works fine when i use OpenCV built with Cuda 8.0

##### Steps to reproduce

```#include <iostream>
#include "opencv2/opencv_modules.hpp"

#if defined(HAVE_OPENCV_CUDACODEC)

#include <opencv2/core.hpp>
#include <opencv2/cudacodec.hpp>
#include <opencv2/highgui.hpp>

int main(int argc, const char* argv[])
{
    const std::string fname = "rtsp://admin:admin@192.168.1.13/media/video2";

    cv::namedWindow("GPU", cv::WINDOW_NORMAL);

    cv::cuda::GpuMat d_frame;
    cv::Ptr<cv::cudacodec::VideoReader> d_reader = cv::cudacodec::createVideoReader(fname);

    for (;;)
    {

        if (!d_reader->nextFrame(d_frame))
            break;

        cv::Mat frame;
        d_frame.download(frame);
        cv::imshow("GPU", frame);

        if (cv::waitKey(3) > 0)
            break;
    }
    return 0;
}

#else
int main()
{
    std::cout << "OpenCV was built without CUDA Video decoding support\n" << std::endl;
    return 0;
}
#endif
```
Repository: javascript
Issue: Method chaining lets the receiver nominate a next receiver
Labels: pull request wanted,editorial

Re https://github.com/airbnb/javascript#constructors--chaining

Code like

```js
luke.jump().setHeight(20);
```
enables luke to provide something other than luke itself as the receiver of the `setHeight` message. When this delegation of control is intended, such method chaining is great. OTOH, if the caller assumes it is equivalent to

```js
luke.jump();
luke.setHeight(20);
```

then they depend on a contract that luke might not obey. That doesn't necessarily mean the style should not be used, but the hazard needs to be explained clearly whenever this style is encouraged.
Repository: javascript
Issue: Distinguish doc-comments from other comments
Labels: editorial

https://github.com/airbnb/javascript#comments--multiline
recommend `/** ... */` without even mentioning `/* ... */`. The former should only be used for doc-comments. The latter should be used for all comments that are not doc-comments, even if they are multiline.
Repository: go
Issue: x/text/collate: ignores width even if the flag is not specified
Labels: NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
go version go1.9 linux/amd64

### Does this issue reproduce with the latest release?
Did not check.

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOBIN="/home/sougou/dev/bin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/sougou/dev"
GORACE=""
GOROOT="/home/sougou/go"
GOTOOLDIR="/home/sougou/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build590551857=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

### What did you do?
I was spot-checking the collation code to see if it matched specifications: if IgnoreWidth was not specified, I was expecting "ae" to not match "Æ". However, it still matched. Here's a simplified reproduction:

```
import (
        "testing"

        "golang.org/x/text/collate"
        "golang.org/x/text/language"
)

func TestUtf8GeneralCI(t *testing.T) {
        a := "ae"
        b := "Æ"
        coll := collate.New(language.Und, collate.IgnoreCase, collate.IgnoreDiacritics)
        if coll.CompareString(a, b) == 0 {
                t.Errorf("Compare(%q, %q): 0, want non-0", a, b)
        }
}
```


### What did you expect to see?
Test should pass.

### What did you see instead?
Test failed.
Repository: neovim
Issue: Multiline completion (also affects LSP textDocument/completion results)
Labels: enhancement,completion

Currently Vim (and by bloodline also NeoVim) allows only single line completions. This is quite limiting as there is also no way to determine beginning and end of the completed text so this leaves us in the limbo where we need to do some hackish things to achieve things like multiline snippets.

Most obvious way to do such thing would be to make (`:h complete-items`):

```viml
{ 'word': "aaa\nbbb" }
```

to insert 2 lines:

```
aaa
bbb
```

Currently it inserts

```
aaa^@bbb
```

Where `^@` is NUL character (`:h NL-used-for-NUL`).

The problems with multiline completion is that there will be open question how to handle indentation.

Alternatively we could allow `List` as `'word'` parameter where each line would be one item.
Repository: go
Issue: testing: Helper's highest function call's information should be maintained for any subsequent/nested calls
Labels: help wanted,NeedsFix

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
go version go1.9.2 android/arm64

### Does this issue reproduce with the latest release?
Yes (I think 1.9.2 is the latest release)

### What operating system and processor architecture are you using (`go env`)?
GOARCH="arm64"
GOHOSTARCH="arm64"
GOHOSTOS="android"
GOOS="android"

### What did you do?

Run the following program with "go test". I would have hoped that the reported error line is in the 2nd call to checkFor3s() in TestHelper(). Instead, the error line is in forEach() (line 9 for me but I think some blank lines may have been eaten below.

I think the problem is that checkFor3s() uses the method forEach which is not marked with t.Helper(). In a more realistic case, forEach would be a non-testing utility method and so would not have the possibility of calling t.Helper().

Perhaps the semantics of t.Helper should be that the displayed error line is in the stack frame above the highest t.Helper() call? That way this example would be fixed, and also it would not be necessary to sprinkle t.Helper() calls everywhere if there are complex testing utility functions.

```
package helper                                                                                                                 

import(
        "testing"
)                                                                                                                               
func forEach(data []int, f func(int)) {
        for _, i := range data {
                f(i)
        }
}

func checkFor3s(tb testing.TB, data []int) {
        tb.Helper()
        forEach(data, func(i int) {
                tb.Helper()
                if i != 3 {
                        tb.Error("Saw", i, "instead of 3")
                }
        })
}

func TestHelper(t *testing.T) {
        checkFor3s(t, []int{3, 3, 3, 3})
        checkFor3s(t, []int{3, 3, 2, 3})
        checkFor3s(t, []int{3, 3, 3, 3})
}
```
Repository: rust
Issue: Types in std::os::raw should be same as libc crate
Labels: C-enhancement,T-libs-api

Right now, there's a bit of a discrepancy between these two, even though there shouldn't be. While the libc crate has [very complicated logic](https://github.com/rust-lang/libc/search?q=%22pub+type+c_long%22) to determine how the `c_*` types are defined, the standard library uses a [much simpler logic](https://github.com/rust-lang/rust/blob/81622c6b02536bdcf56145beb317da0d336703c1/src/libstd/os/raw.rs).

I'm not sure how much these types are desired outside of libc; the only type that I've really seen used across the standard library is `c_char`, which honestly could just be replaced with an opaque struct with `repr(u8)` if it weren't already stabilised.
Repository: opencv
Issue: stitching: matrix.cpp error and core dumped
Labels: bug,category: stitching

Using recent git version.
```
wget -O coredump1.png https://i.imgur.com/eNkIZtU.png
wget -O coredump2.png https://i.imgur.com/DfV31L9.png
```
```
md5sum coredump*.png
baed18323666725f7c07b4b2186cc884 *coredump1.png
55417fdf2b1b14999c22eaa35828781b *coredump2.png
```

```
./opencv/build/bin/cpp-example-stitching_detailed --output test.png coredump*.png
Finding features...
[ INFO:0] Initialize OpenCL runtime...
Features in image #1: 752
Features in image #2: 430
Finding features, time: 0.27072 sec
Pairwise matchingPairwise matching, time: 0.0190275 sec
Initial camera intrinsics #1:
K:
[1614, 0, 290.5;
 0, 1614, 516.5;
 0, 0, 1]
R:
[1, 0, 0;
 0, 1, 0;
 0, 0, 1]
Initial camera intrinsics #2:
K:
[1614, 0, 290.5;
 0, 1614, 516.5;
 0, 0, 1]
R:
[1.0084002, -0.0029160879, -0.00041645425;
 -0.0039012616, 1.0122006, 0.46072242;
 -0.014846272, 0.019930283, 1.0090584]
Camera #1:
K:
[7099.366127436171, 0, 290.5;
 0, 7099.366127436171, 516.5;
 0, 0, 1]
R:
[1, 2.910383e-11, 0;
 5.8207661e-11, 1, 0;
 0, 0, 1]
Camera #2:
K:
[7087.369852449208, 0, 290.5;
 0, 7087.369852449208, 516.5;
 0, 0, 1]
R:
[0.99999684, 0.0024957163, 0.00017471006;
 -0.0025003864, 0.9946146, 0.10361284;
 8.4819272e-05, -0.10361294, 0.9946177]
Warping images (auxiliary)... 
Warping images, time: 13.5285 sec
OpenCV Error: Insufficient memory (Failed to allocate 109281814084 bytes) in OutOfMemoryError, file /home/linux/opencv/modules/core/src/alloc.cpp, line 55
OpenCV Error: Assertion failed (u != 0) in create, file /home/linux/opencv/modules/core/src/matrix.cpp, line 436
terminate called after throwing an instance of 'cv::Exception'
  what():  /home/linux/opencv/modules/core/src/matrix.cpp:436: error: (-215) u != 0 in function create

Aborted (core dumped)
```
Repository: pytorch
Issue: Invoking MKL in multiprocessing with importing torch causes blocking
Labels: module: multiprocessing,triaged,module: mkldnn,module: mkl

Using numpy.lialg.svd(invoking functions in MKL may be its triger) in multiprocessing with importing torch causes blocking.

The following stops at "Start svd":

```python
#!/usr/bin/env python
import multiprocessing as mp

import numpy
import torch # Just to import, not using anymore

def f(x):
    print('Start svd')
    numpy.linalg.svd(numpy.ones((100, 100)))
    print('End svd')

def test1():
    print('### Start test1 ###')
    print('Start multiprocessing')
   # mp.set_start_method('spawn')
    with mp.Pool(1) as p:
        p.map(f, [None])
    print('End multiprocessing')


if __name__ == '__main__':
    test1()
```

It works without the comment of set_start_method or with comment of importing torch, but it means that just importing torch affects the original multiprocessing in python or numpy.mkl.

cc @gujinghui @PenghuiCheng @XiaobingSuper @jianyuh @VitalyFedyunin
Repository: kubernetes
Issue: Allow specifying window over which metrics for HPA are collected
Labels: sig/autoscaling,kind/api-change,kind/feature,sig/instrumentation,lifecycle/frozen

/kind feature

# Use case
The docs say "The Horizontal Pod Autoscaler automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization." without specifying the window over which this was observed. Haven't found where it's defined but it seems like it's ~1-5 minutes.

Now imaging a traffic pattern with short dips. If there is a dip in the calculation window, it will cause the HPA to scale down aggressively. Same applies the other way around, if there is a spike spanning the calculation window, it will add lots of replicas even if the spike is gone already.

The only options to tweak is the cooldown period which doesn't help since it will only limit the number of scale operations, no the amount by which to scale. With longer cooldown the time of over/underprovisioning is just longer and shorter cooldown leads to trashing due to the number of scale operations.

Instead it should made possible to specify the observation interval in the HPA spec.

# Implementation
From what I can tell, the HPA gets the metrics to calculate the number of replicas to add or remove from the metrics API without having any way to specify the observation window. Looking at the API here: https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go it seems like the metrics available via the Metrics api are already preprocessed and the window is determined by the reporter (kubelet/cadvisor?).

With this design it seems impossible to get utilization over different periods of time ad-hoc. Was this discussed for the metrics api design? If the NodeMetrics contained the raw CPU seconds, the HPA could use them to calculate the utilization over a user provided window X (by keeping the value from X ago).

It could be argued that such calcuation have no place in the HPA either and it should defer this to a metrics-server, but I don't know how this would work in the 'push model' we have right now where the kubelets report metrics instead of having the HPA/controller pull them when needed while specifying the window.