sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: net/http: no way to set Fetch options when making outgoing http calls with js/wasm
Labels: Thinking,help wanted,FeatureRequest,arch-wasm

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
go version devel +c814ac44c0 Thu Jul 19 21:30:27 2018 +0000 darwin/amd64

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
GOARCH="wasm"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="js"
GOPATH="/Users/eginez/repos/goland"
GOPROXY=""
GORACE=""
GOROOT="/Users/eginez/repos/go"
GOTMPDIR=""
GCCGO="gccgo"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pm/tlg5p5nx4vj3s05h4rfsv3t40000gn/T/go-build136489492=/tmp/go-build -gno-record-gcc-switches -fno-common"



### What did you do?
 The native http client, maps to the `fetch()` api. With the current client it is impossible to set additional options as supported by the fetch call, see: https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch.


### What did you expect to see?
A way to specify options for the fetch call
Repository: go
Issue: x/playground: fails to run program importing every package
Labels: NeedsInvestigation

Here's a program that empty imports every std package:

https://play.golang.org/p/AgKFdQv1pDV

It runs fine locally on linux/amd64 (13MB binary, 344KB heap alloc), but fails to even compile on the playground.

I get:

```
.dynsym: missing Go type information for global symbol: size 60
go.link.addmoduledata: relocation target runtime.addmoduledata not defined
_cgo_notify_runtime_init_done: relocation target x_cgo_notify_runtime_init_done not defined
_cgo_thread_start: relocation target x_cgo_thread_start not defined
runtime.cgo_yield: relocation target _cgo_yield not defined
.dynsym: relocation target _cgo_topofstack not defined
go.link.addmoduledatainit: phase error: addr=0x74db81 but sym=0x0 type=29
```

/cc @andybons @ianlancetaylor
Repository: pytorch
Issue: [Feature request] Batch eig/symeig functions (for small matrices, with CUDA)
Labels: triaged,module: batching,module: linear algebra,function request

**Proposed** - add `torch.geevj` and `torch.syevj` calls, which hook into cuSolver's jacobi-based eigensolvers. These functions could operate on matrices or batches of matrices (that are smaller than 32x32).

**Long** - there are two issues:

- For small matrices (e.g. <32x32 matrices), `eig` and `symeig` are much slower for cuda matrices than cpu matrices.
- It would be useful to run `eig`/`symeig` on batches of (small) matrices.

```
In [8]: %timeit ac.symeig()  # CUDA 32x32 matrix
19.1 ms ± 840 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [9]: %timeit a.symeig()  # CPU 32x32 matrix
40.8 µs ± 672 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)
```

cuSolver has Jacobi-based eigensolvers (`geevj` and `syevj`), and batched versions of these solvers as well. They are faster for small/medium sized matrices. The only limitation of these functions is that the batched version of `geevj` and `syevj` only operate on matrices smaller than 32x32.

It would be nice to have calls in torch (`torch.geevj` and `torch.syevj`) that hook into these functions.

cc/ @jacobrgardner @Balandat @darbour

cc @vincentqb @vishwakftw @jianyuh @nikitaved @pearu @mruberry @heitorschueroff
Repository: pytorch
Issue: [Caffe2] Modelling using Ops instead of Helper Functions
Labels: caffe2

Hi all,

how could I do the LeNet model using only Ops instead of helper functiones like below?

```
from caffe2.python import model_helper, brew
m= model_helper.ModelHelper(name="train_net")

#LeNet model
        conv1 = brew.conv(m, 'data', 'conv1', dim_in=1, dim_out=20, kernel=5)
        pool1 = brew.max_pool(m, conv1, 'pool1', kernel=2, stride=2)
        conv2 = brew.conv(m, pool1, 'conv2', dim_in=20, dim_out=50, kernel=5)
        pool2 = brew.max_pool(m, conv2, 'pool2', kernel=2, stride=2)
        fc3 = brew.fc(m, pool2, 'fc3', dim_in=50 * 4 * 4, dim_out=500)
        relu = brew.relu(m, fc3, fc3)
        pred = brew.fc(m, relu, 'pred', 500, 10)
        softmax = brew.softmax(m, pred, 'softmax')
```

From the Ops catalogue, I know that the corresponding fc layer and pred are:
```
from caffe2.python import model_helper
m = model_helper.ModelHelper(name="train_net")

weight = m.param_init_net.XavierFill([], 'fc_w', shape=[10, 100])
bias = m.param_init_net.ConstantFill([], 'fc_b', shape=[10, ])

#LeNet model
        #conv1 = m.net.Conv
        #pool1 = m.net.MaxPool
        #conv2 = m.net.Conv
        #pool2 = m.net.MaxPool
        fc3 = m.net.FC(["data", "fc_w", "fc_b"], "fc3")
        #relu = m.net.Relu
        pred = m.net.Relu(relu, "pred")
        #softmax = m.net.Softmax
```

How should I set the **ConvPoolOpBase** operator (mentioned in the catalogue) which provides the stride and kernel size, or the pads’ sizes in each direction for Conv and MaxPool layers?
https://caffe2.ai/docs/operators-catalogue.html#conv
Repository: terminal
Issue: new lines created below tmux after reducing the bash window
Labels: Product-Conhost,Area-VT,Issue-Bug

**Please fill out the below information:**
* Your Windows build number:  Version	10.0.17134 Build 17134

* What you're doing and what's happening: 
- Open a WSL
- launch tmux by executing : tmux (having the normal tmux layout, with the green bar at the bottom) : 
![image](https://user-images.githubusercontent.com/3726435/43592136-3456514c-9675-11e8-80df-8c35e96ffcb1.png)
- Reduce the window
- Re-open the window
=> From this point, there is an extra line below the green bar and I can type on it, also the first line on the top (the prompt) isn't visible anymore.
![image](https://user-images.githubusercontent.com/3726435/43592174-4395b594-9675-11e8-8c58-95463b5ffe29.png)


* What's wrong / what should be happening instead:
Reducing / expanding the windows shouldn't create this "extra line" below the tmux green bottom bar.
It seems that the whole display is moved 1 line ahead.
Repository: go
Issue: x/build: observability using distributed tracing and metrics
Labels: Builders,FeatureRequest

I am coming here from https://groups.google.com/forum/#!msg/golang-dev/MdwFiAx5-PU/UiUvY-8_DwAJ

The OpenCensus project https://opencensus.io/ provides observability into distributed systems(monoliths and microservices alike) by providing mechanisms to record traces and metrics. Those signals help provide insight into the states of a distributed system. 

I presented a talk about OpenCensus at GoSF on 18th July 2018(about 3 weeks ago) and I posted the accompanying slides here https://cdn.rawgit.com/orijtech/talks/master/2018/07/18/gosf/gosf.htm#1 or better https://github.com/orijtech/talks/blob/master/2018/07/18/gosf/gosf.slide for the Go present slide


### The value of it
Traces can help give play-by-play action/visibility into the state of sampled requests e.g. we can see that invoking `os/exec` took this long while fetching metadata from Google Cloud Storage took this long https://cdn.rawgit.com/orijtech/talks/master/2018/07/18/gosf/gosf.htm#14

The metrics that are collected are useful to actively check the health of the system e.g. send alerts to the `x/build` authors when a trybot run takes say 8 minutes or when overall the p99th latency hits 10 minutes.

### Maintenance and technical debt
In regards to maintenance, the OpenCensus Go implementation https://github.com/census-instrumentation/opencensus-go implements the tracer, metrics, and we just use the packages to instrument our code e.g excerpted from my slides https://cdn.rawgit.com/orijtech/talks/master/2018/07/18/gosf/gosf.htm#13
```go
func search(w http.ResponseWriter, r *http.Request) {
    ctx, span := trace.StartSpan(r.Context(), "Search")
    defer span.End()

    // Use the context and the rest of the code goes below
    _ = ctx
}
```

To extract out data, we just need to add an "exporter"/liason-to-our-backend of choice in a main function for example to send traces to Stackdriver
```go
package main

import (
    "log"

    "contrib.go.opencensus.io/exporter/stackdriver"
    "go.opencensus.io/trace"
)

func main() {
    sd, err := stackdriver.NewExporter(stackdriver.Options{ProjectID: "census-demos"})
    if err != nil {
        log.Fatalf("Failed to register Stackdriver Trace exporter: %v", err)
    }
    trace.RegisterExporter(sd)
}
```

Maintenance work is detached from the Go project, since the OpenCensus project is staffed already with collaborators from a wide range of companies. The Go project only needs to import the respective libraries, start and stop traces as well as record metrics and finally create exporters of the desired backend e.g. Prometheus, Zipkin, AWS X-Ray, Jaeger, Stackdriver Tracing and Monitoring, SignalFx etc.


### Next steps
I finally got some dev cycles this quarter to help work on improving our build system but I also would be delighted to delegate/work with people in the community too -- hence why I am filing this right now.

/cc @basvanbeek @ramonza @bogdandrutu @rakyll @kevinburke
Repository: flutter
Issue: Allow usage of system-wide `gradle` for Android builds
Labels: c: new feature,tool,t: gradle,P3,team-tool,triaged-tool

There should be an option to use the system-wide gradle instead of the one installed by flutter. There could also be an option to entirely disable using the gradle wrapper.
Repository: rust
Issue: Mention `;` when not expecting statement and finding one in the context of a macro
Labels: C-enhancement,A-diagnostics,P-low,A-macros,T-compiler,D-papercut

In a macro context that defines `$rename:stmt`, the parser autoinserts a `;` at the end, but the diagnostic message doesn't mention this:

```
error: expected unsuffixed literal or identifier, found "string-equal";
   -->
    |
521 |         #[serde(rename = $rename)]
    |                 ^^^^^^
...
535 | / match_func_impl! {
536 | |   StringEqual = "string-equal"
537 | | }
    | |_- in this macro invocation

error: aborting due to previous error
```
Repository: vscode
Issue: API to retrieve a dimensions from a given Terminal instance
Labels: feature-request,api,api-finalization,terminal-layout

VS Live Share extension needs to know current dimensions of a terminal and also to get notified when they're getting changed.

Consider adding a new API to get read-only access to a terminal renderer associated with given terminal instance.
Repository: rust
Issue: Procedural macro attributes can't be applied to struct fields
Labels: A-macros,T-lang

Given the simple program:

```rust
#![feature(rust_2018_preview)]
extern crate demo_macros;
use demo_macros::nop;

#[nop]
pub struct Foo {
  #[nop]
  pub foo_field: u32,
}

#[nop]
impl Foo {
  #[nop]
  pub fn foo_fn() {}
}
```

And the corresponding definition of the `#[nop]` attribute:

```rust
#![feature(rust_2018_preview)]
extern crate proc_macro;
use proc_macro::TokenStream;

#[proc_macro_attribute]
pub fn nop(_args: TokenStream, input: TokenStream) -> TokenStream {
  return input;
}
```

Attempting to compile this results in the error:

```
error[E0658]: The attribute `nop` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
 --> src/lib.rs:7:3
  |
7 |   #[nop]
  |   ^^^^^^
  |
  = help: add #![feature(custom_attribute)] to the crate attributes to enable

error: aborting due to previous error
```

The problem is the `#[nop]` attribute on `foo_field`. If it's removed, the library compiles fine. I believe this is incorrect and that the code should compile as-is. The `#[nop]` macro can be applied to `foo_fn` just fine; it seems wrong that it doesn't work with `foo_field`.

Rust version: `rustc --version`: `rustc 1.29.0-nightly (97085f9fb 2018-08-01)`  

Please let me know if there's anything I can do to be of assistance.

Here's a bash script that fully reproduces the issue:
```bash
#!/bin/bash

cargo +nightly new --lib demo_macros

cat >> demo_macros/Cargo.toml << EOF
[lib]
proc-macro = true
EOF

cat >| demo_macros/src/lib.rs << EOF
#![feature(rust_2018_preview)]
extern crate proc_macro;
use proc_macro::TokenStream;

#[proc_macro_attribute]
pub fn nop(_args: TokenStream, input: TokenStream) -> TokenStream {
  return input;
}
EOF

cargo +nightly init --lib .

echo 'demo_macros = { path = "demo_macros" }' >> Cargo.toml

cat >| src/lib.rs << EOF
#![feature(rust_2018_preview)]
extern crate demo_macros;
use demo_macros::nop;

#[nop]
pub struct Foo {
  #[nop]
  pub foo_field: u32,
}

#[nop]
impl Foo {
  #[nop]
  pub fn foo_fn() {}
}
EOF

cargo +nightly build
```
Repository: rust
Issue: Lint to use existential type when types mismatched on anonymized types(impl Trait)
Labels: C-enhancement,A-diagnostics,T-compiler

code snippet from @oli-obk 's slices in https://www.youtube.com/watch?v=ippwMSMLD5Q 
```rust
use std::fmt::Display;
fn foo() -> impl Display {
    42
}

fn bar() -> impl Display {
    99
}

fn main() {
    let mut x = foo();
    x = bar();
}
```
error:
```
error[E0308]: mismatched types
  --> src/main.rs:14:9
   |
14 |     x = bar();
   |         ^^^^^ expected anonymized type, found a different anonymized type
   |
   = note: expected type `impl std::fmt::Display` (anonymized type)
              found type `impl std::fmt::Display` (anonymized type)
```
Repository: rust
Issue: Tracking issue for comparing raw pointers in constants
Labels: T-lang,B-unstable,C-tracking-issue,A-const-eval,S-tracking-design-concerns,S-tracking-needs-summary

Comparing raw pointers in constants is forbidden (hard error) in const contexts. 
The `const_compare_raw_pointers` feature gate enables the `guaranteed_eq` and `guaranteed_ne` methods on raw pointers. The root problem with pointer comparisons at compile time is that in many cases we can't know for sure whether two pointers are equal or inequal. While it's fairly obvious that a pointer to a `static` and a local variable won't be equal, we can't ever tell whether two local variables are equal (their memory may alias at runtime) or whether any pointer is equal to a specific integer. In order to make it obvious that there is a discrepancy between runtime and compile-time, the `guaranteed_*` methods only return `true` when we can be sure that two things are (in)equal. At runtime these methods just return the result of the actual pointer comparison.

This permits `const fn` to do performance optimization tricks like the one done in slice comparison (if length is equal and pointer is equal, don't compare the slice contents, just return that it's equal).

Since we aren't sure yet what the semantics of functions that return different values at runtime and at compile-time are, we'll keep this function unstable until we've had that discussion.

### Unresolved questions

* should `guaranteed_eq` return an `Option<bool>` to allow the caller to know whether they got unclear results? What would the use-case for this be?
Repository: rust
Issue: checked_mul<i128> is slower than expected
Labels: A-LLVM,I-slow,T-compiler

checked_mul\<i128> is 200x slower than a normal multiply
checked_mul\<u128> is 10x slower than a normal multiply


Toolchain version according to rustup:
```
active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.30.0-nightly (7e8ca9f8b 2018-08-03)
```

benchmark:
```rust
#![feature(test)]

extern crate rand;
extern crate test;
extern crate trading_engine_rust;

use self::test::{black_box, Bencher};

#[bench]
fn plain_mul_i128(b: &mut Bencher) {
    // multiply two "random" vectors of length 100 to defeat the optimizer
    let left: Vec<i128> = (0..100).collect();
    let right: Vec<i128> = (1..101).collect();

    b.iter(||{
        for (left, right) in left.iter().zip(right.iter()) {
            black_box(left * right);
        }
    });
}

#[bench]
fn plain_mul_u128(b: &mut Bencher) {
    let left: Vec<u128> = (0..100).collect();
    let right: Vec<u128> = (1..101).collect();

    b.iter(||{
        for (left, right) in left.iter().zip(right.iter()) {
            black_box(left * right);
        }
    });
}

#[bench]
fn plain_mul_i64(b: &mut Bencher) {
    let left: Vec<i64> = (0..100).collect();
    let right: Vec<i64> = (1..101).collect();

    b.iter(||{
        for (left, right) in left.iter().zip(right.iter()) {
            black_box(left * right);
        }
    });
}

#[bench]
fn checked_mul_i128(b: &mut Bencher) {
    let left: Vec<i128> = (0..100).collect();
    let right: Vec<i128> = (1..101).collect();

    b.iter(||{
        for (left, right) in left.iter().zip(right.iter()) {
            black_box(i128::checked_mul(*left, *right).unwrap());
        }
    });
}


#[bench]
fn checked_mul_u128(b: &mut Bencher) {
    let left: Vec<u128> = (0..100).collect();
    let right: Vec<u128> = (1..101).collect();

    b.iter(||{
        for (left, right) in left.iter().zip(right.iter()) {
            black_box(u128::checked_mul(*left, *right).unwrap());
        }
    });
}

#[bench]
fn checked_mul_i64(b: &mut Bencher) {
    let left: Vec<i64> = (0..100).collect();
    let right: Vec<i64> = (1..101).collect();

    b.iter(||{
        for (left, right) in left.iter().zip(right.iter()) {
            black_box(i64::checked_mul(*left, *right).unwrap());
        }
    });
}
```

Sample benchmark output:
```
running 6 tests
test checked_mul_i128 ... bench:      27,858 ns/iter (+/- 3,258)
test checked_mul_i64  ... bench:          69 ns/iter (+/- 21)
test checked_mul_u128 ... bench:       1,548 ns/iter (+/- 221)
test plain_mul_i128   ... bench:         158 ns/iter (+/- 25)
test plain_mul_i64    ... bench:          71 ns/iter (+/- 3)
test plain_mul_u128   ... bench:         156 ns/iter (+/- 12)
```
Repository: flutter
Issue: Server Side Layout Definition
Labels: c: new feature,framework,would be a good package,P3,team-framework,triaged-framework

I'm thinking of dynamic layouts, which customer can change the layout of their application whenever they want to.

So I thought of a "**layout definition protocol**" using **json**.
The problem is with the **reflection support in flutter**.

LDP example

```
Map decodedJson = {
    "cname": "Text",
    "args": [
        "hello"
    ]
};

dynamic node;
if (decodedJson["cname"] == "Text") {
    String content = decodedJson["args"][0];
    node = new Text(content );
}
```

**Can you suggest better techniques other than code generation?**

example generated code:

```
ClassesTable = {
    "Text": _$Text
};

class _$Text {
    static Text build(j) {
        String data = j["args"][0];
        TextStyle style = _$TextStyle.build(j);
        TextDirection textDirection = _$TextDirection.build(j);
        ...
        
        return new Text(
            data,
            style: style,
            textDirection: textDirection,
            ...
        );
    }
}
```
Repository: TypeScript
Issue: Compiler API allow custom options in parseCommandLine/ConfigFile
Labels: Suggestion,Awaiting More Feedback

## Search Terms

parser options compiler api

## Suggestion

Add a way to pass additional custom options to the CLI Parser.

## Use Cases

We currently work on a tool transpiling Typescript to Lua.
This works by doing the type checking via the compiler API.
And then transpiling the AST to Lua instead of JS.

We want the user to pass typecheck options via CLI or a tsconfig file. Currently we do that by using `parseCommandLine` and `readConfigFile`/`parseJsonConfigFileContent ` which are both exposed by the compiler API. That way the user can use the Lua compiler in the same way he uses tsc.

The issue is that its hard to add custom options into the parse process because parseCommandLine reports an error if an option is invalid. Currently we just ignore errors if they were cause by our custom options but its not a really clean workaround. Same issue for `parseJsonConfigFileContent` for a workaround there we currently add the options outside `compilerOptions{}` e.g:
```
{
  "luaTarget": "5.1",
  "compilerOptions": {...}
}
```
This also is not real ideal for us.

We don't really want to write our own parser for all tsc options or use some 3rdparty CLI parser in addition to using parseCommandLine.
We also don't really want to use our  own typescript fork.

### Implementation

It would be ideal if we could just pass our own optionDeclarations based on `const optionDeclarations: CommandLineOption[]` or `OptionNameMap` to parseCommandLine and parseJsonConfigFileContent.

One possible way to to this is add a optional parameter to these function that contains an OptionMap and instead of getting the options via getOptionMap / getOptionFromMap that passed parameter would be used.

This would require to merge the additional options with the default options before passing them to the function. An alternative could be that the parameter only gets the additional options and merging is done inside the parser function, that way optionDeclarations would not need to be exposed.

In addition soem option related const/functions/enums might need to be expose.

TL;DR this could be implemented without changing any functionality and only refactoring `commandLineParser.ts`  a bit (EDIT: actually I think it would require a lot of refactoring).
I can also provide you with a PR.

## Examples

What we currently do:
https://github.com/Perryvw/TypescriptToLua/blob/master/src/CommandLineParser.ts

We could basically replace most of that with:

```
let typescriptToLuaOptions: OptionNameMap = {
  // our custom options
}
let commandLine = ts.parseCommandLine(args, typescriptToLuaOptions);
```

## 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)