sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Non-Object Pointers Implicitly Converted to Bool When Used for Variants
Labels: enhancement,topic:core,confirmed

When a non-object pointer is used to construct a Variant, that pointer is implicitly converted to a bool.

This is suboptimal, as a pointer may be mistakenly passed to a function that expects a Variant, and the error will only be caught at run-time, if at all.

If that is done, the engine compiles fine, so that the error can only be caught at run-time. It would make it much simpler to catch those issues if a compiler error occurred when an unsupported (i.e. non-object) pointer is provided for the construction of a Variant. 

A simple way to fix this issue is to add the following line to the Variant class definition

```
Variant(const void *p_void) = delete;
```

Such a deleted function would result in a compiler error if an unsupported pointer were used to construct a Variant, while the expected Variant functionality would remain unaltered.

To give a concrete example of the benefits of fixing this issue: the error in the current release version (now [fixed in master](https://github.com/godotengine/godot/commit/c1e733466bf8cd1dfe44787247c9ee54f4f85ae6)) which occurred in /gdnative/variant.cpp due to calling Variant::evaluate with *pointers* to Variants as arguments instead of actual Variants would easily have been caught with this fix, so that it would never have made to a release version.

Alas, implementing this particular fix to the issue would require using C++11 for Godot, as that is required for supporting deleted functions.
Repository: godot
Issue: NARROWING_CONVERSION warnings when using `clamp` on an integer
Labels: bug,discussion,topic:gdscript,confirmed

**Godot version:**
v3.1.1.stable.official


**OS/device including version:**
iMac (Retina 5K, 27-inch, 2017)
macOS Mojave (10.14.5)


**Issue description:**

I get a NARROWING_CONVERSION warning - Narrowing conversion (float is converted to int and loses precision) - in the following line:

```
func shake(duration: float, intensity: float = 0.2, frequency: int = 80):
	duration = clamp(duration, 0, 4)
	intensity = clamp(intensity, 0, 1)
	frequency = clamp(frequency, 0, 500) # => Warning: NARROWING_CONVERSION
```

I'm not sure why is there a problem, since my intention is to pass an integer, integer limits, and obtain an integer.

I understand the documentation states that this method returns a `float`, not an `int`, although when testing the output I do get an `int`:

```
print(typeof(clamp(frequency,0,500)) == TYPE_INT) # => TRUE
```

Which is the expected behavior. So all is good, except that it's throwing a warning when I think it shouldn't.

Thank you!
Repository: go
Issue: x/tools/go/packages: high CPU usage while processing cgo file
Labels: Performance,NeedsInvestigation,Tools

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12.5 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN="/home/radhi/Go/bin"
GOCACHE="/home/radhi/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/radhi/Go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build763115998=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

This issue is related with [vscode-go#2598](https://github.com/microsoft/vscode-go/issues/2598). While working on cgo project, both `gocode` and `gopls` will use huge amount of CPU when making autocomplete suggestion. It can be seen [here](https://giant.gfycat.com/WateryUnnaturalCrane.webm) for `gocode` and [here](https://giant.gfycat.com/DiligentUglyGrouper.webm) for `gopls`.

After looking around, I found out the reason for this is because both [`gocode`](https://github.com/stamblerre/gocode/blob/81059208699789f992bb4a4a3fedd734e335468d/internal/suggest/suggest.go#L138) and [`gopls`](https://github.com/golang/tools/blob/252024b8295926254bbc18903b9b7d4f0389df2f/internal/lsp/cache/view.go#L118) uses `LoadSyntax` mode, which make `go/packages` run `go list` with `-compiled` flag set to true, which lead to high CPU usage in cgo project.

### What did you expect to see?

The cgo file can be parsed as light as the normal Go code.

### What did you see instead?

The process uses huge amount of CPU.
Repository: youtube-dl
Issue: Unsupported URL: animemusicvideos.org
Labels: site-support-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 2019.06.27. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Make sure that all provided video/audio/playlist URLs (if any) are alive and playable in a browser.
- Make sure that site you are requesting is not dedicated to copyright infringement, see https://yt-dl.org/copyright-infringement. youtube-dl does not support such sites. In order for site support request to be accepted all provided example URLs should not violate any copyrights.
- Search the bugtracker for similar site support 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 new site support request
- [x] I've verified that I'm running youtube-dl version **2019.06.27**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that none of provided URLs violate any copyrights
- [x] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs

<!--
Provide all kinds of example URLs support for which should be included. Replace following example URLs by yours.
-->

- Single video: https://www.animemusicvideos.org/members/members_videoinfo.php?v=19211
Repository: pytorch
Issue: Training CNNs with deconvolution
Labels: module: convolution,triaged,module: vision,function request

## 🚀 Feature

Implicitly calculate the scatter/covariance matrix of the im2col matrix.

```python
def F(I):
    """
    Please help us to do the following implicitly:
    """
    X= im2col(I)
    Cov=X@X.t()/N
    return Cov
```

## Motivation

Neural networks are learning from a convolved world! Machine learning is analogous to human learning with blurred/nearsighted vision. Therefore, it is hard. But things are much easier if the machines wear glasses.

https://arxiv.org/abs/1905.11926

Recently we notice that the convolutional networks converge much faster and better by applying a real 'deconvolution'. For example, on the well known CIFAR-10 dataset, with deconv, 20-epoch training achieves the same performance that used to require 100-300 epochs. Tested on over 10 networks on multiple datasets, our improvements over batch norm is similar to batch norm over vanilla training.

There is one step that hinders the speedup. When calculating the kernel for deconvolution, we need to  calculate the autocorrelation of the pixels. Currently, we resort to the unfold function which uses excessive memory and more time. The training could be much better and easier if this is done implicitly.

## Pitch

We want this simple modification to be included in pytorch so that the future training of CNNs are more straightforward. 

## Alternatives

https://github.com/yechengxi/deconvolution/blob/2aa372fd232ddad08082cb8a1f8ab46b16b28a5b/models/deconv.py#L303

Currently the calculation is implemented in three lines:

```
X = torch.nn.functional.unfold(x, self.kernel_size,self.dilation,self.padding,self.stride).transpose(1, 2).contiguous()
X=X.view(-1,X.shape[-1])
Cov = X.t() @ X / X.shape[0]
```

The world is likely to be very different if these three lines are optimized in the library.


cc @fmassa @vfdev-5
Repository: pytorch
Issue: Integer division by Zero giving large number results instead of NaN/inf on Windows
Labels: module: cpu,triaged

## 🐛 Bug

Integer tensors, when divided by zero, is giving large integer values as answers instead of flagging as ZeroDivision error or results as inf/NaN. Float numbers, however, are behaving as expected (returns inf)

For e.g in Numpy, the behavior is to return inf with "RuntimeWarning: divide by zero encountered in true_divide"

## To Reproduce

Steps to reproduce the behavior:
```
1. torch.tensor([3,4,5])/torch.tensor([5,0,1])
>>> tensor([0, 4294967295,5])

2. torch.tensor([3,4,5])/0
>>> tensor([4294967295, 4294967295, 4294967295])

#For floats
3. torch.tensor([3.0,4.0,5.0])/0
>>> tensor([inf, inf, inf]

Comparison to Numpy:
np.array([3,4,5])/0
>>> array([inf, inf, inf])
RuntimeWarning: divide by zero encountered in true_divide
```



 - PyTorch Version: '1.1.0'
 - OS : Windows
 - Installed PyTorch: pip
 - Python version: 3.7
 - CUDA/cuDNN version: Cuda release 9.0, V9.0.176
 - GPU models and configuration: NVIDIA GTX1070

**Update**: The above behavior is seen in JupyterNotebook. On trying from the Python console itself, the process just terminates - which I found out was an issue closed with won'tfix at https://github.com/pytorch/pytorch/issues/8079. 
Wondering why the behavior is different in JupyterNotebook!
Repository: TypeScript
Issue: Resolve project references from root
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms

Project reference root resolve.

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

Resolve project reference paths from root directory of a mono repository.

## Use Cases

We have a large mono-repository with 1000s of sub-packages we want to convert to TS projects. Currently the references between them must be defined as relative paths, leading to configuration like:

```
  "references": [
    {
      "path": "../../../base"
    },
    {
      "path": "../colors"
    },
    {
      "path": "../device_capabilities"
    }
  ],
``` 

Which is:
* Hard to read and reason about
* Creates noisy diffs when moving packages

Ideally project references could be resolved from the root of the mono-repo project, e.g. `rootDir` or `baseUrl` options.

E.g.:

```
  "references": [
    {
      "path": "base"
    },
    {
      "path": "ui/base/colors"
    },
    {
      "path": "ui/base/device_capabilities"
    }
  ],
``` 

## 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: scrcpy
Issue: Thank You Very Much For Making this Sir !
Labels: wontfix
Repository: pytorch
Issue: Illegal instruction (core dumped) when running in qemu
Labels: high priority,module: crash,module: cpu,triaged,module: vectorization

I had installed Pytorch using Anaconda from pytorch website.

conda install pytorch-cpu torchvision-cpu -c pytorch
I'm getting Illegal instruction (core dumped)

When I start the app using gdb, I get the following error.
I guess something is wrong with libcaffe2.so

Thread 1 "python" received signal SIGILL, Illegal instruction.
0x00007fffa8ec2486 in THFloatVector_normal_fill_AVX2 () from /U01/anaconda3/envs/pyt1/lib/python3.7/site-packages/torch/lib/libcaffe2.so

Machine configuration:

Machine is Ubuntu 18.04.2

```
root@USANZV-MER-DMA485:~# lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              16
On-line CPU(s) list: 0-15
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):           16
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               13
Model name:          QEMU Virtual CPU version (cpu64-rhel6)
Stepping:            3
CPU MHz:             2294.598
BogoMIPS:            4589.19
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            4096K
NUMA node0 CPU(s):   0-15
Flags:               fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm nopl cpuid pni cx16 hypervisor lahf_lm abm pti
root@USANZV-MER-DMA485:~#
```


cc @ezyang @gchanan @zou3519 @VitalyFedyunin
Repository: pytorch
Issue: Reducer bucketing based on autograd profile 
Labels: oncall: distributed,feature,triaged

## 🚀 Feature

How gradient tensors are batched together in bucket prior to reducing them across processes is done completely statically today. A user specifies a lower bound on the bucket size and parameters are bucketed accordingly. We can use profile data of the backwards pass to find a bucket assignment that better aligns with the point in time gradients are ready.

## Motivation

In some vision models the last layers have many weights (big fully connected layers) and the first layers have only a few weights (small convolutional layers) The bulk of gradients are computed early during the backwards pass. Conversely the gradient tensors for the first layers are computed last and are relatively small. If the final bucket to reduce is 25MB and we wait for the final 1KB worth of gradients before we start, we may achieve better end to end latency if we instead start reduction sooner, without the final 1KB, and run a separate reduction for the final piece of data. We have hooks in `c10d::Reducer`, as well as the autograd profiler, both of which can be used to generate timing data for the gradient of every parameter. Depending on this timing and the size of the gradients, we can create a bucketing assignment that is a better match for the execution order of autograd and doesn't have a big "latency bubble" after autograd has finished. 

## Pitch

* Evaluate applicability of the autograd profiler here. E.g. can we get a mapping of the indices in `model.parameters()` to some relative timestamp their gradient was computed? If not, how easy would it be to add it? (If the autograd profiler cannot be used we can look into adding timing to `c10d::Reducer` directly.)
* Generate a new bucketing assignment based on relative time per parameter as well as the size of the corresponding gradient.
* Distribute the newly computed bucketing order to every participating process. This is done by nvidia/apex as well (cc @mcarilli) where the parameter order is distributed to all processes. If there is mismatch between the order that the model layers/parameters are defined and the order they are used, any approach that closely resembles the autograd order will already be an improved over the naive strategy of simply using definition order.  

## Additional context

Stretch goal: generate a number of bucketing assignments and then empirically figure out which one is best for the set of machines the model is running on.
Repository: rust
Issue: Inclusive version of take_while
Labels: T-libs-api,C-feature-request,A-iterators

`Iterator::take_while` stops _before_ the first element where the condition evaluates to `false`. That is the correct behavior given its name, but it makes it difficult to write an iterator that should include the boundary element. In particular consider something like iterating over a [histogram](https://docs.rs/hdrhistogram/), trimming off the tails:

```rust
for v in histogram
    .iter_linear(1_000)
    .skip_while(|v| v.quantile() < 0.01)
    .take_while(|v| v.quantile() < 0.99)
```

This may seem right, but consider an iterator where the elements are such that `v.quantile()` yields this sequence: `[0, 0.02, 0.99]`. Here, the bin that spans `<0.02-0.99]` will be dropped, even though it includes the majority of the samples. What we really want to do is take from the iterator until we have _received_ an element whose `v.quantile() > 0.99`. To write that with `take_while`, we need something like:

```rust
let mut got_true = true;
for v in h
    .iter_linear(1_000)
    .skip_while(|v| v.quantile() < 0.01)
    .take_while(move |v| {
        if got_true {
            // we've already yielded when condition was true
            return false;
        }
        if v.quantile() > 0.99 {
            // this must be the first time condition returns true
            // we should yield i, and then no more
            got_true = true;
        }
        // we should keep yielding
        true
    })


```

Which isn't exactly obvious.

So, I propose we add `Iterator::take_until_inclusive`, which yields elements up to and including the first element for which its argument returns true. The name isn't great, but I'm also struggling to come up with a better one. In some sense, I want the function to communicate that it yields every item it evaluates. Some other possible names if we're willing to invert the boolean: `break_once`, `break_after`, `end_at`, `end_once`, `end_after`.

Thoughts?
Repository: go
Issue: x/tools/go/packages: panic in testParseFileModifyAST
Labels: Testing,NeedsInvestigation,Tools

Observed in https://build.golang.org/log/269df758e38c6dcc180de71777773231b6f98014 (on `windows-amd64-2016`):

```
panic: runtime error: index out of range [recovered]
	panic: runtime error: index out of range

goroutine 512 [running]:
testing.tRunner.func1(0xc0001bab00)
	C:/workdir/go/src/testing/testing.go:830 +0x399
panic(0x6e5800, 0x9959e0)
	C:/workdir/go/src/runtime/panic.go:522 +0x1c3
golang.org/x/tools/go/packages_test.testParseFileModifyAST(0xc0001bab00, 0x7a5740, 0x9bbf10)
	C:/workdir/gopath/src/golang.org/x/tools/go/packages/packages_test.go:852 +0x4b9
golang.org/x/tools/go/packages/packagestest.TestAll.func1(0xc0001bab00)
	C:/workdir/gopath/src/golang.org/x/tools/go/packages/packagestest/export.go:101 +0x6f
testing.tRunner(0xc0001bab00, 0xc000047e60)
	C:/workdir/go/src/testing/testing.go:865 +0xc7
created by testing.(*T).Run
	C:/workdir/go/src/testing/testing.go:916 +0x361
FAIL	golang.org/x/tools/go/packages	17.895s
```

It's not obvious to me whether this is a secondary symptom of the race reported in #31749 or an unrelated bug.

CC @matloob @ianthehat
Repository: go
Issue: x/tools: frequent out-of-memory errors on linux-arm builder
Labels: Testing,Builders,NeedsInvestigation,Tools

The tests under `golang.org/x/tools` almost always fail on the `linux-arm` builder.

Looking at the build dashboard, the most frequent failure mode (by far) seems to result in errors of the form `fork/exec /workdir/go/bin/go: cannot allocate memory *os.PathError` in the `golang.org/x/tools/internal/lsp` tests:

https://build.golang.org/log/5fb7985054d8b682b81438c385ff16e8325a3aa6
https://build.golang.org/log/e422caa59d35f5c76e097fdadb60407ee2807368
https://build.golang.org/log/3e3e538cf33e70880da37c2dd1c716b733b4b009
https://build.golang.org/log/739f069936cc47cc800b4d898c505e17a9d4a7e1

However, some of the other tests have also flaked with various resource-exhaustion errors:

A similar `cannot allocate memory` failure mode for `golang.org/x/tools/go/internal/gcimporter`:
https://build.golang.org/log/99a21d9e2e1064d08890439b43de987e0bfcdf52

`fatal error: runtime: out of memory` in `golang.org/x/tools/go/ssa`:
https://build.golang.org/log/de56b0ffe0e39b38b9ed449bd0cd382be72eda69

`pthread_create failed: Resource temporarily unavailable` and `no space left on device`:
https://build.golang.org/log/7151dca16e38a6f61051f032b2f6b713253052ac

---

I don't know exactly what the resource footprint of the `linux-arm` builder is (@andybons or @dmitshur might know?), but if the `x/tools` tests are expected to pass within that footprint we may need to dial back the test concurrency on that builder.

CC @ianthehat
Repository: go
Issue: x/debug/cmd/viewcore: does not build on aix-ppc64
Labels: Testing,help wanted,Builders,NeedsInvestigation,OS-AIX

The `x/debug` build is consistently failing on the `aix-ppc64` builder.
It appears that `x/debug` depends on `github.com/chzyer/readline`, but that package is missing an `aix` implementation.

CC @chzyer @Helflym 

```
aix-ppc64 at 67f181bfd84dfd5942fe9a29d8a20c9ce5eb2fea building debug at 621e2d3f35dac46daf912f8d9d2fabd57d022520

:: Running /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/bin/go with args ["/ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/bin/go" "test" "-short" "golang.org/x/debug/..."] and env ["TERM=dumb" "AUTHSTATE=compat" "SHELL=/usr/bin/ksh" "HOME=/" "USER=root" "PATH=/ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/bin:/opt/freeware/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java7_64/jre/bin:/usr/java7_64/bin" "TZ=CST6CDT" "LANG=en_US" "LOCPATH=/usr/lib/nls/loc" "LC__FASTMSG=true" "ODMDIR=/etc/objrepos" "CLCMD_PASSTHRU=1" "LOGNAME=root" "LOGIN=root" "META_BUILDLET_BINARY_URL=https://storage.googleapis.com/go-builder-data/buildlet.aix-ppc64" "GO_STAGE0_NET_DELAY=300ms" "GO_STAGE0_DL_DELAY=100ms" "NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat:/usr/lib/nls/msg/%l.%c/%N:/usr/lib/nls/msg/%l.%c/%N.cat" "WORKDIR=/ramdisk8GB/workdir-host-aix-ppc64-osuosl" "GOROOT_BOOTSTRAP=/ramdisk8GB/workdir-host-aix-ppc64-osuosl/go1.4" "GO_BUILDER_NAME=aix-ppc64" "GOROOT_BOOTSTRAP=/opt/freeware/lib/golang" "PATH=/opt/freeware/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java7_64/jre/bin:/usr/java7_64/bin" "GOROOT=/ramdisk8GB/workdir-host-aix-ppc64-osuosl/go" "GOPATH=/ramdisk8GB/workdir-host-aix-ppc64-osuosl/gopath" "GOPROXY=http://10.240.0.23:30157" "GOPROXY=https://proxy.golang.org" "TMPDIR=/ramdisk8GB/workdir-host-aix-ppc64-osuosl/tmp" "GOCACHE=/ramdisk8GB/workdir-host-aix-ppc64-osuosl/gocache"] in dir /ramdisk8GB/workdir-host-aix-ppc64-osuosl/gopath/src/golang.org/x/debug

go: downloading github.com/spf13/cobra v0.0.3
go: downloading github.com/chzyer/readline v0.0.0-20180603132655-2972be24d48e
go: extracting github.com/chzyer/readline v0.0.0-20180603132655-2972be24d48e
go: extracting github.com/spf13/cobra v0.0.3
go: downloading github.com/spf13/pflag v1.0.3
go: extracting github.com/spf13/pflag v1.0.3
go: finding github.com/chzyer/readline v0.0.0-20180603132655-2972be24d48e
go: finding github.com/spf13/pflag v1.0.3
go: finding github.com/spf13/cobra v0.0.3
# github.com/chzyer/readline
../../../../pkg/mod/github.com/chzyer/readline@v0.0.0-20180603132655-2972be24d48e/utils.go:241:9: undefined: State
ok  	golang.org/x/debug/internal/core	0.031s
```