sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Training got stuck due to timeout from dataloader
Labels: module: performance,module: dataloader,triaged


The same training script works well with Pytorch 1.4 before. Trying to test some new stuff in master branch (built from source), but training always got stuck after a few hundreds iterations without triggering any error info. If I ctrl-C it, it was traced down to some timeout function in dataloader. Again the same training code and configuration worked well with 1.4. Any clue?

Iteration 198: train = 1.8057, g_train = 0.9733, t_train = 0.8221, kl_train = 1.02579618
Iteration 199: train = 0.9988, g_train = 0.2920, t_train = 0.6974, kl_train = 0.93473649
Iteration 200: train = 1.3745, g_train = 0.4477, t_train = 0.9169, kl_train = 0.99940717
saved tex images for 200
Iteration 201: train = 1.1959, g_train = 0.3795, t_train = 0.8027, kl_train = 1.37421489
^CTraceback (most recent call last):
......
......
  File "/mnt/home/xxxx/anaconda3/envs/pytorch-py36/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 345, in __next__
    data = self._next_data()
  File "/mnt/home/xxxx/anaconda3/envs/pytorch-py36/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 841, in _next_data
    idx, data = self._get_data()
  File "/mnt/home/xxxx/anaconda3/envs/pytorch-py36/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 808, in _get_data
    success, data = self._try_get_data()
  File "/mnt/home/xxxx/anaconda3/envs/pytorch-py36/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 761, in _try_get_data
    data = self._data_queue.get(timeout=timeout)
  File "/mnt/home/xxxx/anaconda3/envs/pytorch-py36/lib/python3.6/multiprocessing/queues.py", line 104, in get
    if not self._poll(timeout):
  File "/mnt/home/xxxx/anaconda3/envs/pytorch-py36/lib/python3.6/multiprocessing/connection.py", line 257, in poll
    return self._poll(timeout)
  File "/mnt/home/xxxx/anaconda3/envs/pytorch-py36/lib/python3.6/multiprocessing/connection.py", line 414, in _poll
    r = wait([self], timeout)
  File "/mnt/home/xxxx/anaconda3/envs/pytorch-py36/lib/python3.6/multiprocessing/connection.py", line 911, in wait
    ready = selector.select(timeout)
  File "/mnt/home/xxxx/anaconda3/envs/pytorch-py36/lib/python3.6/selectors.py", line 376, in select
    fd_event_list = self._poll.poll(timeout)
KeyboardInterrupt



 - PyTorch Version (e.g., 1.0): 1.5.0a0+ab14375
 - OS (e.g., Linux): Linux
 - How you installed PyTorch (`conda`, `pip`, source): source
 - Build command you used (if compiling from source): USE_MPI=OFF python setup.py install
 - Python version: 3.6
 - CUDA/cuDNN version: 9.0

Thanks in advance!


cc @SsnL @VitalyFedyunin @ngimel
Repository: pytorch
Issue: [feature request] torch.expand to not require unsqueeze and match -1 to existing dimensions if tensor.shape.count(-1) == tensor.ndim
Labels: triaged,enhancement

```python
torch.rand(2).expand(-1, 3)
#RuntimeError: The expanded size of the tensor (3) must match the existing size (2) at non-singleton dimension 1.  Target sizes: [-1, 3].  Tensor sizes: [2]

torch.rand(2).unsqueeze(-1).expand(-1, 3)
# works
```

Docs:
```
Passing -1 as the size for a dimension means not changing the size of that dimension.

Tensor can be also expanded to a larger number of dimensions, and the new ones will be appended at the front. For the new dimensions, the size cannot be set to -1.
```

Here I'm asking a new dimension at the end, not in the front. So it's not perfectly clear why it doesn't like leading -1.

If number of -1's is equal to the number of dimensions in the original tensor, the leading -1 limitation could be alleviated?
Repository: pytorch
Issue: Don't take TensorOptions by reference
Labels: module: cpp,triaged

The class was explicitly designed to be two words large, we should pass it by value.

cc @yf225
Repository: pytorch
Issue: torch::var_out and dimnames
Labels: module: cpp,triaged,module: named tensor

## 🐛 Bug

Using `torch::var_out` in the C++ API with dimnames instead of the index of the dimension seems to return the standard deviation instead of the variance.

## To Reproduce

Running the following program:

```
#include <torch/torch.h>
#include <iostream>

int main() {
    auto d = torch::Dimname::fromSymbol(torch::Symbol::dimname("a"));
    std::vector<torch::Dimname> ds;
    ds.push_back(d);
    
    auto x = torch::rand(100, ds);
    
    auto y = torch::zeros(1);
    torch::var_out(y, x, {0});
    std::cout << y << std::endl;
    
    auto z = torch::zeros(1);
    torch::var_out(z, x, ds);
    std::cout << z << std::endl;
}
```

Returns: 

```
(base) dfalbel@Daniels-MacBook-Pro build % ./example-app
Warning: Named tensors and all their associated APIs are an experimental feature and subject to change. Please do not use them for anything important until they are released as stable. (operator() at ../c10/core/TensorImpl.h:845)
0.073097
[ CPUFloatType{} ]
0.270365
[ CPUFloatType{} ]
```

Since:

```
sqrt(0.073097)
[1] 0.2703646
```

It seems that when using dimnames `torch_var_out` is returning the standard deviation.

## Expected behavior

Expected both values to be identical.

## Environment

I am using Pytorch C++ 1.4 - downloaded from here: https://download.pytorch.org/libtorch/cpu/libtorch-macos-1.4.0.zip on MacOS


cc @yf225 @zou3519
Repository: terminal
Issue: Consider adding a WT_PROFILE env var pointing to settings file
Labels: Issue-Feature,Help Wanted,Area-Settings,Product-Terminal

If the settings UI is not planned until after 1.0, then I strongly recommend adding an environment variable with the path to the json settings file, so it can be edited with the editor of choice (vi, notepad, nano, emacs, whatever) from within the shell of choice without burning brain calories trying to find it buried in AppData. Also: Relying on the GUI menu is, well, unreliable, due to there being no guarantee of a valid file association for json files.

We've already got `WT_SESSION` env var -- something like `WT_PROFILE` would be useful. 

Then from within cmd or powershell, I can easily edit settings with my preferred editor, or interactively using `$settings = gc $env:WT_PROFILE | convertto-json` and flipping settings on the object model directly before saving it back out.
Repository: go
Issue: x/tools/gopls: show message with link to debug server with -debug=:0
Labels: help wanted,NeedsFix,gopls,Tools

currently we ask users to supply flags such as `-port` and `-rpc.trace` and restart gopls when debugging is needed. Please consider turning on the debug port by default and make some traces available.

- Port number needs to be picked up randomly - so we will need a way for the client to ask gopls about the debug port location.
- May need too allow opt-out.
Repository: terminal
Issue: Calling wt from cmd for working directory "C:\" causes an error
Labels: Issue-Bug,Product-Terminal,Priority-2,Area-Commandline

Hi,

I was testing the new command line options to open a Windows Terminal for a specified working directory. When calling `wt new-tab -d "C:\"` from PowerShell this seems to work. Calling the same command from cmd however will print the error message `[error 0x8007010b when launching `powershell.exe']` in the newly opened Windows Terminal instance. Using the "-p" option to launch a different shell will provoke the same error message for the executable associated with the specified profile name.

# Environment

```none
Windows build number: Microsoft Windows [Version 10.0.18363.657]
Windows Terminal version: 0.9.433.0
```

# Steps to reproduce

Call `wt new-tab -d "C:\"` from cmd.

# Expected behavior

Open a new Windows Terminal tab with path `C:\` set as the current working directory.

# Actual behavior

Opens a Windows Terminal instance with the message:
``[error 0x8007010b when launching `powershell.exe']``
Repository: angular
Issue: `preserveWhitespaces`: false cause i18n interpolation placeholder to be different from xi18n
Labels: type: bug/fix,area: i18n,workaround1: obvious,freq1: low,area: compiler,state: confirmed,P3

<!--🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅

Oh hi there! 😄

To expedite issue processing please search open and closed issues before submitting a new one.
Existing issues often contain information about workarounds, resolution, or progress updates.

🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅-->


# 🐞 bug report

### Affected Package
<!-- Can you pin-point one or more @angular/* packages as the source of the bug? -->
The issue is caused by package `@angular/compiler`


### Is this a regression?

<!-- Did this behavior use to work in the previous version? -->
Yes, the previous version in which this bug was not present was: 8.2.12


### Description

If I have this template:

```html
<div>{{ name }} and {{ name  }}</div>
```

`ng xi18n` will cause the first interpolation to be `INTERPOLATION` and the second one to be `INTERPOLATION_1`. (Notice that the second has an extra whitespace.)

After that, if you run `ng build --localize`, the remove whitespace thingy will kick in and the second pass of `I18nMetaVisitor` will cause the second interpolation to be just `INTERPOLATION`, as indicated here:

https://github.com/angular/angular/blob/b2222e7e02a05544c9b0e414c4258751209459ee/packages/compiler/src/render3/view/template.ts#L1974-L1990

That means the `INTERPOLATION_1` won't match and it will error as indicated here:

https://github.com/angular/angular/blob/b2222e7e02a05544c9b0e414c4258751209459ee/packages/localize/src/utils/src/translations.ts#L67-L72

Another example of template that will cause this issue:

```html
<div>{{ name | thePipe }} and {{ name |
thePipe }}
</div>
```

(Notice the newline.)

## 🔬 Minimal Reproduction
https://github.com/sarunint/ng-i18n-preserveWhitespaces

## 🔥 Exception or Error
<pre><code>
No placeholder found with name INTERPOLATION_1 in message "songNormalInstruction" (" {$INTERPOLATION} และ {$INTERPOLATION}
").
</code></pre>


## 🌍  Your Environment

**Angular Version:**
<pre><code>
Angular CLI: 9.0.2
Node: 12.15.0
OS: linux x64

Angular: 9.0.1
... animations, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.900.2
@angular-devkit/build-angular     0.900.2
@angular-devkit/build-optimizer   0.900.2
@angular-devkit/build-webpack     0.900.2
@angular-devkit/core              9.0.2
@angular-devkit/schematics        9.0.2
@angular/cli                      9.0.2
@ngtools/webpack                  9.0.2
@schematics/angular               9.0.2
@schematics/update                0.900.2
rxjs                              6.5.4
typescript                        3.7.5
webpack                           4.41.2
</code></pre>

**Anything else relevant?**
May be related to #26276
Repository: storybook
Issue: vue addon-docs display prop values in prop table.
Labels: feature request,vue,addon: docs,block: props

**Is your feature request related to a problem? Please describe.**
I'm not sure if this is already possible, but I have looked around and tried a bunch of different options, but I would like the possible values for a component prop to show up in the prop table in docs.

_This may already be possible, but it seems that all of my jsdoc comments are being pulled except for the @values field. Please point me in the right direction if so._

**Describe the solution you'd like**
Grab @values from jsdoc on component and display in addon-docs prop table. Displaying under the description would be nice, or another column all together.

**Describe alternatives you've considered**
It looks like this may be possible by describing the props with PropTypes in your story, but since I am using, Vue, that would be an extra dependency that only gets used for this feature. JSDoc has @values so it would be nice to have that pulled in as well.

**Are you able to assist bring the feature to reality?**
Possibly. If someone could point me in the right direction

**Additional context**
Here is the image that shows what I would like:
![Example](https://raw.githubusercontent.com/storybookjs/storybook/master/addons/docs/docs/media/docspage-hero.png)
It shows the possible values in the description. This is from the docs documentation so it looks like it may be possible, but just not working for me.
Repository: terminal
Issue: Cannot find info on hosting terminal in another app.
Labels: Issue-Docs,Area-TerminalControl,Product-Meta

We need documentation on hosting the console.  Project templates would be very helpful.
Repository: rust
Issue: Incorrect trait-object warning when returning a type-alias-impl-trait
Labels: A-lints,T-compiler,C-bug,F-type_alias_impl_trait,D-invalid-suggestion,A-trait-objects

The following code:

```rust
#![feature(type_alias_impl_trait)]

type Foo = impl Copy;
fn bar(val: &u8) -> Foo + 'static {
    true
}
```

produces the following messages:

```
error[E0404]: expected trait, found opaque type `Foo`
 --> src/lib.rs:4:21
  |
4 | fn bar(val: &u8) -> Foo + 'static {
  |                     ^^^ not a trait

warning: trait objects without an explicit `dyn` are deprecated
 --> src/lib.rs:4:21
  |
4 | fn bar(val: &u8) -> Foo + 'static {
  |                     ^^^^^^^^^^^^^ help: use `dyn`: `dyn Foo + 'static`
  |
  = note: `#[warn(bare_trait_objects)]` on by default
```

The error message is correct - `Foo` is not a trait, so writing `+ 'static` makes no sense. However, the warning message is completely inapplicable - `Foo` is not a trait, so adding `dyn` will just produce a different error.

We should suppress this warning if the user didn't actually write down the name of a trait.
Repository: flutter
Issue: Allow Hero to define it's Overlay level
Labels: c: new feature,framework,a: animation,f: routes,P3,team-framework,triaged-framework

This is the `Hero` animation I want to achieve:

![image](https://user-images.githubusercontent.com/8120472/74483838-16a20800-4e96-11ea-9ca9-a4c2fe9b11b5.png)

The green rectangle flies to the second screen, landing BEHIND the rounded-square purple grid.

As far as I know, if I do this right now the `Hero` will land on top of the grid and then it will flicker for a frame appearing behind the grid.

I could use a `flightShuttleBuilder` but this will turn things a lot more complicated, I will have to animate the fade-in of the grid myself, I will have to create the grid in 2 screens, too much stuff to take care for just one animation.

I think cases like this could be simplified if there was a way to tag which `Overlay` the `Hero` should be rendered into, so the grid could tagged to be at the top `Overlay`, the `Hero` at the `Overlay` behind it, and the rest of the UI below.
Repository: TypeScript
Issue: Exported type merged with 'export * as namespace...' only exports type meaning.
Labels: Bug

> Previously I liked using TS namespaces and declaration merging for creating FP-style modules, without needing the `MyModule.T` convention:
>
> ```ts
> export type Foobar = { }
> 
> export namespace Foobar {
>   export function doStuff(foobar: Foobar) { }
> }
> ```
> 
> ```ts
> import { Foobar } from './Foobar'
> 
> Foobar.doStuff(fb)
> ```
> 
> Namespaces are not really the way to go any more, babel doesn't support them, they probably aren't tree-shakeable etc. But I was hoping that the `export * as ns` syntax could be > used as a replacement, like this:
> 
> ```ts
> export type Foobar = import('./Foobar').Foobar
> 
> // Or:
> // export type { Foobar } from './Foobar'
> 
> export * as Foobar from './Foobar'
> ```
> 
> This seems to pass the nightly compiler, but the compiler only knows that Foobar is re-exported as a type, not a value. It would be great if the compiler could merge them into a combined value & type like with namespaces.

_Originally posted by @katis in https://github.com/microsoft/TypeScript/issues/4813#issuecomment-577284794_
Repository: rust
Issue: rustc fails to resolve an associated type when using Self: Trait<A> in a method of a trait
Labels: A-associated-items,T-compiler,C-bug

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

_Somewhat_ minimal reproducible code:

```rust
pub trait Foo<L> {
    type Repr;

    fn foo(repr: &Self::Repr);
}

pub trait Bar {
    fn bar<L>(repr: &Self::Repr)
    where
        Self: Foo<L>;
}

// now let’s implement Bar for a type
#[derive(Debug)]
pub struct Hello {
    pub handle: u32,
}

impl<L> Foo<L> for u32 {
    type Repr = Hello;

    fn foo(repr: &Self::Repr) {
        println!("{:?}", repr);
    }
}

// the weird things start here; notice how we need <Self as Base<L>> here
impl Bar for u32 {
    fn bar<L>(repr: &<Self as Foo<L>>::Repr)
    where
        Self: Foo<L>,
    {
        println!(
            "{}",
            repr.handle // <- opaque type here
            //unsafe { std::mem::transmute::<_, &Hello>(repr) }.handle // <- current workaround :()
        );
    }
}

fn main() {
    let h = Hello { handle: 3 };
    u32::bar::<()>(&h);
}
```

I expected to see this happen: code should compile just fine.

Instead, this happened: result from _rustc_:

```
error[E0609]: no field `handle` on type `&<u32 as Foo<L>>::Repr`
  --> src/main.rs:52:18
   |
52 |             repr.handle // <- opaque type here
   |                  ^^^^^^

error: aborting due to previous error
```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

Bug present in both _stable_ and _nightly_ (I haven’t tested _beta_ but I guess it’s there too).

`rustc --version --verbose`:
```
rustc 1.41.0 (5e1a79984 2020-01-27)
binary: rustc
commit-hash: 5e1a799842ba6ed4a57e91f7ab9435947482f7d8
commit-date: 2020-01-27
host: x86_64-unknown-linux-gnu
release: 1.41.0
LLVM version: 9.0
```

<details><summary>Backtrace</summary>
<p>

```
N/A
```

</p>
</details>
Repository: PowerToys
Issue: [PowerRename] Allow changing of other attributes in a batch
Labels: Idea-Enhancement,Help Wanted,Product-PowerRename,Cost-Large

# Summary of the new feature/enhancement

Do not know the feasibility of this feature, but why to stop with the filenames, ideally it will also detect if all files have the same extension, read the writable properties of the files and allow to change them in batch.

Example for jpg, allow changing the subject, ratings, tags, date taken ... 
for mp4 files, authors, year, genre, parental ratings... 

# Proposed technical implementation details (optional)

- Detect if all files have the same extension and properties/details.
- When clicking on the PowerRenam offer the option to apply it to the filename or any other field detected.
Repository: flutter
Issue: Flutter Gradle plugin improvements
Labels: tool,t: gradle,dependency: android,P2,team-tool,triaged-tool

Review by @cmwarrington:

line 103:       addfluttertasks can happen eagerly (or atleast IIUC on the configuration of the android plugin) See for an example of how to do this see internal example.

line 323: Trigger from application of AGP, rather than afterEvaluate

line 329-330 - use .all rather than .each and .whenObjectAdded

line 366 Trigger from application of AGP, rather than afterEvaluate

line 705 : Cross project configuration is going away - It's not obvious to me looking at the code why you can't just add asset sources - your compile task can output assets into a build directory, and while we don't have a registerGeneratedAssets (we will have something like that soonish), you can just add that directory as an asset source directory, and make the prebuild task depend on it.

line 707 : trigger from application of AGP, rather than afterEvaluate
Repository: go
Issue: proposal: x/crypto/ocsp: Return ocsp.Request from CreateRequest instead of []byte
Labels: Proposal,Proposal-Crypto

The `ocsp.CreateRequest` function returns an OCSP request as a `[]byte`. It would be helpful to instead have it return `ocsp.Request`, which can then be marshalled into `[]byte` if needed.

My specific use case is implementing a cache for OCSP responses. Per https://community.digicert.com/en/blogs.entry.html/2015/02/26/what-is-ocsp.html, the cache key should be the `CertID` sequence for the OCSP request (issueNameHash + issueKeyHash + serialNumber). All of these fields are calculated in `ocsp.CreateRequest` but because that function returns a `[]byte`, accessing them after it's been called would require an additional call to `ocsp.ParseRequest`, which seems wasteful.

I'm not sure what the stability guarantee is for the x/crypto/ocsp library, but if changing the return type for the existing function isn't feasible, perhaps a new function could be added or the existing function could be deprecated and split into two functions.
Repository: vscode
Issue: Add support for premium extensions
Labels: feature-request

This was previously raised in #36577 but that is closed and locked. Rather than reopen it please allow this one to be a backlog candidate at least, so interested folk can upvote it.
Repository: deno
Issue: Support a pty interface
Labels: cli,suggestion,help wanted

Deno should support forking of pty interfaces (psuedo terminals) which would allow Deno workloads to be able to "pretend" to be a terminal, which can allow Deno workloads to be a terminal emulator or allow certain programs to think a Deno workload is an terminal to send it control sequences.

Node.js Prior art: https://github.com/microsoft/node-pty (which is used to provide the terminal interface in VSCode)
Likely this crate can be used: https://docs.rs/portable-pty/0.2.0/portable_pty/ which provides Linux/Mac and Windows support.

cc/ @Lerc
Repository: rust
Issue: Disambiguate method call for impl on dyn Trait
Labels: A-trait-system,T-lang,C-bug

```rust
pub trait Error: Debug + Display {
    fn source(&self) -> Option<&(dyn Error + 'static)> {
        None
    }

    fn chain(&self) -> Chain<'_> where Self: Sized + 'static {
        Chain {
            current: Some(self),
        }
    }
}

impl dyn Error + 'static {
    fn chain(&self) -> Chain<'_> {
        Chain {
            current: Some(self),
        }
    }
}
```

Seems like the compiler tries the trait method for an `dyn Error + 'static` even though it does not work, because of !Sized and does not consider taking the `impl dyn Error + 'static`.

Playground: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a6845b426451f1d7a5105a9bd3a00499

error:
```
error[E0034]: multiple applicable items in scope
  --> src/main.rs:82:28
   |
82 |     let mut iter = dyn_err.chain();
   |                    --------^^^^^--
   |                    |       |
   |                    |       multiple `chain` found
   |                    help: disambiguate the method call for candidate #2: `Error::chain(&dyn_err)`
   |
note: candidate #1 is defined in an impl for the type `(dyn Error + 'static)`
  --> src/main.rs:16:5
   |
16 |     fn chain(&self) -> Chain<'_> {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: candidate #2 is defined in the trait `Error`
  --> src/main.rs:8:5
   |
8  |     fn chain(&self) -> Chain<'_> where Self: Sized + 'static {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```