sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Re-evaluate "use precise math checks" epsilon size
Labels: discussion,topic:core

These lines were added in a32b26dfa26f2a039bf9c84b90d10666bcf785c9 "Several fixes to make GLES2 on HTML5 work much better".

https://github.com/godotengine/godot/blob/ed9a0d0484411e631b0cc927e46dc234054d5ae5/core/math/math_defs.h#L53-L59

I don't think that this code makes sense as-is. With single-precision floats, a good unit epsilon size is `1e-6` (or `1e-5` if you're really paranoid). The above code means that the default value for `UNIT_EPSILON` is `1e-3` when it really could be a lot smaller. Also, with `use_precise_math_checks=yes` the value is `1e-5` which isn't even all that precise since it could be `1e-6`.

I think, instead of defaulting to `1e-3` and allowing the user to enable "precise math checks", we should default to either `1e-5` or `1e-6`, and then we can change it for other platforms like HTML5 if there are number precision issues there.
Repository: TypeScript
Issue: new Map() infers type only from the first item in the iterable
Labels: Needs Investigation

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
Please try to reproduce the issue with 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.3

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** map infer type first item

**Code**

```ts
type Lookup = Map<number, boolean | string>;

const foo = new Map([
    [1, true],
    [2, 'foo']
]);

const bar: Lookup = new Map([
    [1, true],
    [2, 'foo']
]);

const baz: Lookup = new Map<number, boolean | string>([
    [1, true],
    [2, 'foo']
]);
```

**Expected behavior:** All 3 assignments work.

**Actual behavior:** The first 2 assignments fail because the type of the map is inferred as `Map<number, () => boolean>` (because of the first item). The 3rd one works but duplicates the type of the map.

[**Playground Link**](https://www.typescriptlang.org/play#code/C4TwDgpgBAMg9nA1gVzFAvFAsgQzAHgDtkBbAIwgCcAaKMhAGwh0KgB8oBnYSgS0IDmAPgDcAKDEBjOIW5QAZggxRCEAO7Y8ACgDaYqAag6AjLR7IIAXWr7DOgEy0A5IrhPLYywEpxUmXLIcSgAuWAQUNExVDVwwXVsDEzNKC2sEo0coFwR3Tx8JaVlgOhwAL1D4JFRlaM0CYnIqWno4JhZ2Lh5+YXjDI1MocysbPodnV1zvESA)
Repository: pytorch
Issue: The BatchNorm error in `DataParallel`
Labels: module: nn,triaged,module: data parallel

`https://github.com/open-mmlab/mmdetection/issues/2312`
I debug this error. I set breakpoint in 
```
# /opt/anaconda3/lib/python3.7/site-packages/torch/nn/parallel/parallel_apply.py
            with torch.cuda.device(device):
                # this also avoids accidental slicing of `input` if it is a Tensor
                if not isinstance(input, (list, tuple)):
                    input = (input,)
                output = module(*input, **kwargs) # breakpoint
            with lock:
                results[i] = output
```
I found that the parameters and buffer in `cuda:1` and the input in `cuda:1`. I wonder that when the program exec to `/opt/anaconda3/lib/python3.7/site-packages/torch/nn/modules/batchnorm.py`
The parameters and buffer of batchnorm in `cuda:0` and the input in `cuda:1`.
And only batchnorm have this error, I delete batchnorm in model. The program can run.
Repository: vscode
Issue: Should we use namespacing in the CLI
Labels: feature-request,under-discussion,workbench-cli

@Microsoft/vscode

https://github.com/microsoft/vscode/issues/92031 is requesting a terminal CLI to enable things like creating a new tab and splitting the current tab which would align with the capabilities of many terminals (including [Windows Terminal](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingCommandlineArguments.md#using-the-wtexe-commandline)) and enable splitting a terminal tab by running a command in the terminal.

Does anyone have opinions for or against this? If we want to go with this I think we should also do the same for extensions by deprecating/aliasing the current CLI and moving them to either `code ext ...` or `code extension ...` as it keeps growing and could be better organized:

```
Extensions Management
  --extensions-dir <dir>                            Set the root path for
                                                    extensions.
  --list-extensions                                 List the installed
                                                    extensions.
  --show-versions                                   Show versions of installed
                                                    extensions, when using
                                                    --list-extension.
  --category                                        Filters installed
                                                    extensions by provided
                                                    category, when using
                                                    --list-extension.
  --install-extension <extension-id | path-to-vsix> Installs or updates the
                                                    extension. Use `--force`
                                                    argument to avoid
                                                    prompts.
  --uninstall-extension <extension-id>              Uninstalls an extension.
  --enable-proposed-api <extension-id>              Enables proposed API
                                                    features for extensions.
                                                    Can receive one or more
                                                    extension IDs to enable
                                                    individually.
```
Repository: flutter
Issue: Flutter should include popover as part of the default widget library
Labels: c: new feature,framework,a: tablet,f: routes,would be a good package,c: proposal,P3,team-framework,triaged-framework

Flutter should include popovers as part of the default widget library.

It would be good to have an option to select what direction the popover opens in as well as allowing anything the user wants in the popover. On iOS the popovers have a blur background.

iOS: https://developer.apple.com/design/human-interface-guidelines/ios/views/popovers/
Web: https://getbootstrap.com/docs/4.0/components/popovers/
Repository: pytorch
Issue: Get hold of Backward graph from a C++ module.
Labels: oncall: jit

Hi Guys
@huzecong  @ezyang @gqchen @albanD 
Is there a way we could get hold of Backward Graph in C++ code .

We have a custom FPGA and asic & we would like to perform training on a multi-chips HW asics, they are similar to nvidia GPU's and we would like to interconnect them the way nvidia DGZ servers do  and want to run training on them, For the inference part we are able  use a Glow backend for Pytorch. This backend doesn't seems to have enough support for training as of now and in particular Gradient Accumlation and exchange across devices and loss functions.
and Pytorch seems to have an extensive support for CUDA.

 (https://github.com/pytorch/glow/blob/master/torch_glow/src/Registration.cpp)
This backend has a python binding and gets hold of Pytorch JIT IR for the forward graph and converts the JIT Graph Nodes to its own internal representation of the Glow nodes and it performs its own differentiate() to generate a differential graph which kind of contains both the forward graph and backward graph (integrated together) but it does not has the way to provide access to backward graph .

To me seems to me that pytorch has different forward graph and a backward graphs and it looks pretty elaborate with many optimizers.

So essentially could there be a way to get hold of backward graph from a C++ module (from glow backend iteslf ) so that I can generate the ONNX/glow nodes from it and create a Graph which can be run on our HW. 
Looks like the Back Graph does not has a JIT IR , Essentially I am looking for some sample code , where I can visit the Nodes and edges of the Graph but I need some more concrete example.
. Although I did see that there seem to be some test cases cpp folder of   pytorch/test/cpp/jit/test_autodiff.cpp  api/autograd.cpp  which can be used .

If you guys can get me some pointer and direction to the sample code that would help a lot.

Looks like there is way to iterate over backward nodes from python using 
 https://github.com/szagoruyko/pytorchviz 

![pytroch_mlp_backward_graph](https://user-images.githubusercontent.com/61411073/77338968-1b898f80-6d51-11ea-8c6d-ad43a8087738.png)

I was reading the article of ezyang from http://blog.ezyang.com/2019/05/pytorch-internals/
and found that we  need something on lines of attached below pic where multi devices are communicating using scatter all reduce. 
![eyzang_grad_calc_5](https://user-images.githubusercontent.com/61411073/77339374-a8cce400-6d51-11ea-9c59-ef3a2af3f942.png)

![data_parrallel_pytorch](https://user-images.githubusercontent.com/61411073/77339856-6d7ee500-6d52-11ea-8551-36a729266171.png)

Essentially there should be some way to route torch.nn.DataParallel() and torch.nn.parallel.DistributedDataParallel() API's to Glow module to get access to gloo/nccl C++ modules inside pytorch way it gets access to JIT IR.





cc @suo
Repository: go
Issue: x/tools/gopls: support change signature refactoring
Labels: FeatureRequest,gopls,Tools,Refactoring

See https://github.com/microsoft/vscode-go/issues/3122 for the original request.

> **Is your feature request related to a problem? Please describe.**
> I use IntelliJ and VS Code - both for development. VS Code usually for my open source contributions. I noticed that IntelliJ has this cool feature to change the definition / signature of a method or a function - where one can change the parameter's type, add a parameter with a default value for all the callers, and change the return parameters too
> 
> **Describe the solution you'd like**
> VS Code to provide the feature to change the definition / signature of a method or function, which changes all the references of the method or function based on the change
> 
> **Describe alternatives you've considered**
> Some features of the change signature feature can still be used currently - For example changing the name of the parameters - which will only cause a change inside the method or function and it can be done by doing just a rename. Other than that, the only alternate solution for me now is - to find all the references and change all the callers to add a parameter and do something similar for other things too.
> 
> **Additional context**
> It would be cool for VS code to provide this feature. Not sure how it will be implemented. Is this a feature that should be provided by `gopls`? And if help is needed, I can pitch in - raise some PRs. I need to learn some stuff, which I can surely do. It would be a pleasure to raise PR for one of the greatest extensions for Golang 😄
Repository: rust
Issue: Print comments in MIR dumps aligned to the longest line
Labels: A-pretty,C-enhancement,T-compiler,A-MIR

The comments in the following snippet should be aligned, otherwise they are hard to read, especially in larger blocks with lots of indentation changes.

```
        StorageLive(_1);                 // bb0[0]: scope 0 at $DIR/const_allocation.rs:8:5: 8:8
        StorageLive(_2);                 // bb0[1]: scope 0 at $DIR/const_allocation.rs:8:5: 8:8
        _2 = const {alloc0+0: &&[(std::option::Option<i32>, &[&str])]}; // bb0[2]: scope 0 at $DIR/const_allocation.rs:8:5: 8:8
```
Repository: rust
Issue: Constants in MIR dumps are too verbose
Labels: A-pretty,C-enhancement,T-compiler,A-MIR

As an example take

```
        _2 = const {alloc0+0: &&[(std::option::Option<i32>, &[&str])]}; // bb0[2]: scope 0 at $DIR/const_allocation.rs:8:5: 8:8
                                         // ty::Const
                                         // + ty: &&[(std::option::Option<i32>, &[&str])]
                                         // + val: Value(Scalar(alloc0+0))
                                         // mir::Constant
                                         // + span: $DIR/const_allocation.rs:8:5: 8:8
                                         // + literal: Const { ty: &&[(std::option::Option<i32>, &[&str])], val: Value(Scalar(alloc0+0)) }
```

We should trim some of that away and consider printing terminators in a multiline block format so multiple constants occurring in them are printed in a readable way
Repository: flutter
Issue: `flutter pub run build_runner build` loses interactive prompts
Labels: c: new feature,tool,has reproducible steps,P3,found in release: 2.5,found in release: 2.6,team-tool,triaged-tool

I have a project that uses `built_value` with `build_runner`.  If I do:

1. `flutter clean`
2. `flutter pub get`
3. `flutter pub run build_runner build`

I get an error:

> [INFO] Checking for unexpected pre-existing outputs....
> [INFO] Found 2 declared outputs which already exist on disk. This is likely because the`.dart_tool/build` folder was deleted, or you are submitting generated files to your source repository.
> [SEVERE] Conflicting outputs were detected and the build is unable to prompt for permission to remove them. These outputs must be removed manually or the build can be run with `--delete-conflicting-outputs`. The outputs are: foo.g.dart
> bar.g.dart
> pub finished with exit code 78

If I run `pub run builder_runner build` without going through `flutter`, I instead get a prompt:

> [INFO] Checking for unexpected pre-existing outputs....
> [INFO] Found 2 declared outputs which already exist on disk. This is likely because the`.dart_tool/build` folder was deleted, or you are submitting generated files to your source repository.
> 
> Delete these files?
> 1 - Delete
> 2 - Cancel build
> 3 - List conflicts

It would be nice if running `pub` through `flutter` showed the same prompt.
Repository: flutter
Issue: ctrl-c in the middle of a flutter tool build leaves cache in bad state tool can't recover from
Labels: tool,a: first hour,P2,team-tool,triaged-tool

I think what I did was:

1. Changed branch on the flutter sdk repo
2. Invoked the tool, which wiped out the cache
3. Before it could finish downloading, I aborted the process with ctrl-c.

```
~/git/flutter-app$ flutter analyze
Building flutter tool...
/Users/fujino/bin/flutter: line 46: /Users/fujino/git/flutter/bin/cache/dart-sdk/bin/pub: No such file or directory
Error: Unable to 'pub upgrade' flutter tool. Retrying in five seconds... (9 tries left)
```
Repository: rust
Issue: rustc compiles function that is never used
Labels: A-trait-system,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.
-->

`rustc` seems to compile never used functions in traits:
```rust
// Note: both trait and fn are private and never used
trait NeverUsed {
    fn never_used();
}

impl NeverUsed for () {
    fn never_used() {
        size_expectation_failed()
    }
}

fn size_expectation_failed() -> ! {
    panic!("size of `slice` must not be less than size of `Self` to ref cast to success")
}
```
Generates a lot of "panic" asm ([godbolt](https://godbolt.org/z/8ksG7P)).

I expected not to see unused functions in asm, but they are there.

This also happens when using lib with a similar (never used) trait.

## Steps to reproduce
1. create `lib` and `bin` crates:
   `cargo new --bin neverbin && cargo new --lib neverlib`
2. fill `./neverlib/src/lib.rs` with: 
   ```rust
   trait NeverUsed { 
       fn never_used(); 
   } 

   impl NeverUsed for () { 
       fn never_used() { 
           call_panic() 
       } 
   } 
   
   fn call_panic() { panic!(\"ooops\") }
   ```
3. add dependency to bin crate:
   ```toml
    # Cargo.toml
   [dependencies]
   neverlib = { path = "../neverlib" }
   ```
4. [install](https://github.com/gnzlbg/cargo-asm#install) & run `cargo asm` for bin crate, you'll see something like that:
   ```console
   $ cargo asm
   <() as neverlib::NeverUsed>::never_used
   <T as core::any::Any>::type_id
   <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
   <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::take_box
   core::ops::function::FnOnce::call_once{{vtable.shim}}
   core::ptr::drop_in_place
   neverbin::main
   neverlib::call_panic
   std::panicking::begin_panic
   std::rt::lang_start
   std::rt::lang_start::{{closure}}
   ```
5. Note `never_used` and `call_panic` functions, all the `panic!` stuff
6. this behaviour also holds with lto

### 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.
-->

`rustc --version --verbose`:
```
rustc 1.43.0-nightly (564758c4c 2020-03-08)
binary: rustc
commit-hash: 564758c4c329e89722454dd2fbb35f1ac0b8b47c
commit-date: 2020-03-08
host: x86_64-unknown-linux-gnu
release: 1.43.0-nightly
LLVM version: 9.0
```

### P.S.

I may misunderstand something, and maybe I've forgot to turn on some optimizations, so correct me if I'm wrong. But this behaviour seems _strange_.
Repository: pytorch
Issue: Raspberry Pi Zero build fails
Labels: module: build,triaged

## 🐛 Bug

Cannot build from source on Raspberry Pi Zero 1.3

## To Reproduce

Steps to reproduce the behavior:

1. Install prequisite packages
2. Clone GitHub respository to local folder
3. Export flags for build
```
export USE_CUDA=OFF
export USE_DISTRIBUTED=OFF
export USE_MKLDNN=OFF
export USE_NNPACK=OFF
export USE_QNNPACK=OFF
```
4. Ran the following command from the source folder:
`python3 setup.py build`
<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

Encountered the following error message at the 12% mark when:
```
[ 12%] Building C object confu-deps/pthreadpool/CMakeFiles/pthreadpool.dir/src/threadpool-pthreads.c.o
In file included from /home/pi/projects/pytorch/build/confu-srcs/pthreadpool/src/threadpool-pthreads.c:35:
/home/pi/projects/pytorch/build/confu-srcs/pthreadpool/include/pthreadpool.h:183:2: warning: ‘pthreadpool_function_1d_t’ is deprecated [-Wdeprecated-declarations]
  pthreadpool_function_1d_t function,
```


```
/tmp/ccAfk6Hs.s:2530: Error: immediate expression requires a # prefix -- `orr r3,0x1000000'
make[2]: *** [confu-deps/pthreadpool/CMakeFiles/pthreadpool.dir/build.make:76: confu-deps/pthreadpool/CMakeFiles/pthreadpool.dir/src/threadpool-pthreads.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:517: confu-deps/pthreadpool/CMakeFiles/pthreadpool.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
Traceback (most recent call last):
  File "setup.py", line 759, in <module>
    build_deps()
  File "setup.py", line 311, in build_deps
    cmake=cmake)
  File "/home/pi/projects/pytorch/tools/build_pytorch_libs.py", line 59, in build_caffe2
    cmake.build(my_env)

```
## Expected behavior

Build should completion should be 100%.

## Environment

Please copy and paste the output from our
[environment collection script](https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py)
(or fill out the checklist below manually).
```
pi@raspbari3:~/projects/pytorch $ python3 collect_env.py
Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A

OS: Raspbian GNU/Linux 10 (buster)
GCC version: (Raspbian 8.3.0-6+rpi1) 8.3.0
CMake version: version 3.13.4

Python version: 3.7
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect

Versions of relevant libraries:
[pip3] numpy==1.16.2
[conda] Could not collect
```

You can get the script and run it with:
```

```

 - PyTorch Version (e.g., 1.0):
 - OS (e.g., Linux): Raspbian (Debian) Buster
 - How you installed PyTorch (source): **git clone**
 - Build command you used (if compiling from source):
 - Python version: **python3**
 - CUDA/cuDNN version: **None**
 - GPU models and configuration: **None**
 - Any other relevant information:

## Additional context

<!-- Add any other context about the problem here. -->
Repository: rust
Issue: Move from {{closure}}#0 syntax to {closure#0} for (def) path components.
Labels: C-cleanup,T-compiler,A-MIR

Today if a path refers to unnamed defs such as closures, it's printed using double braces e.g. for the following example, `rustc` refers to `Foo` as `main::{{closure}}#0::Foo`:
```rust
fn main() {
    || {
        struct Foo;
        let () = Foo;
        //  ^^ expected struct `main::{{closure}}#0::Foo`, found `()`
    }
}
```

However, the new Rust Symbol Mangling (rust-lang/rfcs#2603 / #60705), uses `{closure#0}` instead.

I forget if I wrote about this before, but I prefer the newer form and it would be nice if we could switch everything uniformly to it.

As an aside, I've long believed that the double braces (e.g. `{{closure}}`, `{{impl}}`) were meant to be single braces (i.e. `{closure}`, `{impl}`), escaped for `format!`, and that somehow that got lost.
Repository: thefuck
Issue: Recognize K8s commands?
Labels: enhancement,help wanted

Hi guys,
Have a Possibility of implementation to recognize K8s commands in future?
Repository: rust
Issue: MIR dump const Allocation printing of large relocation ids
Labels: A-pretty,C-enhancement,T-compiler,A-MIR,A-const-eval

After #69916 the MIR dump of const `Allocation`s can result in things like

```
    0x80 │ 00 00 00 00 00 00 00 00 00 00 ╾alloc11+0╼ 00 00
    0x90 │ ╾alloc12+99 (4 ptr bytes)╼ 00 00 00 00 00 00 00 00 00 00 00 00
```

where even just the `alloc12+99` would be too wide on 32 bit systems.

We should find better ways to handle this. Some suggestions:

# 1. Indent all columns so they align again after the oversized relocation

```
    0x80 │ 00 00 00 00                00 00 00 00 00 00 ╾alloc11+0╼ 00 00
    0x90 │ ╾alloc12+99 (4 ptr bytes)╼ 00 00 00 00 00 00 00 00 00 00 00 00
```

# 2. More ascii art

```
    0x80 │ 00 00 00 00 00 00 00 00 00 00 ╾alloc11+0╼ 00 00
    0x90 │ ╾─────┬───╼ 00 00 00 00 00 00 00 00 00 00 00 00
          ┌──────┴─────┐
          │ alloc12+99 │
          └────────────┘
```



<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->