sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: FindPNG overwrites settings of BuildZLIB
Labels: priority: low,category: build/install

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => 3.4.1
- Operating System / Platform => Ubuntu 16.04
- Compiler => GCC 5.4.0

##### Detailed description

When I configure cmake with the options: ``-DBUILD_ZLIB=ON -DWITH_PNG=ON -DBUILD_PNG=OFF``, the settings of `ZLIB` that are set here:
https://github.com/opencv/opencv/blob/master/cmake/OpenCVFindLibsGrfmt.cmake#L22
are overwritten by the call of ``FindPNG`` included performed here:
https://github.com/opencv/opencv/blob/master/cmake/OpenCVFindLibsGrfmt.cmake#L162

The reason is that `FindPNG`:
https://github.com/LuaDist/libgd/blob/master/cmake/modules/FindPNG.cmake#L18
includes `FindZLIB`:
https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake
which does not check if ZLIB has already been found and simply overwrites corresponding variables, including the ``ZLIB_INCLUDE_DIRS``

Hence, when I finally build my project, the include directories for `zlib` are incorrect.
The current work-around is to use ``-DBUILD_ZLIB=ON -DWITH_PNG=ON -DBUILD_PNG=ON`` so that the png library is built, too.
Repository: create-react-app
Issue: verifyPackageTree() errors when wrong version dependency is installed in any parent directory
Labels: issue: needs investigation

### Is this a bug report?

Yes

### Did you try recovering your dependencies?

No. This issue presents an argument that there may be a bug in the [verifyPackageTree.js](https://github.com/facebook/create-react-app/blob/next/packages/react-scripts/scripts/utils/verifyPackageTree.js) logic added in the `next` branch. 

### Which terms did you search for in User Guide?

`version`, `dependenc`. This does not appear to be documented (and since it is internal, maybe it shouldn't be). There is discussion regarding documenting some of the packages related to this in issue in issue #4137 (suggested by @Timer [here](https://github.com/facebook/create-react-app/issues/4137#issuecomment-372003393)).

### Environment

```bash
$ node -v
v8.9.4

$ npm -v
5.7.1

$ yarn --version
1.5.1

```
Running on macOS `10.13.2`. 

### Steps to Reproduce

I created a reproduction project here: https://github.com/newoga/create-react-app-issue-4167

The project is a simple node package that depends on a version of `jest` that is incompatible with `create-react-app@2.0.0-next.47d2d941`. The project also contains a directory (`cra-app`) that was generated by `create-react-app`. The `react-scripts` dependency in that sub-project has been updated to `2.0.0-next.47d2d941`.

1. `git clone https://github.com/newoga/create-react-app-issue-4167`
2. `cd create-react-app-issue-4167`
3.  `yarn`
4. `yarn run`

### Expected Behavior

From a user perspective, the `yarn run` command should not error and the application should start. The user did not manually install an incompatible version of `jest` in the `create-react-app` generated project. The version of `jest` in the generated project's `node_modules` is the correct version and parent directories should not have an impact.

From a technical perspective, the `verifyPackageTree.js` logic should see that the `cra-app` project contains the correctly installed version of `jest` and stop checking parent directories. Parent directories should only be traversed if `jest` is not installed.

### Actual Behavior

An error occurs because parent directory depends on a version of `jest` that is incompatible with the version of `jest` that `create-react-app` generated project depends on.

### Reproducible Demo

https://github.com/newoga/create-react-app-issue-4167

**Edit:** Updated the issue number on the links.
Repository: godot
Issue: Shaders rendered on a transparent viewport are darker
Labels: topic:rendering,confirmed,documentation,topic:shaders

**Godot version:**
Godot Engine v3.0.2.stable.official


**OS/device including version:**
Windows 10 Home v1709 (Fall Creator's Update); Nvidia GTX 660 (I don't believe this is specific to my GPU, though) 


**Issue description:**
Shaders that get rendered on a transparent viewport (with nothing behind them) end up darker than they normally should. This can be solved by moving the object with a shader outside of any custom viewport, but I imagine that would end up getting messy quick, if viewports are being relied upon in some way.

What's expected:
![image](https://user-images.githubusercontent.com/1008889/37549656-c7cf2ac8-2958-11e8-87ad-c54ed1923996.png)

What actually happened:
![image](https://user-images.githubusercontent.com/1008889/37549662-d443e5b4-2958-11e8-85d3-cb9aba23ed1c.png)

I believe this has to do with how the transparent viewport itself is handled, as having something behind the shader under the viewport will cause the shader to not be dark. (Try moving the ColorRect to under the Viewport, above ShaderPanel, in the reproduction project to see what I mean.)



**Steps to reproduce:**
1. Create a viewport, and enable the "Transparent BG" option, as well as setting up the size. 
2. Create a Panel node (or really any node that supports a shader, I just use a Panel node) under that viewport.
3. Give the Panel node a shader that will, in some way, return some transparent pixels. The one included in the reproduction project below (shader.tres) will work for this purpose, and should show the effect fairly well due to creating a red-to-transparent gradient like in the images above.
4. Create a sprite, and set its texture to the ViewportTexture of the viewport.
5. (Optional, but makes the effect easier to see) Make a ColorRect, and place it behind the Sprite.
6. When the panel is under the Viewport, the image that the shader makes should be darker than expected. Moving the panel out of the Viewport's children will show the expected result.

**Minimal reproduction project:**
[Shader Blackness.zip](https://github.com/godotengine/godot/files/1821096/Shader.Blackness.zip)
Repository: TypeScript
Issue: Proposal: Overload Function.bind for when no argArray is provided.
Labels: Suggestion,In Discussion

# Background

Currently the `Function.bind` type definition defines only one signature:

```typescript
bind(this: Function, thisArg: any, ...argArray: any[]): any;
```

This destroys typing information on the bound function. Given difficulties in generating a new type for the bound function (the number of arguments has changed) this makes sense. However, it's very common to bind functions without using the `argArray` argument to `bind`. In this case a better solution can be made.

# Proposal

I propose that `bind` be overloaded with a second signature:

```typescript
bind<T extends Function>(this: T, thisArg: any): T;
bind(this: Function, thisArg: any, ...argArray: any[]): any;
```

# Example

To use a real world example on how this improves TypeScript I'll pull something from a personal project.

Types used:

```typescript
type SocketMsg = Guess | StateMsg;
type ChannelCallback<T> = (payload: T, ref: Ref, joinRef: Ref) => any;

export class Channel<T> {
  // ...
  on(event: ChannelEvent, callback: ChannelCallback<T>): void;
  // ...
}
```

```typescript
export default class GuessView extends Component<GuessProps, GuessState> {
  channel: Channel<SocketMsg>;

  connectSocket() {
    ...
    this.channel.on("guess", this.gameGuess.bind(this));
  }

  gameGuess(guess: Guess) {
    let newState = Object.assign({}, this.state);
    newState.guesses.push(guess);
    this.setState(newState);
  }
}
```

Under the current `bind` signature a change to `gameGuess` such that it accepts a different type would produce no error:

```typescript
  connectSocket() {
    ...
    this.channel.on("guess", this.gameGuess.bind(this)); // Now being provided the wrong type of function
  }
  gameGuess(guess: number) {
  // ...
```

But with `bind` utilizing a special definition for the case of only using the `thisArg` argument - the above example would produce an error.

> Argument of type '(guess: number) => void' is not assignable to parameter of type 'ChannelCallback<SocketMsg>'. Types of parameters 'guess' and 'payload' are incompatible. Type 'SocketMsg' is not assignable to type 'number'. Type 'Guess' is not assignable to type 'number'.
Repository: neovim
Issue: win: jobwait(): use WaitForSingleObject
Labels: platform:windows,job-control,needs:discussion,complexity:low,system

- `jobwait()` (which depends on `process_wait()` internally) needs to be revisited on Windows. 
 Maybe it should be implemented using `WaitForSingleObject`. https://stackoverflow.com/a/2153846/
  - ~~But `process_stop()` was changed in https://github.com/neovim/neovim/pull/8107 , so maybe `jobwait()` works better after that.~~
- Related: the "proper"/non-racey (Linux) way to kill a process tree is to [use cgroups](https://news.ycombinator.com/item?id=20599575).

Is this rare test failure related? 

```
  [  ERROR   ] C:/projects/neovim/test/functional\api\proc_spec.lua @ 17: api nvim_get_proc_children returns child process ids
  test\functional\helpers.lua:323: 
  retry() attempts: 434
  C:/projects/neovim/test/functional\api\proc_spec.lua:22: Expected objects to be the same.
  Passed in:
  (number) 3
  Expected:
  (number) 1
  
  stack traceback:
```
Repository: rust
Issue: Incorrect warning: Unnecessary unsafe block
Labels: C-enhancement,A-diagnostics,T-compiler

![image](https://user-images.githubusercontent.com/535593/37556345-f30afb3a-29f4-11e8-9fd1-e28909b48c77.png)

This warning is incorrect. It says for both unsafe blocks that they are unnecessary, and when either of the unsafe keywords is removed, it gives an error (of course).
It wrongly says that the first block is nested under the second unsafe block.

Before (nightly at end of January) this warning didn't occur.
Repository: opencv
Issue: ProjectPoints incorrect result w/Java bindings and z-coordinate small
Labels: category: calib3d,category: java bindings


##### System information (version)
- OpenCV => java_340
- Operating System / Platform => win64
- Compiler => javac 1.8

##### Detailed description
When I run projectPoints function using java code below with most simple inputs I get what I believe is incorrect answer when z is small.  Here is result that shows problem.   I find this works in python correctly.
(x,y,z)= [{0.0, 1.0, 1.0}, {0.0, 1.0, 5.0}, {0.0, 1.0, 10.0}]
(u,v)= [{0.0, 78.5398178100586}, {0.0, 19.73955535888672}, {0.0, 9.966865539550781}]
 should be
(u,v)=[{0.0, 100.0}, {0.0, 20.0}, {0.0, 10.0}]

##### Steps to reproduce
 ``` 
    public static void main(String[] args) {
    setDllLibraryPath("C:/aaa_eric/code/lib/x64");
    System.loadLibrary(Core.NATIVE_LIBRARY_NAME); //340

    MatOfPoint3f objectPts3f = new MatOfPoint3f(
            new Point3(0.0,1.0, 1.0),
            new Point3(0.0,1.0, 5.0),
            new Point3(0.0,1.0,10.0));
    MatOfPoint2f imagePts2f = new MatOfPoint2f();
    Mat rVec =  Mat.zeros(3,1, CvType.CV_64F);
    Mat tVec = Mat.zeros(3,1, CvType.CV_64F);

    //camera matrix, no distortion
    Mat kMat = Mat.zeros(3, 3, CvType.CV_64F);
    kMat.put(0, 0,
            100.0, 0.0, 0.0,
            0.0, 100.0, 0.0,
            0.0, 0.0, 1.0);
    Mat dMat = Mat.zeros(4, 1, CvType.CV_64F);

    Calib3d.projectPoints(objectPts3f, imagePts2f, rVec, tVec, kMat, dMat);

    System.out.println(objectPts3f.toList());
    System.out.println(imagePts2f.toList());
}
```
Repository: pytorch
Issue: Change THCudaCheck to suggest that device-side asserts likely mean that you have out of bound indices
Labels: module: cuda,module: error checking,triaged,module: assert failure,small

Hi
I have written the following code to train my model, after a few iterations it stops throwing a similar error as shown in the image. Note that error is similar but not same, it changes everytime. I have read all the answers here and pytorch forum for the similar errors, none of them works. Please help ...

![w1](https://user-images.githubusercontent.com/18963158/37559304-9b509616-2a49-11e8-81e8-30335762ffe2.png)
![w2](https://user-images.githubusercontent.com/18963158/37559306-a1f21738-2a49-11e8-8fb1-5dabf0b5bbdf.png)

 **Note that it is running for few iterations hence the starting few outputs** 
Thank you.
Repository: TypeScript
Issue: Removing "private" modifier from types
Labels: Suggestion,Awaiting More Feedback

[Feature suggestion]
How about this (for Typescript 2.8+):

```ts
type Friend<T> = {
    -private [P in keyof T]: T[P]
}
```
Repository: go
Issue: flag: Value description is inaccurate about zero-values
Labels: NeedsFix

```
// The flag package may call the String method with a zero-valued receiver,
// such as a nil pointer.
type Value interface {
    String() string
    Set(string) error
}
```
But in the example we have:
```
// String is the method to format the flag's value, part of the flag.Value interface.
// The String method's output will be used in diagnostics.
func (i *interval) String() string {
    return fmt.Sprint(*i)
}
```
Which would panic if called with a nil pointer receiver.

Actually that code should be fine because String is never called with a nil pointer receiver (flag.isZeroValue uses reflect.New if the receiver is a pointer), but it is still contradictory.

In fact, from the current phrasing you could assume that doing something like this is fine, which is not:
```
func (x *mytype) String() string {
    if x == nil { // guard for flag.Value requirement
        return "foo"
    }
    return *x.ptr // my constructor guarantees this is fine
}
```
Moreover from the flag.Value description it is not outright clear why the caller has to prepare to handle a value that he never produced.
Yes, the flag.PrintDefaults description answers that, but maybe it would be helpful to mention in the flag.Value description too, that the zero-value string representation is just used to turn off displaying the default (either because it is an unused value meaning *off*, or because it is an *obvious default*).
For instance if someone writes a flag.Value implementation whose zero-value (not the nil pointer) represents an inconsistent state (like I did), he would have to figure out what his String method is supposed to return in such a case and why it matters.
Repository: TypeScript
Issue: Missing error if ClassDeclaration is used in Statement position
Labels: Bug,Help Wanted,Effort: Casual

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨 -->
<!--
Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the CONTRIBUTING guidelines: https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ
-->

<!-- If you have a QUESTION:
   THIS IS NOT A FORUM FOR QUESTIONS.
   Ask questions at http://stackoverflow.com/questions/tagged/typescript
    or https://gitter.im/Microsoft/TypeScript
-->

<!-- If you have a SUGGESTION:
  Most suggestion reports are duplicates, please search extra hard before logging a new suggestion.
  See https://github.com/Microsoft/TypeScript-wiki/blob/master/Writing-Good-Design-Proposals.md
-->

<!-- If you have a BUG:
  Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  2.8.0-dev.20180318

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** class statement

**Code**

```ts
let codition = false as boolean;

if (condition)
    class C {} // runtime error if transpiled to ES2015 or above: Unexpected token class
if (condition)
    enum E { Foo } // should probably be an error?

new C(); // runtime error if transpiled to ES5, because 'C' is undefined
E.Foo; // runtime error: cannot read property 'Foo' of 'E'
```

**Expected behavior:**

Expected a compile error on `class C` and maybe on `enum E`

**Actual behavior:**
no error for these declarations, instead I get a runtime error when targeting  ES2015 or above.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior --> 

**Related Issues:**
Repository: rust
Issue: unused variable: warn about std::collections that are pushed to but not used afterwards
Labels: C-enhancement,A-lints,A-collections,T-compiler

````rust
fn main() {
        let mut var: Vec<i64> = Vec::new();
        var.push(1);
}
````
I would expect a warning here that ````var```` is unused.
I get that it is "used" in the sense that we push to it, however the *resulting* vector is still not done anything with.

Some kind of dead-store warning about the collection being unused/never queried after receiving an item might be helpful.
Repository: node
Issue: child_process: 'close' not emitted after .disconnect() in parent process
Labels: help wanted,child_process

* **Version**: v9.8.0
* **Platform**: Linux 64bit
* **Subsystem**: child_process

When calling ``child.disconnect()`` from a parent process (not in cluster mode), the child process object does not emit a ``close`` event after the ``exit`` event.

If however the child process itself calls ``process.disconnect()`` it works as expected.

**Example:**

```js
// parent.js
const child_process = require('child_process');

const child = child_process.fork('./child.js', {
    stdio: ['pipe', 'pipe', 'pipe', 'ipc']
});

setTimeout(() => {
    child.disconnect();
}, 1000);

child.on('exit', () => {
    console.log('exit');
});

child.on('close', () => {
    console.log('close');
});

child.stderr.pipe(process.stderr);
child.stdout.pipe(process.stdout);
```

```js
// child.js
process.on('disconnect', () => {
    console.log('cya');
});
```

**Output:**

```
cya
exit
```

**Expected Output:**

```
cya
exit
close
```
Repository: flutter
Issue: Update flutter_driver.CommonFinders docs to mention why find.byIcon etc aren't there and how to work around that
Labels: tool,d: api docs,t: flutter driver,P2,team-tool,triaged-tool

 In common finders class there are many methods for finding a widget by using ancestor, byElementPredicate, byElementType, byicon etc for QA in order to write test scripts using flutterDriver. 

Logs
The application runs fine with flutter run. I am trying to automated the testing.
```
Flutter Doctor
[√] Flutter (Channel beta, v0.1.5, on Microsoft Windows [Version 6.1.7601], locale en-US)
• Flutter version 0.1.5 at C:\Users\biswajeet\Documents\Flutter\flutter
• Framework revision 3ea4d06 (3 weeks ago), 2018-02-22 11:12:39 -0800
• Engine revision ead227f
• Dart version 2.0.0-dev.28.0.flutter-0b4f01f759

[√] Android toolchain - develop for Android devices (Android SDK 27.0.3)
• Android SDK at D:\sdk
• Android NDK location not configured (optional; useful for native profiling support)
• Platform android-27, build-tools 27.0.3
• ANDROID_HOME = D:\sdk
• Java binary at: C:\Program Files\Android\Android Studio1\jre\bin\java
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)

[!] Android Studio (version 2.3)
• Android Studio at C:\Program Files\Android\Android Studio
X Unable to find bundled Java version.
• Try updating or re-installing Android Studio.

[√] Android Studio (version 3.0)
• Android Studio at C:\Program Files\Android\Android Studio1
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)

[√] VS Code (version 1.21.0)
• VS Code at C:\Program Files (x86)\Microsoft VS Code
• Dart Code extension version 2.10.0

[√] Connected devices (1 available)
• Android SDK built for x86 • emulator-5554 • android-x86 • Android 7.1.1 (API 25) (emulator)

! Doctor found issues in 1 category.
```
Repository: go
Issue: x/build/maintner: Support additional label details
Labels: Builders

Right now, [`maintner.GitHubLabel`](https://godoc.org/golang.org/x/build/maintner#GitHubLabel) contains only the bare minimal information about labels: its id and name. Labels on GitHub have [additional useful information](https://github.com/golang/go/labels), including:

- color
- description

Is it in scope of `maintner.Corpus` to add support for tracking that additional information?

If this is chosen to be done, it should be a tiny increase of file size and memory requirements, compared to what's needed fetching all the issues already. Labels change very little. This is assuming it is implemented efficiently, where each issue only contains the label ids, but the label details are stored in a separate map. I.e., you probably wouldn't want copies of "Used by googlebot to label PRs as having a valid CLA. The text of this label should not change." label description text to be stored alongside with each issue that has the `cla: yes` label applied.

I'm not yet closely familiar with how data is stored, so I don't know if the efficient implementation can be attained while modifying `maintner.GitHubLabel` to contain the extra fields (it'd be more friendly API if so), or if they'd have to be stored in a separate map and looked up by id by the user. But either way is okay.

(/cc @bradfitz @andybons This is `maintner`-related.)
Repository: flutter
Issue: Should support to add an icon in the SnackBarAction
Labels: c: new feature,framework,f: material design,P3,team-design,triaged-design

Now only support a String .
why not use a widget?
Repository: scrcpy
Issue: Add the possibility to record inputs
Labels: feature request

Thank you again for your project.

Can we add the possibility to record the input ? The goal here is too use it with monkeyrunner or some functionnal testing tools :)
Repository: TypeScript
Issue: Bug: Incorrect module resolution for "valid" ES2015 specifiers with hashes and/or search parameters
Labels: Suggestion,Awaiting More Feedback,Domain: ES Modules

**TypeScript Version:**  2.8.0-dev.20180315

**Search Terms:** moduleResolution "module path" hash

**Code**

```ts
import { x as x1 } from './x.m.js';  // Typed correctly on hover
import { x as x2 } from './x.m.js#esm' // Typed as "import x…" on hover
```

**Expected behavior:**

Since module specifiers are now standardized, whereby if given an absolute specifier (or a relative specifier and the absolute referrer) should always result in a validly constructed `new URL(specifier, referrer)` it is expected that when a specifier includes suffix aspects like hash and search, that those aspects would be excluded from the pathname that is being resolved.

The implications of hash and search in runtime is beyond the scope of TypeScript and should remain so unless somehow the environment is customized to behave different (plugins maybe). However, if at all relevant, the specs have stated that at runtime each unique "resolved" URL (including hash and search) evaluates to a single unique instance of the respective module. It is not expected that TypeScript would need to determine if and when a module is a specific unique instance. It is however expected that when suffix aspects are included in the specifier that TypeScript would still resolve it's types identically as it does for the pathname sans hash and search.

Sorry for the long text!

**Actual behavior:**

TypeScript does not resolve pathnames with hash or search parameters.