sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: torch.nn.functional.threshold not work with LongTensor
Labels: module: nn,triaged,enhancement

## 🐛 Bug

**torch.nn.functional.threshold** and **torch.nn.Threshold** can work on **Tensor** but not work correctly for **LongTensor** variables.

## To Reproduce

Steps to reproduce the behavior:

Follow the following steps or just run the code below.
1. apply `F.threshold` on **LongTensor**
2. apply `F.threshold` on **Tensor**
3. Compare the results of them
```
import torch
turn_long = torch.LongTensor([[10, 10],
                              [ 7,  7],
                              [ 2,  2],
                              [ 4,  4],
                              [10, 10],
                              [ 6,  6]])
turn = torch.Tensor([[10, 10],
                     [ 7,  7],
                     [ 2,  2],
                     [ 4,  4],
                     [10, 10],
                     [ 6,  6]])
turn_long = -torch.nn.functional.threshold(-turn_long, -5, -5) # unexpected
turn = -torch.nn.functional.threshold(-turn, -5, -5) # correct
print("turn_long: ", turn_long)
print("turn: ", turn)
"""Then you will see
turn_long:  tensor([[10, 10],
                    [ 7,  7],
                    [ 5,  5],
                    [ 5,  5],
                    [ 5,  5],
                    [ 5,  5]])
turn:  tensor([[5., 5.],
               [5., 5.],
               [2., 2.],
               [4., 4.],
               [5., 5.],
               [5., 5.]])
, which are different."""
```

## Expected behavior
I want to implement a 'reversed threshold' function.
Threshold is to restrict the original values with given value if they are smaller than the threshold. But I want to restrict the original values if they are larger than the threshold.
The result of the turn (dtype=torch.Tensor) is correct, but I don't know why it doesn't work correctly on LongTensor data.
Take the example above, you will find something weird.

## Environment
 - PyTorch Version (e.g., 1.0): 1.0.0
 - OS (e.g., Linux): Linux & MacOS
 - How you installed PyTorch (`conda`, `pip`, source): `pip`
 - Build command you used (if compiling from source):
 - Python version: 3.7.0
 - CUDA/cuDNN version: 9.0.176
 - GPU models and configuration: Tesla P40 (I don't know what gpu model means, but I post the name of it here.)
 - Any other relevant information:

## Additional context

None
Repository: storybook
Issue: [addon-docs] Add support for providing remark plugins in docs
Labels: feature request,addon: docs

**Is your feature request related to a problem? Please describe.**
See the [twitter discussion](https://twitter.com/kevin940726/status/1217637106182307840) I had with @shilman.

Currently if the user wants to add new remark plugins to docs, they have to manually create the loader in conjunction with `createCompiler`, as seen in the [doc](https://github.com/storybookjs/storybook/blob/next/addons/docs/README.md#manual-configuration).

```js
const createCompiler = require('@storybook/addon-docs/mdx-compiler-plugin');
const emoji = require("remark-emoji");

{
  loader: "@mdx-js/loader",
  options: {
    compilers: [createCompiler({})],
    remarkPlugins: [emoji] // <--
  }
}
```

**Describe the solution you'd like**
We can add a new option in `addon-docs` to add the `remarkPlugins` (and other loader options) to the mdx loader, called `mdxLoaderOptions`.

```js
const emoji = require("remark-emoji");

module.exports = {
  addons: [
    {
      name: "@storybook/addon-docs",
      options: {
        mdxLoaderOptions: {
          remarkPlugins: [emoji] // <--
        }
      }
    }
  ]
};
```

Currently we already have [2 default remark plugins](https://github.com/storybookjs/storybook/blob/next/addons/docs/src/frameworks/common/preset.ts#L32). We can just simply override the options and expect the users to add them back if they still want those plugins.

**Describe alternatives you've considered**
We could dedup the provided plugins, but [that might be a bad idea](https://twitter.com/mshilman/status/1217647872813850624).

**Are you able to assist bring the feature to reality?**
Sure! :) Any heads-up for where to look into?
Repository: pytorch
Issue: Numpy array functionality in torchscript.
Labels: oncall: jit,triaged

I am quantizing one of my model in Linux Machine.
I am using jit to trace and save the model.
One of my function forward path look like this - 

```
 def forward(self, image):
        image_shape = image.shape[2:]
        image_shape = np.array(image_shape)
        image_shapes = [(image_shape + 2 ** x - 1) // (2 ** x) for x in self.pyramid_levels]

        return image_shapes
```

I am saving my model like this -

 `torch.jit.save(torch.jit.script(quant_model),"demo_model.pt")`

But it is giving issues in forward path np.array

Error - 
    `Python builtin <built-in function array> is currently not supported in Torchscript:`
```

 - PyTorch Version (e.g., 1.0): 1.5.0.dev20200115+cpu
 - TorchVision Version -  0.6.0.dev20200115+cpu
 - OS (e.g., Linux): Linux
 - How you installed PyTorch (`conda`, `pip`, source):pip
 - Build command you used (if compiling from source):
 - Python version: 3.7.3
 - CUDA/cuDNN version:
 - GPU models and configuration:
 - Any other relevant information:

## Additional context

<!-- Add any other context about the problem here. -->


cc @suo
Repository: pytorch
Issue: Support strategy to train large model that exceeds GPU mem and DRAM mem
Labels: feature,triaged,module: rpc

## 🚀 Feature
Support strategy to train large model that exceeds GPU mem and DRAM mem.

## Motivation
Models [e.g. **Factorization Machines**(1) or **DeepFM**(2)] in **recommendation task**s are usually very large , **billions of features**(including user id and product id) are used.

Training data in recommendation scenario is very sparse and the large embedding table consumes large memory, the model size may **exceed both GPU mem and DRAM mem** in one Machine. 

Both **DataParallel**  and **DistributedDataParallel**  strategy can't support this scenario. 

This kind of scenario usually use **Parameter Server** strategy.

I wonder how **Facebook** use Pytorch to serve **Recommendation and Ads products**.

1. Rendle, Steffen. "Factorization machines." 2010 IEEE International Conference on Data Mining. IEEE, 2010.  https://www.csie.ntu.edu.tw/~b97053/paper/Rendle2010FM.pdf
2. Guo, Huifeng, et al. "DeepFM: a factorization-machine based neural network for CTR prediction." arXiv preprint arXiv:1703.04247 (2017). https://arxiv.org/abs/1703.04247


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528 @jjlilley @osalpekar
Repository: scrcpy
Issue: Wireless major frame drops and latency
Labels: performance

On a note 9. when I'm connected USB, it's delayed a bit more than the standard 70-100ms. That's fine, would like it to be better, but when I swap to wireless, it's horrible. 10-20 second delay.
Repository: go
Issue: x/tools/gopls: diff metadata before invalidating on changes to go.mod
Labels: NeedsInvestigation,gopls,Tools

Right now, `gopls` invalidates all workspace metadata if there is a change to the user's `go.mod` file. This is unnecessary if the metadata remains valid after the change. @heschik proposes running `go list -m all` as a gate during the snapshot cloning to determine if we should invalidate all metadata or keep it in the cache. Either way, we will either invalidate all metadata for the workspace or none.
Repository: rust
Issue: Unexpected 'static lifetime requirement
Labels: A-borrow-checker,T-compiler

Attempting to compile

```rust
trait Trait<T> { }
impl<A: Trait<T> + ?Sized, T> Trait<T> for Box<A> { }

fn foo<T>(s: &Box<dyn Trait<T>>) {
    let _: &(dyn Trait<T> + 'static) = s;
}
```

yields the following error.

```
error[E0310]: the parameter type `T` may not live long enough
 --> src/lib.rs:5:40
  |
4 | fn foo<T>(s: &Box<dyn Trait<T>>) {
  |        - help: consider adding an explicit lifetime bound `T: 'static`...
5 |     let _: &(dyn Trait<T> + 'static) = s;
  |                                        ^
  |
note: ...so that the type `std::boxed::Box<(dyn Trait<T> + 'static)>` will meet its required lifetime bounds
 --> src/lib.rs:5:40
  |
5 |     let _: &(dyn Trait<T> + 'static) = s;
  |                                        ^
```

However, changing the line mentioned in the error to `let _: &(dyn Trait<T> + 'static) = &**s;` allows the code to compile.

The former attempts to coerce the `Box` itself to a trait object, while the latter simply takes a reference to the trait object within the `Box`, although I fail to understand why the former shouldn't work when the latter does. My guess is that the lifetime of the `Box` is bounded to the lifetime of `T` unnecessarily.
Repository: flutter
Issue: How to pass parameters to flutter web app
Labels: c: new feature,framework,f: routes,d: stackoverflow,platform-web,P2,team-web,triaged-web

This query was originally asked on StackOverflow but since I have got no reply and there is no particular answer resolving this query I am posting it here

[https://stackoverflow.com/q/59698200/9236994](https://stackoverflow.com/q/59698200/9236994)

After hours of searching about the topic and due to lack of documentation on Flutter Web I am asking this question.

I was trying to create a web app using flutter and had an requirement where URL such as below

`website.com/user/someUserCode`

would be called and an page will be launched where the data (`someUserCode`) will be passed to the page

but haven't got any solutions yet to resolve it.

so just rounding it all up,

**How to pass and fetch the data using (get / post) methods to flutter web app?**


What all I know / have tried yet

I am using below code to read if some parameters are being to some class file

```
final Map<String, String> params = Uri.parse(html.window.location.href).queryParameters;
String data = params["userData"];

```

all this actually solves the **Fetch** part of my question (maybe)

but the part where that data will be passed to the page via URL is still missing.
Repository: TypeScript
Issue: Type inference regression due to circular type definition
Labels: Needs Investigation

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.8.0-dev.20200115

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
circular type

**Code**

Replace

```typescript
type DeepPartial<T> =
    T extends Message ? PartialMessage<T> :
    T;

type PartialMessage<T extends Message> = { [K in keyof T]?: DeepPartial<T[K]> };
```

with 

```ts
type DeepPartial<T> =
    T extends Message ? { [K in keyof T]?: DeepPartial<T[K]> } :
    T;
```

**Expected behavior:**

Both works.

**Actual behavior:**

```
Type 'typeof SubMessage' is not assignable to type 'FieldValueType<SubMessage>'.
  The types returned by 'from(...)' are incompatible between these types.
    Property 'n' is missing in type 'Message' but required in type 'SubMessage'.(2322)
```

**Playground Link:** 

[Without circular type definition](https://www.typescriptlang.org/play/?ts=3.8.0-dev.20200115&ssl=6&ssc=1&pln=1&pc=1#code/C4TwDgpgBAIhFgAoEMBOwCWyA2AeAKgHxQC8AUFJVPlBAB7AQB2AJgM5QCyEbbyA5tAD8UFOizZuvARALEAXBSr4A3GTKhIotJhxS+ggrQbN2XHgYjESUAN5QA2gGkoGJlADWEEAHsAZtQAukLysPBIOhIEzoHEAL5qZADG2Mi85tKCdkqUbMDImElQfqg+ALZG9IysHPoyhAAUwAAWGGyhdYIAwj5MeagArknAPqhyADRQPgBGAFahcAhiunhEAJShNLY5VJSoEMADqO62cVBp1Gq7cTtsAISh-W78V1RlIVAAygPTnRBqN2SqXS31+FhkxmqZj+2V2TAeUCYAzK0wgqAB6noYFGwCgmmgfx6fWAg2Go0qJhqGUs1igTXAEH81JkaygADI6UwIAB3OmskjEfBrRJuRioPzIJLQABiGAg2BYADUcAMIPgGXJYVQSuVQg0AG4LcLLKLrUiCjFkLE4vEM5mCOBsJKoDBgEaoWXy9gASSYGGAmps212DkGTEwZQgADlkJHXO4vL4AvhAgBaD6ehXK7Cq9WQXBR3pRgbYVLTbCyfChgbhjCRmOR2KEMgJdRJXp5L74ABK3qjAHFSHZiqUyg12mElpEcLgnkx+IRWfZ9odjlAAOTrlRQM6t5Id3EsHhJDrgh3Hl1u0aZn1+gN-WnBqgTz49vv98Y7MqhUF-T+AmELhvbNcw1B81F-M9oCAuUsxVNUNUgzIrDUIA)

[With circular type definition](https://www.typescriptlang.org/play/?ts=3.8.0-dev.20200115&ssl=1&ssc=1&pln=36&pc=1#code/C4TwDgpgBAIhFgAoEMBOwCWyA2AeAKgHxQC8AUFJVPlBAB7AQB2AJgM5QCyEbbyA5tAD8UAN5QA2gGkoGJlADWEEAHsAZtQC6QgFyx4SNJhwFpm4gF8oOilXwBuMmQDG2ZLy48+gsbcptgZExnKDVUFQBbAloGZnZPXgEIQgAKYAALDDY9bkTBAGEVJgDUAFdnYBVUAkIAGigVACMAKz04BBR0LDwiAEo9GlE-KkpUCGBS1HlRK3dqRxGLYbYAQj0SuX4FqgjdKABlUsbc7whHJZc3D0PjrySYxlYOE-uhkaY1qCZSiMaIVHOTnoYCqwCgoEgCVOhWKwDKFSq0Xoj3iL0ExBIUDS4Ag6ihSV6UAAZFimBAAO5YwkkYj4XqOMhyRioNTIZzQABiGAg2BYADUcKUIPgcTVfCMwpE9CkAG5tAydYw9QjU2mAsjA0HgnH4wRwNjOVAYMCVVBcnnsACSTAwwDFmLeVAkZSYmAiEAAcsh3bJ5EpVBp8JoALR7c28gXYIUiyC4D1FD2lbBuRrYCCmF1uz3eiDmQhkCwM5xFAIHfAAJUtHoA4qQxKFwhEUtl9B0jN1cBsmPwVfWxhMplAAORD+xQKyFpzF2FQFg8Zw5O56+dGk1VcNWm12tHJOuO-x6fYVqvV2rDCKHo47s8XHdQOYbyPR0U7wiOG53h-ciOC4Wij9LskjhAA)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: TypeScript
Issue: Use absolute file paths in error messages
Labels: Suggestion,In Discussion,Domain: Error Messages

## Search Terms

absolute

## Suggestion

Output absolute paths in type errors for `tsc`, or at least a way to specify this.

## Use Cases

When type checking in monorepositories, typically `tsc` is run for each workspace. `tsc` is then run relative to the workspace it is run from, whereas developers are mostly interested in either the absolute path, or the path relative to the project root.

I have configured my terminal emulator so I can CTRL-click a file and then the file is opened in VSCode, even on the correct line. This works for `tsc` output in simple TypeScript projects, because the file paths are relative to the project root. This also works for example for ESLint output, because it prints absolute paths. This does not work for `tsc` in mono repositories, because the output of `yarn workspaces run tsc` is relative to that workspace.

## Examples

Clone and install a TypeScript mono repository.

```sh
git clone https://gitlab.com/remcohaszing/koas.git
cd koas
yarn
```

Let’s open the project using VSCode, since its builtin terminal is preconfigured to work with CTRL-click.

Run `yarn workspaces run tsc` in the VSCode terminal. This should work fine.

Now mess up any type. I changed an instance of `koas.Middleware` to `koas.Middlewar` in `packages/koas-core/src/index.ts`.

Run `yarn workspaces run tsc` in the VSCode terminal again. Now this outputs an error and a file path. The file path is not clickable, because it can’t be resolved.

## 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. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: go
Issue: runtime/cgo: add cgosymbolizer package to provide default Traceback
Labels: NeedsInvestigation,FeatureRequest,compiler/runtime

Go runtime has all the necessary machinery to resolve symbols from platform specific debug data (such as dwarf). It makes sense, therefore, to actually provide the default handlers for `SetCgoTraceback` out of the box, instead of forcing users to use somewhat under maintained and not always wieldy  miniport of the GCC backtrace facility.

This relatively small functionality addition on the Go runtime side (which already has a decent chunk of the machinery required) will make the life of Cgo users everywhere instantaneously better.
Repository: flutter
Issue: Be able to restart/reinstall application during UI test execution
Labels: a: tests,c: new feature,framework,t: flutter driver,c: proposal,P3,team-framework,triaged-framework

## Use case
I'd like to restart application between each UI test run. 
Actually and as workaround we have something that via dataHandler we're doing on each test `setUp()` that's restarting the activity but it's not ideal as we're not properly cleaning memory. As a QA I think that's mandatory that each test has to be executed in isolation and without depending on previous run outcome.

## Proposal

Have an additional argument on `flutter drive` that will let application restart like a fresh install for each test. 
Proposal: 
`flutter drive --reinstall-between-tests` or something similar
Repository: go
Issue: cmd/compile: decide how to better document -wb write barrier flag
Labels: Documentation,NeedsDecision,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13 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
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/experiment0/.cache/go-build"
GOENV="/home/experiment0/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/experiment0/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/experiment0/.gimme/versions/go1.13.linux.amd64"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/experiment0/.gimme/versions/go1.13.linux.amd64/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build011542069=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Opened [`go tool compile` documentation](https://golang.org/cmd/compile/)


### What did you expect to see?

Description of option `-wb=false`. As user of this tool, I need to understand what do I loose when I use this option and what risks I get. I see that the size of a binary could be reduced (through using this option), but I cannot make a decision if it is justified to use this option in my case, because I don't know about other possible effects.

The only information I found (before looking to the source code):
```
$ go tool compile --help 2>&1 | tail -2
  -wb
        enable write barrier (default true)
```

plus

> As preparation for the concurrent garbage collector scheduled for the 1.5 release,
> writes to pointer values in the heap are now done by a function call,
> called a write barrier, rather than directly from the function updating the value.
> In this next release, this will permit the garbage collector to mediate writes to the heap while it is running.
> This change has no semantic effect on programs in 1.4, but was 
> included in the release to test the compiler and the resulting performance.

plus

Some blogs which explains how this barrier works. But no explanation what will happen if I will disable it on Go1.13.


### What did you see instead?

There's no description of the option.
Repository: flutter
Issue: FadeInImage() needs a ImageLoadingBuilder just like Image.network()
Labels: c: new feature,framework,a: images,P3,team-framework,triaged-framework

We are able to get the `loadingBuilder` using `Image.network()` and this allows us to implement the `LinearProgressIndicator()` or any other progress indicator and having a similar `ImageLoadingBuilder` for `FadeInImage()` would really be helpful.
Repository: vue
Issue: Sometimes bubbling stops working on Safari
Labels: browser quirks

### Version
2.6.11

### Reproduction link
[https://codesandbox.io/s/vue-safari-error-tg4mm](https://codesandbox.io/s/vue-safari-error-tg4mm)







### Steps to reproduce
The bug reproduction is quite specific, so please be patient

- open "App.vue" in safari (my version is 13.0.4 (15608.4.9.1.3))
- open the console so that you can watch the logs (the values ​​of "e.TimeStamp" and "attachedTimestamp" from https://github.com/vuejs/vue/blob/dev/dist/vue.esm.js#L7549 are logged)
- make sure that the variable "WITH_GENERATE_NEW_VUE" is false
- wait a while. at least about a minute
- click the "Press me" button several times to make sure that everything works. most likely, in the console there will be "e.timeStamp, attachTimestamp 0 0"

Now the difficult and not completely clear part
- change the value of the variable "WITH_GENERATE_NEW_VUE" to true
- without reloading the browser page, click on the button
- now, most likely, the log will change to something similar to "e.timeStamp, attachedTimestamp 0 51478"
- this is Safari and "e.timeStamp" (the first number in the logs) is zero, but after some time or a few clicks, it will begin to grow and now until it becomes more than the value of "attachedTimestamp", the click will not work

### What is expected?
click and method on it works

### What is actually happening?
in the above case, this check is not performed
https://github.com/vuejs/vue/blob/dev/dist/vue.esm.js#L7549

---
This is a specific situation - something like emulating an application in which there is a lot of legacy. different sections can be written on different technologies and sometimes this bug is caught when switching between sections. Unfortunately, I can’t even suggest how this bug is related to the instantiation of a new vue, maybe this is a coincidence

I think this can be fixed by adding "e.target.contains (e.currentTarget)" to the conditions specified in https://github.com/vuejs/vue/blob/dev/dist/vue.esm.js#L7549 but I don’t know if this will not affect performance

<!-- generated by vue-issues. DO NOT REMOVE -->