sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Explore splitting foundation to a separate package without strict dependency on dart:ui
Labels: framework,customer: dream (g3),c: proposal,P2,team-framework,triaged-framework

Internal: b/128283067

See https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/foundation/README.md

We have a customer request to consume parts of Flutter's foundation pacage in a Dart isolate that isn't using Flutter - specifically to use ValueNotifier/ChangeNotifier.

Today there are only a small handful of dependencies on dart:ui in foundation, and we already know we want to get rid of them.  If we moved foundation to another package (in the flutter/flutter repo), we may be able to make dart:ui a conditional import so that we could define VoidCallback, hashValues, hashList, and lerpDouble pass through to dart:ui if it's available or define them in the foundation package otherwise.  The rest of flutter/flutter could take whatever is exported from the foundation package rather than from dart:ui

/cc @mehmetf @goderbauer @tvolkert @Hixie
Repository: go
Issue: x/build/cmd/coordinator: support builders that only run on subrepos
Labels: Builders,NeedsFix,mobile

It's currently not possible to configure a builder that only builds a subrepo(s) and not the "go" repo.

This is affecting `linux-amd64-androidemu` and `darwin-amd64-wikofever` which aren't building the `mobile` repo currently, despite being configured to do so.

Two reasons why they aren't:

* subrepos always wait for a make.bash snapshot (this should be conditional on "go" being configured to even run for that repo)
* because https://build.golang.org/ never populates the subrepo tables' columns with a builder name if it doesn't also show up in the top ("go") table. And the coordinator uses a json version of that same page (https://build.golang.org/?mode=json) to find work to do.

For the first, it should also be possible to say that a given builder can also use a built make.bash from a different builder. e.g. `linux-amd64-androidemu` can use a built make.bash tarball from `linux-amd64`.

/cc @eliasnaur @dmitshur
Repository: go
Issue: time: Parse behaves inconsistently when parsing numerical timezones with an "MST" format string
Labels: NeedsDecision

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

Local machine:
<pre>
$ go version
go version go1.12 darwin/amd64
</pre>

Docker container:
<pre>
$ go version
go version go1.12 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
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/nmooney/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/nmooney/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12/libexec/pkg/tool/darwin_amd64"
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/vv/t3z4pbwn3pd36hm89fg1m8jc0000gn/T/go-build118701068=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

[Go Playground example here.](https://play.golang.org/p/XXspq1f7WXw)

I attempted to use the `time.Parse` format string `"Mon, 2 Jan 2006 15:04:05 MST"` to parse the date `"Tue, 12 Mar 2019 15:34:39 -0000"`.

### What did you expect to see?

I would expect `time.Parse` to fail to parse the string, since it's suffixed with `-0000` rather than an alphabetical time zone designator.

This behaves correctly when I try to parse a date with a non-zero offset, such as `"Tue, 12 Mar 2019 15:34:39 -0700"` (i.e. parsing fails).

### What did you see instead?

`time.Parse` successfully parses date strings with TZ offsets of zero given a format string that ends with `MST`, when it should likely fail if there is no alphabetical timezone designator.
Repository: flutter
Issue: We've introduced new dependencies on dart:ui in foundation
Labels: framework,dependency: dart,P2,team-framework,triaged-framework

https://github.com/flutter/flutter/pull/25594 and https://github.com/flutter/flutter/pull/27389 introduced new dependencies on `dart:ui` into `flutter/foundation`.

We need to either update https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/foundation/README.md if this is really ok, or move that code out of foundation.

/cc @sbaranov @matthew-carroll @goderbauer

Related: #29230
Repository: TypeScript
Issue: Allow type assertions to consider typed index signatures
Labels: Suggestion,In Discussion

## Search Terms

interface, index, signature, typed, assertion, conversion, partial,

## Suggestion

Currently type assertions do not seem to respect typed index signatures `[key: string]: any;` in interfaces or test for compatibility before attempting to convert.

I am proposing that type assertions would be able to convert this situation without error:
```ts
interface Test {
	a: string;
	b?: string;
	[key: string]: any;
}

const a = {b: 'b', c: 3 } as Test;
```  

## Use Cases

Currently to work around this I need to first create an intermediate variable that is typed as a Partial before making the assertion.  I would prefer to just make the assertion.

## Examples
This example above will error because `{b: 'b', c: 3 }` is missing property `a`
```ts
interface Test {
	a: string;
	b?: string;
	[key: string]: any;
}

const a = {b: 'b', c: 3 } as Test;
```  
[playground](https://www.typescriptlang.org/play/#src=interface%20Test%20%7B%0D%0A%09a%3A%20string%3B%0D%0A%09b%3F%3A%20string%3B%0D%0A%09%5Bkey%3A%20string%5D%3A%20any%3B%0D%0A%7D%0D%0A%0D%0Aconst%20a%20%3D%20%7Bb%3A%20'b'%2C%20c%3A%203%20%7D%20as%20Test%3B)

If I remove `c: 3` from the object then there is no error and `a` is no longer required:
```ts
interface Test {
	a: string;
	b?: string;
	[key: string]: any;
}

const a = {b: 'b' } as Test;
```
[playground](https://www.typescriptlang.org/play/#src=interface%20Test%20%7B%0D%0A%09a%3A%20string%3B%0D%0A%09b%3F%3A%20string%3B%0D%0A%09%5Bkey%3A%20string%5D%3A%20any%3B%0D%0A%7D%0D%0A%0D%0Aconst%20a%20%3D%20%7Bb%3A%20'b'%20%7D%20as%20Test%3B)

Currently to workaround this an intermediate **typed** value can be used so the subtype is already confirmed before the assertion:

```ts
interface Test {
	a: string;
	b?: string;
	[key: string]: any;
}

const test: Partial<Test> = { b: 'b', c: 3 };
const a = test as Test
```
[playground](https://www.typescriptlang.org/play/#src=interface%20Test%20%7B%0D%0A%09a%3A%20string%3B%0D%0A%09b%3F%3A%20string%3B%0D%0A%09%5Bkey%3A%20string%5D%3A%20any%3B%0D%0A%7D%0D%0A%0D%0Aconst%20test%3A%20Partial%3CTest%3E%20%3D%20%7B%20b%3A%20'b'%2C%20c%3A%203%20%7D%3B%0D%0Aconst%20a%20%3D%20test%20as%20Test%3B)

## 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: pytorch
Issue: JIT torch.ones_like with dtype starts failing on master
Labels: oncall: jit

## 🐛 Bug

Similar symptom to #15478, when using `torch.jit.script`, calling `torch.ones_like()` with dtype starts to give errors while previously it works.

## To Reproduce

```python
import torch

@torch.jit.script
def test_ones_like(x):
    return torch.ones_like(x, dtype=torch.int64)

test_ones_like(torch.zeros(4, 5))
```
Run with `PYTORCH_JIT=0 python ones_like_test.py` works fine. `PYTORCH_JIT=1 python ones_like_test.py` gives error
```
RuntimeError: 
arguments for call are not valid:
  
  for operator aten::ones_like(Tensor self) -> Tensor:
  keyword argument dtype unknown
  
  for operator aten::ones_like(Tensor self, *, int dtype, int layout, Device device) -> Tensor:
  argument layout not provided.
  @torch.jit.script
  def test_ones_like(x):
      return torch.ones_like(x, dtype=torch.int64)
             ~~~~~~~~~~ <--- HERE
for call at:
@torch.jit.script
def test_ones_like(x):
    return torch.ones_like(x, dtype=torch.int64)
           ~~~~~~~~~~ <--- HERE
```
## Expected behavior

Should not throw error.

## Environment

Collecting environment information...
PyTorch version: 1.1.0a0+ba06fa3
Is debug build: Yes
CUDA used to build PyTorch: 10.0.130

OS: Ubuntu 16.04.5 LTS
GCC version: (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609
CMake version: version 3.12.2

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: GeForce GTX 1070
Nvidia driver version: 410.78
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.7.4.1
/usr/local/cuda-10.0/lib64/libcudnn.so.7

Versions of relevant libraries:
[pip] numpy==1.15.4
[pip] torch==1.1.0a0+ba06fa3
[conda] blas                      1.0                         mkl  
[conda] mkl                       2018.0.3                      1  
[conda] mkl_fft                   1.0.6            py37h7dd41cf_0  
[conda] mkl_random                1.0.1            py37h4414c95_1  
[conda] torch                     1.1.0a0+ba06fa3           <pip>
Repository: pytorch
Issue: [caffe2] resize_op_test.py::TestResize::test_nearest FAILED
Labels: caffe2

## 🐛 Bug
resize_op_test.py::TestResize::test_nearest FAILED

## To Reproduce 

Steps to reproduce the behavior:
Decorate the function test_nearest in resize_op_test.py with:
```
    @reproduce_failure('3.59.1', 'AAMBGgDn8sXqhzzgA2trGwBu+/hbaVU5')
```
```
example: 
from hypothesis import reproduce_failure

class TestResize(hu.HypothesisTestCase):
    @reproduce_failure('3.59.1', 'AAMBGgDn8sXqhzzgA2trGwBu+/hbaVU5')
    @given(height_scale=st.floats(0.25, 4.0) | st.just(2.0),
           width_scale=st.floats(0.25, 4.0) | st.just(2.0),
           height=st.integers(4, 32),
           width=st.integers(4, 32),
           num_channels=st.integers(1, 4),
           batch_size=st.integers(1, 4),
           seed=st.integers(0, 65535),
           **hu.gcs)
    def test_nearest(self, height_scale, width_scale, height, width,
                     num_channels, batch_size, seed,
                     gc, dc):
```

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->
the gradient data calculated apears to be the same on both x86 and ppc
log of test failure from x86 system
[results.txt](https://github.com/pytorch/pytorch/files/2958366/results.txt)
log of test failure from ppc64le system
[results.ppc64le.txt](https://github.com/pytorch/pytorch/files/2958695/results.ppc64le.txt)

## Expected behavior

<!-- A clear and concise description of what you expected to happen. -->
The test should pass

## Environment
The failure is seen on both:

- ppc64le / CUDA 10.1 / NVIDIA V100 GPU / Driver Version 418 / RHEL 7.6
   GPU models and configuration:
   GPU 0: Tesla V100-SXM2-16GB 
   GPU 1: Tesla V100-SXM2-16GB
   GPU 2: Tesla V100-SXM2-16GB
   GPU 3: Tesla V100-SXM2-16GB

- x86 / CUDA 10.1 / NVIDIA P100 GPU/ Driver version 418 /Ubuntu 18.04
  GPU models and configuration:
  GPU 0: Tesla P100-PCIE-16GB
  GPU 1: Tesla P100-PCIE-16GB

## Additional context

<!-- Add any other context about the problem here. -->
Repository: godot
Issue: Implement additional indentation for line breaking when word wrap is on
Labels: enhancement,usability,topic:gui

**Godot version:**
3.1 rc2

**OS/device including version:**
Windows 10 x64

**Issue description:**
When word wrap option in on, the line breaking put the broken part left aligned with the starting line:
![image](https://user-images.githubusercontent.com/11199752/54235851-f5e86a00-44f0-11e9-9979-f5c4d2d0ef83.png)

This is not aesthetically good and can lead to confusion in reading the code.
It would be best to insert an additional indentation for the broken parts, thus differentiating them from the first line:
![image](https://user-images.githubusercontent.com/11199752/54235896-131d3880-44f1-11e9-892a-ab9727748c1f.png)
Repository: rust
Issue: E0587 error on packed and aligned structures from C
Labels: C-enhancement,A-diagnostics,A-FFI,T-lang,T-compiler,A-repr-packed

When converting C structures that are both packed and aligned using either C2Rust or bindgen, such as:
```C
struct xregs_state {
	struct fxregs_state		i387;
	struct xstate_header		header;
	u8				extended_state_area[0];
} __attribute__ ((packed, aligned (64)));
```
the code that either tool produces looks something like:
```Rust
#[repr(C, packed(64))]
#[repr(align(64))]
pub struct xregs_state {
    pub i387: fxregs_state,
    pub header: xstate_header,
    pub extended_state_area: __IncompleteArrayField<u8>,
}
```

This Rust code fails to compile due to error `E0587`:
```
error[E0587]: type has conflicting packed and align representation hints
    --> .../out/bindings.rs:3894:1
     |
3894 | / pub struct xregs_state {
3895 | |     pub i387: fxregs_state,
3896 | |     pub header: xstate_header,
3897 | |     pub extended_state_area: __IncompleteArrayField<u8>,
3898 | | }
     | |_^
```

We can work around this in C2Rust by emitting an aligned outer/packed inner structure pair (I think bindgen could do the same), but I'm wondering if it would be better to fix this on the Rust language/compiler side.
Repository: vue
Issue: Performance: Include/Use uid in the name when using performance.measure
Labels: improvement

### What problem does this feature solve?
This is in regards when Vue.config.performance is set to true. 
When there is multiple components of the same name, it is difficult to distinguish which component coincide to which performance information.

One simple use case is rendering components inside a v-for.

### What does the proposed API look like?
Instead of just using name (Vue._name), I suggest to include the _uid to better distinguish components with the same name

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: flutter
Issue: Feature Request : Google Map Navigation & Best Route Package/Plug-in
Labels: c: new feature,p: maps,package,c: proposal,team-ecosystem,P3,triaged-ecosystem

I wonder if flutter support google map navigation and also best route? If it can be integrate into Flutter, I looking forward for that package/plug-in and tutorial.

Thank you :)
Repository: flutter
Issue: No documentation for uninstalling Flutter on Windows
Labels: tool,platform-windows,d: api docs,P3,team-tool,triaged-tool

 I want to remove or uninstall flutter from my windows 10 system
Repository: pytorch
Issue: torch.cuda.is_available()  returns misleading value
Labels: module: cuda,triaged,module: ux

Using pytorch version 1.0.0 on python 3.6.8 on a machine with a NVIDIA GF108 GeForce GT630 GPU.

On this machine torch.cuda.is_available() returns True, but then a warning is shown ("PyTorch no longer supports this GPU because it is too old.") and eventually the attempt to use it generates an exception:

```
    ret = torch.addmm(torch.jit._unwrap_optional(bias), input, weight.t())
RuntimeError: CUDA error: no kernel image is available for execution on the device
```
It seems useless for the function to report that CUDA can be used whan in fact, it cannot. 
This function should clearly reflect if CUDA is actually usable, not just "available" or a function should get added which does that. 


cc @ngimel
Repository: flutter
Issue: Navigator.pushNamedAndRemoveUntil ，The phone may have a black screen
Labels: c: new feature,framework,f: material design,f: routes,c: proposal,P3,team-design,triaged-design

I am using MOTO Phone to test , when I use Navigator.pushNamedAndRemoveUntil api to remove all the routes , and then new screen use Navigator.pop  or backspace key , The phone went black screen.

flow:
1. screen_1 => Navigator.of(context).pushNamed("/screen_1");
2. screen_2 => Navigator.of(context).pushNamed("/screen_2");
3. screen_3 => Navigator.of(context).pushNamedAndRemoveUntil("/screen_4",(Route<dynamic> route) => false);
4. screen_4 => Navigator.of(context).pop();

```
class RouteDemoApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'RouteDemo',
      theme: ThemeData(
        primaryColor: Colors.redAccent,
      ),
      home: RouteUserDemo(),
      routes: <String, WidgetBuilder>{
        '/screen1': (BuildContext context) => new Screen1(),
        '/screen2': (BuildContext context) => new Screen2(),
        '/screen3': (BuildContext context) => new Screen3(),
        '/screen4': (BuildContext context) => new Screen4(),
      },
    );
  }
}
```
Repository: TypeScript
Issue: `importHelpers` generates code, that is incompatible with browsers
Labels: Suggestion,Awaiting More Feedback

Currently enabling `importHelpers` adds
```
import * as tslib_1 from "tslib";
```
at the top of every source file.

Such notation is not compatible with browsers. Nowadays, all modern browsers supports Ecma modules, there's no reason for writing code that assumes Node.js environment + bundler build. Code should assume ["Ecma modules" environment](https://www.bryntum.com/blog/writing-isomorphic-tests-with-siesta-5-2-0/) instead. And bundlers can stop being compilers and do the work they are supposed to do - create _optimized_ builds (if needed at all).

The change is simple, `importHelpers` should generate:
```
import * as tslib_1 from "../../../node_modules/tslib/index.js";
```
The path to "node_modules" should be determined at compile time of course.
Repository: opencv
Issue: VideoCapture::read() returns success when camera disconnected
Labels: bug,category: videoio(camera),incomplete,platform: win32,needs investigation

##### System information (version)

- OpenCV => 4.0.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2017

##### Detailed description

The app is reading camera and camera is unplugged during the run of the app, the first time it returns false and empty frame, but the second time it returns success and a not empty frame. My desire was to handle cheap cameras which can deliver empty frames. I would expect to get false and empty frame even for further read calls.

##### Steps to reproduce
...
m_camera.open(0);
bool success=m_camera.read(m_originalFrame);
    if(!success || m_originalFrame.empty())
    {
        success=m_camera.read(m_originalFrame);
        if(!success || m_originalFrame.empty())
        {
          m_camera.release();
...
Repository: three.js
Issue: feature request: transform origin (or "pivot point")
Labels: Enhancement

##### Description of the problem

As an example, Babylon has this feature built in, called [pivot points](https://doc.babylonjs.com/how_to/pivots). CSS has it in the form of the [`transform-origin` property](https://developer.mozilla.org/en-US/docs/Web/CSS/transform-origin).

These features enable rotation about a pivot point with a one-liner.

Here's an implementation idea: https://jsfiddle.net/mmalex/hd8ex0ok/ (thanks @nmalex).

I believe ideally this would be implemented inside `Matrix4`, and the `Matrix4.compose( position, quaternion, scale )` signature would be changed to `Matrix4.compose( position, quaternion, scale[, origin] )`, with the `origin` parameter being optional for backwards compatibility.

An `origin` property would be added to `Object3D`, so that we can for example write `object.origin.set(1,2,3)`.

`updateMatrixWorld` would then call `this.matrix.compose( this.position, this.quaternion, this.scale, this.origin )`.

Just bike shedding, but `pivot` could also be another name in place of `origin`, but I like `origin` better because "pivot" doesn't seem to align with "scale" (I'm thinking that `scale` would also happen about the `origin`).

##### Three.js version

- [x] Dev
- [ ] r102
- [ ] ...

##### Browser

- [x] All of them
- [ ] Chrome
- [ ] Firefox
- [ ] Internet Explorer

##### OS

- [x] All of them
- [ ] Windows
- [ ] macOS
- [ ] Linux
- [ ] Android
- [ ] iOS

##### Hardware Requirements (graphics card, VR Device, ...)

N/A
Repository: godot
Issue: Viewport display modes not working in GLES 2
Labels: bug,topic:rendering,topic:editor,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if non-official. -->
3.1

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Pop OS 18.10/ NVIDIA GeForce 920MX

**Issue description:**
<!-- What happened, and what was expected. -->
when you try to change the viewport render mode to something like wireframe with the gles 2 renderer nothing happens
![Screenshot from 2019-03-13 19-08-37](https://user-images.githubusercontent.com/47189897/54300196-079b4180-45c5-11e9-8ea7-30e0fe619a08.png)


when i tried it in gles 3 it worked fine
![Screenshot from 2019-03-13 19-24-26](https://user-images.githubusercontent.com/47189897/54300492-a758cf80-45c5-11e9-8416-af9aa3ef5a0d.png)


**Steps to reproduce:**
create a new project
switch to gles 2
add a mesh instance
change the viewport display mode to wireframe, overdraw, unshaded.
Repository: pytorch
Issue: "unknown builtin op" error with static library
Labels: module: cpp,triaged

Getting error while running libtorch example from https://pytorch.org/tutorials/advanced/cpp_export.html . Getting error only with static library. Shared library works fine. 

```
./libtorch_test model.pt
terminate called after throwing an instance of 'torch::jit::script::ErrorReport'
  what():
unknown builtin op:

def mul(a : float, b : Tensor) -> Tensor:
  return b * a
         ~~~~~ <--- HERE
def add(a : float, b : Tensor) -> Tensor:
  return b + a
def ne(a : float, b : Tensor) -> Tensor:
  return b != a
def eq(a : float, b : Tensor) -> Tensor:
  return b == a
def lt(a : float, b : Tensor) -> Tensor:
  return b > a
def le(a : float, b : Tensor) -> Tensor:
Aborted (core dumped)
```

Command used to compile libtorch_test
```
LIBTORCH = /pytorch/torch/lib/tmp_install

g++ -I"$LIBTORCH/include" -I"$LIBTORCH/include/torch/csrc/api/include" -D_GLIBCXX_USE_CXX11_ABI=0 -std=gnu++11 libtorch_test.cpp -o libtorch_test -L"$LIBTORCH/lib"  -ltorch -lcaffe2  -lc10 -lc10d -lTHD -fopenmp -lpthread -lrt -lm -lsleef  -llapack -lblas -lcpuinfo -lclog -lprotobuf -lonnx -lonnx_proto -lcaffe2_protos 
```

## Environment

 - PyTorch Version:  1.0.1:
 - OS: Redhat Linux:
 - Build command: 
`EXTRA_CAFFE2_CMAKE_FLAGS="-DTORCH_STATIC=1 -DBUILD_SHARED_LIBS=OFF -DUSE_CUDA=0" python ../tools/build_libtorch.py`
 

cc @yf225