sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: RigidBody2D tunnels CollisionShape2D and bounces back with even greater momentum
Labels: bug,topic:physics

**Godot version:**
3.2

**OS/device including version:**
Windows 10

**Issue description:**
When a `RigidBody2D` with very small mass (e.g. 0.1) is connected with a `PinJoint2D` to another `RigidBody2D` with a larger mass like (e.g. 100), the heavier body pushes the smaller mass through the `CollisionShape2D` of another object that it is collides with and bounces back with even greater momentum. This effect diminishes as you keep increasing the mass of the lighter body.

`RigidBody2D` should not pass through `CollisionShape2D` of another object and should not bounce back with a greater momentum than before collision.
![](https://i.imgur.com/usQYWJz.gif)

**Minimal reproduction project:**
[CollisionBug.zip](https://github.com/godotengine/godot/files/4213102/CollisionBug.zip)
Repository: create-react-app
Issue: Print QRCode for local network IP address
Labels: issue: proposal,needs triage

I usually like to test my mobile site versions on real devices. A printed QRCode of the local network IP address would make connecting more convenient by just scanning a QRCode instead of having to type out the IP address.
I think something like a CLI flag à la `react-scripts start --print-qrcode` could work nicely.

Libraries that could be used:
- [qrterminal](https://github.com/mdp/qrterminal)
- [qrcode-terminal](https://github.com/gtanner/qrcode-terminal)

Looking for feedback!
Repository: react
Issue: Bug: [eslint-plugin-react-hooks] exhaustive-deps false positive on "unnecessary" dependency if its a React component
Labels: Type: Bug,Component: ESLint Rules

## Steps to reproduce

1. create a memoized value using `useMemo`
2. a React component is used in the creation of this value, in a JSX expression
3. specify the React component in the dependency array

Link to code example: https://github.com/zeorin/eslint-plugin-react-hooks-repro

## The current behavior

```
React Hook useMemo has an unnecessary dependency: 'Component'. Either exclude it or remove the dependency array react-hooks/exhaustive-deps
```

## The expected behavior

No lint errors.

## More details

A simple repro (taken from the link above) is:

```javascript.jsx
function Foo({ component: Component }) {
	const memoized = useMemo(() => ({
		render: () => <Component />
	}), [Component]);

	return memoized.render();
}
```

## Workarounds

If one changes the component to lowercase, the lint error goes away. It does also mean that we need to change the way we render the component:

```javascript.jsx
function Foo({ component }) {
	const memoized = useMemo(() => ({
		render: component
	}), [component]);

	return memoized.render();
}
```

Alternatively we can decide not to use JSX, in which case the lint rule functions correctly, too:

```javascript.jsx
function Foo({ component: Component }) {
	const memoized = useMemo(() => ({
		render: () => React.createElement(Component)
	}), [Component]);

	return memoized.render();
}
```

## Impact

Currently it is hard to use props that are components in a JSX expression if one is using the `exhaustive-deps` rule.

This is also compounded by the fact that this rule has a ESLint fix that removes the dependency, thus changing the behaviour of the code and leading to bugs. See https://github.com/facebook/react/issues/16313 for that bug report.
Repository: opencv
Issue: Unify fisheye and omnidir API
Labels: category: calib3d,RFC

##### System information (version)

- OpenCV => 4.2.0-dev
- Operating System / Platform => any
- Compiler => any

##### Detailed description

It would be great to have a matching API for fisheye and omnidirectional cameras. There are a couple of features missing from each to complete the set:

fisheye     | omnidir
------------|------------
calibrate | calibrate
distortPoints | n/a
estimateNewCameraMatrixForUndistortRectify | n/a
initUndistortRectifyMap | initUndistortRectifyMap (arg name inconsistent - mltype vs m1type)
projectPoints | projectPoints (missing overload w/ affine mtx)
stereoCalibrate | stereoCalibrate
n/a | stereoReconstruct
stereoRectify | stereoRectify
undistortImage | undistortImage
undistortPoints | undistortPoints
Repository: godot
Issue: Removing and adding lots of sprites is very slow if done in the same tick
Labels: bug,topic:core,confirmed,performance

**Godot version:** 3.2 stable

**OS/device including version:** Arch Linux, kernel 5.5.2

**Issue description:**
When deleting and adding a lot of sprites at once Godot's performance heavily depends upon whether deletion and addition are done in the same tick or not.

In detail: I added around 3000 sprites as children to the same (empty) parent by a script which is reasonable fast. When I then sometime later remove all those nodes again (by calling `queue_free()` on them and removing them from the parent) and immediately add another 3000 new ones to the same parent, Godot takes significantly more time than when just creating and adding new sprites. I'd like to note that the hiccup occurs between frames (i.e. Godot's calls to `_process()`) and not during my calls to `queue_free()` or `add_child()` or anywhere in my script code.

I was then able to find a kind of workaround that is a lot faster. Instead of deleting and adding all the sprites in the same tick, I first delete all sprites in one `_process()` call and delay creation of new ones until the next `_process()` call

The slow down factor depends - according to my experiments - on the number of nodes removed/added. When deleting and adding 10000 sprites it takes about 1 second when splitting work into to ticks while it takes about 10 seconds when doing all the work in one tick, while the factor is less than 2 when using just 500 nodes.

It is also important to node that the difference is measurable but rather low when removing and adding bare `Node2D`s instead of sprites. I got a difference of 200 ms of about 12 % when trying 40000 nodes.

The observations I made where basically the same when running the project in the editor or a Linux or HTML5 export.

**Steps to reproduce:**
Download the example project I created and run it. You should see debug/console output in the likes of

    Preparing ...
    Removing nodes
    Creating nodes
    Action took 885 ms
    Removing and recreating nodes
    Action took 10642 ms
    Done

You can then close the window. To run the experiment with different number of sprites change `num_sprites` of the root node in scene `Main.tscn` or in the script `Main.gd`.

**Minimal reproduction project:**
Here I'm using `OS.get_ticks_msec()` to measure time. The first number printed is the time measured over two ticks*, first deleting previously created nodes, second adding the same amount again. The second number printed is measured over one tick* where deletion and addition are done immediately after another.

*The starting time stamp is stored in the first tick where the work load starts. The ending time stamp is retrieved in the tick immediately following the tick where the work load ends. This allows the time between calls to `_process()` to be included in the measurement.

[BugQueueFreeDelay.zip](https://github.com/godotengine/godot/files/4214074/BugQueueFreeDelay.zip)
Repository: opencv
Issue: FLANN feature matching in opencv.js
Labels: category: javascript (js)

Hi! FlannBasedMatcher is present in C++ version, is there some way to use it in OpenCV.js? Maybe I need to change some of the build parameters to get this function in the wasm version of OpenCV?
Repository: go
Issue: dl: return the same exit status of the wrapped command
Labels: NeedsDecision

Currently, the `Run` function in the `internal/version` and `gotip` packages returns the exit status `1` if the wrapped command fails:

```
if err := cmd.Run(); err != nil {
		// TODO: return the same exit status maybe.
		os.Exit(1)
	}
	os.Exit(0)
```

I'm developing a package that wraps various `go` commands, and I'm adding support for testing different versions of the `go` tool.  Unfortunately one test that checks for the exit status 2 now fails.

I'm using this patched version locally:
```
diff --git a/gotip/main.go b/gotip/main.go
index 6338234..0a8f0db 100644
--- a/gotip/main.go
+++ b/gotip/main.go
@@ -57,9 +57,8 @@ func main() {
 	}
 	cmd.Env = dedupEnv(caseInsensitiveEnv, append(os.Environ(), "GOROOT="+root, "PATH="+newPath))
 	if err := cmd.Run(); err != nil {
-		if _, ok := err.(*exec.ExitError); ok {
-			// TODO: return the same exit status maybe.
-			os.Exit(1)
+		if err, ok := err.(*exec.ExitError); ok {
+			os.Exit(err.ExitCode())
 		}
 		log.Fatalf("gotip: failed to execute %v: %v", gobin, err)
 	}
diff --git a/internal/version/version.go b/internal/version/version.go
index a63c649..349bd6e 100644
--- a/internal/version/version.go
+++ b/internal/version/version.go
@@ -61,7 +61,9 @@ func Run(version string) {
 	}
 	cmd.Env = dedupEnv(caseInsensitiveEnv, append(os.Environ(), "GOROOT="+root, "PATH="+newPath))
 	if err := cmd.Run(); err != nil {
-		// TODO: return the same exit status maybe.
+		if err, ok := err.(*exec.ExitError); ok {
+			os.Exit(err.ExitCode())
+		}
 		os.Exit(1)
 	}
 	os.Exit(0)
```
Repository: TypeScript
Issue: Assignment to constant variables imported from ES6 modules allowed
Labels: Bug


<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  
3.7.5

**Search Terms:**
- Assignment to constant variable in imported modules

**Code**

```ts
// originalFunction.js
let originalFunction = () => console.log('Original function executed! 🏁');
export {originalFunction};

// patchFunction.js
import {originalFunction} from "./originalFunction.js";
originalFunction = () => console.log('patched function 💥');

// run.js
import './patchFunction.js';
import {originalFunction} from './originalFunction.js';

originalFunction();
```

**Expected behavior:**
After `tsc` (with `"allowJs": true`, `"target": "es5"` or es6, `"module": "commonjs"`) and running `node run.js` in output folder you should get `Uncaught TypeError: Assignment to constant variable.   at patchFunction.js:6` 

Just like you'd get with _pure_ es6 in browser with this html (on same 3 original .js files):

```html
<html >
<head></head>
<body>
<script type="module" src="originalFunction.js"></script>
<script type="module" src="patchFunction.js"></script>
<script type="module" src="run.js"></script>
</body>
</html>
```

**Actual behavior:**

Output is `patched function 💥` because the code is transpiled in this manner:

```js
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
var originalFunction_js_1 = require("./originalFunction.js");
originalFunction_js_1.originalFunction = function () {
    console.log('patched function 💥');
};
```

**Playground Link:** 

Hard to get it on playground because it requires having separate files on filesystem and actually loading them by browser.
Repository: godot
Issue: AnimationPlayer: and key symbol disappearing when Region is enabled
Labels: bug,topic:editor

**Godot version:** 3.2. stable

**OS/device including version:** Win 64

**Issue description:**
Key symbol next to properties in the inspector are disappearing when Sprite Region is enabled. Effectively making it impossible to animate Sprite Regions.

Possibly related closed issue: https://github.com/godotengine/godot/issues/8306

**Steps to reproduce:**
1. Create new scene
2. Add Sprite and set texture. 
3. Enable region. Draw a region or chose autosclice in the bottom TextureRegion panel.
4. Add AnimationPlayer and create a New Anim
5. Make sure you have the AnimationPlayer Node selected, so key symbol is visible next to properties
6. Click the Sprite node
7. Wonder where the keys went.

![region_animation_bug](https://user-images.githubusercontent.com/47016402/74091853-e97fdf00-4abc-11ea-802c-486277110546.gif)

**Minimal reproduction project:**
[Region-Bug.zip](https:**//github.com/godotengine/godot/files/4175151/Region-Bug.zip)

Sidenote: Reimporting as "Region" seem to break everything: png still shows up in the File System, but disappears from the Viewport and Inspector, and cannot be loaded back into the Texture property anymore. Might have something to do with [this update](https://godotengine.org/article/atlas-support-returns-godot-3-2)? Made a separate issue here: https://github.com/godotengine/godot/issues/37071
Repository: flutter
Issue: Make ListView scrollable within PageView 
Labels: framework,f: scrolling,f: gestures,c: proposal,P3,team-framework,triaged-framework

Unless I'm missing something, I don't believe it's possible to achieve scrolling on both a `ListView` (or `SingleChildScrollView`) and a `PageView` when the `ListView` is within the `PageView` and they both scroll in the same direction.

Consider the following simple example app with a vertical scrolling `ListView` within a vertical `PageView`:

```dart
void main() => runApp(App());

class App extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(),
        body: PageView(
          scrollDirection: Axis.vertical,
          children: <Widget>[
            ListView.builder(
              itemCount: 20,
              itemBuilder: (BuildContext context, int index) => ListTile(title: Text('Item $index'))
            ),
            Text('Page 2')
          ],
        )
      )
    );
  }

}
```

There is no way to get the `PageView` to scroll pages. I think expected behavior should be that when the `ListView` is scrolled to the bottom, the `PageView` should then handle the gesture. If I remember correctly, I believe it works like this with Android's `RecyclerView` and `ViewPager`.

I've played around with `ScrollPhysics`, `ScrollBehavior`, and `NotificationListener` such as listening for `OverscrollNotification` and then disabling scrolling for `ListView`, but I could not find a solution that worked well.
Repository: storybook
Issue: Using react hooks + storybook hooks between stories and decorators break SB
Labels: bug,api: addons

**Describe the bug**

The error: **Storybook preview hooks can only be called inside decorators and story functions**

**To Reproduce**
Steps to reproduce the behavior:
1. Write a story with just a div.
2. Write two decorators.
3. Write the first decorator with **useParameter** and some react hooks.
4. Write the second decorator with just rendering the story as a react component.
5. See the error.

**Expected behavior**
To not have this issue.

**Code snippets**
```tsx
// Component.story.tsx

export default {
  title: 'New story',
  decorators: [hooksDecorator, justDecorator],
};

export function initial() {
  return <div>Hiii</div>;
}

// decorators.tsx
export function hooksDecorator(Story) {
  const someBool = useParameter<boolean>('bool');
  const [state, setState] = useState(someBool);

  useEffect(() => {
    setTimeout(() => {
      setState(someBool || true);
    }, 100);
  }, [someBool]);

  return <Story />
}

export function justDecorator(Story) {
  return <Story />
}
```

**System:**
```
    OS: Linux 4.15 Ubuntu 18.04.4 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz
  Binaries:
    Node: 12.14.1 - ~/.nvm/versions/node/v12.14.1/bin/node
    Yarn: 1.21.1 - /usr/bin/yarn
    npm: 6.13.4 - ~/.nvm/versions/node/v12.14.1/bin/npm
  Browsers:
    Chrome: 80.0.3987.106
    Firefox: 74.0b4
  npmPackages:
    @storybook/addon-actions: 5.3.13 => 5.3.13 
    @storybook/addon-docs: 5.3.13 => 5.3.13 
    @storybook/addon-knobs: 5.3.13 => 5.3.13 
    @storybook/preset-typescript: 1.1.0 => 1.1.0 
    @storybook/react: 5.3.13 => 5.3.13
```

**Extra information:**
You don't need to really use the parameter data nor the react hooks' data to get to this error state. Just because you're rendering the story as a component will produce this situation.

But something to note: if the decorators are reordered and the **hooksDecorator** is in the last place, the bug won't happen. Also, if **hooksDecorator** is first and the rest just render the story as a function, it won't happen either.
Repository: rust
Issue: Documentation unclear with Fn trait on extern "C" function pointers
Labels: C-enhancement,A-FFI,T-lang,A-docs

The relevant docs are [here](https://doc.rust-lang.org/std/primitive.fn.html) and [here in the repo](https://github.com/rust-lang/rust/blob/master/src/libstd/primitive_docs.rs#L1133-L1135):

> In addition, function pointers of any signature, ABI, or safety are Copy, and all safe function pointers implement Fn, FnMut, and FnOnce. This works because these traits are specially known to the compiler.

The code:

```Rust
extern "C" fn abc(x: u32) {
    println!("Hello, {}", x);
}

fn do_it<F: Fn(u32)>(f: F, n: u32) {
    f(n)
}

fn main() {
    do_it(abc, 5);
}
```

Does not compile even though `abc` can be called without `unsafe`, which the docs seem to suggest is sufficient for this to work.

[Rust playground demonstrating the issue](https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=8735414c1ecb5b4e58d9997912419b21)

I'd be happy to update the docs, but unfortunately I think I don't understand why this doesn't work well enough to do so.
Repository: go
Issue: cmd/compile: combine int tests when comparing against a constant string
Labels: Performance,NeedsFix

To compare against "abc", we currently emit code to test whether uint16(first two bytes)==uint16("ab") and then whether (third byte)=="c".

I suspect that it'd be more efficient to load the three bytes into the first three bytes of a uint32 (two loads combined with `|`) and then compare that to uint32("abc\0").

I'm not sure whether we could do this with comparison-combining rewrite rules (note that the loads have side-effects in general, but we're sure in this case they won't fault) or whether it'd be better to fix this in walk.go, where this optimization is generated.

Low priority.
Repository: go
Issue: cmd/compile: optimize small runtime.memequal calls
Labels: Performance,NeedsFix

In the SSA backend, we could optimize a call to runtime.memequal in which the length is small and one argument points to a readonly data symbol. We could replace it by reading the readonly data and checking the bytes of the other argument directly.

This is similar to the optimization in walk.go for comparing against a constant string, and could potentially supercede it. The optimization in walk.go doesn't always trigger. An example is using strings.HasPrefix to check for a constant prefix; the call gets inlined, but walk.go isn't able to do the optimization because its analysis isn't powerful enough.

Low priority.
Repository: node
Issue: Nodejs build system incorrectly prepending zlib include path to small-icu includes.
Labels: build,i18n-api

* **Version**: 12.14.1(bug appears to be in master as well)
* **Platform**: buildroot master
* **Subsystem**: small-icu

### What steps will reproduce the bug?

attempt to build nodejs with small-icu and a shared zlib on a system that also contains a system icu with both zlib and icu headers in the `/include` directory

See [here](http://autobuild.buildroot.net/results/497/497275b0e4eba8bfadab9d781f7dcea6adf12029/build-end.log) for buildroot build log failure.

### How often does it reproduce? Is there a required condition?

always when building with small-icu and shared zlib on a system with zlib and icu headers in the system include path

### What is the expected behavior?

nodejs will use icu headers from small-icu instead of system icu headers when small-icu is selected

### What do you see instead?

nodejs attempts to use system-icu headers due to zlib include directory being prepended to small-icu include directories

### Additional information

this bug is due to nodejs passing all include directories from config.gypi before the small-icu includes to the compiler which causes the compiler to try and use the incompatible system icu headers instead of the built in small-icu headers
Repository: TypeScript
Issue: strictNullChecks allows inconsistent indexed type with spread syntax
Labels: Bug

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

Reporting this as a bug since I couldn't find a suitable duplicate. If this behavior is by design, please consider adding an option to change it.

**TypeScript Version:**  3.7.5

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** indexed undefined spread spreading strictNullChecks

**Expected behavior:** `useObjects(...objectList)` should fail to compile

**Actual behavior:** `useObjects(...objectList)` compiles without error

**Code**
```ts
const objectList =
[
    { a: 1, b: 2 },
    { c: 3, d: 4 },
];

function useObjects
(
    obj1?: { [key: string]: number | undefined; },
    obj2?: { [key: string]: number; },
): void
{
    // ...
}

useObjects(...objectList);                // no error 
useObjects(objectList[0], objectList[1]); // error 2345 on second argument
```

<details><summary><b>Compiler Options</b></summary>

```json
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "declaration": true,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}
```


</details>

**Playground Link:** [Provided](https://www.typescriptlang.org/play/?ssl=1&ssc=1&pln=18&pc=1#code/MYewdgzgLgBCBGArApsKAZAltGBeAUANr4ykwDeMAhgFwwCMANDPHQEwwC+jJZlwdAMzMAJnQAsXHgF0A3PnwAzAK5g0mcDGURkAeSSooEfAApepBInoB+OpUIBrZAE860AE6YwAc2l0wygC28MjuMAA+WmAiyIpeyCKyUuZwSGy2FDCOLm5Qnj5+MAHBoUnc+ACUdABuIJgi+OQpAPTNMAB0nficCtp6BmgQJp3tloZY0BXyffoogyZjaBNQhAAM0syLGNgr9NJT+EA)
Repository: pytorch
Issue: It seems nn.Sequential.add_module() could take duplicate names
Labels: module: nn,triaged

Hi, guys,
I am reproducing DeepLabV3+ model these days,
and I find that nn.Sequential.add_module() could take duplicate names, as
```python
            # some initialization code
            depthwise.add_module("act", act)
            pointwise.add_module("act", act)
```
Is that normal?

Any idea or suggestion will be appreciated!