sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Android Remote debug sync script not work(cant access any signal)
Labels: topic:core

**Godot version:**
Godot 3.0.6 on steam

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->

Remote debug on wifi.
Remote debug & Sync scene change & Sync script change checked
The app can be deploy success on my android, and it update the visual when I change the scene(label's text, button size and coordinate, etc), but if I change some vars value(change label's text) in my script and save, the app will not accept any signal anymore, but it still update the scene, just cant response any signal, button not work. Debuggers on godot will throw

"0:00:28:0728 - Error calling method from signal 'pressed': 'Control(Test.gd)::onButton_pressed': Method not found.
Type:Error
Description: 
Time: 0:00:28:0728
C Error: Error calling method from signal 'pressed': 'Control(Test.gd)::_on_Button_pressed': Method not found.
C Source: core/object.cpp:1202
C Function: emit_signal"
Very appreciate if anyone tell me something about that.
Repository: go
Issue: runtime/pprof: add ReadMaps preloading API
Labels: help wanted,Proposal,Proposal-Accepted,NeedsFix,compiler/runtime

### What version of Go are you using (`go version`)?
1.12

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
Linux Debian 4.19.16-1 x86_64 GNU/Linux

### What did you do?
Certain processes run with tight seccomp filters to restrict the access to the host OS. Namely the gVisor sandbox process is prohibited from calling open(2) and openat(2) to reduce the blast radius in case the gVisor kernel gets compromised. However, when using runtime.pprof, it tries to open `/proc/self/maps` ([here](https://github.com/golang/go/blob/232c9793092115870a430ef3c9ef9ae04f9e25c9/src/runtime/pprof/proto.go#L442)) and executable/libs [here](https://github.com/golang/go/blob/232c9793092115870a430ef3c9ef9ae04f9e25c9/src/runtime/pprof/proto.go#L552). Those calls trip over the seccomp filters and kill the process.

If it would be possible to make a call to pprof to preload this information, applications could call it before seccomp filters are installed, and thus allow the process to be profiled while remaining secure. Another option is to pre-open `/proc/self/maps` and then read when needed by the profiler.
Repository: flutter
Issue: Better Ordered Name Parameters in a Constructor Documentation
Labels: team,framework,d: api docs,c: proposal,a: annoyance,P2,team-framework,triaged-framework

In any Flutter Widget documentation, the constructor definition seems rather unreadable because there is no set ordering of the named parameters. Granted, named parameters can appear in any order, but for better readability in the documentation, please either ALPHABETIZE the parameters or order them by TYPE.

![image](https://user-images.githubusercontent.com/230380/53844148-74319300-3f6a-11e9-9375-d41bb0e79f6e.png)
Repository: go
Issue: net/url: Parse documentation does not adequately explain escaping rules or RFC compliance
Labels: Documentation,help wanted,NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.1 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes, [see playground](https://play.golang.org/p/TGYai9G0M6j).

### 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/neilalexander/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/neilalexander/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/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/cv/wv7k9w2s4qdfjfd60nd7_5t40000gn/T/go-build007721452=/tmp/go-build -gno-record-gcc-switches -fno-common"
</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.
-->

[See playground](https://play.golang.org/p/TGYai9G0M6j):

```
if _, err := url.Parse("http://[fe80::1%en0]:12345"); err != nil {
	panic(err)
}
```

### What did you expect to see?

IPv6 link-local literals should be accepted and `fe80::1%en0` should be returned within the `Host`. 

### What did you see instead?

Parsing error due to invalid URL escape with the percent sign - in above example produces: 
```
panic: parse http://[fe80::1%en0]:12345: invalid URL escape "%en"
```
Repository: go
Issue: proposal: spec: checked integer types
Labels: LanguageChange,Proposal,LanguageChangeReview

As a simpler alternative to #30209, I propose that we add a new set of integer types that panic on overflow.

First a quick summary of some other languages, to the best of my knowledge:

- C and C++: integer overflow is undefined.
- Java and D: integer overflow wraps.  This is also what Go does today.
- Rust, Clojure, and Ada: integer overflow throws an exception.
- Swift: integer overflow throws an exception but additional operators wrap: `&+`, `&-`, `&*`.
- Haskell: integer overflow is implementation defined.
- C#: integer overflow may be checked or wrapped by using the `checked` and `unchecked` keywords.
- Python and Ruby: integers have unbounded size and cannot overflow.

Issues #19624 and #30209 argue that in Go integer overflow should panic.  But today integer overflow wraps, and we cannot break existing code.

I propose that we add a new set of checked integer types.  These will use a prefix `o`, for overflow.  The types will be `oint`, `oint8`, `oint16`, `oint32`, `oint64`, `ouint`, `ouint8`, `ouint16`, `ouint32`, `ouint64`, `ouintptr`.  We can also consider adding the type aliases `obyte` (= `ouint8`) and `orune` (= `ouint32`) although I'm not sure they are very important.

These new types act exactly like the corresponding types without the `o` prefix, except that if an addition, subtraction, multiplication, or division operation overflows, the result is a run-time panic.

Issue #30209 suggests adding a comma-ok form to detect integer overflow in an expression, as is also suggested in #6815.  The main advantage of comma-ok for simple expressions is for a simpler implementation of multi-precision arithmetic, but for that use we have instead chosen to provide functions in the math/bits package.  The main advantage of comma-ok for complex expressions is to permit switching between checked and wrapping arithmetic, but we already have wrapping arithmetic in the `int` type, and there is no realistic prospect of removing that from the language.  So I do not think we need a comma-ok form.  If there are other uses of comma-ok, this proposal still supports them, awkwardly, via a deferred function that calls `recover`.

There will as usual be no automatic conversion between existing types and the new types.  This requirement of Go is the only way that this approach can work.
Repository: go
Issue: proposal: os: add PathSeparatorString and PathListSeparatorString
Labels: Proposal,Proposal-Hold

Issue #3939 proposes eliminating the conversion from integer types to string types.  Examining code shows that one common case where the conversion is used correctly is `string(os.PathSeparator)`.  If we eliminate the conversion from the language, we will need a replacement for code of that sort, ideally one that does not involve a function call.

I propose that we add two new constants to the os package: `PathSeparatorString` and `PathListSeparatorString`.  These are the best names I've come up with, but they are not great, and I would be happy to hear better suggestions.  The new constants will have the same value as the current constants `PathSeparator` and `PathListSeparator`, but will be untyped string constants rather than untyped rune constants.

Similarly, I propose that we add `SeparatorString` and `ListSeparatorString` to the path/filepath package.
Repository: go
Issue: proposal: unicode/utf8: add String
Labels: Proposal,Proposal-Hold

Issue #3939 proposes removing the conversion from integer types to string types.  In order to do that, it will be convenient if we have an exact replacement in the standard library.

I propose adding a new function to the unicode/utf8 package:

```Go
func String(r rune) string
```

This function will return a string containing the UTF-8 encoding of its argument.

The implementation will be equivalent to the following, though of course it may be further optimized.

```Go
func String(r rune) string {
    var a [4]byte
    return string(a[:EncodeRune(a[:], r)])
}
```
Repository: pytorch
Issue: Training hangs when using DistributedDataParallel in two pod on two nodes 
Labels: oncall: distributed,triaged

<!-- A clear and concise description of what the bug is. -->
Training hangs when using DistributedDataParallel in two pod on nodes.
The problem **occasionally** happens  and can not be reproduced each time. 
The pods were started by k8s using flannel network. The physical nodes are connected by 10Ge ethernet.

Training started normally, but hanged in the middle of training process.
![image](https://user-images.githubusercontent.com/41627739/53853400-4860ec80-4000-11e9-9929-678b7547f630.png)
Then there was no output again. The training process did not exit for servel hours.
We found that the GPU utilization  was always 100% on both two nodes.
![image](https://user-images.githubusercontent.com/41627739/53852922-a096ef00-3ffe-11e9-828c-6d38e8d5dd68.png)
After we added NCCL_DEBUG=WARN before the training command, we found the WARN as follows.
On on pod:
_worker0-0d9gnb:15:91 [3] include/socket.h 398 NCCL WARN Call to **write** failed : Connection reset  by peer.
worker0-0d9gnb:15:91 [3] transport.cu:153 NCCL WARN transport.cu:153 ->2 [Proxy thread error]_
On the other pod:
_worker0-0d9gnb:15:91 [3] include/socket.h 398 NCCL WARN Call to **recv** failed : Connection reset  by peer.
worker0-0d9gnb:15:91 [3] transport.cu:153 NCCL WARN transport.cu:153 ->2 [Proxy thread error]_
<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Environment
Training code is pull from https://github.com/pytorch/examples/tree/master/imagenet.
Model is Resnet. We used 8 V100s to train (4 on each node).
Batch size was set 8, 32 or 128 per GPU.
The network rate is about 500 MB/s to synchronize the gradients.

 - PyTorch Version (e.g., 1.0): both 1.0 and 0.4.1
 - OS (e.g., Linux): Ubunut 16.04
 - How you installed PyTorch (`conda`, `pip`, source): pip
 - Build command you used (if compiling from source): None
 - Python version: 3.6
 - CUDA/cuDNN version: CUDA 9.0/cuDNN 7.1.2
 - GPU models and configuration: V100 with NVLink
 - Any other relevant information:
Repository: flutter
Issue: didChangeDependencies docs don't specify where to call super
Labels: framework,d: api docs,P2,team-framework,triaged-framework

`didChangeDependencies` annotation says we must call `super.didChangeDependencies()` if we override this method in a `State` class, but the docs don't specify if we should do it at the beginning or at the end, like `initState` and many others do specify.
Repository: TypeScript
Issue: Support multi-threaded compilation for --build
Labels: Suggestion,Awaiting More Feedback,Scenario: Monorepos & Cross-Project References,Domain: tsc -b

## Search Terms

Project references, multi-thread, compilation, performance

## Suggestion

We have migrated our main project to use project references. It simplifies the development workflow, but brings basically 0 noticeable performance improvement (for both local development and CI). There's even an illusion that now we get worse performance during development.

I guess the main reason behind this is lacking support for multi-thread compilation.

## Use Cases

Improve compilation performance.

## Examples

N/A

## 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: material-ui
Issue: [RFC] createElement changes 
Labels: discussion,RFC

This is a premature tracking issue for changes in https://github.com/reactjs/rfcs/pull/107 that would affect this repository. Don't actually allocate time to this issue. Just something you might want to keep in the back of you head.

# defaultProps and function components
> Deprecate defaultProps on function components.

- need to investigate implications for `react-docgen`
- assuming we stick with not destructuring props in the function signature
```diff
function Component(props) {
-  const { someProp, anotherProp } = props;
+  const { someProp = 'default', anotherProp } = props;
}
-Component.defaultProps = {
-  someProp: 'defaulted'
-};
```
Looks doable for static analysis. If anybody encounters other patterns please post them here.

## related discussions
- https://github.com/mui-org/material-ui/pull/14865#discussion_r267619658

# `key` spreading
> Deprecate spreading key from objects.

Unknown if we do this

# refs
> Move ref extraction to class render time and forwardRef render time.

As far as I understood this we can get rid of `React.forwardRef` on function components and instead of

```jsx
const Component = React.forwardRef(function Component(props, ref) {
  return <div ref={ref} {...props} />;
});
```
do
```jsx
function Component(props) {
  return <div {...props} />;
};
```
which is equivalent to
```jsx
function Component({ ref, ...props }) {
  return <div ref={ref} {...props} />;
};
```
Really glad about this change. Although it would've been nice if this had landed with the `findDOMNode` deprecation :weary:
Repository: pytorch
Issue: Can we to build Caffe2 custom ops independently from a Caffe2 build ?
Labels: caffe2

I'm trying to create a custom op for Caffe2, but separately a Caffe2 build and Caffe2 source code.

Looking at this example (https://github.com/caffe2/caffe2_bhtsne), I could managed to build a custom op shared lib. But I had to hack a bit to have Caffe2 accepting to load my custom op shared lib without the following error `undefined symbol: _ZN6google8protobuf8internal10LogMessageC1ENS0_8LogLevelEPKci`.

After analysing the problem, it turns out that the problem is due to a mismatch between the caffe2 protobuf lib and my system protobuf lib:
- Caffe2 builds its own version of protobuf
- The custom layer code includes some Caffe2 headers (`caffe2/core/context.h`,
`caffe2/core/operator.h`), which drags some protobuf includes. The build takes the protobuf system library and then, I have the 'missing symbol' error when loading the custom op: `lib(dyndep.InitOpsLibrary('lib_my_custom_op.so'))`.

The work around I found was to:
1- make the custom op build point to the Caffe2 internal protobuf headers (in the caffe2 source dir)
2- statically link the custom op shared lib with the `libprotobuf.a` lib in the Caffe2 build.

I find this approach a bit hacky and I'd like to see if there is a cleaner solution to have users create custom ops without to need to get Caffe2 sources and build Caffe2 themselves.
Repository: rust
Issue: Compiler bad error message: E0277 error in Diesel
Labels: C-enhancement,A-diagnostics,T-compiler

I tried this code:
```
pub fn establish_connection(database_url: &str) -> Pool<PgConnection> {
        let manager = ConnectionManager::<PgConnection>::new(database_url);
        Pool::builder()
                .build(manager)
                .expect(&format!("Error connecting to {}", database_url))
}
```

And was expecting to get an error message something like:

```
Expected Pool<ConnectionManager<PgConnection>> got Pool<PgConnection>
```

Instead i got an misleading error:

```
the trait `diesel::r2d2::ManageConnection` is not implemented for `diesel::PgConnection`
```
Repository: vue
Issue: Missing information regarding v1.x EOL/LTS plans
Labels: intend to implement,improvement,1.x

### Version
1.0.28

### Reproduction link
[https://jsfiddle.net/3ay9r8hz/](https://jsfiddle.net/3ay9r8hz/)







### Steps to reproduce
Open README.md and search for End Of Life / LTS support

### What is expected?
Find information about expected response from VueJs regarding 1.x EOL/LTS

### What is actually happening?
Nothing is mentioned regarding the stance from VueJs on supporting 1.x branches

---
Opening after discussion with @LinusBorg on the forum: https://forum.vuejs.org/t/vue-1-x-end-of-life-support/58143

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: godot
Issue: Expose FileSystemDock to EditorInterface and restructure the FileSystemDock "*_moved" and "*_removed" signals
Labels: enhancement,topic:editor

**Godot version:**
Godot v3.1 Beta 11

**Issue description:**
1. Right now there is no way to access the `FileSystemDock` from the scripting API and as plugins/addons may need to access signals like `folder_moved` or `file_removed`.... it would be a good idea to expose it my Idea would be to use EditorInterface to expose the `FileSystemDock`.. using a `get_filesystem_dock()` method. This should be a 2 line change!

2. The other issue is also related to the signals `FileSystemDock` is exposing right now. For example `file_removed` right now has this signature `file_removed(file_path)` which is okay if you want to delete a single file but what if you are deleting a bunch of them? What happens right now is there is `signal_emit` is inside of a loop so there are a lot of signals being emitted in such cases. The solution I'm presenting could change the signature to files_removed(file_data):

Where file data could be a dictionary:
-> `Dictionary<old_name, new_name>`
Or an array of dictionaries:
-> `Array<Dictionary<>>` -> where the dictionary would contain "name", "new_name", "old_name"... keys depending on the signal emitting it!!

```
remove -> "path"
move -> "old_path", "new_path"
rename -> "old_path", "new_path"
duplicate -> "original_path", "new_path"
```

Accessing this signals is very helpful if you need to maintain a cache of files and don't want to rescan the whole FileSystem when just a file is changed.
Repository: pytorch
Issue: collate_fn returns subclass of torch.Tensor, but DataLoader transforms back to torch.Tensor
Labels: module: dataloader,triaged,module: __torch_function__

## 🐛 Bug / Unexpected Behaviour

I have a custom subclass of `torch.Tensor`: `PackedSequences`, which is meant to pack together sequences of variable length. I supply my `DataLoader` with a custom `collate_fn` which returns `PackedSequences` objects just fine. When I sample a batch, I find my `PackedSequences` objects have been converted to `torch.Tensor`, losing the elementary extra data in `PackedSequences`.

## To Reproduce
I'm unsure how to create a minimal example with _working data_.

```python
class PackedSequences(torch.Tensor):
    @staticmethod
    def __new__(cls, tensors, *args, **kwargs):
        flat = torch.cat(tensors)
        return super().__new__(cls, flat, *args, **kwargs)

    def __init__(self, tensors):
        self.lengths = [len(t) for t in tensors]

def collate_seq(batch):
   batch = PackedSequences(batch)
   assert type(batch) == PackedSequences
   return batch

dataset = None
dataloader = DataLoader(dataset, collate_fn=collate_seq)
batch = dataloader[0]
# type(batch[0]) == torch.Tensor
```

## Expected behavior
I'd expect 
```python
batch = dataloader[0]
# type(batch[0]) == PackedSequences
```

## Environment
PyTorch version: 0.4.1
OS: Linux Mint 18.3 Sylvia
GCC version: (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
CMake version: version 3.5.1
Python version: 3.6

cc @SsnL @VitalyFedyunin @ejguan @hameerabbasi @rgommers @peterbell10
Repository: TypeScript
Issue: Restrict template literal interpolation expressions to strings
Labels: Suggestion,Needs Proposal

## Search Terms

"template literal"
 
There are many hits, some which seem related, but everything I could find was a much bigger ask or wider in scope

## Suggestion

Add a compiler option to enforce using only strings in ES6 string template literals

## Use Cases

When using string literals, any variables are coerced to strings, which can lead to undesirable behavior. 

As far as I can tell there's no way to avoid this behaviour. In the spirit of tying everything, I'd prefer that only actual `string` types are permissible for use in string templates to avoid accidental coercion by passing null, undefined or object types that may have unexpected string representations, and force users to explicitly convert them to strings.

## Examples

For example:

```
function formatName(name: string | null): string {
   return `Name is: ${name}`;
} 

formatName(null)  === "Name is: null"
```

Ideally the compiler would fail  since `name` can be null.

## 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: go
Issue: all: document the default doc assumptions around concurrency, zero values, interfaces and return values
Labels: Suggested,Documentation,help wanted,NeedsInvestigation

In general, across all go libraries, some documentation rules are implicit. As @bradfitz [worded it](https://github.com/golang/go/issues/28461#issuecomment-433957200):
> The assumption when unstated is that things are not safe for concurrent use, that zero values are not usable, that implementations implement interfaces faithfully, and that only one return values is non-zero and meaningful.

This is a very important piece of knowledge and I think it should be documented somewhere. I don't know if the right place for it would be "Effective Go" (especially considering #28782) but it feels like newcomers should know this before they start browsing Go docs or writing Go code.
Repository: go
Issue: x/build: ensure that TryBot builders are using a released toolchain for GOROOT_BOOTSTRAP
Labels: Builders,NeedsInvestigation

The OpenBSD builder is using an unreleased development build of the `go` toolchain:
```
buildlet$ ./go1.4/bin/go version
go version devel +f14067f3c1 Tue Oct 30 17:45:19 2018 +0000 openbsd/amd64
```

That builder also runs as a TryBot. That means:
1. Failures of the builder stand in the way of active Go development (such as #30228).
3. Such failures are difficult to reproduce, and may be due to bugs fixed after Oct. 30.

Now that Go 1.12 is released, we should make sure that all of the TryBot builders are using a released `go` toolchain for their `GOROOT_BOOTSTRAP`.

CC @dmitshur @bradfitz