sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: WARNING:root:This caffe2 python run does not have GPU support. Will run in CPU only mode. WARNING:root:Debug message: libcurand.so.9.0: cannot open shared object file: No such file or directory Segmentation fault (core dumped)
Labels: caffe2

HI,
I have GPU and CUDA, CuDNN, and NCCL. My OS is Ubuntu 16.04, I followed this tutorial to install Coffe2 with GPU support (
conda install -c caffe2 caffe2-cuda9.0-cudnn7
) and the installation finished successfully but this command: python2 -c 'from caffe2.python import workspace; print(workspace.NumCudaDevices())'

returns: WARNING:root:This caffe2 python run does not have GPU support. Will run in CPU only mode.
WARNING:root:Debug message: libcurand.so.9.0: cannot open shared object file: No such file or directory
Segmentation fault (core dumped)
Any Idea how can I solve it??
TNX

$nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2018 NVIDIA Corporation
Built on Tue_Jun_12_23:07:04_CDT_2018
Cuda compilation tools, release 9.2, V9.2.148

$ conda -V
conda 4.5.8

 nvidia-smi
Tue Jul 17 01:58:01 2018       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.130                Driver Version: 384.130                   |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Quadro M520         Off  | 00000000:02:00.0 Off |                  N/A |
| N/A   41C    P0    N/A /  N/A |    298MiB /  2002MiB |      2%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0     21578      G   /usr/lib/xorg/Xorg                           234MiB |
|    0     22157      G   compiz                                        62MiB |
+-----------------------------------------------------------------------------+
Repository: rust
Issue: Blanket impl of `Into::into` for `From` should be default
Labels: C-enhancement,T-libs-api,A-specialization

Because of the blanket impl of `Into` for `From`, in which `Into::into` is not `default`, one cannot override the default implementation of `Into::into` using `specialization`.
Repository: TypeScript
Issue: Allow inferring rest element types in conditional types involving tuples
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms
rest element infer tuple

## Suggestion
Currently, inferring single elements of tuple types is possible using the `infer` keyword:
```ts
type FirstArg<T extends any[]> = 
	T extends [infer R, ...any[]] ? R : 
	T extends [] ? undefined : 
	never;
type T1 = FirstArg<[number, 2, 3]>; // number
type T2 = FirstArg<[1, 2, 3]>; // 1
type T3 = FirstArg<["", 2]>; // ""
type T4 = FirstArg<[]>; // undefined
```

However it is not possible to infer the type of the remaining arguments in one go, except by resorting to functions:
```ts
type RestArgs<T extends any[]> = 
	T extends [any, infer R[]] ? R : // this does not work - no way to specify that R should be an array!
	T extends [any] ? []] : 
	never;

// this does
type RestArgs<T extends any[]> =
	((...args: T) => void) extends ((first: any, ...rest: infer S1) => void) ? S1
	: T extends [infer S2] ? []
	: T extends [] ? []
	: never;
type T1 = RestArgs<[1,2,3]>; // [2, 3]
type T2 = RestArgs<[1,2]>; // [2]
type T3 = RestArgs<[1]>; // []
type T4 = RestArgs<[]>; // []
```
I would like to see the possibility to infer rest types in tuples, e.g. like this (square brackets):
```ts
type RestArgs<T extends any[]> = T extends [any, infer R[]] ? R : never;
```
or like this (3 dots)
```ts
type RestArgs<T extends any[]> = T extends [any, infer ...R] ? R : never;
```

## Checklist

My suggestion meets these guidelines:
* [x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. new expression-level syntax)
Repository: TypeScript
Issue: Allow more constructs to work as type guards for `unknown`
Labels: Suggestion,Awaiting More Feedback

## Search Terms
unknown type guard
Related: https://github.com/Microsoft/TypeScript/pull/24439#issuecomment-394185089, https://github.com/Microsoft/TypeScript/issues/25172

## Suggestion
Currently, only a very limited set of type guards are able to narrow the new `unknown` type:
* Array.isArray (because it is a typeguard for `arg is any[]`) and probably some more in the lib files
* instanceof
* self-written typeguards

However to make working with unknown types less awkward, I'd like to see a couple of other constructs being able to narrow the `unknown` type:
```ts
let x: unknown;
// Direct equality should narrow to the type we compare to
x === "1"; // should narrow x to string or the literal "1" type, similar for other types aswell

// All these should narrow x to {prop: any}
"prop" in x;
x.prop != null;
x.prop !== undefined;
typeof x.prop !== "undefined";

// typeof should work on properties of the unknown variable
typeof x.prop === "string"; // should narrow x to {prop: string}
```

## Use Cases
Make `unknown` easier to work with!

```ts
// before, very verbose!
const x: unknown = undefined!;

function hasProp1(x: any): x is {prop1: any} {
	return "prop1" in x;
}
function hasProp2(x: any): x is {prop2: any} {
	return "prop2" in x;
}
// imagine doing this for many more properties

if (hasProp1(x)) {
	x.prop1;
	if (hasProp2(x)) {
		x.prop2;
	}
}

// ===========

// after, much more concise and less overhead
const x: unknown = undefined!;
if ("prop1" in x) {
	x.prop1;
	if ("prop2" in x) {
		x.prop2;
	}
}
```

## Checklist

My suggestion meets these guidelines:
* [x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. new expression-level syntax)
Repository: deno
Issue: Capability-based security model
Labels: permissions,suggestion

I don't know if anyone here has considered using a capability-based security model in Deno but when I read this paragraph in the Readme I thought that such a model would be perfect for this sort of thing:

> File system and network access can be controlled in order to run sandboxed code. Defaults to read-only file system access and no network access. Access between V8 (unprivileged) and Golang (privileged) is only done via serialized messages defined in this protobuf.

It is already based on message passing and a possibility to drop privileges may be needed in the future (e.g. a program runs with network access and wants to run a module but without giving it network access).

There have been some interesting operating systems based on capabilities (search for GNOSIS, KeyKOS, EROS, CapROS and Coyotos for good info) where some complexities were needed to model entire file system and user privileges with capabilities, which didn't map well to the traditional Unix permission model.

But here as I understand all we need is to make sure which privileged code an unprivileged code can run, and then let the OS do the rest of permission checking so most of the complexities that are inherent to designing a security model for an operating system are not relevant here.

We can start a program with certain capabilites (like the read-only file system access by default, plus some additional ones turned on by the command-line switches if needed) and those capabilities could be passed (or not passed, which is really most important here) to certain modules used by the main program. Those modules running as unprivileged code (V8) would pass the capabilities along the serialized messages to the privileged code (previously Golang, now Rust) and the privileged code would either allow or reject such a request to a system call or other funcionality that requires a certain set of capabilities.

Since Deno is already using message passing between unprivileged and privileged code, and since the idea to disallow certain permissions from the running code seems to be widely supported, then maybe a capability-based security model would work well here.

Some resources:

- Wikipedia: 
  - https://en.wikipedia.org/wiki/Capability-based_security
  - https://en.wikipedia.org/wiki/Object-capability_model
- Articles on Capability Theory by Norman Hardy: 
  - http://www.cap-lore.com/CapTheory/
- Capsicum: practical capabilities for UNIX: 
  - https://www.usenix.org/legacy/event/sec10/tech/full_papers/Watson.pdf
- The KeyKOS Architecture:
  - http://webarchive.loc.gov/all/20011116155616/http://www.cis.upenn.edu/~keykos/osrpaper.html
Repository: go
Issue: cmd/go: add 'go release'
Labels: NeedsInvestigation,modules

Collecting things we would want a 'go release' command to do:

 - API-level compatibility checks
 - warning about dependence on prerelease or pseudo-versions.
 - checking that root/go.mod and root/v2/go.mod don't both say module foo/v2.
Repository: flutter
Issue: MediaQuery.viewInsets.bottom changes instantly when keyboard opens
Labels: c: new feature,framework,a: animation,f: material design,a: fidelity,P2,team-design,triaged-design

## Steps to Reproduce

```dart
import 'package:flutter/material.dart';

void main() => runApp(MaterialApp(
  home: MyApp(),
));

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Column(
        children: <Widget>[
          Expanded(child: Container(color: Colors.yellow.withOpacity(0.5),),),
          Container(
            color: Colors.grey,
            child: Padding(
              padding: const EdgeInsets.symmetric(vertical: 12.0),
              child: TextField(
                decoration: InputDecoration.collapsed(hintText: ''),
              ),
            ),
          ),
        ],
      ),
    );
  }
}
```

1. Start this simple app on an ios device 
2. Click at the text field at the bottom
3. See the snap of the text field

## Description

The text fields goes to its final position instantly because the MediaQuery.viewInsets.bottom changes instantly to X when the keyboard opens. Would be nice if the MediaQuery.viewInsets.bottom would animate at the speed of the keyboard. The snap of the text field makes the ui very unnatural. 
A example of a production app (is a flutter app): https://drive.google.com/file/d/1CA8VXp14-_JihOT-xwafg16ahHQRbSZb/view?usp=sharing
Repository: TypeScript
Issue: `@callback` is only generic after `@template` tag
Labels: Bug,Domain: JSDoc,checkJs,Domain: JavaScript

**TypeScript Version:**  master

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

Our declaration:
```ts
export interface JSDocSignature extends JSDocType, Declaration {
    kind: SyntaxKind.JSDocSignature;
    typeParameters?: ReadonlyArray<JSDocTemplateTag>;
    ...
}
```

Attempt to use:
```js
/**
 * @callback Cb
 * @template T
 * @param {T} p
 * @return {T}
 */

/** @type {Cb} */
const x = p => p;
```

**Expected behavior:**

`typeParameters` is set somewhere, and `type Cb = <T>(p: T) => T` (or `type Cb<T> = (p: T) => T`)

**Actual behavior:**

1. `typeParameters` is not set.
2. `Cb` says that it requires a generic argument, but when provided, there's an error on `x`: 'any => any' isn't assignable to 'Cb<number>'.
3. Requesting quickinfo on `Cb/**/<number>` causes an infinite recursion in `getTypePredicateOfSignature`.
Repository: vue
Issue: Possible memory leak when v-for in development mode
Labels: improvement

### Version
2.5.16

### Reproduction link
[https://codepen.io/anon/pen/KBMaOY](https://codepen.io/anon/pen/KBMaOY)

### Steps to reproduce
- Open the codepen https://codepen.io/anon/pen/gjMgzG
- Click a couple of times to list 0 item, then 1000
- See the memory increasing
- Try force GC (trash icon) before measure it
- Take heap snapshots in Chrome "Memory" tab
- Watch the memory usage in the Chome task manager (shift   esc)
- Watch the memory usage in OS task manager

### What is expected?
Same memory usage after garbage collector

### What is actually happening?
Despite the "Performance" tab displays the same memory usage, the "Memory" heap snapshot displays a memory increase.
Also, the both Chrome and OS task managers show the memory only increasing.

---
It get worse when:
- Using Vuei18n (even without translating)
- Having big children components

Tested on:
- Windows 7 64 Bits
- Chrome 67.0.3396.99 64 bits

Please, consider that:
- I may be doing something wrong
- It can be a Chrome issue
- It can be an OS issue

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: TypeScript
Issue: Unreachable code defaults
Labels: Docs

Apparently, since 2.9.1, unreachable code is allowed by default, you have to explicitly set `allowUnreachableCode` to `false` in `tsconfig.json` to get the old behavior.

This doesn't match what's described [in the docs](https://www.typescriptlang.org/docs/handbook/compiler-options.html).

![image](https://user-images.githubusercontent.com/3883992/42838636-538d9dde-89cf-11e8-9df0-e077da8d5927.png)

Quick repro :
package.json 
```json
{
  "name": "tmp",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "typescript": "2.9.1"
  }
}
```

tsconfig.json (default from tsc --init)
```
{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true
  }
}
```

index.ts
```
export const a = (): boolean => {
    return true;
    return false;
};
```


`yarn tsc` outputs no warning as of 2.9.1
Repository: go
Issue: proposal: os/exec/v2: follow Context guidelines
Labels: v2,Proposal

# Proposal: Make `exec` follow guidelines for using `Context` objects

Author(s): Casey Barker

Last updated: 2018-07-17

## Abstract

This proposal is to add `cmd.StartCtx()` and `cmd.RunCtx()` methods to the `exec` package, eventually deprecating `exec.CommandContext()`, and bringing it into compliance with the guidelines for use of `Context` objects.

## Background

The documentation for the `context` package says:
> Do not store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it. The Context should be the first parameter, typically named ctx.

The `exec.CommandContext()` function breaks this rule; it stores the `ctx` parameter inside the `Cmd` object until later referenced by the `cmd.Start()` method (which is also called by `cmd.Run()`). A caller of `cmd.Start()` or `cmd.Run()` has no control over which context gets used in the execution.

Issue originally raised here:
https://groups.google.com/forum/#!topic/golang-nuts/uvJIogNTD2c

Looking at the development history for the `exec` package's use of `context,` I suspect this inconsistency arose accidentally, as the `Cmd.ctx` field was used differently early in development.

## Proposal

1) Add the following two new methods to the `exec` package:
```func (c *Cmd) StartCtx(ctx context.Context) error```
```func (c *Cmd) RunCtx(ctx context.Context) error```

These two methods honor the passed-in context, rather than any context that might be attached to the `Cmd`.

2) Deprecate the following function in the `exec` package:
```func CommandContext(ctx context.Context, name string, arg ...string) *Cmd```

Once the deprecation is complete, the private `ctx` field could be removed from the `Cmd` object.

## Rationale

The recommendations provided by the `context` package are solid; the context object should be passed at the time and place where a long-running operation is started. This makes it clear which calls are long-running, and it allows the source object (in this case, the `Cmd`) to be created without needing to know about the `ctx` that might eventually be used to control the execution.

## Compatibility

Part 1 (adding two new methods) does not break compatibility, although it introduces some possible confusion in that the new methods would ignore the context provided if `exec.CommandContext()` were initially used to create the `Cmd` object.

Part 2 (deprecating the `exec.CommandContext()` function) is a hard break in compatibility.

## Implementation

TBD. This is my first proposal and I'm not yet familiar with the Go release process, but I'm willing to provide a patch if this proposal is acceptable.
Repository: vscode
Issue: Improve readability of diagnotic hovers
Labels: feature-request,languages-diagnostics

The number one annoyance I have and hear from people about VS Code + TypeScript is that type errors are hard to read. TypeScript will display nested type errors with each level indented, but because of the line wrapping, that indentation basically lost.
This makes the error hard to follow and in consequence hard to solve.

![image](https://user-images.githubusercontent.com/10532611/42839855-dbc732a2-89b9-11e8-841d-f0b66f3a62fb.png)

Here are things that I think would improve the readability:
- Add an option to enable horizontal scrolling in hovers. This would mean the indentation would actually have the intended visual effect.
- Make the width of the hover configurable. I have way more space on my screen it could utilize.
- Add smart wrapping that preserves indentation.
- Add markdown support to diagnostics and make TypeScript output markdown. This would mean not the whole diagnostic has to be rendered in a monospace font, therefor saving horizontal space. The parts that are code would use backticks instead of single quotes.
Repository: kubernetes
Issue: TokenReview audience support for nodes
Labels: sig/node,kind/feature,sig/auth,priority/important-longterm,lifecycle/frozen

Once https://github.com/kubernetes/kubernetes/pull/62692 merges, we should add support for audiences to the Kubelet's token review.

This is important as part of the node isolation efforts, as the node could otherwise use tokens sent with requests to the nodes endpoints (e.g. stats requests) to send requests to other nodes.

I think the node should accept 3 types of audiences:

- legacy (no audience) - required for backwards compatibility
- `system:nodes` - token used for all nodes
- `system:node:<nodeName>` - per-node token, preferred

/kind feature
/sig auth
/sig node
/priority important-longterm
Repository: flutter
Issue: Feature Request for `SliverBottomAppBar`
Labels: c: new feature,framework,f: material design,f: scrolling,customer: crowd,P3,team-design,triaged-design

**Problem:**
When using SlideTransition to slide off BottomAppBar on SliverList scroll which is inside NestedScrollView with SliverAppBar, animation works, but SliverList does not occupy remaining space where BottomAppBar once was.

**Intended behaviour:**
https://material.io/design/components/app-bars-bottom.html#behavior ("Scrolling" paragraph) 

**Examples:**
How it looks when SlideTransition finishes and BottomAppBar is no longer visible:
![screenshot_20180717-143740](https://user-images.githubusercontent.com/11775678/42862423-17f71ea0-8a68-11e8-8601-df8e32c4f833.jpg)

**"Hack":**
To archive intended effect I use SizeTransition instead of SlideTransition with _axis: Axis.vertical_ and _axisAlignment: -1.0_ , but that for some reason removes BottomAppBar elevation and FAB moves down when BottomAppBar changes size.

**Feature request:**
There could be a SliverBottomAppBar Widget with _floating/snap/pinned_ properties and it could react to scrolling of CustomScrollView same as SliverAppBar does.
Repository: opencv
Issue: Lower FPS with the newest OpenCV version(3.4) than 3.3/3.2
Labels: category: videoio(camera),incomplete

<!--
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 =>
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV =>  3.4 and 3.3 and 3.2
- Operating System / Platform => Linux Ubuntu 16.04
- Compiler => g++

##### Detailed description
Hey guys, I'm faced with an interesting problem: I got a lower FPS of UVC camera using the newest version 3.4 than the older version 3.3/3.2.

<!-- your description -->

##### Steps to reproduce

Here is the result of my test:
I test the same code on the same machine. 
In a WHILE loop my program did nothing but read one image from the usb camera and display it every time. 
1. When I used the version 3.4, each frame cost 30ms.
2. And in the same condition except for the version of OpenCV(I used 3.3 and 3.2 for test), each frame cost 10ms.

It surprised my a lot...and I'm very confused about it.
Repository: vscode
Issue: Enhancement: finer control of word separators
Labels: feature-request,languages-basic,editor-core

<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

Currently, the setting term `"editor.wordSeparators"` only tells the editor to separate words *at* these characters. Can we make it *before* or *after* the separators?

Now I take LaTeX as an example. If we remove `\` from "editor.wordSeparators", then double click on `\cmdA\cmdB\cmdC`, we will select the whole expression. However, as the expression is actually three commands, we should select a single (e.g. `\cmdA`) one at a time. That means, we should only separate words *before* `\`, not after.
Repository: opencv
Issue: setting parameters of openCV tracking API in python
Labels: feature,category: python bindings,category: contrib

I'm trying to use openCV tracking API in Python for object tracking. I tried the code in this [link](https://www.learnopencv.com/object-tracking-using-opencv-cpp-python/) and don't have any problem running the code. But, looking at the openCV documentation [here](http://docs.opencv.org/trunk/d9/df8/group__tracking.html), I realized there are parameters for each of the tracking algorithms. I could not find a way how I can set these parameters in python. Note, this question was asked on [StackOverflow](https://stackoverflow.com/questions/45677651)
Repository: go
Issue: testing: parallel test output reported in non-deterministic order
Labels: NeedsInvestigation

I have a test with parallel subtests. A few are failing. Every time I run the test, the failures come out in a different order, presumably depending on which ones finish first. This makes it hard to see at a glance what is different each time I make a tweak and re-run the tests.

Given that we're saving up the output to print at the end of the test anyway, we should also arrange to order the test results - at least all the parallel ones - in the order they started, not the order they finished.

/cc @mpvl