sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: [Bug]: Could not find framework package: @storybook/ember-webpack5
Labels: bug,help wanted,cli,ember

### Describe the bug

I'm getting an error when trying to add storybook 7 to a new Ember app. When runing `npx storybook@latest init`, I get asked which builder to use, and when then selecting Webpack 5, it tries to install a package that does not exist (@storybook/ember-webpack5). Error also happens when selecting Vite.

### To Reproduce

```sh
$ ember --version
ember-cli: 3.28.6
node: 16.19.0

$ ember new storybook -sb --no-welcome --yarn true --lang en
$ cd storybook
$ npx storybook@latest init

 • Detecting project type. ✓
? We were not able to detect the right builder for your project. Please select one: › - Use arrow-keys. Return to submit.
    Vite
❯    Webpack 5


✔ We were not able to detect the right builder for your project. Please select one: › Webpack 5
 • Adding Storybook support to your "Ember" app
     Error: Could not find framework package: @storybook/ember-webpack5.
Make sure this package exists, and if it does, please file an issue as this might be a bug in Storybook.
    at getFrameworkPackage (/Users/alexanderlang/.npm/_npx/bc7e1e37fcb46ffc/node_modules/@storybook/cli/dist/generate.js:46:1255)
    at getFrameworkDetails (/Users/alexanderlang/.npm/_npx/bc7e1e37fcb46ffc/node_modules/@storybook/cli/dist/generate.js:49:569)
    at baseGenerator (/Users/alexanderlang/.npm/_npx/bc7e1e37fcb46ffc/node_modules/@storybook/cli/dist/generate.js:49:2207)
    at generator2 (/Users/alexanderlang/.npm/_npx/bc7e1e37fcb46ffc/node_modules/@storybook/cli/dist/generate.js:57:4737)
    at runGenerator (/Users/alexanderlang/.npm/_npx/bc7e1e37fcb46ffc/node_modules/@storybook/cli/dist/generate.js:70:4729)
    at installStorybook (/Users/alexanderlang/.npm/_npx/bc7e1e37fcb46ffc/node_modules/@storybook/cli/dist/generate.js:74:795)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async doInitiate (/Users/alexanderlang/.npm/_npx/bc7e1e37fcb46ffc/node_modules/@storybook/cli/dist/generate.js:79:704)
    at async withTelemetry (/Users/alexanderlang/.npm/_npx/bc7e1e37fcb46ffc/node_modules/@storybook/core-server/dist/index.js:35:3422)
    at async initiate (/Users/alexanderlang/.npm/_npx/bc7e1e37fcb46ffc/node_modules/@storybook/cli/dist/generate.js:90:108)
```

### System

```shell
Environment Info:

  System:
    OS: macOS 13.3.1
    CPU: (10) arm64 Apple M1 Pro
  Binaries:
    Node: 16.19.0 - ~/.asdf/installs/nodejs/lts-gallium/bin/node
    Yarn: 1.22.19 - ~/.yarn/bin/yarn
    npm: 8.19.3 - ~/.asdf/plugins/nodejs/shims/npm
  Browsers:
    Chrome: 113.0.5672.126
    Firefox: 113.0.1
    Safari: 16.4
  npmGlobalPackages:
    @storybook/docs-mdx: 0.1.0
```


### Additional context

Current storybook version on npm is 7.0.12.
Repository: godot
Issue: Gridmap gizmo positioned randomly
Labels: bug,topic:3d

### Godot version

4.0.2.stable.arch_linux

### System information

Linux

### Issue description

The orange grid gizmo for a gridmap in the editor appears centered at a seemingly random spot every time you select a `GridMap`
![1684406625](https://github.com/godotengine/godot/assets/2496231/7cbbeef5-be10-43ac-9e75-c66dc69bf7a0)


### Steps to reproduce

1. Create a gridmap
2. Zoom out, find the grid (may be very far away)
3. Select another node
4. Select the GridMap
5. See the grid gizmo is now in a different spot

### Minimal reproduction project

N/A, just add a `GridMap` to an empty project
Repository: next.js
Issue: Wrong generateMetadata used when running parallel routes
Labels: Parallel & Intercepting Routes

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: linux
      Arch: x64
      Version: #1 SMP Fri Jan 27 02:56:13 UTC 2023
    Binaries:
      Node: 18.14.0
      npm: 9.3.1
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.4.3-canary.2
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.0.4
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true)

### Link to the code that reproduces this issue

https://github.com/kossnocorp/next-parallel-routes-bug

### To Reproduce

Run the dev server, and open these URLs:

- http://localhost:3000/@hello/world
- http://localhost:3000/hello/world

### Describe the Bug

`generateMetadata` is used from the wrong parallel route.

With the given routes structure:

```
.
├── [root]
│   ├── @category
│   │   └── [workflow]
│   │       └── page.tsx
│   ├── @workspace
│   │   └── [workflow]
│   │       └── page.tsx
│   └── layout.tsx
```

...and given layout (that renders `workspace` when there's @ in the front, and `category` otherwise):

```ts
export default function RootLayout({
  category,
  workspace,
  params: { root },
}: RootLayoutProps) {
  const slug = decodeURIComponent(root);
  return slug[0] === "@" ? workspace : category;
}
```

When opening http://localhost:3000/@hello/world, it should show `@workspace` both in title and body and when opening http://localhost:3000/hello/world it should show `@category`.

In the current Next.js version, both these pages have `@workspace` in the title, meaning `generateMetadata` picked up from the wrong parallel route.

See the screenshot:

![image](https://github.com/vercel/next.js/assets/52201/9ca99eff-10c3-4275-a5bf-f2673bac678e)


### Expected Behavior

When opening http://localhost:3000/@hello/world, it should show `@workspace` both in the title and body, and when opening http://localhost:3000/hello/world it should show `@category`.

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

<sub>[NEXT-2027](https://linear.app/vercel/issue/NEXT-2027/wrong-generatemetadata-used-when-running-parallel-routes)</sub>
Repository: opencv
Issue: Bug for opencv "solvePoly" function: can't solve the right roots for x^2 - 2x - 3=0
Labels: bug,category: core,confirmed

### System Information

OpenCV version: 3.2.0 (also have tested in 3.4.10)
Operating System / Platform: Ubuntu 18.04
Compiler & compiler version: GCC 7.5.0

I test this in CLion-2022.3.1.

### Detailed description

```
#include <iostream>
#include <opencv2/core/core.hpp>

int main() {
    cv::Mat coeff = (cv::Mat_<float>(3, 1) << -3.0, -2.0, 1.0);
    cv::Mat roots;
    cv::solvePoly(coeff, roots);
    std::cout << roots << '\t';
    return 0;
}
```
 
the output is:`
[1, -0.58432907;
 1, -6.667408]	`

This is not the right answer `[3, 0; -1, 0]`.

### Steps to reproduce

**CMakeLists.txt**
```cmake
cmake_minimum_required(VERSION 3.24)
project(ClionTest)

set(CMAKE_CXX_STANDARD 17)

add_executable(ClionTest main.cpp)

find_package(OpenCV 3.0 QUIET)
if(NOT OpenCV_FOUND)
    find_package(OpenCV 2.4.3 QUIET)
    if(NOT OpenCV_FOUND)
        message(FATAL_ERROR "OpenCV > 2.4.3 not found.")
    endif()
endif()

target_link_libraries(${PROJECT_NAME}
        ${OpenCV_LIBS}
        )
```

**main.cpp**
```cpp
#include <iostream>
#include <opencv2/core/core.hpp>



int main() {
    cv::Mat coeff = (cv::Mat_<float>(3, 1) << -3.0, -2.0, 1.0);
    cv::Mat roots;
    cv::solvePoly(coeff, roots);
    std::cout << roots << '\t';
    return 0;
```

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: flutter
Issue: [path_provider] Support available directory types on Desktop
Labels: platform-mac,platform-windows,platform-linux,p: path_provider,package,c: proposal,a: desktop,team-ecosystem,P3,triaged-ecosystem

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

When users want to write to directories that are specifically meant for certain types of media (i.e. music or pictures)
the options are currently limited on Desktop platforms, even though there are options available. 

### Proposal

Support the different directory types available on Desktop.

On MacOS this would be the NSxyzDirectory types.
https://developer.apple.com/documentation/foundation/nssearchpathdirectory/nsdocumentdirectory#see-also

I don't know the Windows / Linux details out the top of my head.

We _could_ amend to [getExternalStorageDirectories](https://pub.dev/documentation/path_provider/latest/path_provider/getExternalStorageDirectories.html) (which would make the comment about only supporting Android outdated)
but that is only a short term solution and doesn't feel like the right API to add to.

The long term solution would be to rethink the way we allow retrieving directories.
Something like

```
Future<List<Directory>> getDirectories(DirectoryType type);
```

where the type is an abstraction over the underlying types, and since there could be more than one directory, we return a list. 

I don't think having a specific method to return a single directory makes sense, as it is platform dependent and there is the `List.first / List.single` getter. Feel free to disagree on this if you think it is useful somewhere.

Related #118712
Repository: vscode
Issue: Merge Editor overrides manually resolved conflicts
Labels: bug,merge-editor

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.77.3
- OS Version: Linux x64 3.10.0-1160.90.1.el7.x86_64

Steps to Reproduce:

1. Open a conflicted file not in the merge editor, but a normal editor
2. Resolve some of the conflicts manually and save
3. Now open the file in the merge editor with the intent of using to resolve the remaining conflicts
4. The already-resolved conflicts are back
Repository: godot
Issue: Compute Shader res compiled by PC editor cannot be exported to Android for use
Labels: bug,platform:android,topic:rendering,topic:porting

### Godot version

4.0.2

### System information

PC: MANJARO-6.1.26 GTX1650  PE: HarmonyOS-3.0 Huawei Kirin980

### Issue description

When exporting Compute Shader project to Android, I found that glsl failed to load, but importing the project to Android editor works fine, I found the gap lies in . /godot/imported, after replacing the Compute Shader res file in apk with the res file generated by Android editor, the app can be used normally.

PC:
![image](https://github.com/godotengine/godot/assets/52148221/23dc819c-dd56-4e44-a228-7c2acff9fa2b)
PE:
![Screenshot_20230518194644](https://github.com/godotengine/godot/assets/52148221/17d728e9-6750-4f37-b00b-c12957084989)
There is a significant size difference in the res file, and I don't know if this is related to the problem.

### Steps to reproduce

1.  Import the computational shader project into the pc and pe editors respectively.
2. Export Android apk in pc editor and install it, Compute Shader fails
3. Replace the res file inside the apk with the res file generated by the Android editor and install it, Compute Shader works normally

### Minimal reproduction project

https://github.com/godotengine/godot-demo-projects/tree/master/misc/compute_shader_heightmap
Repository: PowerToys
Issue: PowerToys Run Search function improvements
Labels: Needs-Triage

### Description of the new feature / enhancement

Hello. I would like you to implement two things:

1. When you select the search results the bar fills with the selected results. It'll be good to act like Launchy. It doesn't change the searched text while you select results.

2. It'll be good searching some letter or part of the name of the file, like Launchy. For example: _TERMINAL5_ only appears by typing _TERMINAL5_ while in Launchy it appears by typing _L5._

If this is already implemented, please refer me to the documentation info beacause I haven't found it.

Thanks a lot.



### Scenario when this would be used?

PowerToys Run Search function

### Supporting information

_No response_
Repository: TypeScript
Issue: Tuple with optional element and exactOptionalPropertyTypes still returns undefined during iteration
Labels: Bug,Help Wanted

# Bug Report

When iterating over a variable with a tuple type with optional element `[T?]`, the type of the item is still `T | undefined` even when `exactOptionalPropertyTypes: true` (i.e. creating a variable like `let foo: [string?] = [undefined]` errors).

### 🔎 Search Terms

tuple, optional tuple element, exactOptionalPropertyTypes

### 🕗 Version & Regression Information

This is the behavior in every relevant version I tried (4.4.4 to 5.1-beta), and I reviewed the FAQ for entries about tuples

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?noUncheckedIndexedAccess=true&exactOptionalPropertyTypes=true&ts=5.0.4#code/C4TwDgpgBAksEFsoF4oG8CwAoKuoDcBDAGwFcIAuKAZ2ACcBLAOwHMBubAXw621EigAxAPbCUUANpxEAfgC6PbMQjAoAM1EBGKiLGoJCqAHojUJmIh06wugBooLUQBN7wABaXoAY0JMoAI2gABigbKE0oBngEJRV1UQAmHVFxCVImJwg1ZggnQxMoS2s7B2d7QJ9SamhhNSgAAwgAD0IvYAB5MGAGYSYSAAVrSDpQABVwCGoqenJ6tki6mChgUjo-dwZqUK6ev1q1Vw9CqzDHSahCAHdCEFjVDWEAZmS9STQiMkooAHJNb858qZzMdivZHMIXKF-PgelViLdeFgvL1qMJlAA6YjCFgACl+3wAlIosBo6FAccpVFFEKE6g9NAT0NhcMimKiMVjcd8EoSeCyUWiIJjsTjqQh0R9yETjKYijZyqRVJc3CAZA1ud96pFqExvqpOSxclAnKtmCwoHR0t0EBAuNhsKz2ULOXjHrz7UiBRyRfSJEE5BKSFL5gU5SVwZCKoQqtB3J4oAgbgFoMCxR7HYLhVyACy8mXLNybbW6-XYw1OZOVaq0i1Whg2kFhXpQMB0CAw4RVKDEHIe-jQABChDJ+mkCAUHspAWHVCHI7ekq++IBxNJ5KnYpr-mHjMwOCgGe9uLFgc+0oKwLDYOcdqwQA)

### 💻 Code

```ts
type Item = {
    value: string;
};

type Foo = [Item?];

let foo1: Foo = []; // no error, good, there can be 0 or 1 item
let foo2: Foo = [undefined]; // error, good, because of `exactOptionalPropertyTypes: true`; if I turn this option off, the error goes away
let foo3: Foo = [{value: '1'}]; // no error, good, obviously

console.log('1');

for (let item of foo1) {
  console.log('2');
  console.log(item.value); // error, but why? `'2'` isn't logged during runtime
}

console.log('3');

console.log(foo1[0].value); // error, good, because there may be no item

console.log('4'); // this isn't logged because of runtime error on previous line

type Bar = [Item];

let bar: Bar = [{value: '1'}];

for (let item of bar) {
  console.log(item.value); // no error, good
}
```

### 🙁 Actual behavior

Error on line 15 (`console.log(item.value);`) because `item` has type `Item | undefined`.

### 🙂 Expected behavior

I would expect no error on line 15 and the type of `item` to be `Item`. Is this maybe somehow related to #51643? Or is my expectation incorrect and there's some possible runtime behavior that I'm not taking into account? But I think that e.g. `noUncheckedIndexedAccess` doesn't apply in this situation (and toggling it off and on didn't change anything anyway). I also tried `readonly [Item?]`, although it too doesn't affect anything (as I think it shouldn't).
Repository: pytorch
Issue: Fix absolute links in pytorch repository and allow it to be proxied
Labels: oncall: releng,triaged

### 🐛 Describe the bug

The pip repositories like `https://download.pytorch.org/whl/cu118` do not follow common standards like PEP503.

While for itself pip this is not an issue, we are having trouble proxying the repository using Sonatype Nexus.

When looking at the actual location of the wheels, `https://download.pytorch.org/whl/torch/` the links to the wheel files use absolute paths like that:

`<a href="/whl/cu117/torch-2.0.1%2Bcu117-cp310-cp310-linux_x86_64.whl">torch-2.0.1+cu117-cp310-cp310-linux_x86_64.whl</a>`

So far so good.

Now I am proxying the pytorch repo to make use of caching and faster downloads in our corporate network. Additionally direct internet access is not allowed. We are using a so-called "raw repository" inside Sonatype Nexus. We cannot use their "PyPI" repository feature, because the pytorch repository does not follow PEP503 standard. But that is a separate issue.

Our cached repository ends up at `https://nexus.corporate.info/repository/pytorch-raw/` with the wheels ending up at `https://nexus.corporate.info/repository/pytorch-raw/whl/torch/`. The page shows links the same way as the original repo.

`<a href="/whl/cu117/torch-2.0.1%2Bcu117-cp310-cp310-linux_x86_64.whl">torch-2.0.1+cu117-cp310-cp310-linux_x86_64.whl</a>`

But a link like `/whl/cu117/torch-2.0.1%2Bcu117-cp310-cp310-linux_x86_64.whl` ends up being resolved to `https://nexus.corporate.info/whl/cu117/torch-2.0.1%2Bcu117-cp310-cp310-linux_x86_64.whl`

The correct URL should be `https://nexus.corporate.info/repository/pytorch-raw/whl/cu117/torch-2.0.1%2Bcu117-cp310-cp310-linux_x86_64.whl`

Could you please fix the absolute links and use relative ones if possible?

Alternatively, can you implement a PEP503 simple repository? What is the issue with that?



### Versions

2.0.1
Repository: flutter
Issue: SliverAppBar add snapBehaviour property and deprecate snap property
Labels: c: new feature,framework,f: material design,f: scrolling,c: proposal,P3,team-design,triaged-design

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

Currently, `snap: true` will snap the `SliverAppBar` only based on the latest direction.

The `snap` property should be deprecated and replaced by the `SnapBehavior` enum.

For instance:
`enum SnapBehavior { closest, direction, none }`

While deprecating the old API, `snap: true` can be mapped to `SnapBehavior.direction` and `snap: false` can be mapped to `SnapBehavior.none`.

Current behavior ( _SnapBehavior.direction_ ):

https://github.com/flutter/flutter/assets/8436039/532f2b88-6a1f-4df7-be19-54aec8137805

### Proposal

Add the `enum SnapBehavior { closest, direction, none }` to `SliverAppBar`.

The `SnapBehavior.closest` should function similarly to the Play Store.

https://github.com/flutter/flutter/assets/8436039/e6939b70-9e97-4379-9d58-9c9893e97320
Repository: next.js
Issue: A 'JavaScript heap out of memory' error occurred while exporting getStaticProps
Labels: bug,Pages Router

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103
    Binaries:
      Node: 16.14.2
      npm: 8.5.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 13.4.2
      eslint-config-next: 13.4.2
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.0.4
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

Data fetching (gS(S)P, getInitialProps)

### Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/quizzical-keller-6i69gj?file=%2Fpages%2Findex.tsx%3A5%2C1

### To Reproduce

Export getStaticProps within any page

### Describe the Bug

I used `getStaticProps` to obtain data when building pages using Nextjs and Tailwindcss, but when running `yarn dev` or `yarn build`, I encountered an error: `FATAL ERROR: Ineffective mark compacts near heap limit Allocation failed - JavaScript heap out of memory`

### Expected Behavior

`getStaticProps` working properly

### Which browser are you using? (if relevant)

Chrome 113.0.5672.126  (arm64) 

### How are you deploying your application? (if relevant)

_No response_
Repository: next.js
Issue: Script component calls onReady when the script could not be loaded
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: linux
      Arch: x64
      Version: #42~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 18 17:40:00 UTC 2
    Binaries:
      Node: 18.12.1
      npm: 8.19.2
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.3.4
      eslint-config-next: 13.0.5
      react: 17.0.2
      react-dom: 17.0.2
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

Script optimization (next/script)

### Link to the code that reproduces this issue

https://stackblitz.com/edit/nextjs-vrdz8s?file=pages/index.js

### To Reproduce

To reproduce the error: 

1. Open the browser's javascript console and verify that handleOnError is called
2. Navigate to the "other page" using the link and return to the previous page
3. Navigate to the other page via the link and return to the previous page again
4. handleOnReady function is called when not expected :exploding_head: 

### Describe the Bug

The onReady function is being called when the script could not be loaded instead of onError.
This can cause errors when initializing third-party widgets when the script could not be loaded.

### Expected Behavior

If the third-party script could not be loaded, it should not call the onReady function.

### Which browser are you using? (if relevant)

Firefox 113.0 and Chrome 113.0.5672.126

### How are you deploying your application? (if relevant)

not relevant