sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: Opencvjs solvepnp not working in Safari-12, but works in safari-13 and chrome browser
Labels: category: javascript (js)

Hello,

We followed opencvjs documents and compiled the JS file.

solvepnp function working fine in safari-13 and other browsers like chrome, but it is not working on safari-12.

```
let success = cv.solvePnP(
        modelPoints,
        imagePoints,
        cameraMatrix,
        distCoeffs,
        rvec,
        tvec
      );
      if (!success) {
        return;
      }
```

Please find the error screenshot captured in safari-12 browser.

![Screen Shot 2019-10-04 at 4 41 53 PM](https://user-images.githubusercontent.com/20619142/66240233-0f8a1280-e6ca-11e9-93ba-5d2ea8f6981d.jpeg)
Repository: flutter
Issue: Glitch with short paths with wide stroke.
Labels: engine,dependency: skia,customer: web10,customer: thrive,P2,team-engine,triaged-engine

This is an issue that came to our attention in a Flare bug report:
https://github.com/2d-inc/support/issues/244

The glitch occurs when a short path is stroked. This can occur when animating the trim of a path in Flare.

Here's a repo with more details and example code in pure Flutter which exhibits the issue:
https://github.com/luigi-rosso/flutter_trim_path_244/blob/master/README.md

Looks like it's related to how Skia extrudes the stroke of a path.
Repository: pytorch
Issue: Installer not setting rpath for MAGMA (OS X w/ GPU)
Labels: module: build,module: cuda,triaged,module: macos

## 🐛 Bug

The installation scripts aren't adding the magma path to the dylib. This is at least as far back as 1.1, and exists in the current master. 

It's easily fixable post-install with `install_name_tool -add_rpath /usr/local/magma/lib /path/to/libtorch.dylib` (actually in 1.1 its the `caffe_gpu` dylib), but of course this should be set properly by the installer.

## To Reproduce

Steps to reproduce the behavior:

1. Compile 1.1 or later on OS  X with GPU and MAGA support.
1. Launch python, `import torch`

```
Python 3.6.9 |Anaconda, Inc.| (default, Jul 30 2019, 13:42:17)
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Volumes/home500/anaconda/envs/pytorch1.2/lib/python3.6/site-packages/torch/__init__.py", line 81, in <module>
    from torch._C import *
ImportError: dlopen(/Volumes/home500/anaconda/envs/pytorch1.2/lib/python3.6/site-packages/torch/_C.cpython-36m-darwin.so, 9): Library not loaded: @rpath/libmagma.so
  Referenced from: /Volumes/home500/anaconda/envs/pytorch1.2/lib/python3.6/site-packages/torch/lib/libtorch.dylib
  Reason: image not found
```

## Expected behavior

Not throw an exception, and instead return silently and run properly.

## Environment

PyTorch version: 1.1.0
Is debug build: No
CUDA used to build PyTorch: 10.0

OS: Mac OSX 10.13.6
GCC version: Could not collect
CMake version: version 3.14.0

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: Could not collect
GPU models and configuration: GeForce GTX 1080 Ti
Nvidia driver version: 1.1.0
cuDNN version: Probably one of the following:
/usr/local/cuda/lib/libcudnn.7.dylib
/usr/local/cuda/lib/libcudnn_static.a

Versions of relevant libraries:
[pip3] numpy==1.16.4
[conda] blas                      1.0                         mkl
[conda] gpytorch                  0.3.5                    pypi_0    pypi
[conda] mkl                       2019.4                      233
[conda] mkl-include               2019.4                      233
[conda] mkl-service               2.3.0            py36hfbe908c_0
[conda] mkl_fft                   1.0.14           py36h5e564d8_0
[conda] mkl_random                1.1.0            py36ha771720_0
[conda] torch                     1.1.0                    pypi_0    pypi
[conda] torchfile                 0.1.0                    pypi_0    pypi
[conda] torchnet                  0.0.4                    pypi_0    pypi
[conda] torchtext                 0.4.0                    pypi_0    pypi
[conda] torchvision               0.4.0a0+d31eafa          pypi_0    pypi
Repository: terminal
Issue: Enable users to disable VT colors (for accessibility, visibility, contrast, etc.)
Labels: Issue-Feature,Area-Rendering,Area-VT,Area-Accessibility,Area-Settings,Product-Terminal

# Description of the new feature/enhancement
Users, esp those with accessibility needs, should be able to disable command-line apps from altering text and background colors, either via API calls, or via VT sequences.

Terminal should still honor users' color theme and default foreground and background color choices, allowing users to select high-contrast etc. themes / colors if they wish.

# Proposed technical implementation details (optional)
Suggest a setting called something like:

```
disableDynamicColors
disableAppColors
```

... or similar.
Repository: rust
Issue: Document the error cases for std::process::Command
Labels: C-enhancement,T-libs-api,A-docs,A-process

The current documentation of the [std::process::Command](https://doc.rust-lang.org/std/process/struct.Command.html#method.spawn)-struct lacks the description of possible error cases. All examples assume the working case, too.
There is currently no easy was to see, why a e.g. a call to `spawn()` could fail (before running).

I would recommend to add either a list of possible error cases (if this is similar on every platform) or add links to external documentation, if the different platforms have their own possible error codes. 

Unfortunately I cannot help here very much, as I'm not aware of the Process implementations on different platforms, e.g. Windows.
Repository: rust
Issue: link_section attribute misleadingly allowed on modules and impls 
Labels: A-linkage,A-attributes,T-compiler,C-bug

The `#[link_section]` attribute seems to be allowed on modules and impl blocks, but it will not do anything. I would expect either all functions/statics within the module/impl to be placed into the specified link_section, but this does not happen. 

Code used:

```
#[link_section = ".textaux1"]
mod foo{
    //#[link_section = ".textaux1"]
    pub fn testing() -> u32{
        20
    }
}
mod foo2{
    pub struct Whatever{}
    #[link_section = ".textaux1"]
    impl Whatever{
        //#[link_section = ".textaux1"]
        pub fn watt(&self) -> u32{
            50
        }
    }
}
```

I've verified the functions are linked in and not just optimized out etc. As-is the functions will be placed into the default `.text` section, but if I uncomment the link_section attributes then they are properly placed in the `.textaux1` section. No compiler errors or warnings are generated

rustc version:
rustc 1.40.0-nightly (2daa404e9 2019-10-02)
binary: rustc
commit-hash: 2daa404e9a151a2e8262cbd6d8c209fd067aca16
commit-date: 2019-10-02
host: x86_64-apple-darwin
release: 1.40.0-nightly
LLVM version: 9.0
Repository: pytorch
Issue: [dataloader] Sampler abstract constructor API minor proposal
Labels: module: dataloader,triaged

Currently the base abstract Sampler class [has](https://github.com/pytorch/pytorch/blob/master/torch/utils/data/sampler.py#L17):
```python
def __init__(self, data_source):
  pass
```

The `data_source` is declared as a common argument but not saved to `self.data_source`. Many samplers that do take `data_source` as argument indeed do that. And there exist samplers that do not even take `data_source` as argument. Two proposed suggestions: 1) add `self.data_source = data_source` to the abstract class; 2) remove `__init__` method from the base abstract class completely

cc @SsnL
Repository: opencv
Issue: Redesign of OpenCV's PnP algorithms
Labels: category: calib3d,RFC

The implementation of Perspective n Point (PnP) in OpenCV needs a significant improvement.
Object oriented design could help a lot to provide interfaces and implementations for:

- PnP Solvers: Algorithms that solve PnP without an initial estimate (also called closed-form solutions)
- PnP Refiners: Algorithms that take a solution from a PnP solver, and improve on the solution by minimizing a non-convex objective function, using e.g. Levenberg Marquardt

It will improve genericity, it will resolve confusion about solvePnP arguments (#12334) and "useExtrinsicGuess", and stop the need of C-style flags for selecting a solver & refiner combination. It will be much easier to include new solvers and refiners, to benchmark different combinations of solvers & refiners, and to unit test. 

Furthermore, it can help with a consistent description of algorithms. Different PnP solvers are able to work in some conditions and not others. For example, DLT requires 6 or more non-coplanar points, IPPE requires 4 or more co-planar points. For the same input, different algorithms may return different solutions and a different _number_ of solutions. For some algorithms, there may exist special cases which cause the algorithm to fail. For example, _all_ PnP algorithms will fail if the model points are co-linear (this is known as a **general degeneracy** in PnP).  Some PnP algorithms will fail if the model points are co-planar (e.g. DLT or OpenCV's EPnP implementation). Also, there may exist special corner cases that cause an algorithm to fail that are either not known or not well documented. For example, OpenCV implementation of Zhang's method (for solving PnP with co-planar points) fails if the model points are 4 corners of a square. This is called an **artificial degeneracy** (i.e. when the problem can be solved, but the algorithm fails as a result of its design.) None of this is documented in OpenCV, and it is the cause of a lot of confusion and inexplicable results. There are also no test cases to document and verify failure cases of algorithms. 

Note: issue and discussion about algorithm-based design and PnP with python bindings is #14181
Repository: youtube-dl
Issue: Support for socks5h:// proxies
Labels: request

## Checklist

- [x] I'm reporting a feature request
- [x] I've verified that I'm running youtube-dl version **2019.09.28**
- [x] I've searched the bugtracker for similar feature requests including closed ones


## Description

The difference between SOCKS5 and SOCKS5H is that SOCKS5H resolves DNS requests through the proxy and SOCKS5 resolves them locally. The DNS leak has technically been addressed in #9677 and it appears to been removed based on tests I carried out sniffing for DNS packets while running youtube-dl with `--proxy socks5://` ([this is the relevant line, I think](../blob/master/youtube_dl/socks.py#L219)).

So `youtube-dl --proxy socks5://` behaves how `youtube-dl --proxy socks5h://` should behave, and the latter misbehaves:

```
youtube-dl --proxy socks5h://127.0.0.1:9050 https://www.youtube.com/watch?v=BaW_jenozKc
[youtube] BaW_jenozKc: Downloading webpage
ERROR: Unable to download webpage: <urlopen error Tunnel connection failed: 501 Tor is not an HTTP Proxy> (caused by URLError(error('Tunnel connection failed: 501 Tor is not an HTTP Proxy',),))
```

I suggest that youtube-dl should accept the `socks5h` protocol and use for it the implementation of SOCKS5 that already exists (where DNS is resolved by the SOCKS server).

And maybe `socks5`'s implementation should be changed to resolve DNS locally to honour the specification. The only issue I can see with fixing the names of the protocols is any scripts with `socks5://` in them will start leaking DNS requests.
Repository: terminal
Issue: More Unicode-savvy wordDelimiters
Labels: Help Wanted,Area-Settings,Product-Terminal,Issue-Task,Priority-3

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement

"wordDelimiter" lists a couple of stop characters, such as ASCII quotation mark `"`, apostrophe `'`, hyphen/minus `-` and such.

However, special Unicode quotation marks like `“`, `”`, apostrophes like `’` dashes `–`, `—`, box drawing characters, non-breaking spaces and so on an so forth remain word characters (selected on a double click) which is most likely not the best behavior, and adding such characters one by one to the set as the user encounters them is cumbersome.

# Proposed technical implementation details

I think the default behavior should be based on [Unicode character categories](https://en.wikipedia.org/wiki/Unicode_character_property#General_Category). On top of this there could be a way to add/remove certain characters to/from the set as exceptions. (Maybe even a way to add/remove entire character categories at once, although that might be an overkill.)
Repository: terminal
Issue: Per-profile wordCharacters
Labels: Help Wanted,Area-Settings,Product-Terminal,Issue-Task

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement

"wordDelimiters" is a global config option rather than a per-profile one, although there's nothing in this option that inherently has to make it a global one.

In gnome-terminal we had quite a lot of debates around which character should be included and which not. The biggest debate was around `:`. Folks working with URLs or timestamps want colons to be word characters. Folks working with e.g. `grep` or compiler outputs (such as `filename:matching_content` or `filename:line_number` want the colon to be a stop character.

I can easily imagine that some users would prefer to have different profiles with different double click behaviors, depending on the kind of task they're working on.

Could you guys consider moving it to a per-profile option? Although then it's a bit of maintenance burden when someone wants to update the set and has to do for all the profiles. Feel free to close this bug if it was a deliberate choice from you to make it global.

(On a side note, the same question could also be asked for "copyOnSelect" I guess...?? I'm not sure about that, my gut feelings tell me it's better to have an overall consistent experience here, just as you don't want to have different "keybindings" per profile, but again, these are just feelings.)
Repository: terminal
Issue: DEC private 47/1047 not supported (alt buffer)
Labels: Product-Conhost,Help Wanted,Area-VT,Issue-Task

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

<!--
This bug tracker is monitored by Windows Terminal development team and other technical folks.

**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.

If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible.

-->

# Environment

```none
Windows build number: Win32NT 10.0.18362.0
Windows Terminal version (if applicable): 0.5.2762.0
```

# Steps to reproduce

    printf '\e[?47h'

or the same with `1047`, and `l`.

# Expected behavior

DEC private mode controls 47 and 1047 should switch to/from the alternate screen, just as 1049 already does in WT. Except that these shouldn't save and restore the cursor and clear the alternate screen.

Current terminfo uses 1049 for TERM=xterm-256color and friends, but older systems or apps not relying on terminfo might still emit the older 47 or 1047.

(While at it, please check 1048 too, I haven't checked that one.)

# Actual behavior

Nothing happens on these.
Repository: go
Issue: x/mobile: Remove gomobile dependency on gobind binary
Labels: NeedsDecision,mobile

Currently `gomobile bind` internally depends on gobind command. This is not user friendly and seems unnecessary too complex as user need to build both binaries. I propose to remove cmd/gobind so there is only one binary. As there is difference what `gomobile bind` and `gobind` does we can pass extra flag to `gomobile bind -gen_only` to only generate bindings without compiling to final project.

If cmd/gobind is still needed (not sure why) we can extra all reusable logic to separate package so it can be used directly in both cmd/gomobile and cmd/gobind.

If this make sense I can work on it.

/cc @hajimehoshi @eliasnaur
Repository: go
Issue: cmd/go: handle ldflag escapes in pkg-config output
Labels: NeedsInvestigation

<!-- 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.9 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=""
GOCACHE="/home/raphi/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/raphi/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/golang"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/raphi/code/go/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-build148444745=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

### What did you do?
Attempt to build a cgo binary with `pkg-config` containing ldflags with a whitespace.

### What did you expect to see?
A successfull build.

### What did you see instead?
`go build github.com/ElektraInitiative/go-elektra/kdb: invalid flag in pkg-config --libs: elektra/build/lib`

PR: https://github.com/golang/go/pull/34709

Relates to
* https://github.com/golang/go/issues/16455 
* https://github.com/golang/go/issues/7906
Repository: TypeScript
Issue: `getSignaturesOfType` throws `Cannot read property 'flags' of undefined`
Labels: Bug,Crash,Fix Available,Rescheduled

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.7.0-dev.20191005

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** conditional, infer, mapped

**Code**

```ts
declare interface Foo {
    a(): boolean;
    b(): void;
    c(argument: boolean): void;
    d(argument: number): void;
}

declare const Foo: Mapped<Foo>;
type Mapped<T> = {
  [K in keyof T]: T[K] extends (...args: infer Args) => infer R
    ? (...args: Args) => R
    : never;
};

function foo(key: 'a' | 'b' | 'c' | 'd') {
  Foo[key]();
}
```

Note: removing any infer declaration or method from `Foo` makes it valid.


**Expected behavior:**

No errors

**Actual behavior:**

```
TypeError: Cannot read property 'flags' of undefined
    at Object.getCheckFlags (typescript/lib/tsc.js:10461:23)
    at getTypeOfSymbol (typescript/lib/tsc.js:32706:20)
    at getParameterCount (typescript/lib/tsc.js:46831:32)
    at combineUnionParameters (typescript/lib/tsc.js:33697:29)
    at combineSignaturesOfUnionMembers (typescript/lib/tsc.js:33730:26)
    at typescript/lib/tsc.js:33673:181
    at Object.map (typescript/lib/tsc.js:446:29)
    at _loop_7 (typescript/lib/tsc.js:33673:144)
    at getUnionSignatures (typescript/lib/tsc.js:33681:35)
    at resolveUnionTypeMembers (typescript/lib/tsc.js:33754:34)
    at resolveStructuredTypeMembers (typescript/lib/tsc.js:34078:21)
    at getSignaturesOfStructuredType (typescript/lib/tsc.js:34573:32)
    at getSignaturesOfType (typescript/lib/tsc.js:34579:20)
```

**Playground Link:** https://www.typescriptlang.org/play/?ts=3.7-Beta&ssl=1&ssc=1&pln=18&pc=2#code/CYUwxgNghgTiAEBLAdgFxDAZlMCBiA9gfAN4CwAUPNfFABQCUAXPAEZEQhTIDclNbRiwBuBRMD5UaYOrADmAVwC2INC3YFO3ZvFHjJA4LJiKVa+MmWsMOvRMoBfSpVCRYCMAWQBnVPEIELACyUAAOoSDAADwBAHySqACeEfAh4ZFRACqx8AC8pPzwANoA0kjI8ADWIIkEmPCZALosmaWN8CAAHujIwN7wdAB0w-LeLCiYGPAAgibeDHk5E1MASoXUAPwDw4OjLLNy84vwa1LULMggwhiSDpKUmArIYKiIXvCYRHTViSwA5FA-vAAD7wP6sIGgv5gSFg4B-BbkKQBIo-RqMW5AA

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: rust
Issue: Tracking issue for `Cow::is_borrowed` and `Cow::is_owned`
Labels: T-libs-api,B-unstable,C-tracking-issue,Libs-Tracked

I just tried to use these in my own code and was kind of shocked they didn't exist.

Justification: this seems like a common Rust pattern. We have `is_some` and `is_none` for `Option`, `is_ok` and `is_err` for `Result`, etc., so, it seems pretty fair to have `is_borrowed` and `is_owned` for `Cow`.

Having `as_borrowed` and `as_owned` wouldn't really make much sense, as a simple `&` and `&mut/to_mut` cover those use cases. But, these check functions are pretty useful on their own.