sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Can't export Windows with custom icon using headless
Labels: bug,topic:editor

**Godot version:**
Godot_v3.1.1-stable_linux_headless.64


**OS/device including version:**
Ubuntu 16.04 inside a Docker container, running on an Ubuntu 18.04 host


**Issue description:**
Godot headless fails to load the editor settings config file even if it is present with an error that says only an editor can read those settings:

```
ERROR: instance: Class 'EditorSettings' can only be instantiated by editor.
   At: core/class_db.cpp:523.
ERROR: poll: /root/.config/godot/editor_settings-3.tres:3 - Parse Error: Can't create sub resource of type: EditorSettings
   At: scene/resources/resource_format_text.cpp:561.
ERROR: load: Condition ' err != OK ' is true. returned: RES()
   At: core/io/resource_loader.cpp:208.
ERROR: _load: Failed loading resource: /root/.config/godot/editor_settings-3.tres
   At: core/io/resource_loader.cpp:285.
WARNING: create: Could not open config file.
   At: editor/editor_settings.cpp:871.
ERROR: get_edited_scene_root: Index current_edited_scene=-1 out of size (edited_scene.size()=0)
   At: editor/editor_data.cpp:678.
ERROR: texture_set_flags: Condition ' !t ' is true.
   At: ./drivers/dummy/rasterizer_dummy.h:199.
ERROR: texture_set_flags: Condition ' !t ' is true.
   At: ./drivers/dummy/rasterizer_dummy.h:199.
ERROR: get_edited_scene_root: Index current_edited_scene=-1 out of size (edited_scene.size()=0)
   At: editor/editor_data.cpp:678.
```

However, there are export settings in the editor settings config file, namely the ones I'm trying to use that specify an rcedit and wine location so that Windows exports can have a custom icon on the executable.  This prevents me from using the custom icon feature at all in exports since I'm not using the editor, and my builds are automated using headless.

I suspect this may be related to #29149 which is another issue where headless breaks an existing editor settings config file.


**Steps to reproduce:**
Export a project for Windows with a custom icon set and an editor settings config file existing in the user's .config/godot directory.
Repository: godot
Issue: Overlapping nodes on y-sorted TileMap "jump" back and forth
Labels: bug,topic:core,topic:rendering,confirmed

**Godot version:**
3.1


**OS/device including version:**
Windows, Radeon R9 200 series


**Issue description:**
I have two nodes that are overlapping (exact same x/y position) on a y-sorted TileMap. The nodes will swap places randomly and Node A will be in front of Node B then randomly Node B will show up in front of Node A.

I'm guessing the algorithm that sorts the nodes is not deterministic. I would recommend that the sorting should probably just fallback to the node's index in the parent to decide on ordering if they overlap OR just make it deterministic so it doesn't jump back and forth.

**Steps to reproduce:**
1. Add 2 sprites on the same x/y position
2. Have other sprites that are moving around to force the engine to have to re-sort children.

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
[YSortBug.zip](https://github.com/godotengine/godot/files/3434005/YSortBug.zip)

See video. There are 2 sprites on the top left tile which will jump back and forth. The other nodes that are animating to the right/down are there just to force sorting to happen.
![ysortbug](https://user-images.githubusercontent.com/92303/61922741-81f2af80-af2f-11e9-99a5-56638f3929d3.gif)
Repository: go
Issue: x/tools/internal/imports: redundant import name is not removed
Labels: NeedsDecision,FeatureRequest,Tools

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12.6 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="/home/nd/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/nd/go"
GOPROXY=""
GORACE=""
GOROOT="/home/nd/go/go1.12.6"
GOTMPDIR=""
GOTOOLDIR="/home/nd/go/go1.12.6/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/nd/p/golang-tools/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-build074254564=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

### What did you do?

I've ran goimports built on revision 2e34cfcb95cb3d24b197d58fe6d25046b8f25c86 on the following file:

```
package main

import opentracing "github.com/opentracing/opentracing-go"

func main() {
	println(opentracing.Binary)
}
```


### What did you expect to see?

The redundant import alias is removed.

### What did you see instead?

Nothing is changed.

Looks like introduced by 9bea2ecb9504b47b0689751119be8b92a371a771: the [imp.name != "" check](https://github.com/golang/tools/blob/master/internal/imports/fix.go#L425) prevents redundant import cleanup.
Repository: pytorch
Issue: Hanging on when one gpu node return zero as loss in the context of distributed data parallel training
Labels: oncall: distributed,triaged

## 🐛 Bug

Hello.
I am training a multi task network on a cluster using 8 gpu with `Distributed Data Parallel`.
On every iteration, I process one image per gpu.
Suppose I have `task_a` and `task_b` with `loss_a` and `loss_b` respectively.
In some case, the `loss_a` could be zero on one gpu, which means that there is no loss computed.
Then I just return the zero tensor.
When this situation happens, the code just hang on.

 - PyTorch Version: 1.1.0 
 - OS (e.g., Linux): Ubuntu 
 - How you installed PyTorch (`conda`, `pip`, source): docker conda
 - Python version: 3.6
 - CUDA/cuDNN version:  CUDA 9.0
 - GPU models and configuration: 1080ti
 - Any other relevant information:
Repository: rust
Issue: Iterator::skip is not zero-cost in some cases (badly optimized by LLVM)
Labels: A-LLVM,I-slow,C-enhancement,T-compiler,A-iterators

See https://rust.godbolt.org/z/DkMgKv for full, commented source and the generated assembly.

---

rustc doesn't optimize the iterator `buffer.windows(size).skip(1)` well.
You can very easily outperform the Rust compiler by writing an imperative loop with a boolean flag whether the current element is the first.

Consider the function:
```rust
fn inner_buffer_ngrams_bad<'a>(&mut self, buf: &'a [u8]) -> &'a [u8] {
    let order = self.order.get() as usize; // Note: self.order is a NonZeroU8
    let mut last = buf;
    for win in buf.windows(order).skip(1) {
        self.add_ngram(last);
        last = win;
    }
    last // return trailing bytes to prepend to next chunk
}
```
The intent of this function is to iterate over `order`-sized windows of `buf` and return any unprocessed data. We specifically don't want to process the last window in the `buf`, but since there is no useful method that would allow us to split off the last element in the iterator, we instead skip the first element and create a mutable variable to lag behind by one iteration.
This implementation is correct since `self.add_ngram` ignores trailing data in a slice, so passing the whole buffer on the first iteration is fine.

Sadly, this implementation is extremely poorly optimized. If you graph the generated assembly you can see two weirdly-interwoven loops, **with two bounds checks** inside those loops.

---

Reimplementing this function with a boolean flag instead of `.skip(1)` results in this code:
```rust
fn inner_buffer_ngrams<'a>(&mut self, buf: &'a [u8]) -> &'a [u8] {
    let order = self.order.get() as usize; // Note: self.order is a NonZeroU8
    let mut last = buf;
    let mut is_first = true;
    for win in buf.windows(order) {
        if !is_first {
            self.add_ngram(last);
            last = win;
        }
        is_first = false;
    }
    last // return trailing bytes to prepend to next chunk
}
```

I intentionally did as little refactoring as possible to make it obvious the code is equivalent to the previous example.

The assembly this code generates is almost three times shorter, only contains a single loop, and contains **no bounds checks**. The assembly looks like something you'd write by hand.

---

Note: All of the above applies to `opt-level = 2` and `opt-level = 3`. This does not apply to `opt-level = 1` since it does little to no inlining.
Repository: flutter
Issue: The default margin right spacing in AppBar actions is too wide
Labels: c: new feature,framework,f: material design,a: quality,c: proposal,P3,team-design,triaged-design

The default margin right spacing in AppBar actions is too wide，

There are too many margin Rights. How to modify margin's broadband?

tks....
Repository: scrcpy
Issue: Recorded or Displayed video puts some older frames after more recent frames – [feature request] option to select encoder
Labels: feature request

I downloaded scrcpy 1.9 on 7/24/2019 with the goal of recording video from my Droid Turbo onto my Windows 7 x64 PC.  When I connect with USB and run scrcpy and have it display to my screen, and the video from the phone has a lot of motion, it's common for the display from scrcpy to periodically appear to show maybe 1 frame that probably would have been the correct frame to display about 1/10 of a second ago.  So whatever motion was happening appears to jump backwards to where it would have been maybe 1/10th of a second ago for just one frame and then jump back to what the phone is currently displaying; it's a very jarring appearance.  Depending on the size I am displaying with scrcpy, these frame jumps may happen as frequently as once a second.  If I reduce the display size very small like scrcpy --max-size 400, the frame jumps are less frequent, but they still happen occasionally, maybe a few times every 10 seconds.

I have had my phone display its CPU and memory usage while running this, and it seems to display around 15.00/14.00/14.00 as the CPU usage and the bar only seems to go around 15% across the screen so I interpret that as 15% CPU usage.  The phone memory remains with over 1 GB free while this happens.  My PC CPU usage is only around 5% while it happens, and only 4 out of 8 GB of memory are in use; these are when I'm running scrcpy --max-size 1920.

I also tried having scrcpy do the file recording.  I ran one with mp4 and one with mkv, with the --no-display option so it wouldn't need to do double work, but the mp4 and mkv files it created still have the same kinds of frame jumps I would see in the live display.  I play the files in VLC, and I've checked that I'm not just getting some kind of playback issue with the mp4 and mkv files by advancing individual frames in VLC and I can still see the motion get jumped backwards for a frame.

I do not usually run it with --render-expired-frames, and when I've tried it, the frame jumps seem just as frequent, possibly more frequent.  When I use ctrl+i, I often see skipped frames, but I am fairly certain I have observed these frame jumps in the display even during periods where no skipped frames are logged.  The display on the phone itself always looks perfect during the whole thing, and the game doesn't feel any less responsive than it would while scrcpy was not running.

Do you have any suggestions to get it where it doesn't end up displaying or recording an older frame after it has already displayed/recorded a newer frame?  I can probably share the mp4 and mkv file with google drive or something later if that would help.
Repository: pytorch
Issue: Unreachable code in tanh
Labels: caffe2,triaged

## 🐛 Bug

In https://github.com/pytorch/pytorch/blob/9a281451ed7f00d052212695ea112ebe872776f6/caffe2/quantization/server/tanh.cc#L17-L48
all code after line 22 is unreachable. This doesn't seem to be intentional (maybe someone added it for testing and forgot to remove it?).
Repository: pytorch
Issue: [Feature request] Let DistributedSampler take a Sampler as input
Labels: oncall: distributed,feature,module: dataloader,triaged,has workaround

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->


## Motivation

Currently, `DistributedSampler` assumes that it takes a `Dataset` as argument. But in reality, the only information it exploits from it is its `len`.

We sometimes want to have a custom Sampler to be used in distributed mode. So it might be desirable to also let `DistributedSampler` take a `Sampler` as argument.

## Potential implementation

The only difference is that in 

https://github.com/pytorch/pytorch/blob/46224ef89edcd0e350d1572bb4d12d370245cc6e/torch/utils/data/distributed.py#L57-L61
We would additionally have something like

```python
if isinstance(self.dataset, Sampler):
    orig_indices = list(iter(self.dataset))
    indices = [orig_indices[i] for i in indices]

return iter(indices)
```

## Pitch

More modularity and code reuse
```python
sampler = MyNiceSampler(dataset)
if distributed:
    sampler = DistributedSampler(sampler)
```

Additionally, it make writing code more (in my view) clear. Instead of
```python
if distributed:
    sampler = DistributedSampler(dataset)
else:
    sampler = RandomSampler(dataset)
```
we can always have
```python
sampler = RandomSampler(dataset)
if distributed:
    sampler = DistributedSampler(sampler, shuffle=False)
```
which, at first sight might seem very similar, but they imply different things.

## Alternatives

We can integrate the functionality of `DistributedSampler` inside our custom sampler, but this seems redundant.

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @SsnL @VitalyFedyunin @ejguan @NivekT @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: rust
Issue: Tracking issue for `fs::Metadata` extensions on Windows based on handle information
Labels: O-windows,T-libs-api,B-unstable,C-tracking-issue,A-io,Libs-Tracked

This is a tracking issue for APIs added in https://github.com/rust-lang/rust/pull/62980, namely the following Windows-specific APIs:

```rust
impl MetadataExt for Metadata {
    fn volume_serial_number(&self) -> Option<u32>;
    fn number_of_links(&self) -> Option<u32>;
    fn file_index(&self) -> Option<u64>;
}
```

The motivation of these accessors are that the standard library learns about them in its call to `GetFileInformationByHandle` but doesn't expose it from the standard library, which means consumers that want to learn this either need to reimplement the pieces in the standard library or execute a second syscall. Concrete motivation for these fields arose during https://github.com/CraneStation/wasi-common/pull/42.

These fields all return `Option` which is a bit odd, but there's a few way of learning about a `Metadata` on Windows. When learned through a `DirEntry` these fields aren't available but when learned through a `fs::metadata` call or `File::metadata` these fields are available. It's unfortunately not as uniform as Unix, but we don't have a ton of options as well.
Repository: rust
Issue: Tracking issue for -Z binary-dep-depinfo
Labels: T-compiler,B-unstable,C-tracking-issue,requires-nightly,S-tracking-design-concerns,S-tracking-needs-summary,A-CLI

This is a tracking issue for `-Z binary-dep-depinfo` added in #61727.
The cargo side is implemented in https://github.com/rust-lang/cargo/pull/7137.

Blockers:

- [ ] Canonicalized paths on Windows. The dep-info file includes a mix of dos-style and extended-length (`\\?\`) paths, and I think we want to use only one style (whatever is compatible with make and other tools). See the PR for details.
 - [ ] Codegen backends are not tracked.

cc @Mark-Simulacrum @alexcrichton
Repository: vscode
Issue: [folding] When you cut a collapsed code block it should stays collapsed when you paste/drop it.
Labels: feature-request,editor-folding

I have searched the issues and requests and I don't see this one anywhere. And it seems like too good of an idea to pass up. 

While you can cut a collapsed code block and paste it elsewhere, when you paste it, it "uncollapses." 

It would be really cool and useful if the code remained collapsed after you pasted it. 

Thanks.
Repository: godot
Issue: Errors hidden in error tab
Labels: bug,topic:editor,confirmed,usability

**Godot version:**
Godot 3.1.1

**Issue description:**
![image](https://user-images.githubusercontent.com/26231126/61968334-11ec3400-afd8-11e9-97bb-6b7b0c14469e.png)


**Steps to reproduce:**
Produce an error that is longer than the error window.

**Possible fix:**
* The tooltip allows to see the whole error (Already implemented)
* Side scroll / shift+scroll (Not implemented)
* Text wrapping (Not implemented)
Repository: pytorch
Issue: einsum equation with conditional mask works in numpy but not in PyTorch
Labels: triaged,module: type promotion,module: linear algebra,function request

## 🐛 Issue Description

I have a snippet of code that works when I use ``np.einsum``. But it's PyTorch equivalent throws an error for the conditional mask ``A==1.0``. Is this a bug or is this behaviour expected?

## To Reproduce

Steps to reproduce the behavior:

Input:
```
A_np = np.array([[0,1,1],[1,0,1],[1,1,0]])
B_np = np.array([[1,1,1],[1,1,1],[1,1,1]])
```

NumPy Code for matrix multiplication using ``einsum``:
```
C_np = np.einsum('ij,jk->ik', B, A==1.0)
```

Output:
```
>>> C_np
array([[2., 2., 2.],
       [2., 2., 2.],
       [2., 2., 2.]], dtype=float32)
```

Equivalent PyTorch Code:
```
C = torch.einsum('ij,jk->ik', B, A==1.0)
```

Error Message:
```
    return torch._C._VariableFunctions.einsum(equation, operands)
RuntimeError: expected scalar type Float but found Byte
```

## Environment

```
PyTorch version: 1.0.1.post2
Is debug build: No
CUDA used to build PyTorch: 10.0.130

OS: CentOS Linux release 7.6.1810 (Core)
GCC version: (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
CMake version: Could not collect

Python version: 3.6
Is CUDA available: No
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA

Versions of relevant libraries:
[pip] numpy==1.16.2
[pip] torch==1.0.1.post2
[pip] torchvision==0.2.2
[conda] _tflow_select             2.3.0                       mkl
[conda] blas                      1.0                         mkl
[conda] mkl                       2019.1                      144
[conda] mkl_fft                   1.0.10           py36ha843d7b_0
[conda] mkl_random                1.0.2            py36hd81dba3_0
[conda] pytorch                   1.0.1           py3.6_cuda10.0.130_cudnn7.4.2_2    pytorch
[conda] tensorflow                1.12.0          mkl_py36h69b6ba0_0    anaconda
[conda] tensorflow-base           1.12.0          mkl_py36h3c3e929_0
[conda] torch                     1.0.1.post2              pypi_0    pypi
[conda] torchvision               0.2.2                      py_3    pytorch
```


cc @vincentqb @vishwakftw @jianyuh @nikitaved @pearu @mruberry @heitorschueroff @nairbv
Repository: rust
Issue: SIGSEGV during compilation of extern x86-interrupt fn with u128 param
Labels: I-crash,A-LLVM,O-x86_64,T-compiler,C-bug,requires-nightly,O-x86_32,F-abi_x86_interrupt,A-hardware-interrupts

```rust
#![feature(abi_x86_interrupt)]

pub extern "x86-interrupt" fn main (_a: u128) {}
```

I suspect LLVM being the culprit.
Repository: flutter
Issue: SceneBuilder::addPlatformView offset parameter is ignored.
Labels: platform-ios,engine,a: platform-views,P2,team-ios,triaged-ios

Currently, the offset parameter is only used to specify the paint bounds of the platform view layer in flow. However, since the platform view layer is a leaf, this is effectively a no-op. The expectation is that this offset would be propagated to the embedder in the effective embedded view params. However, the offset in EmbeddedViewParams is currently only determined from the effective transformation matrix.

Potential fixes:
* Remove the offset from the API. This is a breaking API change but this API is the lowest layer in the stack and currently has no users (or at least the current calls don't do anything).
* Propagate the offset to the embedder by adding it to the offset in the embedded view params. This will require patching existing plugins to account for this extra offset.
* Do nothing but document that this offset is ignored.

I like the first option.
Repository: flutter
Issue: Better support for migrating existing localization schemes from Android/iOS to Flutter
Labels: tool,a: internationalization,a: existing-apps,P3,team-tool,triaged-tool

Given a user who already has an iOS style Localizable.strings or a collection of Android strings.xml, create a conversion tool or an import tool for using them in Flutter.
Repository: go
Issue: gccgo: bad "incompatible types" error when comparing untyped expressions
Labels: NeedsInvestigation

gccgo incorrectly reports `error: incompatible types in binary expression` for this test program:

```
package main

func main() {
        var v uint = 32
        println(1 << v == '\002' << v)
}
```

The Go spec says:

> If the left operand of a non-constant shift expression is an untyped constant, it is first implicitly converted to the type it would assume if the shift expression were replaced by its left operand alone.

So `1` and `'\002'` should take on the types that they would in the comparison `1 == '\002'`, which is `rune`/`int32`.

For comparison, the program prints `true` when compiled with cmd/compile, and it type checks with go/types.

/cc @ianlancetaylor
Repository: go
Issue: x/net/websocket: override the Host header
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?
Relevant as of today's `master` of `x/net/websocket` (see below).

### Does this issue reproduce with the latest release?
Yes.

### What did you do?
Tried changing the `Host` header appearing in the initial WebSocket query by creating a config through `websocket.NewConfig` and changing its host through `Header.Set("Host", "example.com")`.

### What did you expect to see?
That the `Host` header would be set to `example.com`.

### What did you see instead?
That the `Host` header was `config.Location.Host`.

In the current `master`, this is set on [line 411 of `hybi.go`](https://go.googlesource.com/net/+/refs/heads/master/websocket/hybi.go#411), in `hybiClientHandshake`.

Is this the intended API? It means that it becomes impossible to change the `Host` header without also changing the `config.Location.Host`, which might be undesirable (in my use case because it has the undesired side effect of changing the TLS SNI field, which is also based on `config.Location.Host`, and I can't have the SNI host and the WebSocket hosts be synchronized like that).

Given that there's a field called `Header`, I would have expected that to impact what headers end up being set; I would have been less surprised if `hybiClientHandshake` had used `Header.Get("Host")` if that header is set, and then fall back to `config.Location.Host` if it's not (similar to what you would see with e.g. curl).
Repository: flutter
Issue: Flutter/* generated files are created for plugins
Labels: tool,platform-mac,a: desktop,P3,team-macos,triaged-macos

I haven't tracked down the exact trigger, but I frequently end up with `macos/Flutter/GeneratedPluginRegistrant.swift` and `macos/Flutter/ephemeral/Flutter-Generated.xcconfig` in plugins after building a project that uses them. I notice this all the time with FDE plugins because `testbed` includes them by path, not fetching them from pub, but presumably it's happening all the time (harmlessly for pub-fetched plugins, but pointlessly).

I suspect given the amount of code-sharing that this is happening for iOS plugins too, but that nobody has noticed.