sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: create-react-app
Issue: `--template` cannot load a GItHub repository
Labels: issue: proposal

### Describe the bug

Hey folks 👋 I'm not positive that this is a bug, talking with @iansu this seems to be more of a feature that doesn't (yet!) exist. I was wondering if `--template owner/repo` would work in the same way as `npm i owner/repo`, where it looks for a package on GitHub. For example:

```
npm install -g facebook/create-react-app
```

Would grab the code, as-is, from `master` of this repo.

### Environment

```
create-react-app@3.3.0
```

### Steps to reproduce

1. Run `npx create-react-app wheeler-mode --template iansu/cra-template-wheeler-mode`

Any `owner/repo` string should work in the same way!

2. Observe the error message as shown below!

### Expected behavior

I'd expect `yarn` to resolve the template similar to how it grabs it from `npm`, when given an `owner/repo` string that maps to a GitHub repository. Aside from being able to function similar to `yarn` under the hood, this even enables _private_ templates by implementing existing `git` credentials 🙌 🔒 

### Actual behavior

```
❯ npx create-react-app wheeler-mode --template iansu/cra-template-wheeler-mode 
```

Here's the output:

```
Creating a new React app in /Users/jasonetco/dev/wheeler-mode.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template-iansu/cra-template-wheeler-mode...

yarn add v1.17.3
[1/4] 🔍  Resolving packages...
error Command failed.
Exit code: 128
Command: git
Arguments: ls-remote --tags --heads ssh://git@github.com/cra-template-iansu/cra-template-wheeler-mode.git
Directory: /Users/jasonetco/dev/wheeler-mode
Output:
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

Aborting installation.
  yarnpkg add --exact react react-dom react-scripts cra-template-iansu/cra-template-wheeler-mode --cwd /Users/jasonetco/dev/wheeler-mode has failed.

Deleting generated file... package.json
Deleting generated file... yarn.lock
Deleting wheeler-mode/ from /Users/jasonetco/dev
Done.
```

Worth noting that `yarn` tried to clone the GitHub repo, but got the SSH URL wrong:

```
ssh://git@github.com/cra-template-iansu/cra-template-wheeler-mode.git
```

Should be:

```diff
- ssh://git@github.com/cra-template-iansu/cra-template-wheeler-mode.git
+ ssh://git@github.com/iansu/cra-template-wheeler-mode.git
```

Let me know how I can help! If y'all are open to a PR here, my first inclination would be to look for `/` in the provided template string and just not prepend `cra-template` before giving it over to `yarn`.
Repository: angular
Issue: Align with the optional chaining spec
Labels: feature,area: core,area: compiler,core: binding & interpolation

# 🚀 feature request

### Relevant Package

`@angular/compiler`

### Description

[Optional chaining](https://github.com/tc39/proposal-optional-chaining)[1] reached stage 4. We've been supporting similar syntax in templates for a while now, calling it the ["safe navigation operator"](https://angular.io/guide/template-syntax#safe-navigation-operator)[2]. For simplicity and smaller payload, we can consider aligning with the spec in future versions of the framework.

There are a couple of semantical and syntactical differences between optional chaining and safe navigation.

## Syntax 

Optional chaining has the following syntax:

```ts
obj?.prop       // optional static property access
obj?.[expr]     // optional dynamic property access
func?.(...args) // optional function or method call
```

Safe navigation supports only direct property access. Optional chaining supports this, as well as, method calls and function calls. Function calls are particularly useful in iterators:

```ts
iterator.return?.()
```

## Semantics

With optional chaining, the expression `a?.b` will be translated to `a == null ? undefined : a.b`. In Angular, the semantics of the same expression would be `null == a ? null : a.b`.

If `a` is `null` or `undefined`, the expression `typeof a?.b` would evaluate to `"object"` with optional chaining and `"undefined"` in Angular's safe navigation operator.

Except the mentioned difference above, method calls are compiled similarly:

```ts
a?.b()
a == null ? undefined : a.b()
```

In both, optional chaining and safe navigation in templates, stacking the operators is translated the same way: `(a?.b).c?.d` becomes `null == a ? null : null == a.b.c ? null : a.b.c.d`.

Another difference seems to be the way parentheses are handled. The optional chaining spec defines that `null==e.foo?null:e.foo.b.c` should be translated to `(a == null ? undefined : a.b).c`. In Angular the same expression translates to `null == a ? null : a.b.c`.

PS: looks like the last issue is fixed by https://github.com/angular/angular/pull/34221.

---

[1] Optional chaining spec https://github.com/tc39/proposal-optional-chaining
[2] Safe navigation https://angular.io/guide/template-syntax#safe-navigation-operator
Repository: pytorch
Issue: [RPC] Support nn.Module pickling with share memory
Labels: triaged,module: rpc

## 🚀 Feature
To share memory across processes for multiprocessing hogwild,  Pytorch supports doing it at process spawning, with special [reduce functions](https://github.com/pytorch/pytorch/blob/master/torch/multiprocessing/reductions.py
).

With the introduction of `torch.distributed.rpc`, we will need to support packing share memory relating info while RPC send() pickles nn.Module.
There is a hacky implementation in https://github.com/pytorch/pytorch/issues/30633, but it relies on the special reduce functions mentioned above that are supposed to work with Python's ForkingPickler.

We will need a clean solution that works for RPC.





cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528
Repository: flutter
Issue: Tool crash Github template should include enabled/disabled features
Labels: c: new feature,tool,a: triage improvements,P3,team-tool,triaged-tool

For example, the results of flutter config (minus signing cert info)

```
Settings:
  flutter-web: true
  flutter-linux-desktop: true
  enable-macos-desktop: true
  ~~ios-signing-cert: iPhone Developer: Jonah Williams (XXXX)~~ (But pretend  this is a strikethough)
  enable-web-incremental-compiler: false


```
Repository: pytorch
Issue: Default shuffle behavior of DistributedSampler
Labels: oncall: distributed,module: dataloader,triaged

## 🚀 Feature
The **DistributedSampler** should shuffle data without explicitly set `set_epoch`.

## Motivation
I have found that the parameter shuffle of **DistributedSampler** is set True in default but the behavior and intuition are inconsistent. The GPU always load the same data between every epoch. It still needs manual set sampler.set_epoch to change the data loaded by GPU
## Pitch
Truely shuffle the data when the shuffle=True in **DistributedSampler** 
## Alternatives
Just show this potential feature in doc.
## Additional context

The test code, 

`CUDA_VISIBLE_DEVICES=1,3 python -m torch.distributed.launch --nproc_per_node=2 test.py`

test.py:
```import torch
import torch.nn as nn
from torch.utils.data import Dataset, DataLoader
from torch.utils.data.distributed import DistributedSampler


torch.distributed.init_process_group(backend="nccl")

input_size = 5
output_size = 2
batch_size = 2
data_size = 16

local_rank = torch.distributed.get_rank()
torch.cuda.set_device(local_rank)
device = torch.device("cuda", local_rank)

class RandomDataset(Dataset):
    def __init__(self, size, length, local_rank):
        self.len = length
        self.data = torch.stack([torch.ones(5), torch.ones(5)*2,
                                 torch.ones(5)*3,torch.ones(5)*4,
                                 torch.ones(5)*5,torch.ones(5)*6,
                                 torch.ones(5)*7,torch.ones(5)*8,
                                 torch.ones(5)*9, torch.ones(5)*10,
                                 torch.ones(5)*11,torch.ones(5)*12,
                                 torch.ones(5)*13,torch.ones(5)*14,
                                 torch.ones(5)*15,torch.ones(5)*16]).to('cuda')

        self.local_rank = local_rank
    def __getitem__(self, index):

        return self.data[index]

    def __len__(self):
        return self.len
    
dataset = RandomDataset(input_size, data_size, local_rank)
sampler = DistributedSampler(dataset)
rand_loader = DataLoader(dataset=dataset,
                         batch_size=batch_size,
                         sampler=sampler)

e = 0
while e < 2:
    t = 0
    sampler.set_epoch(e) # this is key, if this line removed, the data will be same, else the data won't be same between iteration but will be same in every per run
    for data in rand_loader:
        print(data)
    e+=1
```

cc @SsnL @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528
Repository: go
Issue: x/image/tiff: grayscale tiled images are not decoded correctly
Labels: NeedsDecision

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.4 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/ivan/.cache/go-build"
GOENV="/home/ivan/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/srv/work/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/ivan/.local/share/umake/go/go-lang"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/ivan/.local/share/umake/go/go-lang/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/srv/work/go/src/go.googlesource.com/image/go.mod"
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-build974283161=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
When you decode tiled tiff grayscale image you may find that tiles placed on the image boundary (right) are decoded incorrectly.

It happens because the tiff file contains the complete tile compressed, while the loop iterates only over the part of it that fits the image boundary:

```go
			for y := ymin; y < rMaxY; y++ {
				for x := xmin; x < rMaxX; x++ {
```

So if you read pixels from the non-complete tiles (from the right edge) all lines but the first one would contain real data mixed with garbage (bits from outside the image boundary).

### What did you expect to see?



### What did you see instead?
Repository: ant-design
Issue: [4.0] Proposal: Fieldset component
Labels: 💡 Feature Request,☘️ New Component,Inactive

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### What problem does this feature solve?
There's a standard HTML tag `<fieldset>` which is used to visually group form elements, see [example](https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_fieldset). It would be great if antd had `<Fieldset>` with a standard antd styling and may some configuration like title and border style.

### What does the proposed API look like?
Example: https://codesandbox.io/s/antd-reproduction-template-4924q
This example uses standard `<fieldset>` with `<legend>`, imagine if we had something like: 
```
<Fieldset title="" fullBorder titlePosition="right">
```


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: terminal
Issue: vim slower to open/close in conhost v2 compared to v1
Labels: Product-Conhost,Help Wanted,Needs-Repro,Area-Performance,Issue-Task


# Environment

```none
Windows build number: 17763
Windows Terminal version (if applicable): N/A, conhost only

Any other software? Vim for Windows, tested with 7.4-8.1
```

# Steps to reproduce

Open a CMD window with a shortcut that specifies a large window buffer.  The default in RS5 appears to be 9000, which is sufficient.  Use the command line vim to open a random text file and observe startup time.  Quit vim and observe exit time.

(Note that vim has a startup time debugging facility - run "vim --startuptime logfile filetoopen" and it will report the time spent in various phases of startup to the log file.)

# Expected behavior

Expecting performance of open/close to be more in line with the legacy console.  Note that the change to default to 9000 lines of history is also causal.

# Actual behavior

Vim appears to take around a second or two to start and a second or two to exit, which appears to be saving and restoring the console screen buffer, when using conhost v2.  This does not occur with v1, and can be mitigated by reducing the screen buffer size.
Repository: godot
Issue: Sub-Viewport Update Mode UPDATE_ALWAYS does not update when not visible
Labels: bug,topic:core

**Godot version:**
Godot 3.2 Beta 3

**OS/device including version:**
Ubuntu 19.04

**Issue description:**
(TLDR : Update Always does not update always)

On a viewport set to Update Always, it still only updates when visible (Which is the expected behaviour only of "Update When Visible"

**Steps to reproduce:**
Make a script checking the values of a viewport texture and try disabling the visibility of a viewport container parent

**Minimal reproduction project:**
[Test5.zip](https://github.com/godotengine/godot/files/3959474/Test5.zip)
Color value is printed every frame
Repository: godot
Issue: the cell index is not consequent when create tiles
Labels: discussion,topic:core,topic:2d

**Godot version:3.1.2

**OS/device including version:**

**Issue description:**
When create tile use the new single tile button, the cell index is not consequent after delete some tiles.
**Steps to reproduce:**
1. add some new tiles
2. delete some tiles
3. add some new tiles

the cell index of the tile is not consequent, the index of deleted cell will not used.

**Minimal reproduction project:**
<img width="1174" alt="Screen Shot 2019-12-13 at 5 43 21 PM" src="https://user-images.githubusercontent.com/1130047/70790842-d4dedd80-1dd0-11ea-9b3d-8d22ef3fd2f1.png">
Repository: react-native
Issue: [Android] Vector images from native resources is not working
Labels: Platform: Android,Component: Image,Bug,Never gets stale

Based on React Native [documentation](https://facebook.github.io/react-native/docs/images#images-from-hybrid-apps-resources), we should be able to fetch images from native resources.
This is works great on iOS, but in Android you can't load [vector images](https://developer.android.com/guide/topics/graphics/vector-drawable-resources.html) using `uri`.

React Native version:
```
react-native: 0.61.5
```

## Steps To Reproduce

Placing vector image named `image.xml` in `drawable` folder and using this code, is not working:
`<Image width={100} height={100} source={{ uri: 'image' }} style={{ width: 100, height: 100 }} />`

Placing the vector image in `assets` folder and using this code, is not working either:
`<Image width={100} height={100} source={{ uri: 'asset:/image.xml' }} style={{ width: 100, height: 100 }} />`

Note that placing `.jpg` or `.png` images is working without any issues.
Repository: terminal
Issue: Fullscreen mode + "Show desktop" not working as expected
Labels: Help Wanted,Issue-Bug,Area-UserInterface,Product-Terminal,Priority-3

# Environment

```
Windows build number: Microsoft Windows Version 10.0.18362.476
Windows Terminal version: microsoft-windows-terminal 0.7.3291.0
```

# Steps to reproduce

> Open Windows Terminal
> Toggle fullscreen (F11)
> Use "show desktop" (win + d)
> Use "show desktop" again

# Expected behavior

All windows should hide and the desktop should be shown (First trigger of "show desktop"). On second tirgger all windows should be shown again, and the terminal window should be visible on top again.

# Actual behavior

On the second trigger of "show desktop", another window gets shown on top. Also sometimes the taskbar disappears, and you can see parts of the terminal peeking through.

PS: When using win+d with a AutoHotkey remapping, this gets even more buggy. (I can provide details if necessary)
Repository: pytorch
Issue: [feature request] Better handling for CUDA Out of Memory
Labels: module: cuda,triaged

Currently, users have little recourse when the CUDA allocator raises an OOM error due to fragmentation. Providing better handling when the allocator fails to allocate memory could alleviate some fragmentation related issues. For example, I occasionally make use of the following code to address fragmentation related issues:

```python
import gc
import torch


def refresh_cuda_memory():
    """
    Re-allocate all cuda memory to help alleviate fragmentation
    """
    # Run a full garbage collect first so any dangling tensors are released
    gc.collect()

    # Then move all tensors to the CPU
    locations = {}
    for obj in gc.get_objects():
        if not isinstance(obj, torch.Tensor):
            continue

        locations[obj] = obj.device
        obj.data = obj.data.cpu()
        if isinstance(obj, torch.nn.Parameter) and obj.grad is not None:
            obj.grad.data = obj.grad.cpu()

    # Now empty the cache to flush the allocator
    torch.cuda.empty_cache()

    # Finally move the tensors back to their associated GPUs
    for tensor, device in locations.items():
        tensor.data = tensor.to(device)
        if isinstance(tensor, torch.nn.Parameter) and tensor.grad is not None:
            tensor.grad.data = tensor.grad.to(device)
```

I have verified that this can fix some OOM problems due to fragmentation. For example, I was running into an issue when trying to save a model when using NVIDIA's [apex](https://github.com/NVIDIA/apex) package. Apparently calling `amp.state_dict()` was trying to allocate memory. I consistently got the following OOM error during the save:

```
CUDA out of memory. Tried to allocate 246.00 MiB (GPU 0; 10.76 GiB total capacity; 8.98 GiB already allocated; 212.00 MiB free; 722.71 MiB cached)
```

Clearly there was enough free memory, but fragmentation likely made it impossible to allocate a contiguous block. Adding a call to `refresh_cuda_memory` before calling `amp.state_dict()` alleviated the issue. This approach does not work when using variable sized batches, since a user cannot know before running a batch if it will result in an OOM error and calling `refresh_cuda_memory` between each batch is likely too slow. Rather, a user can only react after the OOM error occurs by refreshing memory and trying the batch again.

Here are a couple of suggestions for how the CUDA caching allocator could address the issue:
1) The allocator itself might run a variant of the code above upon determining there is not enough available memory and then retry the allocation

and/or

2) Make a python hook available upon detecting OOM where users can free CUDA memory or try this refresh operation themselves. It would require care to ensure this does not result in infinite recursion.

If these seem like reasonable suggestions, I'm happy to try to implement this feature provided some guidance on what direction to take. Linking some of the people who discussed #1529. @vadimkantorov @ezyang @SsnL @VitalyFedyunin @soumith 

cc @ngimel
Repository: go
Issue: cmd/compile: Finer grained visibility debug info for variables
Labels: NeedsInvestigation,Debugging,compiler/runtime

Delve currently determines variable visibility by using a combination of DWARF lexical blocks and the variable declaration line: a variable is visible if the lexical block is active (current PC is contained in the range of the lexical block) and if the current line is greater than or equal to the declaration line. The reason for the "equal to" part is that variables declared in the header of a for statement are initialized on every iteration after the first one (there are other situations where this could happen, by manually setting breakpoints at specific addresses, but that's the most common case).

This is fine for the most part but when current line equals declaration line Delve will show uninitialized variables. As far as I can tell there is no way to improve this with the debug symbols currently exported by the compiler. 

There has been [some interest in from users of Delve in having finer grained tracking of variable visibility](https://github.com/go-delve/delve/issues/1134). Since this isn't actually a thing Delve can do anything about I think there should be a bug here about this.

DWARF offers two ways of doing this: the DW_AT_start_scope and loclists.

DW_AT_start_scope specifies an offset, from the start of the containing lexical block of a variable, where the variable begins being visible. For this to be useful there needs to be a rough correspondence between the order of statements in the source and the order of instructions in the compiled output. I don't think the SSA backend guarantees that.

Since the compiler already tracks the information needed for loclists and simply discards it when optimizations are disabled I thought loclists could be an easier solution and decided to test what would happen if I [made the compiler emit loclists for non-optimized programs](https://go-review.googlesource.com/c/go/+/211278).

At first glance this works, however upon closer inspection it does not. I wrote [a program](https://github.com/aarzilli/loclist_experiment_check) (the program will assume there is an executable file called 'compile' in the current director and that it has been compiled with optimizations disabled) to compare visibility as determined from loclists with visibility as determined from lexical blocks and using this method we occasionally lose visibility of some variables at some statements. As a quick example the variable argID in cmd/compile/internal/ssa.critical will not be visible during the call on line critical.go:62 (incidentally I think this type of check could be also useful to test the coverage of loclists generated for optimized executables).

I don't know that the compiler should actually change anything, maybe Delve should just start showing variables as visible on the line after the declaration line.

cc @heschik @dr2chase @derekparker
@gopherbot label Debugging