sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Comments before a decorator produces a weird comma in the emitted JS output
Labels: Bug,Domain: Comment Emit

**TypeScript Version:**  3.0.0-dev.20180522

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** decorator comma comment

**Code**

```ts
function decorator1(target) {}
function decorator2(target) {}
function decorator3(target) {}

@decorator1
// this is a comment
@decorator2
@decorator3
class Foo {

}
```

**Expected behavior:**
```js
function decorator1(target) { }
function decorator2(target) { }
function decorator3(target) { }
let Foo = class Foo {
};
Foo = __decorate([
    decorator1,
    // this is a comment
    decorator2,
    decorator3
], Foo);
```

**Actual behavior:**
```js
// ... _decorate helper ...

function decorator1(target) { }
function decorator2(target) { }
function decorator3(target) { }
let Foo = class Foo {
};
Foo = __decorate([
    decorator1
    // this is a comment
    ,
    decorator2,
    decorator3
], Foo);
```
**Playground Link:** https://www.typescriptlang.org/play/#src=function%20decorator1(target)%20%7B%7D%0D%0Afunction%20decorator2(target)%20%7B%7D%0D%0Afunction%20decorator3(target)%20%7B%7D%0D%0A%0D%0A%40decorator1%0D%0A%2F%2F%20this%20is%20a%20comment%0D%0A%40decorator2%0D%0A%40decorator3%0D%0Aclass%20Foo%20%7B%0D%0A%0D%0A%7D

**Related Issues:** found none
Repository: go
Issue: os: ModeSetgid has no effect while using with Mkdir() on Linux
Labels: help wanted,OS-Linux,NeedsFix

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?

go version go1.9.4 linux/amd64

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/root/go"
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build203196509=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

### What did you do?

```go
package main

import (
	"os"
)

func main() {
	os.Mkdir("test", 0770 | os.ModeSetgid)
}
```

### What did you expect to see?

```
# ls -la test
insgesamt 4
drwxr-s---.  2 root root    6 24. Mai 04:09 .
dr-xr-x---. 13 root root 4096 24. Mai 04:09 ..
#
```

### What did you see instead?

```
# ls -la test
insgesamt 4
drwxr-x---.  2 root root    6 24. Mai 04:09 .
dr-xr-x---. 13 root root 4096 24. Mai 04:09 ..
#
```

### Why did this happen?

According to `strace -f ./mkdir` the Go stdlib behaves as expected...

```
[pid  6782] mkdirat(AT_FDCWD, "test", 02770 <unfinished ...>
[pid  6782] <... mkdirat resumed> )     = 0
```

... but on Linux this is not enough, see `mkdirat(2)`:

```
The mkdirat() system call operates in exactly the same way as mkdir(2), (...)
```

... and `mkdir(2)`:

```
The  argument  mode  specifies the permissions to use.
It is modified (...): the permissions of the created directory are (mode & ~umask & 0777).
Other mode bits of the created directory depend on the operating system.
For Linux, see below.
(...)
That is, under Linux the created directory actually gets mode (mode & ~umask & 01777)
```

### How could this be fixed?

Similar to #8383, [via Chmod](https://codereview.appspot.com/102640045/patch/120001/130001).
Repository: godot
Issue: CSG shapes textures are mapped different than normal meshes
Labels: bug,discussion,confirmed,topic:3d

**Godot version:**
3.1.dev.5b11d16


**OS/device including version:**
Win10 64 bit. Geforce gtx 950M


**Issue description:**
added texture to a CSGcube and it did not align as you would expect. Works fine if you create a CSGmesh
![image](https://user-images.githubusercontent.com/35765659/40493099-b42b4c60-5f7a-11e8-90f0-45d3633fddd5.png)



**Steps to reproduce:**
Create a mesh and a CSGshape of same type. add texture to both and see.
Repository: neovim
Issue: Windows: console: <C-2>, <C-/>
Labels: status:blocked-external,platform:windows,tui

A couple control key combos are missing on Windows, notably `^@` which prevents `<C-space>` mappings.

- `nvim --version`: 0.2.2 (still present in 0.3)
- Vim (version: 8.1) behaves differently? Yes
- Operating system/version: Win10 17672
- Terminal name/version: conhost
- `$TERM`: N/A

### Steps to reproduce using `nvim -u NORC`
Type the following keys in insert mode preceded by `<C-v>`: `<C-2> <C-space> <C-/>`

### Actual behaviour
`<C-2>` and `<C-/>` are not recognized at all, `<C-space>` is recognized as regular space.

### Expected behaviour
The control characters `^@^@^_` are inserted.

There is slightly different behavior between Windows vim and Linux vim/nvim here. On Windows vim, `^_` is not generated when pressing `<C-/>` (but it can be generated by the _ key still), and `<C-space>` does not generate `^@`, it types a space, but `<C-space>` itself is mappable. Copying either behavior would probably be fine, although I'd prefer to mimic Linux as it leads to a less complicated vimrc.
Repository: opencv
Issue: opencv js - cv.resize causes exceptions when fx and fy randomly changed very fast
Labels: incomplete,category: javascript (js)

##### System information (version)
- OpenCV => 3.4.1
- Operating System / Platform => JavaScript
- Compiler => Emscripten SDK

##### Detailed description

Function cv.resize is very unstable and causes all Mat to throw exception, when trying to get Mat.data. 

**Situation:**
An image should be scaled to some size every frame captured from Web Cam, then combined with this captured frame and displayed.

**Conditions:**
_src_ Mat - image gotten from canvas, loaded once at the beginning. 
_dst_ Mat - temporary Mat
_dsize_ - zero
_fx, fy_ - randomly changed doubles every captured frame from web cam. Everything is OK when fx and fy are decimal or when fx and fy stays same every frame. But if fx and fy are randomly changed every captured frame, all Mat in the script loses their reference.
Algorithm - does not matter.

##### Steps to reproduce
Launching below script will cause this error after a few moments:

> v Uncaught abort(13). Build with -s ASSERTIONS=1 for more info.
> abort | @opencv.js?ver=4.9.6:55
> Zlc | @opencv.js?ver=4.9.6:48
> Vt | @opencv.js?ver=4.9.6:24
> kjc | @opencv.js?ver=4.9.6:48
> dynCall_iii_384 | @VM210:4
> Mat$type | @VM211:8
> Module.imshow | @opencv.js:55


Try use high resolution image to cause exception faster.
```.js
    function Launch(video, imageCanvas) {
	let img = cv.imread(imageCanvas);
	let cap = new cv.VideoCapture(video);

	const FPS = 30;
	navigator.mediaDevices.getUserMedia({ video: true, audio: false })
		.then(function(stream) {
			video.srcObject = stream;
			video.play();
		})
		.catch(function(err) {
			console.log('An error occurred! ' + err);
		});

	function processVideo() {

		let imgScaled = new cv.Mat();
		let begin = Date.now();
		let srcVid = new cv.Mat(video.height, video.width, cv.CV_8UC4);
		cap.read(srcVid);

		let numb = (Math.random() * (0.12 - 5.0) + 5.0);
		cv.resize(img, imgScaled,  new cv.Size(0,0),numb,numb, cv.INTER_NEAREST );
			
		imgScaled.delete();
		cv.imshow('canvasOutput', srcVid);
		srcVid.delete();
		// schedule next one.
		let delay = 1000/FPS - (Date.now() - begin);
		setTimeout(processVideo, delay);
	}
	// schedule first one.
	setTimeout(processVideo, 0);
    }
```
Repository: go
Issue: x/tools/go/buildutil: make ExpandPatterns support all go tool patterns
Labels: Tools

This TODO exists within the ExpandPatterns function:

	// TODO(adonovan): support other features of 'go list':
	// - "std"/"cmd"/"all" meta-packages
	// - "..." not at the end of a pattern
	// - relative patterns using "./" or "../" prefix

I'd very much like to use `golang.org/x/tools/go/buildutil` instead of `github.com/kisielk/gotool` but the current limitations mean that I can't do so without breaking backward compatibility.
Repository: flutter
Issue: flutter_image handling of exceptions from http clients not allowing retries.  
Labels: package,team-ecosystem,P3,p: flutter_image,triaged-ecosystem

In the flutter_image library, the FetchStrategyBuilder.build method returns a FetchStrategy that requires a non-null FetchFailure.httpStatusCode to return FetchInstructions.attempt any time after the first call to FetchStrategyBuilder.build.  However, in NetworkImageWithRetry._loadWithRetry, when the http client throws an exception, a FetchFailure with a httpStatusCode of null is created, so no retry occurs on exceptions from the http client (in my case on a timeout).  Is this the expected behaviour or should FetchFailure.httpStatusCode be 0 (to correspond with the Network Error code in defaultTransientHttpStatusCodes) when there's an exception thrown by the http client?
Repository: godot
Issue: Light2D "Add" mode does not appear to be additive
Labels: discussion,topic:rendering

**Godot version:**
3.0.2


**OS/device including version:**
Windows 10.0.16299; Solus Linux


**Issue description:**
When I create a Light2D in "Add" mode and with energy 1, and I apply it to a texture, the light texture does not appear to be applied linearly. In particular, if the background texture is black, there is no effect, and as the brightness of the background texture increases, the amount of light value applied to the texture seems to increase. See screenshots:

Here, the background is black and the light has no effect on the background (disregard the white circle, it's a sprite):
![light_black](https://user-images.githubusercontent.com/1829032/40519029-48049bac-5f72-11e8-8dd0-982a25a7fbd9.png)

Here, the background is `#202020`, so it is not significantly brighter, but now the light texture is being applied to the background.
![light_darkgrey](https://user-images.githubusercontent.com/1829032/40519167-038250b8-5f73-11e8-9df2-c1a3c3434dd1.png)

Here, the background is `#282828`, so it is only very slightly brighter than the above screenshot, but the light appears disproportionately brighter:

![light_lightergrey](https://user-images.githubusercontent.com/1829032/40519409-385ac7b0-5f74-11e8-98c3-cb2a28562412.png)

It definitely seems like there's some sort of multiplicative effect happening here. Am I completely misunderstanding how 2D lighting is supposed to work, or is this not right? The docs definitely seem to suggest that the pixel values will be directly added together.

**Steps to reproduce:**
Open the "2D Lights and Shadows" sample project and brighten or darken the `bg.png` image to observe the effects.


**Minimal reproduction project:**
Open the "2D Lights and Shadows" sample project
Repository: flutter
Issue: flutter tool should check for consistency between --local-engine, --debug/profile/release and --target-platform
Labels: team,tool,P2,team-tool,triaged-tool

For example, if you use an ARM32 local engine, don't specify a target-platform and have a Pixel connected, the target-platform will be auto detected as ARM64, flutter tool won't pass --no-use-integer-division to gen_snapshot, and the engine will crash with a SIGILL on sdiv.

@cbracken
Repository: go
Issue: x/text/internal/colltab: numeric.go should not skip "0" when is followed by a non-number
Labels: NeedsInvestigation,FixPending

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
go1.8.5

### Does this issue reproduce with the latest release?
yes

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tlin/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/9g/342mj7bd3h776hmqdw5c9xdn5wch_k/T/go-build934806691=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

### 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.

```go
package main

import (
	"fmt"

	"golang.org/x/text/collate"
	"golang.org/x/text/language"
)

func main() {
	strings := []string{
		"file0_1",
		"file1_1",
	}
	collator := collate.New(language.English, collate.Numeric)
	collator.SortStrings(strings)
	for _, s := range strings {
		fmt.Println(s)
	}
}
```

### What did you expect to see?

The output to be: 
```
file0_1
file1_1
```

### What did you see instead?

The actual output is:
```
file1_1
file0_1
```
Possible fix would be:
```diff
+++ golang.org/x/text/internal/colltab/numeric.go
@@ -79,7 +79,11 @@
 		return ce, n
 	}
 	// ce might have been grown already, so take it instead of buf.
-	nc.init(ce, len(buf), isZero)
+      nextByte := byte('0');
+      if n < len(s) {
+         nextByte = s[n]
+      }
+	nc.init(ce, len(buf), isZero, nextByte)
 	for n < len(s) {
 		ce, sz := nw.Weighter.AppendNext(nc.elems, s[n:])
 		nc.b = s
@@ -104,7 +108,11 @@
 	if !ok {
 		return ce, n
 	}
-	nc.init(ce, len(buf), isZero)
+      nextByte := byte('0');
+      if n < len(s) {
+         nextByte = s[n]
+      }
+	nc.init(ce, len(buf), isZero, nextByte)
 	for n < len(s) {
 		ce, sz := nw.Weighter.AppendNextString(nc.elems, s[n:])
 		nc.s = s
@@ -129,10 +137,10 @@
 
 // init completes initialization of a numberConverter and prepares it for adding
 // more digits. elems is assumed to have a digit starting at oldLen.
-func (nc *numberConverter) init(elems []Elem, oldLen int, isZero bool) {
+func (nc *numberConverter) init(elems []Elem, oldLen int, isZero bool, nextByte byte) {
 	// Insert a marker indicating the start of a number and and a placeholder
 	// for the number of digits.
-	if isZero {
+	if isZero && nextByte >= byte('0') && nextByte <= byte('9') {
 		elems = append(elems[:oldLen], nc.w.numberStart, 0)
 	} else {
 		elems = append(elems, 0, 0)
```
Repository: flutter
Issue: [google_maps_flutter] Plugin Crashes Without a Helpful Error message on iOS If No API Key Specified
Labels: c: crash,platform-ios,p: maps,package,a: error message,has reproducible steps,P2,c: fatal crash,found in release: 2.0,found in release: 2.2,team-ios,triaged-ios

https://github.com/flutter/plugins/tree/master/packages/google_maps_flutter

If you don't include the API key in an iOS app the google_maps_flutter plugin will crash hard with the following with no indication as to why:
```
*** First throw call stack:
(
        0   CoreFoundation                      0x000000010cd3912b __exceptionPreprocess + 171
        1   libobjc.A.dylib                     0x000000010c3cdf41 objc_exception_throw + 48
        2   CoreFoundation                      0x000000010cdae245 +[NSException raise:format:] + 197
        3   Runner                              0x00000001058b5723 +[GMSServices checkServicePreconditions] + 182
        4   Runner                              0x00000001058b2562 +[GMSServices sharedServicesSync] + 110
        5   Runner                              0x00000001058a1fb9 -[GMSMapView sharedInitWithServices:camera:forPlaces:] + 156
        6   Runner                              0x00000001058a1421 -[GMSMapView initWithFrame:camera:] + 123
        7   Runner                              0x00000001058a1245 +[GMSMapView mapWithFrame:camera:] + 104
        8   Runner <…>
```
Only if you run "flutter run -v" will you get the actual reason:
```
[ +111 ms] [DEVICE LOG] 2018-05-24 20:41:34.563396-0500  localhost Runner[72738]: (CoreFoundation) *** Terminating app due to uncaught exception 'GMSServicesException', reason: 'Google Maps SDK for iOS must be initialized via [GMSServices provideAPIKey:...] prior to use'
[        ] [DEVICE LOG] *** First throw call stack:
```
It seems kind of harsh. If possible it would be nice to display a console message at the minimum.
Repository: pytorch
Issue: torch.Tensor.new() disappeared in 0.4 doc
Labels: module: docs,triaged,module: deprecation,module: tensor creation

There are only `torch.new_*()` in 0.4 doc now.

But I can still use this function, no deprecated warning, and I do not found any deprecated note about it in 0.4 release too.

cc @jlin27 @mruberry
Repository: pytorch
Issue: [caffe2] how to using the Mul operator to mul the input vetor
Labels: caffe2

Hi!  In my project, i need to mul some blobs [x1,x2,x3,x4],
but i found that the Mul opeartor only support 2 inputs in caffe2,
Any using the loop will cost too much memory of my graphics card,
So is there any good solution to help this problem? Thank you !
Repository: TypeScript
Issue: Missing type description in suggestion popup
Labels: Bug

Note, this issue was discovered while trying to reproduce https://github.com/Microsoft/TypeScript/issues/24408.

**TypeScript Version:**  `typescript@3.0.0-dev.20180522`

**Code**
```ts
// x.ts
import { Enum } from '~/types'

type ObjectFromEnum<T, R extends string = Enum> = {
  [S in R]: T
}

export const SYMBOLS: ObjectFromEnum| // <- cursor for ctrl+space hints here

// types.d.ts
export type Enum = 'a' | 'b' | 'c'
export type EnumX = 'd' | 'e' | 'f'
export type ObjectFromEnumX<T, R extends string = EnumX> = {
  [S in R]: T
}
```

**Expected behavior:**
Expected is that suggested types are fully described for both local and imported types.
In this case locally defined type `ObjectFromEnum`.
![image](https://user-images.githubusercontent.com/2313018/40551233-a51cc6f0-603c-11e8-8f15-ecaf6ec7e74e.png)


**Actual behavior:**
Type `ObjectFromEnumX` is not fully described for external type.
![image](https://user-images.githubusercontent.com/2313018/40551315-d0587526-603c-11e8-9508-89dd5ea57668.png)

After the import is done and suggestion popup is invoked again, the missing generics are presented.
![image](https://user-images.githubusercontent.com/2313018/40551399-16dbf11c-603d-11e8-93ba-fe12de209f27.png)


<hr/>

Also note that in the linked issue above, the actual behavior is different (v2.9. vs v3.0.), the referenced `EnumX` in the generic is also resolved.
![image](https://user-images.githubusercontent.com/2313018/40550020-43948e16-6039-11e8-8636-f0d978cc4707.png)
Repository: go
Issue: x/build/cmd/gopherbot: follow-up backport comments are ignored
Labels: help wanted,Builders,NeedsFix,Friction

In https://github.com/golang/go/issues/25242#issuecomment-392110768 I ask for gopherbot to create a backport for 1.9 as well (the original backport was only for 1.10). But an issue was not created (had to create it manually).

/cc @FiloSottile
Repository: pytorch
Issue: Feature Request: Logistic Distribution
Labels: module: distributions,feature,triaged

Could we have logistic distribution in PyTorch?

https://github.com/tensorflow/tensorflow/blob/r1.8/tensorflow/contrib/distributions/python/ops/logistic.py

cc @fritzo @neerajprad @alicanb @nikitaved @brianjo @mruberry
Repository: go
Issue: runtime: support resuming a single goroutine under debuggers
Labels: NeedsInvestigation,Debugging,compiler/runtime

[CL 109699](https://golang.org/cl/109699) added support for debugger function call injection, but has an annoying limitation: it requires that the debugger resume the entire Go process after injecting the function call (and, to inject into a runnable but not running goroutine, it requires resuming the entire process even before injecting the call).

@heschik argued that this is a pretty bad experience. E.g., all the user wants to do is call String() to format something, and the entire process moves under them in the meantime. It's also different from what other debuggers do, which could surprise users.

This is tricky to solve. Simply resuming only the thread where the call was injected doesn't work because 1) it could easily lead to runtime-level deadlocks if any other thread is in the runtime, 2) the runtime could just switch to a different goroutine on that thread, and 3) if the GC kicks in it will try to cooperatively stop the other threads and deadlock.

I think solving this requires at least a little help from the runtime to pause all other user goroutines during the injected call. I'm not sure what exact form this should take, but I'm imagining the debugger could use call injection to first inject a runtime call to stop user goroutines, and then inject the real call.

However, even this gets tricky with non-cooperative safe points (e.g., the runtime would need to use the register maps to immediately preempt the other goroutines rather than waiting for them to reach a cooperative safe point) and with goroutines that are at unsafe points (particularly goroutines that are in the runtime). One possibility would be to have the debugger inject this "stop" call on every running thread. Using the call injection mechanism takes care of stopping at non-cooperative points, and would give the debugger the opportunity to step other goroutines past unsafe points and out of the runtime before injecting the stop. This puts some complexity into the debugger, but it should already have most of the core mechanisms necessary to do this (such as single stepping ability). Specifically, I'm picturing a protocol like:

1. For each thread, attempt to inject a `runtime.debugStop` call. Let all threads resume.
2. These calls will notify the debugger when the goroutine is successfully stopped, or the debug call injection will fail.
3. For injection that failed because the thread is in the runtime, unwind the stack and insert a breakpoint at the first return to user code. At that breakpoint attempt another `debugStop`. For injection that failed because the thread is at an unsafe point, single step the thread, attempting to inject `debugStop` at each step.
4. Let the remaining threads continue running. Repeat steps 2 through 4 until all threads are stopped.

This is basically a debugger-assisted non-cooperative stop-the-world. For Go 1.12, I plan to implement non-cooperative preemption directly in the runtime, which may move much of this logic into the runtime itself.

/cc @aarzilli
Repository: pytorch
Issue: [PyTorch] weight tensor dimension assumption
Labels: module: nn,triaged

Now in both inits <del>and spectral norm</del>, we assume that dim `0` of `weight` is the output feature dim. However, this is incorrect for `ConvTranspose`. 

We need to figure out how to properly handle those.

cc @albanD @mruberry
Repository: go
Issue: math/big: improve threshold calibration
Labels: Performance,NeedsInvestigation

For multiplication and squaring we use different algorithms depending on the input length. We currently have 3 threshold constants to decide which algorithm to use. These are calibrated with TestCalibrate.

This calibration takes multiple minutes to run and the outcome doesn't seem to be that reliable. Last noticed in [cl 105075](https://go-review.googlesource.com/c/go/+/105075).

Quote @griesemer :
> On my machine, the threshold is much lower (less than 200). At some point we need to find a better way to determine these values.

I see three issues:
1. Reliable result on a single machine: this worked on my machine, but didn't for @ALTree.
2. Similar results on different machines: for calibrating `karatsubaSqrThreshold` we got differences of more than 100% between our 3 machines
3. Slowness. This might be less important, but if this wouldn't take multiple minutes where you shouldn't run other programs it might be easier to ask more people to run the calibration.