sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: Windows 10 CMake | OPENCV_EXTRA_MODULES_PATH | Bug
Labels: bug,priority: low,category: build/install

- OpenCV => Latest Github
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015

```
CMake Error at cmake/OpenCVModule.cmake:368 (_glob_locations):
  Syntax error in cmake code at

    E:/opencv_github/opencv/cmake/OpenCVModule.cmake:368

  when parsing string

    E:\opencv_github\opencv_contrib\modules

  Invalid character escape '\o'.
Call Stack (most recent call first):
  modules/CMakeLists.txt:7 (ocv_glob_modules)
```

This error is only generated when i set OPENCV_EXTRA_MODULES_PATH,
I have set the path to the modules folder after taking checkout of opencv_contrib.

![image](https://user-images.githubusercontent.com/31314950/40835083-16b3842a-65b0-11e8-9d58-0325f1347012.png)
Repository: go
Issue: all: be consistent about the term "embedded field"
Labels: NeedsFix

The spec very clearly calls fields with no names "embedded fields": https://golang.org/ref/spec#Struct_types

> A field declared with a type but no explicit field name is called an embedded field.

However, the Go standard library and documentation mixes that term with "anonymous field":

```
$ cd tip
$ git grep -i 'embedded field' | wc -l
83
$ git grep -i 'anonymous field' | wc -l
38
```

In particular, I found it in https://golang.org/pkg/go/ast/#Field:

    Names   []*Ident      // field/method/parameter names; or nil if anonymous field

Since the spec only mentions one, and it seems to dominate in usage anyway, I think we should try to be as consistent as possible. Specific cases have been fixed in the past, like https://github.com/golang/go/commit/b396d1143b3e717eb2828a101feeb8eb6810891b.

Of course, this doesn't include names that would break Go1 if changed - it is mainly meant for godocs, comments, and errors messages given by `go/*` and `cmd/*`. I presume that old changelogs, such as `doc/devel/weekly.html`, don't need to be changed.

/cc @griesemer @rsc @mdempsky
Repository: pytorch
Issue: Build error : mpi/mpi_gpu_test.cc.o:  undefined reference to symbol '_ZN3MPI8Datatype4FreeEv'
Labels: caffe2

I get the following error while trying to build the package on ubuntu 16.04:

cc1plus: warning: unrecognized command line option '-Wno-unknown-warning-option'
cc1plus: warning: unrecognized command line option '-Wno-invalid-partial-specialization'
[ 91%] Linking CXX executable ../bin/mpi_gpu_test
/usr/bin/ld: CMakeFiles/mpi_gpu_test.dir/mpi/mpi_gpu_test.cc.o: undefined reference to symbol '_ZN3MPI8Datatype4FreeEv'
//usr/lib/libmpi_cxx.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
caffe2/CMakeFiles/mpi_gpu_test.dir/build.make:110: recipe for target 'bin/mpi_gpu_test' failed
make[2]: *** [bin/mpi_gpu_test] Error 1
CMakeFiles/Makefile2:3504: recipe for target 'caffe2/CMakeFiles/mpi_gpu_test.dir/all' failed
make[1]: *** [caffe2/CMakeFiles/mpi_gpu_test.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
Repository: angular
Issue: minlength validator causes ExpressionChangedAfterItHasBeenCheckedError when its value is dynamically updated
Labels: type: bug/fix,freq2: medium,workaround2: non-obvious,area: forms,state: confirmed,P3

<!--
PLEASE HELP US PROCESS GITHUB ISSUES FASTER BY PROVIDING THE FOLLOWING INFORMATION.

ISSUES MISSING IMPORTANT INFORMATION MAY BE CLOSED WITHOUT INVESTIGATION.
-->

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:
</code></pre>

## Current behavior
When an input field has a minlength validator directive and minlength value dynamically changes this causes ExpressionChangedAfterItHasBeenCheckedError when the field turns from valid to invalid, and vice-versa, and if you additionally check form validity with *ngIf above the input field. Strangely, when you check form validity below the field with *ngIf there is no error.


## Expected behavior
<!-- Describe what the desired behavior would be. -->
There shouldn't be ExpressionChangedAfterItHasBeenCheckedError after minlenght validation returns a result and field changes state (valid/invalid).



## Minimal reproduction of the problem with instructions
<!--
For bug reports please provide the *STEPS TO REPRODUCE* and if possible a *MINIMAL DEMO* of the problem via
https://stackblitz.com or similar (you can use this template as a starting point: https://stackblitz.com/fork/angular-gitter).
-->
Here is a [demo](https://stackblitz.com/edit/angular-5-minlength-validator-error) which demonstrates the problem and also cases where there is no problem. All the details are described in the demo.

## What is the motivation / use case for changing the behavior?
<!-- Describe the motivation or the concrete use case. -->
It should be possible to dynamically change the value for validation without bumping into ExpressionChangedAfterItHasBeenCheckedError.


## Environment

<pre><code>
Angular version: 5.x
<!-- Check whether this is still an issue in the most recent Angular version -->

Browser:
- [x] Chrome (desktop)
- [x] Firefox
 
</code></pre>
Repository: flutter
Issue: App throws "Failed assertion ... labelStyle != null" when applying TextTheme with only Title color defined
Labels: framework,f: material design,d: api docs,P2,team-design,triaged-design

Hi! I am working on an app using Android studio using Flutter 4.4 and I get the following issue.

This works fine:
```dart
return new MaterialApp(
      title: 'Title',
      theme: new ThemeData(primarySwatch: Colors.lightBlue,)
      home: new HomePage(title: 'Title'),
    );
```
This doesn't:
```dart
return new MaterialApp(
      title: 'Title',
      theme: new ThemeData(
        primarySwatch: Colors.lightBlue,
        textTheme: new TextTheme(
          title: new TextStyle(color: Colors.white),
        )
      ),
      home: new HomePage(title: 'Title'),
    );
```
I've looked and I don't see why this shouldn't work. Is it an issue, or am I missing something basic?
Repository: terminal
Issue: Secondary buffer window restore glitch
Labels: Product-Conhost,Area-Output,Issue-Bug

* Your Windows build number:  (Type `ver` at a Windows Command Prompt)
17682

* What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
Run `vim -u NONE -i NONE "+set tgc"` (needs a recent Windows vim). Maximize the window and then restore it. The buffer will have some visual glitches - the some of the tildes are in random places on the screen. This is a minimal repro, and only happens with termguicolors set (e.g. using ANSI colors in the secondary buffer). The issue is more apparent though if you have some vim plugins installed:
![image](https://user-images.githubusercontent.com/1094150/40816690-31b5e900-6503-11e8-9244-ca7e38c6d324.png)

After typing a couple lines with my vimrc:
![image](https://user-images.githubusercontent.com/1094150/40816779-9cd4cdaa-6503-11e8-9b5b-36b8c68d48d2.png)

If you're using no vimrc, it helps to see the issue if you type a couple lines of text and/or `set number` first. The buffer gets pushed about a third of the way down the screen, and the bottom third appears on top.

![image](https://user-images.githubusercontent.com/1094150/40848568-7858bbaa-6574-11e8-8815-2ce58b17feec.png)

* What's wrong / what should be happening instead:
The buffer shouldn't be glitchy.
Repository: vscode
Issue: onEnterRules should be multi-line aware
Labels: feature-request,languages-basic,editor-autoindent

<!--
Do you have a question? Please ask it on https://stackoverflow.com/questions/tagged/vscode.

For bug reports, please fill in the details below. For feature requests, please describe the desired feature.
-->

<!-- Use Help > Report Issue to prefill these. -->

Use  case: Microsoft/vscode-cpptools#2072
Steps to Reproduce:

Type the following text in a .cpp file
```
a = a
    * b;
```
Then hit enter at the end of the line to begin a new line. You'll get

```
a = a
    * b;
    * 
```
This is not expected behavior in this context. This is perhaps expected when in the middle of a multiline decorated comment but not otherwise.

This does not happen in an unsaved file, a file with no extension, .txt extension etc. and does not happen if the cpptools extension is disabled and happens when it is re-enabled.
Repository: pytorch
Issue: [PyTorch] EmbeddingBag comparison vs Embedding fails w/ small max_norm on CUDA
Labels: triaged,module: norms and normalization

When using small `max_norm` values like `0.1`, `1` or `2`, the comparison on CUDA fails with large error (Half w/ 0.1 fails with error ~`0.16`), but passes on CPU.

Relevant lines: https://github.com/pytorch/pytorch/blob/master/test/test_nn.py#L1674-L1706 

Discovered when doing #7959 

cc @adamlerer
Repository: neovim
Issue: swapfile dialog should check for zombie processes
Labels: enhancement,complexity:low,system

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`: 0.2.2
- Vim (version: ) behaves differently? unknown
- Operating system/version: FreeBSD but probably all OS except Windows
- Terminal name/version: conhost but N/A
- `$TERM`: xterm-256color but N/A

### Steps to reproduce using `nvim -u NORC`

```
nvim -u NORC foo.cpp
# now in another terminal kill the nvim process but don't reap it
# probably easiest to spawn nvim programatically so that you can skip reaping by not checking its exit status
nvim -u NORC foo.cpp
```

### Actual behaviour
neovim presents the swap file warning as the swap file exists, but when querying the parent process it considers it to still be alive since the pid remains in the OS ps tables. 

### Expected behaviour
neovim should take into account that the process status for the pid specified in the swap file is zombie and treat it as if it were not running.

(Please note that I experienced this running 0.2.2 but did not have the time to set up a repro case under master, given the complexity in reproducing, however given how straightforward the problem is, I presume this is either a "still exists in master" or "yup, known issue and since fixed".)
Repository: bitcoin
Issue: Notes on Compact Block getdata fallback responses
Labels: P2P

This came up at a meeting a while back, but I realized it was never materially written down anywhere.

Compact Block high-bandwidth processing can fall back to getdatas when the client belives a short id collision may have occurred (among a few other cases). In such cases, we are required to wait until we have verified the full block before we can respond to the getdata request (hence the few awkward ActivateBestChain calls in net_processing). However, in case we find the block to be invalid (or decide its actually not our best-chain-candidate due to some race receiving another block in parallel) we will simply leave the getdata unresponded to. This will result in us eventually getting disconnected for stalling.

It is important to note that, were an attacker able to generate a block which, when relayed, would cause getdata fallbacks on an invalid block, such an attacker would be able to cause massive disconnections across the network, especially targeting mining nodes or other nodes which receive blocks particularly fastly. I do not believe such creation is currently possible, but definitely could be bad if we did something dumb like fixing the nonce in the future.

During the meeting we discussed using the existing NOTFOUND message for block requests as well, which seemed to have some level of support (or a BLOCK_NOTFOUND or whathaveyou) and using that to allow peers to simply reject providing a block without being disconnected as a staller.
Repository: pytorch
Issue: [PyTorch] Windows CI CUDA mem leak check on BN tests are flaky
Labels: module: memory usage,triaged,module: flaky-tests

They often report -1024 anti-leaks. Instances:
https://ci.pytorch.org/jenkins/job/pytorch-builds/job/pytorch-win-ws2016-cuda9-cudnn7-py3-test1/44/console
https://ci.pytorch.org/jenkins/job/pytorch-builds/job/pytorch-win-ws2016-cuda9-cudnn7-py3-test1/106/console
https://ci.pytorch.org/jenkins/job/pytorch-builds/job/pytorch-win-ws2016-cuda9-cudnn7-py3-test1/107/console

Can't reproduce on our Win dev CI machine, so temporarily disabling at #8043 .
Repository: flutter
Issue: Min width of material button is greater than it should be
Labels: framework,f: material design,a: fidelity,P2,team-design,triaged-design

Spec says 64dp, but its set to 88dp
Repository: go
Issue: net/http: consider implementing browser http client at http.Client level instead of http.RoundTripper
Labels: arch-wasm

The motivation for considering implementing the HTTP client at `http.Client` level rather than `http.RoundTripper`, it has to do with the fact that browser APIs (such as XmlHTTPRequest and Fetch) do not allow making individual HTTP requests without interpreting the response code, they operate at a higher level, closer to what `http.Client.Do` method does.

This issue is a continuation of a [discussion in CL 114515](https://go-review.googlesource.com/c/go/+/114515#message-24f243ca77abe666842f6f24a1019d1bd6f2d5d3). /cc @bradfitz @johanbrandhorst @neelance

I wrote:

> http.Transport type is documented as:
> 
>     // A Transport is a low-level primitive for making HTTP and HTTPS requests.
>     // For high-level functionality, such as cookies and redirects, see Client.
> 
> When I originally wrote this functionality in GopherJS, I started by doing it at the http.RoundTripper level and was hoping to implement as much of its semantics as possible. Getting response body streaming was my main motivation, and the XHR transport was already implemented at http.RoundTripper level too, so it was a quick decision.
> 
> Over time, I learned that both XHR and Fetch browser APIs are higher level and don't allow making individual HTTP requests. Due to security reasons and things like CORS, the frontend code doesn't actually ever get Redirect responses, only the final redirect destination. Fetch also deals with caching, credentials, etc.
> 
> I didn't want to touch this decision for GopherJS because it was more of a prototype, but since this is the real Go tree, perhaps we should revisit the decision of what abstraction level to implement this at. I haven't prototyped it yet, but given what I've seen so far, I suspect that implementing the HTTP client in browsers at the http.Client level may be a closer fit to what browsers allow client code to do.
> 
> Thoughts (Brad, Johan, Richard)?

@johanbrandhorst wrote:

> I'm not sure I understand how this would apply here - wouldn't we still need a custom Transport implementation? If we defined a js,wasm specific client presumably it'd still need to have all the same fields as the normal client.

@bradfitz wrote:

> Good point, but I'm more concerned with more code working by default without changes, so I think this is okay to violate for now in Go 1.11. We can revisit in Go 1.12 & later.

I've been thinking about this more, and I have 2 comments (to be posted as replies). It's not clear to me what will end up being the best (least bad) solution.
Repository: go
Issue: runtime: TestGdbPython flaky on linux-mipsle builder
Labels: Testing,help wanted,NeedsInvestigation,compiler/runtime

Examples:
https://build.golang.org/log/e59511fa905a9939c7b85a9f6cefb99140c8915f
https://build.golang.org/log/dc9b43b3eb5e0029089cf9ac53b37f6b8b0e7847

Detail:
```
##### GOMAXPROCS=2 runtime -cpu=1,2,4 -quick
--- FAIL: TestGdbPython (3.10s)
    runtime-gdb_test.go:61: gdb version 7.7
    runtime-gdb_test.go:195: gdb output: Loading Go Runtime support.
        Loaded  Script                                                                 
        Yes     /data/mipsle/go/src/runtime/runtime-gdb.py                             
        Breakpoint 1 at 0x9b508: file /data/mipsle/go/src/fmt/print.go, line 264.
        Failed to read a valid object file image from memory.
        
        Breakpoint 1, fmt.Println (a=..., err=..., n=<optimized out>) at /data/mipsle/go/src/fmt/print.go:264
        264		return Fprintln(os.Stdout, a...)
        BEGIN info goroutines
        * 1 running  runtime.systemstack_switch
          2 runnable runtime.forcegchelper
          3 waiting  runtime.gopark
          4 runnable runtime.runfinq
        END
        #1  0x000a24e0 in main.main () at /tmp/go-build482556707/main.go:13
        13		slicevar = append(slicevar, mapvar["abc"])
        BEGIN print mapvar
        $1 = map[string]string = {["abc"] = "def", ["ghi"] = "jkl"}
        END
        BEGIN print strvar
        $2 = "abc"
        END
        BEGIN info locals
        mapvar = map[string]string = {["abc"] = "def", ["ghi"] = "jkl"}
        slicevar =  []string = {"def"}
        strvar = "abc"
        END
        #0  fmt.Println (a=..., err=..., n=<optimized out>) at /data/mipsle/go/src/fmt/print.go:264
        264		return Fprintln(os.Stdout, a...)
        BEGIN goroutine 1 bt
        #0  fmt.Println (a=..., err=..., n=<optimized out>) at /data/mipsle/go/src/fmt/print.go:264
        #1  0x000a24e0 in main.main () at /tmp/go-build482556707/main.go:13
        END
        BEGIN goroutine 2 bt
        #0  runtime.forcegchelper () at /data/mipsle/go/src/runtime/proc.go:243
        #1  0x000a24e0 in main.main () at /tmp/go-build482556707/main.go:13
        END
        Breakpoint 2 at 0xa2514: file /tmp/go-build482556707/main.go, line 18.
        
        Program received signal SIGTRAP, Trace/breakpoint trap.
        fmt.Println (a=..., err=..., n=<optimized out>) at /data/mipsle/go/src/fmt/print.go:264
        264		return Fprintln(os.Stdout, a...)
        BEGIN goroutine 1 bt at the end
        #0  fmt.Println (a=..., err=..., n=<optimized out>) at /data/mipsle/go/src/fmt/print.go:264
        #1  0x000a24e0 in main.main () at /tmp/go-build482556707/main.go:13
        END
        
    runtime-gdb_test.go:264: goroutine 1 bt at the end failed: #0  fmt.Println (a=..., err=..., n=<optimized out>) at /data/mipsle/go/src/fmt/print.go:264
        #1  0x000a24e0 in main.main () at /tmp/go-build482556707/main.go:13
FAIL
FAIL	runtime	208.804s
```

```

```
Repository: angular
Issue: Adding property/event bindings to ng-content should error
Labels: type: bug/fix,hotlist: error messages,freq1: low,area: core,state: confirmed,core: content projection,design complexity: low-hanging

### Issue
Adding property/event bindings to `<ng-content>` (attributes that are not explicitly supported APIs) currently no-op. They should be an error, as the attributes will be completely lost.

### Reproduction 
https://stackblitz.com/edit/angular-gitter-hm6egs?file=app%2Fapp.component.ts
Repository: flutter
Issue: DatePicker touch targets are too small
Labels: framework,f: material design,a: accessibility,f: date/time picker,P2,team-design,triaged-design
Repository: pytorch
Issue: CrossEntropyLoss mishandles weights
Labels: module: nn,module: loss,triaged

## Issue description
When a `weight` tensor is passed to CrossEntropyLoss, it exhibits unusual behavior, such as occasionally ignoring the weights, and returning different results when it averages losses over examples versus averaging them manually.

## Code example
1) Incorrect size_average result
```
input = torch.tensor([
    [-100.,  100.],
    [-100.,  100.]
])
target = torch.tensor([0,1], dtype=torch.long)
weights = torch.tensor([20,10], dtype=torch.float)

ce_noreduce = nn.CrossEntropyLoss(weight=weights, reduce=False)
ce_reduce = nn.CrossEntropyLoss(weight=weights, reduce=True, size_average=True)

loss1 = ce_noreduce(input, target)
loss2 = ce_reduce(input, target)

print(loss1)
print(loss1.mean())
print(loss2)
```
output:
```
tensor([ 4000.,    -0.])
tensor(2000.)
tensor(133.3333)
```

2) Weights ignored
```
input = torch.tensor([
    [-1,  1, -1],
    [-1,  1, -1],
    [-1,  1, -1],
], dtype=torch.float) * 100
target = torch.tensor([0,0,1], dtype=torch.long)
weights = torch.tensor([1,10,1], dtype=torch.float)

ce_noweights = nn.CrossEntropyLoss(weight=None, reduce=False)
ce_weights = nn.CrossEntropyLoss(weight=weights, reduce=False)

loss1 = ce_noweights(input, target)
loss2 = ce_weights(input, target)

print(loss1.mean())
print(loss2.mean())
```
output:
```
tensor(133.3333)
tensor(133.3333)
```

## System Info
```
PyTorch version: 0.4.0
Is debug build: No
CUDA used to build PyTorch: None

OS: Mac OSX 10.13.4
GCC version: Could not collect
CMake version: Could not collect

Python version: 3.6
Is CUDA available: No
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA

Versions of relevant libraries:
[pip3] msgpack-numpy (0.4.1)
[pip3] numpy (1.13.3)
[pip3] numpydoc (0.7.0)
[pip3] torch (0.3.0.post4)
[pip3] torchfile (0.1.0)
[pip3] torchnet (0.0.1)
[pip3] torchtext (0.2.1)
[pip3] torchvision (0.2.0)
[conda] pytorch                   0.4.0           py36_cuda0.0_cudnn0.0_1    pytorch
[conda] torchvision               0.2.1                    py36_1    pytorch
```


cc @albanD @mruberry @jbschlosser
Repository: godot
Issue: UWP export can't find my script
Labels: bug,topic:porting,confirmed,platform:uwp

**Godot version:**
Master as of 2/06/2018, UWP template updated with fresh build and using matching editor build.

**OS/device including version:**
Universal Windows Platform running on Windows 10

**Issue description:**
Exporting to UWP gives error:
Parse Error: [ext_resource] referenced nonexistent resource at: res://Main.gd

The project works fine when running on Windows. Extracting the UWP package I can see that main.gd has been changed to main.gdc (I guess parsed GDScript in binary form?) and there is a main.gd.remap file which I'm guessing the resource loader should be picking up but isn't

**Steps to reproduce:**
Create a new Godot project. Add a root node with a script attached to it.
Export to UWP
Install and run.