sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: [Caffe2] Fail to build after upgrading to cuda 9.2
Labels: caffe2

## Issue description
I am baffled by this actually (probably because I don't understand cmake very well). After I upgraded to cuda-9.2, wiped out the whole build directory, and reran the build flow, Caffe2 cannot be run: 

`WARNING:root:Debug message: libcurand.so.9.1: cannot open shared object file: No such file or directory`

While 'ldd libcaffe2_gpu.so' gives: 
`	libcurand.so.9.2 => /usr/local/cuda-9.2/targets/x86_64-linux/lib/libcurand.so.9.2 (0x00007f7b4965c000)`
## Code example


## System Info
- PyTorch or Caffe2: Caffe2
- How you installed PyTorch (conda, pip, source): Source build
- Build command you used (if compiling from source): `mkdir build && cd mkdir && cmake $(python3 ../scripts/get_python_cmake_flags.py) -DUSE_NATIVE_ARCH=ON  -DUSE_CUDA=ON .. && make && sudo make install`
- OS: Ubuntu 1604
- PyTorch version:
- Python version: 3.5.2
- CUDA/cuDNN version: 9.2
- GPU models and configuration: GTX 1070
- GCC version (if compiling from source): gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
- CMake version: 3.5.1
- Versions of any other relevant libraries:
Repository: TypeScript
Issue: Assume arity of tuples when declared as literal
Labels: Suggestion,Revisit

## Search Terms

tuples, length, arity

## Suggestion
Now that #17765 is out I'm curious about if we could change the arity of tuples declared as literals. This was proposed as part of #16896 but I thought it might be better to pull this part out to have a discussion about this part of that proposal.

With fixed length tuples TypeScript allows you to convert `[number, number]` to `number[]` but not the other way around (which is great).

```ts
const foo = [1, 2];
const bar = [1, 2] as [number, number];

const foo2: [number, number] = foo;
const bar2: number[] = bar;
```

If you declare a constant such as `foo` above it would be nice if it would be nice if it would have the length as part of its type, that is, if `foo` was assumed to be of type `[number, number]` not `number[]`.

This would have potential issues with mutable arrays allowing you to call `push` and `pop` although this isn't different to present and was discussed a bit in #6229.

```ts
const foo = [1, 2] as [number, number]; // After this proposal TypeScript would infer the type as `[number, number]` not `number[]`.
foo.push(3); // foo is of type `[number, number]` even though it now has 3 elements.
foo.splice(2); // And now it has 2 elements again.
```

## Use Cases

When using a function such as `fromPairs` from lodash it requires that the type is a list of tuples. A simplified version is
```ts
function fromPairs<T>(values: [PropertyKey, T][]): { [key: string]: T } {
  return values.reduce((acc, [key, value]) => ({ ...acc, [key]: value }), {});
}
```

If I do
```ts
const foo = fromPairs(Object.entries({ a: 1, b: 2 }));
```
it works because the type passed into `fromPairs` is `[string, number][]`, but if I try to say map the values to double their value I get a compile error:

```ts
const bar = fromPairs(Object.entries({ a: 1, b: 2 }).map(([key, value]) => [key, value * 2]));
```
as the parameter is of type `(string | number)[][]`

This can be fixed by going
```ts
const bar = fromPairs(Object.entries({ a: 1, b: 2 }).map(([key, value]) => [key, value * 2] as [string, number]));
```
but this is cumbersome.

## Checklist

My suggestion meets these guidelines:
* [ ] 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: pytorch
Issue: detectron net create error
Labels: caffe2

I changed detectron pkl model to caffe2 pb model,
errors happened when called
CAFFE_ENFORCE(workspace.CreateNet(model.predict.net));


terminate called after throwing an instance of 'caffe2::EnforceNotMet'
what(): [enforce fail at operator.cc:185] op. Cannot create operator of type 'GenerateProposals' on the device 'CUDA'. Verify that implementation for the corresponding device exist. It might also happen if the binary is not linked with the operator implementation code. If Python frontend is used it might happen if dyndep.InitOpsLibrary call is missing. Operator def: input: "rpn_cls_probs_fpn2_cpu" input: "rpn_bbox_pred_fpn2_cpu" input: "im_info" input: "anchor2_cpu" output: "rpn_rois_fpn2" output: "rpn_roi_probs_fpn2" name: "" type: "GenerateProposals" arg { name: "nms_thres" f: 0.7 } arg { name: "min_size" f: 0 } arg { name: "spatial_scale" f: 0.25 } arg { name: "correct_transform_coords" i: 1 } arg { name: "post_nms_topN" i: 1000 } arg { name: "pre_nms_topN" i: 1000 } device_option { device_type: 1 }
Repository: vue
Issue: 👋 Vue reactivity engine and MobX 🖖
Labels: discussion

Hey,

Vue is cool, over at React land MobX ( https://github.com/mobxjs/mobx/ ) takes a similar approach by defining getters/setters. 

The architectural nature of Vue apps is much closer to React+MobX than the typical React architecture and MobX is used and trusted by some [big companies](https://github.com/mobxjs/mobx/issues/681)

I am not aware of any knowledge sharing or idea sharing between the projects. I think it would be really cool if we explore possibilities to collaborate.

Some areas of collaboration which could be cool:
 - Standardized benchmarks.
 - Optimization tips and what things that worked out and didn't.
 - Good user experience for things like circular references.
 - What code can be shared between libraries or extracted.
 - Discuss the transition to from getters/setters to proxies.
 - Discuss what's hard from the language PoV to provide feedback to TC39.

I am explicitly not suggesting anything concrete. Just to get the discussion started. I got the idea after I started participating in SinonJS and someone from Jest reached out to us in order to use a shared code component.

What do you think?

(And I want to point out that "no" is also a perfectly acceptable response here)

----

Full disclosure - I am a part of the MobX team - MobX is written and is the brainchild of @mweststrate - I am also probably quite terrible at Vue itself :D

It's possible Michel reached out in the past (or vice versa) and the discussion simply isn't public.
Repository: angular
Issue: Expose '_loadedConfig' in a public way.
Labels: feature,area: router,router: lazy loading,feature: under consideration

<!--
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)
[ ] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Performance issue
[x ] 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

From a component that is loaded at bootstrap time I would like to dynamically instantiate a component that is loaded lazily on the current route. For that purpose I need access to the ComponentFactoryResolver for that route.

The only way I could find to access that resolver is via the private "_loadedConfig" property on the active route.

## Expected behavior

I would like to be able to access the resolved via a public API, not relying on an implementation detail.

## What is the motivation / use case for changing the behavior?

Better stability of my code by relying on public APIs, only.

## Environment

<pre><code>
Angular version: 6.0.2
<!-- Check whether this is still an issue in the most recent Angular version -->

Browser:
- [x ] Chrome (desktop) version XX
- [x] Chrome (Android) version XX
- [x] Chrome (iOS) version XX
- [x] Firefox version XX
- [x] Safari (desktop) version XX
- [x] Safari (iOS) version XX
- [x] IE version XX
- [x] Edge version XX
 
</code></pre>
Repository: rust
Issue: rewrite `liveness` analysis to be based on MIR
Labels: C-cleanup,T-compiler,A-MIR

The current liveness code does a simple liveness computation (actually a few such things) and tells you when e.g. assignments are dead and that sort of thing. It does this on the HIR. It would be better to do this on the MIR — in fact, the NLL computation is already computing liveness across all of MIR, so we ought to be able to piggy back on those results I imagine.

It may be a good idea to wait though until the MIR borrowck stuff "settles down" a bit before attempting this.
Repository: rust
Issue: Closure type mismatch on higher-ranked bounds
Labels: A-lifetimes,A-closures,T-compiler,C-bug,A-higher-ranked

In the following code, identical impls for a concrete type, a `fn` type, and a closure exist yet the only the closure fails to meet the higher-ranked bound:

```rust
trait FnLt<'a> {
    fn apply(self, input: &'a u8) -> &'a u8;
}

// Struct impl
struct Foo;
impl<'a> FnLt<'a> for Foo {
    fn apply(self, input: &'a u8) -> &'a u8 {
        input
    }
}

// Closure impl
impl<'a, T> FnLt<'a> for T
where
    T: FnOnce(&'a u8) -> &'a u8,
{
    fn apply(self, input: &'a u8) -> &'a u8 {
        (self)(input)
    }
}

fn take_fn_lt(_: impl for<'a> FnLt<'a>) {}

fn main() {
    take_fn_lt(Foo); // Works
    
    fn foo(x: &u8) -> &u8 { x }
    take_fn_lt(foo); // Works
    
    take_fn_lt(|x: &u8| -> &u8 { x }); // Doesn't work
}
```

The error is this:

```
error[E0271]: type mismatch resolving `for<'a> <[closure@src/main.rs:31:16: 31:37] as std::ops::FnOnce<(&'a u8,)>>::Output == &'a u8`
  --> src/main.rs:31:5
   |
31 |     take_fn_lt(|x: &u8| -> &u8 { x }); // Doesn't work
   |     ^^^^^^^^^^ expected bound lifetime parameter 'a, found concrete lifetime
   |
   = note: required because of the requirements on the impl of `for<'a> FnLt<'a>` for `[closure@src/main.rs:31:16: 31:37]`
note: required by `take_fn_lt`
  --> src/main.rs:23:1
   |
23 | fn take_fn_lt(_: impl for<'a> FnLt<'a>) {}
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

Edit: the closure can be made to work through coercion to a `fn` pointer (which is unsurprising, since it's then the same as `foo`). `take_fn_lt({ |x: &u8| -> &u8 { x } } as fn(&u8) -> &u8);` compiles.
Repository: TypeScript
Issue: Should resolveJsonModule resolve json files without a .json file extension?
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  2.9.0-dev.20180521

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** 
- json
- resolveJsonModule

**Code**
In a project using `resolveJsonModule`.

For a file:

```ts
import foo = require('./foo')
import foo2 = require('./foo.json')
 
console.log(foo, foo2);  
```

**Expected behavior:**
If we follow node, both imports are resolved

**Actual behavior:**
Only the `foo2` import is resolved. The import without the `.json` file extension is not resolved
Repository: rust
Issue: LTO ignored for all crate types when building multiple crate types and one doesn't support it
Labels: T-compiler,C-bug,A-LTO

https://github.com/rustwasm/rust_wasm_template has

```toml
[lib]
crate-type = [
  # Build a cdylib to make a `.wasm` library.
  "cdylib",
  # Build an rlib for testing and benching.
  "rlib"
]

[profile.release]
lto = true
```

The `lto = true` is ignored for everything because rlibs don't support LTO. I would expect that the cdylib has LTO and that only the rlib ignores the LTO options.

@alexcrichton tells me this is a rust compiler bug, not a cargo bug.

FWIW, this command does not work either:

```
cargo rustc -- -C lto=fat --crate-type cdylib
```
Repository: pytorch
Issue: [feature request] Add cudaification API for distributions
Labels: module: distributions,triaged,enhancement

Right now it's possible to have a distribution "live" on the GPU, so that you can sample to directly get cuda tensors. You'll have to do something like the following though:

    N = Normal(0.0, 1.0)
    N.loc = N.loc.cuda()
    N.scale = N.scale.cuda()

Alternatively, you can directly initialize the parameters on the GPU:

    N_cuda = Normal(torch.tensor([0.0], device='cuda'), torch.tensor([1.0], device='cuda'))

Both of these methods are somewhat verbose and cumbersome. It would be great having something simpler like the following:

        Ncuda = Normal(0.0, 1.0).cuda()

Basically, one would just have to make sure that `.cuda()` gets called on all relevant parameters of the respective distribution. 

Some background on my use case: I'm using distributions to create more abstract notions of priors, which I register inside some Modules. Ideally, I'd just be able to call `.cuda()` on the top Module and have everything moved to GPU, like is the case with most modules - the above feature request is the basis for that. 

cc @fritzo @neerajprad @alicanb @vishwakftw
Repository: kubernetes
Issue: Missing proto struct tags incompatible with latest golang/protobuf changes
Labels: kind/bug,sig/api-machinery,lifecycle/frozen

> /kind bug

**What happened**:
Imported proto files and tried to use with latest `golang/protobuf` lib.  https://github.com/golang/protobuf/blob/master/proto/table_unmarshal.go#L331 mandates that all struct fields have proto tags. The TypeMeta fields in kubernetes structs do not contain a proto tag, https://github.com/kubernetes/apiserver/blob/master/pkg/apis/audit/v1beta1/types.go#L145 is a typical example.

**What you expected to happen**:
Be able to import proto files and have them serialize/deserialize properly

**How to reproduce it (as minimally and precisely as possible)**:
Import a kubernetes proto file and use with latest `golang/protobuf` lib

**Anything else we need to know?**:
I filed an issue with `golang/protobuf` https://github.com/golang/protobuf/issues/617 as it seems like a breaking change but they are pushing back

**Environment**:
- Kubernetes version: 1.10.3
- golang/protobuf version: master
Repository: javascript-algorithms
Issue: What about rope?
Labels: enhancement

I found this repo while looking for a good example of [rope](https://en.wikipedia.org/wiki/Rope_(data_structure)). But I can't find one :(
Repository: flutter
Issue: AnimatedIcons should have Cupertino-specific versions
Labels: c: new feature,framework,f: material design,a: fidelity,P2,team-design,triaged-design

The Cupertino lib should include AnimatedIcons similar to the ones provided for Material that animated from the hamburger menu to the Cupertino style back button and vice versa. 

https://docs.flutter.io/flutter/material/AnimatedIcons-class.html, specifically talking about `menu_arrow` and `arrow_menu`, which should have equivalents in Cupertino.

/cc @xster @amirh
Repository: pytorch
Issue: Checkpointing is slow on nn.DataParallel models
Labels: module: performance,module: checkpoint,triaged

@wandering007 pointed out this issue in https://github.com/gpleiss/efficient_densenet_pytorch/blob/master/models/densenet.py

I have a model that uses checkpointing on several layers. On a single GPU, the model runs fairly fast (e.g. only a 15-20% overhead). On multiple GPUs, using an `nn.DataParallel` @wandering007 claims that the model runs up to 100x slower.

Here's the important snippets of the model.

```python
def _bn_function_factory(norm, relu, conv):
    def bn_function(*inputs):
        concated_features = torch.cat(inputs, 1)
        bottleneck_output = conv(relu(norm(concated_features)))
        return bottleneck_output
    return bn_function

class _DenseLayer(nn.Module):
    # ...

    def forward(self, *prev_features):
        bn_function = _bn_function_factory(self.norm1, self.relu1, self.conv1)
        bottleneck_output = cp.checkpoint(bn_function, *prev_features)
        # ...
```

There are several `_DenseLayer`s throughout the model.
@wandering007 seems to think that the issue has to do with GPU synchronization? As in, the models must synchronize at every checkpoint during the backward pass.

Original issue is here: https://github.com/gpleiss/efficient_densenet_pytorch/issues/36
Full code of the model is here: https://github.com/gpleiss/efficient_densenet_pytorch/blob/master/models/densenet.py
Repository: vue
Issue: VueSSRServerPlugin produces a slow-to-parse JSON for large projects
Labels: improvement

### What problem does this feature solve?
Makes for a better development experience with vue SSR.

I was looking into why it takes 500ms to render an single-component page from the server in our fairly large application and found an interesting issue. Webpack creates ~40 bundles for us. Altogether, these weigh ~20MB. The way  `VueSSRServerPlugin` plugin works, as you know, is it combines all of these files into a single `vue-ssr-server-bundle.json` file. Reading that file in node is fast (5ms on average) for us, but after reading it we need to `JSON.parse` it before providing to `createBundleRenderer` and _that_ takes ~400ms.

Initially I was thinking of using webpack's `splitChunks`, to reduce the file-size (our router dynamically imports top-level pages, so each chunk could benefit from not having to bring in common component) but `VueSSRServerPlugin` does not support that (and throws the "Server-side bundle should have one single entry file" error).

### What does the proposed API look like?
I'm not exactly sure what to do here at this point as I just noticed this issue. I'm concerned that as the app grows, the json parse time will increase adding seconds to the load-time in development.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: javascript-algorithms
Issue: A* algorithm?
Labels: enhancement

Hey! This repo is awesome! Nice job!

While I was reading through the algorithms, I found weird that the [A* algorithm](https://en.m.wikipedia.org/wiki/A*_search_algorithm) was missing, which is one of the few I know.

I'm just gonna leave this as a suggestion, sorry if I can't do a pull request!
Repository: pytorch
Issue: OOM Exception when using torch.nn.grad.conv2d_weight (apparently because CuDNN backwards is not used)
Labels: module: performance,module: cudnn,module: memory usage,module: convolution,triaged,has workaround

## Issue description

I encountered an out of memory exception when using torch.nn.grad.conv2d_weight even though using torch.nn.functional.conv2d works (forward and backward, and I assume the same calculations done in torch.nn.grad.conv2d_weight are done at some point during conv2d()'s backward pass).

## Code example

I'm using the following custom convolutional layer:
```
class MyConv(Function):
    @staticmethod
    def forward(ctx, x, w):
        ctx.save_for_backward(x, w)
        return F.conv2d(x, w)

    @staticmethod
    def backward(ctx, grad_output):
        x, w = ctx.saved_variables
        x_grad = w_grad = None
        if ctx.needs_input_grad[0]:
            x_grad = torch.nn.grad.conv2d_input(x.shape, w, grad_output)
        if ctx.needs_input_grad[1]:
            w_grad = torch.nn.grad.conv2d_weight(x, w.shape, grad_output)
        return x_grad, w_grad
```
Using torch.nn.functional.conv2d works, Using MyConv does not. It fails during torch.nn.grad.conv2d_weight and gives an out of memory exception. As I said before, I don't understand how that can happen since, I assume, at some point during conv2d back-prop, it performs the same calculations that are done in torch.nn.grad.conv2d_weight.
I can give a more detailed code example if needed.

## System Info
- PyTorch or Caffe2: Pytorch
- How you installed PyTorch (conda, pip, source): conda
- Build command you used (if compiling from source):
- OS: Ubuntu 16.04
- PyTorch version: 0.4
- Python version: 3.6
- CUDA/cuDNN version: 9.0/7.0.5
- GPU models and configuration: Tesla V100-SXM2-16GB
- GCC version (if compiling from source): (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
- CMake version: 3.5.1
- Versions of any other relevant libraries:
[pip3] numpy (1.14.2)
[conda] cuda90                    1.0                  h6433d27_0    pytorch
[conda] pytorch                   0.4.0           py36_cuda9.0.176_cudnn7.1.2_1  [cuda90]  pytorch
[conda] torchvision               0.2.1                    py36_1    pytorch
Repository: pytorch
Issue: LMDB read error for Mnist
Labels: caffe2

If you have a question or would like help and support, please ask at our
[forums](https://discuss.pytorch.org/).

If you are submitting a feature request, please preface the title with [feature request].
If you are submitting a bug report, please fill in the following details.

## Issue description

Provide a short description.
I am trying to learn caffe2, and I tried to run the provided MNIST tutorial but i get lmdb error on lmdb read.

## Code example
workspace.RunNetOnce(train_model.param_init_net)

Please try to provide a minimal example to repro the bug.
Error messages and stack traces are also helpful.
RuntimeError: [enforce fail at db.h:190] db_. Cannot open db: /home/rohit/caffe2_notebooks/tutorial_data/mnist/mnist-train-nchw-lmdb of type lmdb Error from operator: 
output: "dbreader_/home/rohit/caffe2_notebooks/tutorial_data/mnist/mnist-train-nchw-lmdb" name: "" type: "CreateDB" arg { name: "db" s: "/home/rohit/caffe2_notebooks/tutorial_data/mnist/mnist-train-nchw-lmdb" } arg { name: "db_type" s: "lmdb" }

## System Info
Please copy and paste the output from our
[environment collection script](https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py)
(or fill out the checklist below manually).

You can get the script and run it with:
```
wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py
```

- PyTorch or Caffe2: Caffe2
- How you installed PyTorch (conda, pip, source):  conda install -c caffe2 caffe2
- Build command you used (if compiling from source): N/A
- OS: Ubuntu 16.04.4 LTS
- PyTorch version: N/A
- Python version:Python 3.6.4 :: Anaconda custom (64-bit)
- CUDA/cuDNN version: N/A
- GPU models and configuration:N/A
- GCC version (if compiling from source):N/A
- CMake version:N/A
- Versions of any other relevant libraries:N/A

Any pointers to resolve this problem would be really helpful