sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/go: checksum mismatch lacks resolution information
Labels: NeedsInvestigation,modules

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version

go version devel +5f45a3337e Wed Aug 14 19:49:15 2019 +0000 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
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/iand/.cache/go-build"
GOENV="/home/iand/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/iand"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/iand/wip/--elided---/go.mod"
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-build133450829=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

### What did you do?

Ran `go mod tidy`

### What did you expect to see?

Instructions for investigating the cause and potential resolution of a checksum mismatch.

### What did you see instead?

```
10:24 $ go mod tidy
verifying gotest.tools@v2.2.0+incompatible: checksum mismatch
	downloaded: h1:y0IMTfclpMdsdIbr6uwmJn5/WZ7vFuObxDMdrylFM3A=
	sum.golang.org: h1:VsBPFP1AI068pPrMxtb/S8Zkgf9xEmTLJjfM+P5UIEo=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.
```


This information, while correct, is not very informative for most users. It tells them the problem but doesn't indicate how they can resolve it. Their build will not progress until they resolve the problem. 

`go help module-auth` provides very detailed information on the operation of the module checksum mechanism but doesn't help the typical user get their build working.

In my case `go clean -modcache` solved my problem although I am left with the feeling that I just did the module analog of "switching it off and on again".

The message would be more informative if it told me where the downloaded code is and how I can cross reference that with the code the checksum server saw.
Repository: pytorch
Issue: When running model forward with large batch size, it reports the error: THCudaTensor sizes too large for THCDeviceTensor conversion
Labels: module: cuda,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

When running forward for a language model with a large batch (700 instances per gpu), a tensor storing prediction scores is created with the size of about 700 (batch size) * 128 (sequence length) * 30000 (vocabulary size), and then it reports the following error:

~~~~
 File "/home/work/anaconda3/lib/python3.6/site-packages/torch/nn/modules/module.py", line 489, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/work/anaconda3/lib/python3.6/site-packages/torch/nn/modules/loss.py", line 904, in forward
    ignore_index=self.ignore_index, reduction=self.reduction)
  File "/home/work/anaconda3/lib/python3.6/site-packages/torch/nn/functional.py", line 1970, in cross_entropy
    return nll_loss(log_softmax(input, 1), target, weight, None, ignore_index, None, reduction)
  File "/home/work/anaconda3/lib/python3.6/site-packages/torch/nn/functional.py", line 1790, in nll_loss
    ret = torch._C._nn.nll_loss(input, target, weight, _Reduction.get_enum(reduction), ignore_index)
RuntimeError: THCudaTensor sizes too large for THCDeviceTensor conversion at /pytorch/aten/src/THC/THCDeviceTensorUtils.cuh:71
~~~~

However, it's probably not the out-of-memory error because it's still below the gpu memory capacity.





<!-- A clear and concise description of what you expected to happen. -->

## Environment

* item PyTorch version: 1.0.1.post2
* Is debug build: No
* CUDA used to build PyTorch: 10.0.130

* OS: Ubuntu 18.04.2 LTS
* GCC version: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
* CMake version: version 3.10.2

* Python version: 3.6
* Is CUDA available: Yes
* CUDA runtime version: Could not collect
* GPU models and configuration: 
GPU 0: Tesla V100-SXM2-32GB
GPU 1: Tesla V100-SXM2-32GB
GPU 2: Tesla V100-SXM2-32GB
GPU 3: Tesla V100-SXM2-32GB

* Nvidia driver version: 418.67
* cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.5.0

## Additional context

<!-- Add any other context about the problem here. -->
Repository: go
Issue: cmd/go: fetching dependencies can be very aggressive when going via an HTTP proxy
Labels: NeedsInvestigation,modules

<!-- 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.8 windows/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

`windows/amd64`

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->

1. Set `http_proxy` environment variable
2. `git clone https://github.com/weaveworks/eksctl && cd eksctl`
3. `go build ./cmd/eksctl`

### What did you expect to see?

All dependencies get downloaded and binary gets built. If errors occur, there are a few retries with a back-off.

### What did you see instead?

Some dependencies get downloaded, some fail to download with 407 error in `git fetch`. Binary is not built. I had to rerun `go build` multiple times before it succeeded.
Repository: go
Issue: proposal: identify large changes & add more process
Labels: Proposal

The proposal process was designed in 2015, when the language was effectively frozen and we were not making large changes. Even now, the vast majority of proposed changes are small. But some are large. 

The lightweight process we have works well for small changes, and we wouldn't want to add unnecessary process to those. But if we can reliably identify large changes then we can think about adding extra process for those.

One way to identify large changes is with a simple checklist of how much impact it would have. For example:

 - Is the change user-visible at all?
 - Does it require any changes to any documentation?
 - Are its effects confined to a single package?
 - Does it require changes to the language spec?
 - Does it require users to change existing scripts or workflows?
 - Does it require updating introductory materials?
 - And so on.

Once a change has been identified as large, we could add more process, although we need to decide exactly what that is too. One idea is to keep iterating on design drafts before making an official proposal. Another is to require an experimental prototype be available. And so on. We can collect those ideas here too.
Repository: godot
Issue: Provide an error message for each function that currently returns an Error enum
Labels: enhancement,discussion,topic:core

Following on from https://github.com/godotengine/godot/issues/31393, I noticed that I get the following error:

```
E 0:00:04:0301   Condition ' err ' is true. returned: ERR_CANT_OPEN
  <C Source>     scene/resources/resource_format_text.cpp:1488 @ save()
  <Stack Trace>  Game.gd:56 @ save()
                 SavePopup.gd:70 @ _on_new_save_confirmed()
                 NewSavePopup.gd:14 @ _on_confirm_pressed()
```

I would like to show an `AcceptDialog` that says something like:

> Error saving game: can't open "blah/blah/save.tscn"

Currently I have to check the return type of the function and account for every possible type of failure for that function - something which is not currently documented, and hence would require me to look through Godot's source.

In the comments of another bug report, @bojidar-bg proposed a more elaborate return type:

https://github.com/godotengine/godot/issues/7643#issuecomment-280099751

> One other way I was thinking about in the past is to have
> 
> ```
> CallResult Object::call_error(method_name, args...);
> class CallResult {
>    Variant result = NULL;
>    Error error = OK;
>    String error_text = "";
> }
> ```
> 
> That way we can make a simple try catch already, with something like this:
> 
> ```
> func call_something_that_fails():
>   var result = some_object.call_error("oh_no", argument1, argument2)
>   if result.error != OK:
>     raise "How totally expected"
>     return result.error
>   else:
>     return result.result
> ```

This would be perfect: it saves me from having to account for each possible error that the function can return and I can just show the message directly to the user.

Is it possible to do this in a backwards-compatible way, or is not really possible?
Repository: youtube-dl
Issue: Unsupported URL: mytaratata.com
Labels: site-support-request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist



- [x ] I'm reporting a new site support request
- [x ] I've verified that I'm running youtube-dl version **2019.08.13**
- [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

https://mytaratata.com/taratata/228/no-one-is-innocent-la-peur-2007
https://mytaratata.com/taratata/203/cassius-toop-toop-2007


## Description
youtube-dl https://mytaratata.com/taratata/203/cassius-toop-toop-2007
[generic] cassius-toop-toop-2007: Requesting header
WARNING: Falling back on generic information extractor.
[generic] cassius-toop-toop-2007: Downloading webpage
[generic] cassius-toop-toop-2007: Extracting information
ERROR: Unsupported URL: https://mytaratata.com/taratata/203/cassius-toop-toop-2007


WRITE DESCRIPTION HERE
Repository: rust
Issue: pgo: -Cprofile-use can't find file
Labels: A-frontend,C-enhancement,A-diagnostics,T-compiler,T-cargo,A-PGO

````bash
git clone https://github.com/matthiaskrgr/cargo-cache
cd cargo-cache
RUSTFLAGS="-Cprofile-generate=target/pgodata" cargo build --release
./target/release/cargo-cache
./target/release/cargo-cache
./target/release/cargo-cache q hello
./target/release/cargo-cache r
./target/release/cargo-cache --top-cache-items 10
llvm-profdata merge -o target/merged.profdata ./target/pgodata/
file target/merged.profdata  
# target/merged.profdata: LLVM indexed profile data, version 5
RUSTFLAGS="-Cprofile-use=target/merged.profdata" cargo build --release  -j 1
````
````
   Compiling serde v1.0.98
error: File `target/merged.profdata` passed to `-C profile-use` does not exist.

error: aborting due to previous error

error: Could not compile `serde`.

To learn more, run the command again with --verbose.
````

The file is definitely there, but for some reason it is not found??

`rustc 1.38.0-nightly (c43d03a19 2019-08-14)`
Repository: flutter
Issue: Add FlutterView systemGestureInsets tests in the Flutter engine
Labels: a: tests,c: new feature,platform-android,engine,P3,team-android,triaged-android

Currently, JUnit tests are blocked for tests requiring Android SDK 29 (Q) because of issues with Robolectric, our Android testing framework. To make progress on high priority tickets, we will land PRs now and land tests as a follow-up. This issue is created to track where such tests need to be added once the issues with Robolectric have been resolved.

Issue tracking implementation of Robolectric support of Q: https://github.com/flutter/flutter/issues/38471 

Edit: The above issue has now been fixed, so the only thing that's needed to be done here is to introduce tests for systemGestureInsets! 

Tests required:
- [ ] FlutterView systemGestureInsets tests - https://github.com/flutter/engine/pull/10413
Repository: pytorch
Issue: 1.0rc0-6216 installs empty directories under include and duplicates under /
Labels: module: build,triaged

The FreeBSD ports framework complains:
```
@dir include/c10/cuda/test/impl
@dir include/c10/hip
@dir include/c10/test/core/impl
@dir include/c10/test/util
@dir include/caffe2/contrib/aten/docs
@dir include/caffe2/contrib/docker-ubuntu-14.04
@dir include/caffe2/contrib/ideep
@dir include/caffe2/contrib/nnpack
@dir include/caffe2/contrib/opencl/OpenCL
@dir include/caffe2/contrib/playground/resnetdemo
@dir include/caffe2/contrib/pytorch
@dir include/caffe2/contrib/script/examples
@dir include/caffe2/contrib/tensorboard
...
@dir include/caffe2/python/trt
@dir include/caffe2/share/contrib/depthwise
@dir include/caffe2/share/contrib/nnpack
@dir include/caffe2/test/assets
@dir include/caffe2/utils/hip
@dir include/torch/csrc/api/src/data/datasets
@dir include/torch/csrc/api/src/data/samplers
@dir include/torch/csrc/api/src/nn/modules
@dir include/torch/csrc/api/src/optim
@dir include/torch/csrc/api/src/python
@dir include/torch/csrc/api/src/serialize
@dir include/torch/csrc/jit/backends
@dir include/torch/csrc/jit/docs
@dir include/torch/csrc/jit/generated
@dir /usr/torch/csrc/jit/script
@dir /usr/torch/csrc/jit
@dir /usr/torch/csrc
@dir /usr/torch
```

I have to remove them manually for the FreeBSD port, but they shouldn't be installed by the project in the first place.

```/usr/torch``` has duplicates of what is already installed under ```/usr/local/torch```.
Repository: terminal
Issue: Terminal cannot use SVG files in backgroundImage, icon (xaml limitation?)
Labels: Issue-Bug,Area-Settings,Product-Terminal,Tracking-External,External-Blocked-WinUI3

Over at UsingJsonSettings.md, in [the section about adding a background image](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#add-a-custom-background-to-the-wsl-debian-terminal-profile) it directs me to download the .SVG image in Step 1

Step 4 then says to use the .JPG: ( `"backgroundImage": "ms-appdata:///Roaming/openlogo.jpg",` ) but this doesn't display the image in the Terminal.

Changing Step 4 to use the .SVG also doesn't display the image

Changing the file to be an actual .JPG (downloaded from the [Debian logo page](https://www.debian.org/logos/)  ) causes the image to appear.  

The docs definitely need to be tweaked :)
(I'm not sure if .SVG is supposed to work or not, otherwise I'd do a PR to offer a fix)
Repository: pytorch
Issue: Building Python bits separate from C++ bits and making one play well with the other
Labels: module: build,triaged,enhancement

I am in the process of creating of the FreeBSD port for PyTorch.
So far I am able to build the C++ part (with ```BUILD_PYTHON=OFF```), and am intending to create a port/package named ```science/pytorch```. Since there are C++ examples available I concluded that the C++ part is usable in itself.

Obviously, the next step will be to create the pythonic port that would use the C++ library.

Are there instructions available on how to build the python part once the C++ library is available? I'm asking because the source tree is the same for some reason.
Repository: opencv
Issue: JS: npm package
Labels: category: javascript (js)

I see there's no package for opencv.js so JavaScript users can install it using `npm install` as is accustomed by JS users. 

The benefits of this would be also that is better integrated with web bundlers like webpack, parcel, browserify which simplify development workflow used in generally for web development. 

I think for supporting this, the .wasm version could be better. BTW the current open.js file, although it works since it supports UMD, it would not be the best since it will be combined by bundlers (so the resulting .js file will contain it and will be huge bloking the user's apps). Instead it should be downloaded separately optionally allowing users to define an alternative url for it (like a CDN). 

I'm working on a proof f concept for this, and also to support / tests for node.js as API and a little CLI tool too, and I wonder if something like this would be accepted as a PR to at least start the discussion. 

Thanks
Repository: pytorch
Issue: Use a ScriptModule on GPU that was saved from CPU
Labels: oncall: jit,module: serialization,triaged

## 🐛 Bug

When a ``nn.Module`` that have been instantiated on CPU is traced and saved, it expects a `CPUFloatType` tensor even if the `ScriptModule` is mapped onto GPU.

## To Reproduce

Steps to reproduce the behavior:

1.Build a `nn.Module` on CPU
1.Trace and save the `ScriptModule` in a file
1.Load the file with `map_location=GPU`

```python
module = torch.jit.trace_module(model, {'forward': torch.rand(1, 1, 200, 200)})
torch.jit.save(module, 'test_torchscript_cpu.pt')

script_module = torch.jit.load('test_torchscript_cpu.pt', 
                               map_location=torch.device('cuda:0'))
input_tensor = torch.rand(1, 1, 200, 200).to(torch.device('cuda:0'))  # --> RuntimeError: expected device cuda:0 and dtype Float but got device cpu and dtype Float
input_tensor = torch.rand(1, 1, 200, 200))  # --> RuntimeError: Input type (Variable[CPUFloatType]) and weight type (Variable[CUDAFloatType]) should be the same
script_module(input_tensor)
```

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

I expected that whether a `nn.Module` was traced on GPU or CPU, when loaded on CPU (resp. GPU) it needs a tensor from the CPU(resp. GPU)

## Environment

PyTorch version: 1.2.0
Is debug build: No
CUDA used to build PyTorch: 10.0.130

OS: Ubuntu 18.04.3 LTS
GCC version: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
CMake version: version 3.10.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

Nvidia driver version: 430.14
cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.0

Versions of relevant libraries:
[pip] numpy==1.16.4
[pip] torch==1.2.0
[pip] torchsummary==1.5.1
[pip] torchvision==0.4.0a0+6b959ee
[conda] Could not collect

## What works
If I expect the model to run on GPU, it needs to be loaded onto GPU before tracing, then saved

```python
model.to(torch.device('cuda:0')
input_tensor = torch.rand(1, 1, 200, 200).to(torch.device('cuda:0'))
module = torch.jit.trace_module(model, {'forward': input_tensor})
torch.jit.save(module, 'test_torchscript_gpu.pt')
script_module = torch.jit.load('test_torchscript_gpu.pt', 
                               map_location=torch.device('cuda:0'))
script_module(input_tensor)
```


cc @suo
Repository: flutter
Issue: InkWell from UserAccountsDrawerHeader not showing
Labels: framework,f: material design,has reproducible steps,P2,found in release: 3.0,found in release: 3.1,team-design,triaged-design

The `UserAccountsDrawerHeader` is supposed to have a `InkWell` in its `_AccountDetailsState`, but this isn't visible at all when using it. This can be confirmed by downloading the Flutter Gallery App and taping at the user details in the Drawer Navigation example.
Repository: godot
Issue: Godot ignores Viewports with size 0 even though their size is determined by OpenVR
Labels: bug,topic:core,usability,topic:xr

**Godot version:**
3.1.1


**OS/device including version:**
Ubuntu 19.10
Nvidia GTX 1080
Nvidia Driver: 430.34
Headset: HTC Vive
SteamVR Version: 1.7.4

**Issue description:**
Attempting to use arvr with a secondary viewport results in a blank screen on the headset


**Steps to reproduce:**
Add godot-openvr addon
Add camera to scene
Add viewport to scene
Add VR components (inc arvarcamera) to viewport
Disable HDR on viewport, enable arvr
Add following script to root of scene:
 ```
	var vr = ARVRServer.find_interface("OpenVR")
	if vr and vr.initialize():
		OS.vsync_enabled = false
		Engine.target_fps = 90
```
Start scene

Expected Result:
Main window should render the fixed camera
VR headset should render the ARVRcamerea

Actual Results:
Main window renders fixed camera
VR headset is blank

**Minimal reproduction project:**
https://github.com/mrmakeit/VR-Viewport-Test

Additional Notes:
The version of the openvr addon does not seem to matter. I have used both the latest and one downloaded for 3.0.6 with exactly the same results

Everything works as expected with 3.0.6.

I've opened an issue in godot-openvr as well, but since the bug shows up only in 3.1.1, regardless of addon version, I thought I'd open a issue here as well.
Issue for godot-openvr: godotvr/godot_openvr#61
Repository: rust
Issue: object lifetime bound defaults in trait bindings are incompletely implemented
Labels: A-type-system,A-lifetimes,A-trait-system,T-lang,T-compiler,T-types,A-trait-objects

In https://github.com/rust-lang/rust/pull/63376, we fixed the behavior of default object lifetime bounds in "binding arguments", as described in [this gist](https://gist.github.com/nikomatsakis/e0ac0276744d10b952cf4ea3d3d8a814). For example the following type;

```rust
dyn Foo<Bar = dyn Baz>
```

will now default `dyn Baz` to `dyn Baz + 'static`.

However, the rules were incompletely implemented. If the trait has a lifetime parameter, we currently require an explicit lifetime bound. The expected behavior is to use the bounds declared on the associated type to set the default. So, given `Foo` like so:

```rust
trait Foo<'a> {
  type Bar: 'a + ?Sized;
}
```

then `dyn Foo<'x, Bar = dyn Baz>` would default to `dyn Baz + 'a`. Presently, however, it gives an error.

NB. There is one "design decision" to be made; does a where clause like `where Self::Bar: 'x` adjust the default? And how does that work when extended to GATs? My personal opinion is that we should limit ourselves to bounds declared on the associated type itself (and hence `where Self::Bar: 'x` would not count towards the default object lifetime bound), but this merits a bit of further discussion. This is largely because the complexity to specify and implement the behavior around where clauses and with GATs is kind feels out of proportion with the benefit.