sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: Conflicts of cv::InputArray::size()  and cv::InputArray::getSz() for std::array<cv::Mat, N>
Labels: bug,category: core,RFC

<!--
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)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => master


##### Detailed description

<!-- your description -->

For `std::array<cv::Mat, N>`, 
 - `cv::InputArray::getSz()` returns a column vector representation, see [here][1]
```.cpp
template<std::size_t _Nm> inline
_InputArray::_InputArray(const std::array<Mat, _Nm>& arr)
{ init(STD_ARRAY_MAT + ACCESS_READ, arr.data(), Size(1, _Nm)); }
#endif
```
 - `cv::InputArray::size()` returns a row vector representation, see [here][2]

```.cpp
return sz.height==0 ? Size() : Size(sz.height, 1);
```
[2]: https://github.com/opencv/opencv/blob/master/modules/core/src/matrix.cpp#L1659
[1]: https://github.com/opencv/opencv/blob/master/modules/core/include/opencv2/core/mat.inl.hpp#L94



<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
Repository: opencv
Issue: Request to enable CV_Assert for cv::Mat::size()
Labels: category: core,RFC

<!--
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)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => master


##### Detailed description

The current version of `cv::Mat::size()`
supports only 2-D matrices, but the
assertion is enabled only in the debug mode, see
[here][1]
```.cpp
inline
Size MatSize::operator()() const
{
    CV_DbgAssert(p[-1] <= 2);
    return Size(p[1], p[0]);
}
```

It is error-prone to use `cv::Mat::size()` and `cv::InputArray::size()` for
n-D matrices in the release mode.

Change `CV_DbgAssert(p[-1] <= 2);` to
`CV_Assert(p[-1] <= 2);` will eliminate this concern.

[1]: https://github.com/opencv/opencv/blob/a55aed5f42b89fd0544de1eaeb95b76c1c9d3734/modules/core/include/opencv2/core/mat.inl.hpp#L1407

<!-- your description -->


<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
Repository: go
Issue: go/types/gotype: build tags not supported
Labels: NeedsFix

### What version of Go are you using (`go version`)?
`go version go1.9.2 linux/amd64`

### Does this issue reproduce with the latest release?
Already using latest release, so yes

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOOS="linux"

### What did you do?
Created a program where one of two build tags must be provided to build, then tried to lint it with `gotype`.

`main.go`
```go
package main

import (
	"./sub"
	"fmt"
)

func main() {
	fmt.Printf("Hello, %s!\n", sub.Get())
}
```
`sub/sub_a.go`
```go
//+build a

package sub

func Get() string {
	return "world"
}
```
`sub/sub_b.go`
```go
//+build b

package sub

func Get() string {
	return "everyone"
}
```
`sub/sub.go`
```go
package sub

// some shared code
```

```
$ ls
main.go  sub
$ gotype .
main.go:9:29: Get not declared by package sub
$ go run -tags a main.go 
Hello, world!
$ go run -tags b main.go 
Hello, everyone!
```

### What did you expect to see?
`gotype` would have a `-tags` argument to specify build tags, e.g.
```
$ gotype -tags a .
```

### What did you see instead?
`gotype` has no way to specify build tags for linting
Repository: create-react-app
Issue: Set 'currentScript' as default 'PUBLIC_URL'
Labels: issue: proposal

Like I suggested in [#3708 (comment)](https://github.com/facebookincubator/create-react-app/issues/3708#issuecomment-358298289), `currentScript` could be a possible default for `PUBLIC_URL`.

Right now **all** asset paths are relative (ie `/static/media/logo.2e151009.png`) to the root of the app.
When setting the [`PUBLIC_URL` environment parameter](https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#adding-assets-outside-of-the-module-system) or the [`homepage` in `package.json`](https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#building-for-relative-paths), the asset paths become absolute (ie `https://app.com/static/media/logo.2e151009.png`).
Setting these 2 variables is mostly used when you have your app running in a subdirectory on your server.

My proposal is to default the `PUBLIC_URL` to the root of the app, so there will be less need of setting the `PUBLIC_URL` or `homepage` and CRA would need less configuration **by default**. If it's still necessary to set `PUBLIC_URL` or `homepage`, that would still be possible of course. 🙂

The implementation for this could be to check the file-path of the `main.*.js` script (ref: [StackOverflow](https://stackoverflow.com/q/2255689)), which could be accessed by calling `document.currentScript` (ref: [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Document/currentScript)). Since this isn't possible in IE, we could use [this answer](https://stackoverflow.com/a/2255727/4001231) as a fallback.

```js
function resolvePublicPath() {
  const currentScript = document.currentScript || getCurrentScriptViaFallback();
  const publicPath = currentScript.src
    .split('/static/js')[0] // app root directory
    .split('main.')[0]; // add support for script in app root directory
  
  return `${publicPath}/`;
}
```
Repository: go
Issue: x/tools/go/buildutil: split TagsFlagDoc into multiple lines?
Labels: NeedsDecision,Tools

### What version of Go are you using (`go version`)?

    go version devel +7e054553ad Tue Jan 16 15:11:05 2018 +0000 linux/amd64

### Does this issue reproduce with the latest release?

Yes.

### What did you do?

Add a `-tags` flag to a static analysis tool of mine:

```
func init() {
        flag.Var((*buildutil.TagsFlag)(&build.Default.BuildTags), "tags", buildutil.TagsFlagDoc)
}
```

Then run `mytool -h`.

### What did you expect to see?

The long flag usage line to be split in multiple lines somehow.

```
Usage of mytool:
  -tags build tags
        a list of build tags to consider satisfied during the build.
        For more information about build tags, see the description of
        build constraints in the documentation for the go/build package.
```

### What did you see instead?

```
Usage of mytool:
  -tags build tags
        a list of build tags to consider satisfied during the build. For more information about build tags, see the description of build constraints in the documentation for the go/build package
```

I initially thought that changing the string constant would be enough, for example by adding `"\n\t"` twice to split the one log line into three lines.

However, the `flag` package is not consistent about placing the usage line, so I am not sure if that is enough:

```
// Boolean flags of one ASCII letter are so common we
// treat them specially, putting their usage on the same line.
if len(s) <= 4 { // space, space, '-', 'x'.
        s += "\t"
} else {
        // Four spaces before the tab triggers good alignment
        // for both 4- and 8-space tab stops.
        s += "\n    \t"
}
```

So perhaps this should be a proposal to add special handling of long flag usage texts in the `flag` package, to wrap them around a certain around of columns. But I imagine that such a feature wouldn't be welcome, as the package is meant to be simple, and one has multiple workarounds available like using shorter texts, using a custom `Usage` func, or using a third-party flag package.

Still, it seems to me like this is a problem with either `buildutil` or `flag`.

/cc @alandonovan @shurcooL
Repository: rust
Issue: Panic related strings are still in binary with custom panic_fmt
Labels: A-LLVM,C-enhancement,T-compiler,WG-embedded,I-heavy

It seems that custom `panic_fmt` that doesn't touches `Arguments` doesnt not help to strip all panic-related strings from final binary while compiling to wasm (either emscripten or wasm32-unknown-unknown)

```rust
#![feature(lang_items)]
#![no_std]
#![no_main]

extern "C" {
    fn halt();
}

#[no_mangle]
#[lang = "panic_fmt"]
pub extern "C" fn panic_fmt(
    _args: ::core::fmt::Arguments,
    _file: &'static str,
    _line: u32,
    _col: u32,
) -> ! {
    loop { 
        unsafe { halt() }
    }
}

#[lang = "eh_personality"] extern fn eh_personality() {}

#[no_mangle]
pub fn call(descriptor: u8) -> u8 {
    assert!(descriptor > 0);
    descriptor
}
```

Invocation:
`rustc --target=wasm32-unknown-emscripten --emit llvm-ir -C lto -C opt-level=3 src/main.rs`

```
$ rustc --version
rustc 1.24.0-nightly (1956d5535 2017-12-03)
```

this produces the following [LLVM IR](https://gist.github.com/pepyakin/ccb14c80d91baf8ec2e09c94b253a30a).

The problem is that `panic_fmt` is not using it's `_args`, so it is a dead arg. However, despite this, strings for panic messages are still [end up in the LLVM IR](https://gist.github.com/pepyakin/ccb14c80d91baf8ec2e09c94b253a30a#file-main-ll-L9)}. 

It seems that running `opt -deadargelim -globaldce` helps to strip this strings.
Repository: angular
Issue: ICU messages don't work on attributes
Labels: feature,area: i18n,hotlist: error messages,freq2: medium,P4,feature: under consideration,area: docs

<!--
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 -->
[ ] Feature request
[x] 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
</code></pre>

## Current behavior
<!-- Describe how the issue manifests. -->
When I try to use ICU syntax in a translated attribute (like `placeholder`) I get an error:  
`Template parse errors:  
Unexpected translation for attribute "placeholder" (id="...`

## Expected behavior
<!-- Describe what the desired behavior would be. -->
Either **a)** nothing fails, everything works! or **b)** Fail more gracefully telling me this is not supported and make a note of this in the [documentation](https://angular.io/guide/i18n#nesting-plural-and-select-icu-expressions).

## 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://plnkr.co or similar (you can use this template as a starting point: http://plnkr.co/edit/tpl:AvJOMERrnz94ekVua0u5).
-->
https://stackblitz.com/edit/angular-xafhzk?file=app/autocomplete-overview-example.html
https://angular-xafhzk.stackblitz.io

```html
<input placeholder="{foo, select, bar{a} baz{b} other{c}}" i18n-placeholder>
```

## What is the motivation / use case for changing the behavior?
<!-- Describe the motivation or the concrete use case. -->
i'm forced to do this in different ways, like `goog.getMsg`. I'd like not to do this and have a consistent way of doing stuff.

## Environment

<pre><code>
Angular version: 5.2.1
<!-- Check whether this is still an issue in the most recent Angular version -->
</code></pre>
Repository: go
Issue: cmd/cgo: don't use syscall.Errno type as errno return on Windows
Labels: help wanted,OS-Windows,NeedsFix

Apologies in advance If I'm explaining anything poorly.

#### What did you do?
I made an Go binding library for a static C lib, then wrote a go application to use that.  During the course of developing that application, I managed to trigger the following error: 

`The process cannot access the file because another process has locked a portion of the file.`

I have a stripped down testable chunk of code (complete with a more in depth readme) here: https://github.com/technicalviking/cgotest

I'd like to stress:  I'm not looking to debug the code itself.  I know the outputs are not what I expected (casting the C **double variable back to [][]float64 in 'extractOutputs' shows a significant number of NaN entries, but meh), but rather why the functionality puts the code in a state where a windows error populates the error return value of the go reference to the C function in this case.

**EDIT TO INVESTIGATION**

On further digging I found that calling `sqrt` on a negative number, even in a function defined in the preamble, is sufficient to trigger this behavior.  The test code referenced in this issue has been updated accordingly.


#### What did you expect to see?

No errors

#### What did you see instead?

calling the c function using the mechanism 
`doResponse, doError = C.bridgeIndicatorFunction(...)` 
to leverage a C function pointer results in `doError` containing the following value: "The process cannot access the file because another process has locked a portion of the file."


#### System details

```
go version go1.9.2 windows/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=".exe"
GOHOSTARCH="amd64"
GOHOSTOS="windows"
GOOS="windows"
GOPATH="C:\Users\dmurker\Documents\Dev\DM\Go Projects"
GORACE=""
GOROOT="C:\Program Files Dev\Go"
GOTOOLDIR="C:\Program Files Dev\Go\pkg\tool\windows_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\D-DANI~1\AppData\Local\Temp\1\go-build223821631=/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"
GOROOT/bin/go version: go version go1.9.2 windows/amd64
GOROOT/bin/go tool compile -V: compile version go1.9.2
gdb --version: GNU gdb (GDB) 7.10.1
```
Repository: pytorch
Issue: Compilation issue: problem with GPU capability check
Labels: module: build,module: cuda,triaged

cudnn 7.0.3, cuda 8.0, gcc 5.4, ubuntu 16.04
The machine has three GPUs: two Pascal ones, and one simple old one.

When I don't set CUDA_VISIBLE_DEVICES prior to compilation, automatic GPU capability discovery picks on a wrong GPU and fails with `__shfl_xor` undefined.

The pytorch repo README doesn't mention the need to set CUDA_VISIBLE_DEVICES to a target GPU before compilation.

```
.../pytorch/aten/src/THC/generated/../THCDeviceUtils.cuh(61): error: identifier "__shfl_xor" is undefined
          detected during:
            instantiation of "T WARP_SHFL_XOR(T, int, int, unsigned int) [with T=float]"
.../pytorch/aten/src/THC/generated/../THCTensorMathReduce.cuh(445): here
            instantiation of "void THCTensor_kernel_varInnermostDim<Real,Accreal,flag,apply_sqrt>(Real *, Real *, unsigned int, unsigned int) [with Real=half, Accreal=float, flag=true, apply_sqrt=true]"
.../pytorch/aten/src/THC/generated/../THCTensorMathReduce.cuh(505): here
            instantiation of "void THCTensor_varInnermostDim<TensorTypeK,Real,Accreal,apply_sqrt>(THCState *, TensorTypeK *, TensorTypeK *, int) [with TensorTypeK=THCudaHalfTensor, Real=half, Accreal=float, apply_sqrt=true]"
...pytorch/aten/src/THC/generated/../generic/THCTensorMathReduce.cu(89): here

...pytorch/aten/src/THC/generated/../THCDeviceUtils.cuh(91): error: identifier "__shfl_down" is undefined
          detected during:
            instantiation of "T WARP_SHFL_DOWN(T, unsigned int, int, unsigned int) [with T=float]"
...pytorch/aten/src/THC/generated/../THCTensorMathReduce.cuh(471): here
            instantiation of "void THCTensor_kernel_varInnermostDim<Real,Accreal,flag,apply_sqrt>(Real *, Real *, unsigned int, unsigned int) [with Real=half, Accreal=float, flag=true, apply_sqrt=true]"
...pytorch/aten/src/THC/generated/../THCTensorMathReduce.cuh(505): here
            instantiation of "void THCTensor_varInnermostDim<TensorTypeK,Real,Accreal,apply_sqrt>(THCState *, TensorTypeK *, TensorTypeK *, int) [with TensorTypeK=THCudaHalfTensor, Real=half, Accreal=float, apply_sqrt=true]"
...pytorch/aten/src/THC/generated/../generic/THCTensorMathReduce.cu(89): here

2 errors detected in the compilation of "/tmp/tmpxft_00007616_00000000-9_THCTensorMathReduceHalf.compute_20.cpp1.ii".
CMake Error at ATen_generated_THCTensorMathReduceHalf.cu.o.cmake:267 (message):
  Error generating file
  .../pytorch/torch/lib/build/aten/src/ATen/CMakeFiles/ATen.dir/__/THC/generated/./ATen_generated_THCTensorMathReduceHalf.cu.o
```

cc @malfet @ngimel
Repository: godot
Issue: Unable to interact with titlebar or window chrome of editor
Labels: bug,platform:windows,topic:editor,topic:porting,confirmed

**Godot version:**
ff59c56 mono x64


**OS/device including version:**
Windows 10 x64


**Issue description:**
The titlebar and window chrome (including the close/minimize/maximize buttons and the edges of the window used to resize the window) are sometimes impossible to interact with. When this situation happens, the window cannot be moved via the titlebar, the titlebar buttons do not show hover effects and cannot be clicked, and the window cannot be resized.

Whenever Godot is exhibiting this behavior, opening up a different window and then going back to the editor seems to fix it temporarily. On the other hand, clicking anywhere in the editor causes this to happen once again.

**Steps to reproduce:**
The issue is intermittent, and I'm not actually sure what causes this. Once it starts happening, I can reproduce the effect 100% of the time (see above) as long as the editor isn't closed. Upon a fresh start of the editor, the issue disappears and I'm not sure what causes it to happen again.
Repository: TypeScript
Issue: 'utilities.ts' is an API surface hazard
Labels: Infrastructure

`utilities.ts` consists of 4 different namespaces:

* one which seems to be entirely internal
* one which is entirely exposed
* one which is entirely exposed *and* is entirely type predicate functions
* one which is a random assortment of internal and exposed functions that have no consistent usage

Just from my intuition and experience, I don't think this is a good idea. It's just too easy to put a new helper in some random section of the file and forget whether or not it's being exposed.

As a naive first approximation, here's what I think would be more appropriate for each respective namespace:

* `utilities.ts`
* `publicUtilities.ts`
* `publicPredicates.ts`
* I don't know, TBD.
Repository: opencv
Issue: Missing documentation for choosing inliers in LMeDS estimation
Labels: bug,category: documentation,category: calib3d

<!--
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)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => master


##### Detailed description

Both [cv::estimateAffine2D][1] and [cv::estimateAffinePartial2D][2]
support to refine the estimatied model using only inliers.

The same problem applies to [cv::findHomography][4].

However, it does not specify how the inliers are selected when
the model is estimated using the LMeDS algorithm.

The relevant code is [here][3]
```.cpp
double sigma = 2.5*1.4826*(1 + 5./(count - modelPoints))*std::sqrt(minMedian);
```
It is not documented at all why the threshold `sigma` is computed as above.

[4]: https://docs.opencv.org/master/d9/d0c/group__calib3d.html#ga4abc2ece9fab9398f2e560d53c8c9780
[3]: https://github.com/opencv/opencv/blob/master/modules/calib3d/src/ptsetreg.cpp#L360

[2]: https://docs.opencv.org/master/d9/d0c/group__calib3d.html#gad767faff73e9cbd8b9d92b955b50062d
[1]: https://docs.opencv.org/master/d9/d0c/group__calib3d.html#ga27865b1d26bac9ce91efaee83e94d4dd

<!-- your description -->


<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
Repository: opencv
Issue: Missing estimation method, maxIteration and refinement option in cv::estimateAffine3D
Labels: category: documentation,category: calib3d,RFC,future

<!--
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)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => master


##### Detailed description
Both [cv::estimateAffine3D][1] and [cv::estimateAffine2D][2] **SHOULD**
have similar signatures, however,

 - `cv::estimateAffine2D` returns the model as the return value
 - `cv::estimateAffine3D` returns the model as a parameter

 - `cv::estimateAffine2D` supports RANSAC and LMeDS
 - `cv::estimateAffine3D` supports only RANSAC

 - `cv::estimateAffine2D` supports to specify the maximum number of iterations
 - `cv::estimateAffine3D` dose not support maxIter

 - `cv::estimateAffine2D` supports to refine the estimated model
 - `cv::estimateAffine3D` does not support refinement

[2]: https://docs.opencv.org/master/d9/d0c/group__calib3d.html#ga27865b1d26bac9ce91efaee83e94d4dd
[1]: https://docs.opencv.org/master/d9/d0c/group__calib3d.html#ga396afb6411b30770e56ab69548724715



<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->