sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: Error while creating next-app with Typescript using Yarn
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: #1 ZEN SMP PREEMPT_DYNAMIC Mon, 13 Mar 2023 17:02:40 +0000
Binaries:
Node: 18.14.2
npm: 9.5.0
Yarn: 1.22.19
pnpm: N/A
Relevant packages:
next: 13.1.5
eslint-config-next: N/A
react: 18.2.0
react-dom: 18.2.0
```


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

_No response_

### Link to the code that reproduces this issue

https://github.com/Deveesh-Shetty/CineSurge

### To Reproduce

I am creating a next-app with typescript using yarn
`yarn create next-app --typescript .`

The creation is done successfully, but I am getting an error while doing `next build`

### Describe the Bug

```
info  - Linting and checking validity of types
info  - Creating an optimized production build
info  - Compiled successfully
info  - Collecting page data .Error: You tried to import `next/font/google`, did you mean `@next/font/google`?
Read more: https://nextjs.org/docs/basic-features/font-optimization
at 68 (/home/deveesh/DriveD/Projects/cinesurge/.next/server/chunks/47.js:533:7)
at __webpack_require__ (/home/deveesh/DriveD/Projects/cinesurge/.next/server/webpack-runtime.js:25:42)
at 681 (/home/deveesh/DriveD/Projects/cinesurge/.next/server/pages/index.js:42:74)
at __webpack_require__ (/home/deveesh/DriveD/Projects/cinesurge/.next/server/webpack-runtime.js:25:42)
at __webpack_exec__ (/home/deveesh/DriveD/Projects/cinesurge/.next/server/pages/index.js:321:39)
at /home/deveesh/DriveD/Projects/cinesurge/.next/server/pages/index.js:322:69
at __webpack_require__.X (/home/deveesh/DriveD/Projects/cinesurge/.next/server/webpack-runtime.js:108:21)
at /home/deveesh/DriveD/Projects/cinesurge/.next/server/pages/index.js:322:47
at Object.<anonymous> (/home/deveesh/DriveD/Projects/cinesurge/.next/server/pages/index.js:325:3)
at Module._compile (node:internal/modules/cjs/loader:1254:14)

> Build error occurred
Error: Failed to collect page data for /
at /usr/lib/node_modules/next/dist/build/utils.js:963:15
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
type: 'Error'
}
```

### Expected Behavior

I ran the same command in my previous project some weeks ago, but at that time I didn't get any errors. But now I am getting this error,  I tried redoing the same 2-3 times and every time getting the same issue.

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

_No response_

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

_No response_
Repository: neovim
Issue: Expose a simple way to cancel LSP requests from `vim.lsp.buf.*`
Labels: enhancement,lsp,architecture

### Problem

When LSP responses are slow, popups from functions in `vim.lsp.buf` (e.g. `vim.lsp.buf.hover()`) can appear significantly after the initial call. With the delay, it's easy to move to a different context (different part of the file, or different file entirely) while the LSP request is in-flight and have the popup appear unexpectedly in the wrong place.

It's possible to work around this currently by looping through pending LSP client requests and cancelling them, but that's not great IMO. An easy fix for this would be to return the cancel function returned by `vim.lsp.buf_request` from the higher level functions like `vim.lsp.buf.hover()`, but I wonder if those high level functions should just do the cancellation themselves -- I can't see a reason why people would want to have things like stale hovers.

### Expected behavior

High level LSP functions that show something to the user should either auto cancel in cases where they're no longer relevant, or expose a simple way to get such functionality via user config.
Repository: godot
Issue: Blender model doesn't have materials imported unless using Principled BSDF (due to glTF exporter limitation)
Labels: documentation,topic:import,topic:3d

### Godot version

4.0.1

### System information

Win11 22H2, Intel UHD Graphics 730, 31.0.101.3413

### Issue description

Some blender model have no texture.

### Steps to reproduce

I have two blender model, "model1" and "model2", and they both have texture.
![image](https://user-images.githubusercontent.com/72609054/229297464-6c187880-bd3a-452f-a512-4835ca5e5c3b.png)
But in godot 4.0.1, "model2" have no texture.
![image](https://user-images.githubusercontent.com/72609054/229297493-9ef13771-12d1-4fb0-8dd5-d7f55af4ce0c.png)
I tried using another format, such as .gltf, but it still doesn't work.
![image](https://user-images.githubusercontent.com/72609054/229297616-d1c23e6e-6c4b-4952-bfbd-39d3d94b3c3c.png)

### Minimal reproduction project

[model.zip](https://github.com/godotengine/godot/files/11129877/model.zip)
Repository: deno
Issue: `deno install` fails to run program
Labels: bug,node compat

I used this command to generate a bin script:

```
deno install -A --root /usr/local --name my-program --force $PWD/cli/main.ts
✅ Successfully installed my-program
/usr/local/bin/my-program
```

If I then run it, I get this error:

```
error: Uncaught ReferenceError: __DENO_NODE_GLOBAL_THIS_1680362762__ is not defined
    at file:///Users/me/Library/Caches/deno/npm/registry.npmjs.org/ts-pattern/4.2.2/dist/index.module.js:1:18
```

After looking into this... the install command adds `--no-config`.

```
#!/bin/sh
# generated by deno install
exec deno run --allow-all --no-config 'file:///path/cli/main.ts' "$@"
```

If I remove `--no-config` and run `my-program` (from any directory) it works. Example:

```
#!/bin/sh
# generated by deno install
exec deno run --allow-all  'file:///path/cli/main.ts' "$@"
```

I tried this and it fails:

```
#!/bin/sh
# generated by deno install
exec deno run --allow-all --no-lock 'file:///path/cli/main.ts' "$@"
```

I don't understand how the auto-discovery stuff works. As I mentioned, after removing `--no-config` I can run this program from any directory (not just the directory where the `deno.jsonc` and `deno.lock` related to the cli/main.ts script are found).
Repository: PowerToys
Issue: Gap with "move windows to last known zone"
Labels: Issue-Bug,Product-FancyZones,Needs-Triage,Needs-Team-Response

### Microsoft PowerToys version

0.68.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

FancyZones

### Steps to reproduce

1. Enable "Move newly created windows to their last known zone"
2. Snap Visual Studio (or Unity Editor) to a zone that touches 3 sides of the monitor. If that doesn't show the bug, try this custom layout:
    ```json
    {
      "custom-layouts": [
        {
          "uuid": "{F00F2787-DEE5-4343-8A2C-069E2A7322BF}",
          "name": "Custom layout 1",
          "type": "canvas",
          "info": {
            "ref-width": 2498,
            "ref-height": 1440,
            "zones": [
              {
                "X": 0,
                "Y": 0,
                "width": 1271,
                "height": 1440
              }
            ],
            "sensitivity-radius": 20
          }
        }
      ]
    }
    ```
3. Close, reopen.


[PowerToysReport_2023-04-01-09-39-09.zip](https://github.com/microsoft/PowerToys/files/11129972/PowerToysReport_2023-04-01-09-39-09.zip)


### ✔️ Expected Behavior

Window is in last known zone

### ❌ Actual Behavior

There's 5px gap below and sometimes to the sides of the window, along the screen edge.

This happens only with certain apps, I believe the ones that customize their window-chrome (e.g. Visual Studio, Unity Editor) and seems to require the zone touching three edges of the screen. My resolution is 2560x1440 with 1:1 (100%) UI scaling in Windows.

💡 The gap goes away after toggling between duplicate layouts with "during zone layout changes, windows assigned to a zone will match new size/positions". That might shine light on a potential fix.

![Untitled](https://user-images.githubusercontent.com/6148201/229301287-38b395ea-1327-4ef9-925e-59f7b19c2db1.png)


### Other Software

Windows 10 Version 22H2 (OS Build 19045.2728)
Repository: electron
Issue: [Bug]: Can not fire click(or double click) event if set a '-webkit-app-region: drag;' style
Labels: platform/macOS,bug :beetle:,status/confirmed,has-repro-gist,23-x-y,component/draggable-regions

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

23.2.1

### What operating system are you using?

macOS

### Operating System Version

13.3 (22E252)

### What arch are you using?

x64

### Last Known Working Electron version

22.0.3

### Expected Behavior

I can drag the item to move window and fire click (double click) event.

### Actual Behavior

click event NOT FIRED.

### Testcase Gist URL

https://gist.github.com/fcc8358e36cae1dc3ed07458e4be46dc

### Additional Information

Is it a bug?
Repository: stable-diffusion-webui
Issue: [Bug]: Override settings doesn't work in API
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

I'm trying to change `outdir_txt2img_samples` with `save_images=True`, but images still saves to default folder. 

### Steps to reproduce the problem

1. Make request to API with override settings 
2. Include `outdir_txt2img_samples` to absolute path to folder 

### What should have happened?

Images should be save in selected folder 

### Commit where the problem happens

22bcc7b

### What platforms do you use to access the UI ?

Windows

### What browsers do you use to access the UI ?

Google Chrome

### Command Line Arguments

```Shell
—api —xformers
```


### List of extensions

No

### Console logs

```Shell
Samples generated
```


### Additional information

_No response_
Repository: neovim
Issue: API Info: some functions are incorrectly typed
Labels: bug,api

### Problem

The current API is not as well-typed it could be. This is an issue when attempting to automatically generate ergonomic API clients for strongly statically typed languages.

Here are a few examples:
- "nvim_get_autocmds":
  + Current: "parameters": [ [ "Dictionary", "opts" ] ], "return_type": "Array",
  + Improve: "parameters": [ [ "Dictionary", "opts" ] ], "return_type": "ArrayOf(Dictionary)"
- "nvim_exec_lua":
  + Current: "parameters": [ [ "String", "code" ], [ "Array", "args" ] ], "return_type": "Object"
  + Improve: "parameters": [ [ "String", "code" ], [ "ArrayOf(Object)", "args" ] ], "return_type": "Object"
- "nvim_echo":
  + Current: "parameters": [ [ "Array", "chunks" ], [ "Boolean", "history" ], [ "Dictionary", "opts" ] ], "return_type": "void"
  + Improve: "parameters": [ [ "ArrayOf(ArrayOf(String, 2))", "chunks" ], [ "Boolean", "history" ], [ "Dictionary", "opts" ] ], "return_type": "void"
- "nvim_get_proc":
  + Current: "parameters": [ [ "Integer", "pid" ] ], "return_type": "Object",
  + Improve: "parameters": [ [ "Integer", "pid" ] ], "return_type": "Dictionary",
Repository: neovim
Issue: API Info: present types as structured information
Labels: enhancement

### Problem

Consider the API Info of nvim_tabpage_list_wins:
```json
  {
    "name": "nvim_tabpage_list_wins",
    "since": 1,
    "parameters": [
      [
        "Tabpage",
        "tabpage"
      ]
    ],
    "return_type": "ArrayOf(Window)",
    "method": true
  },
```
The return type is presented as a string (`ArrayOf(Window)`). This forces API client generators to parse type strings in order to be able to generate well-typed functions.

An improvement could be:
```json
  {
    "name": "nvim_tabpage_list_wins",
    "since": 1,
    "parameters": [
      [
        "Tabpage",
        "tabpage"
      ]
    ],
    "return_type": {
      "name": "Array",
      "parameters": [
          {"name": "Window"}
      ]
    },
    "method": true
  },
```
The reason we want `parameters` to be an array of types is for tuples and enumerations. Tuples are currently presented as:
```json
  {
    "name": "nvim_win_get_cursor",
    "since": 1,
    "parameters": [
      [
        "Window",
        "window"
      ]
    ],
    "return_type": "ArrayOf(Integer, 2)",
    "method": true
  },
```
But it would be nicer if they were:
```json
  {
    "name": "nvim_win_get_cursor",
    "since": 1,
    "parameters": [
      [
        "Window",
        "window"
      ]
    ],
    "return_type": {
        "name": "Tuple",
        "parameters": [
            {"name": "Integer"},
            {"name": "Integer"}
        ]
    },
    "method": true
  },
```
This would enable describing arbitrary-length tuples whose types mismatch.
Repository: godot
Issue: SDFGI very slow when far from the origin
Labels: bug,topic:rendering,topic:3d

### Godot version

v4.1.dev.custom_build [d9fcc54cf] with Double Precision

### System information

Linux X11, Vulkan, Forward+, RX6600XT

### Issue description

Enabling SDFGI when the Camera is far from the origin (1_000_000_000 units away) makes the application grind to a halt. Gradually increasing the distance from the origin results in a almost linear slowdown, the further you are, the longer SDFGI takes to "kick in".

This seems to be a problem only when running the engine with double precision enabled.
On single precision, even thought the scene is almost unplayable due to jitter, SDFGI doesn't cause the application to halt.

### Steps to reproduce

This can be easily reproduced with the Global Illumination Demo (https://github.com/godotengine/godot-demo-projects/tree/master/3d/global_illumination or the version attached below).
Simply open the project, move the root node far from the origin, run the application and set Global Illumination mode to SDFGI by pressing space a couple times.

### Minimal reproduction project

[global_illumination.zip](https://github.com/godotengine/godot/files/11130243/global_illumination.zip)
Repository: bitcoin
Issue: rpc: show P2(W)SH redeemScript in getrawtransaction (and friends)
Labels: Feature

### Please describe the feature you'd like to see added.

I'd like to be able to get the (decompiled) P2SH `redeemScript` and P2WSH `witnessScript` when calling `getrawtransaction` and `getblock … 2`.

### Is your feature related to a problem, if so please describe it.

I found myself having a hard time counting sigops in the recently invalid block. For scriptPubKey it's easy:

```
# Raw OP_CHECKMULTISIG: 20 x 4 sigops each
bitcoin-cli getblock 00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4 2 | jq -r '.tx[].vout[].scriptPubKey.asm' | grep OP_CHECKMULTISIG | wc -l
# Raw OP_CHECKSIG(VERIFY): 4 sigops each
bitcoin-cli getblock 00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4 2 | jq -r '.tx[].vout[].scriptPubKey.asm' | grep OP_CHECKSIG | wc -l
```

Ideally something like this should work:

```
# TODO: OP_CHECK(MULTI)SIG in redeemScript:
…  jq -r '.tx[].vin[].redeemScript.asm …
…  jq -r '.tx[].vin[].witnesScript.asm …
```

https://twitter.com/provoost/status/1642165984629780481

### Describe the solution you'd like

An attempt was made in #8849.

### Describe any alternatives you've considered

Inferred miniscript would catch many common P2WSH scripts, but not regular P2SH.

### Please leave any additional context

_No response_
Repository: deno
Issue: Deno.Command().spawn() fails with unclear error message on undefined envs
Labels: bug,public API

**Description:**

Deno.Command().spawn() fails with unclear error message if one of the specified environment variables is set to `undefined`

**Minimal reproduction:**

```ts
// test.ts
const commander = new Deno.Command(
    "deno",
    { 
        args: ["run","test_client.ts"], 
        env: {
            HELLO: undefined
        }
    }
);

commander.spawn();
```

**Expected outcome:**

One of these options 

*    Command runs, ignoring environment variable HELLO
*    Command runs, setting HELLO to an empty string internally
*    A understandable error message

**Actual outcome:**

```
error: Uncaught TypeError: Error parsing args at position 0: serde_v8 error: ExpectedString
commander.spawn();
          ^
    at spawnChildInner (ext:runtime/40_process.js:162:17)
    at spawnChild (ext:runtime/40_process.js:182:10)
    at Command.spawn (ext:runtime/40_process.js:439:12)
    at file:///C:/Users/user/source/pup/test.ts:12:11
```

The error message points to the line containing .spawn(), but there is no indication that the problem is within the environment variables, making it a tricky debug.

**Versions:**

```
PS C:\Users\user\source\pup> deno --version
deno 1.32.2 (release, x86_64-pc-windows-msvc)
v8 11.2.214.9
typescript 5.0.3
```
Repository: godot
Issue: @tool script scene with instantiated child scene can lose data under certain circumstances
Labels: bug,topic:editor

### Godot version

4.0.1, 4.0.2rc1

### System information

Pop!_OS 22.04 (Ubuntu), Intel Xe (TGL GT2), Mesa 22.3.5, Vulkan. Also found in Windows 

### Issue description

This requires some steps to reproduce.

If you have a @tool script scene that has an instantiated child scene, and **both** are open in the editor, then you run a scene, next time you switch into the @tool scene, it will re-instantiate itself (and all child nodes). When this happens, any data that isn't a either an owned child node or variable that would be written to disk (ie. `PROPERTY_USAGE_STORAGE` or equivalent) is reset to its default value (or deleted in the case of _un_-owned child nodes).

### Steps to reproduce

In the reproduction:

1) Open both `scene_reinstantiating_bug.tscn` and `child_scene.tscn` in the editor.
    Note that the editor prints out the instance ids for both nodes on `NOTIFICATION_SCENE_INSTANTIATED`,  and `test_value` is changed from its default value in the `_ready` callback.
2) Run any scene (even a scene that isn't one of these).
3) If the currently open scene is `scene_reinstantiating_bug.tscn`, switch to a different tab (including an empty one).
4) Switch back to `scene_reinstantiating_bug.tscn`.

At this point, `NOTIFICATION_SCENE_INSTANTIATED` will be called again, printing out new instance values for both nodes, and that `test_value` has returned to its default value.

### Minimal reproduction project

[SceneReistantiatingBug.zip](https://github.com/godotengine/godot/files/11130549/SceneReistantiatingBug.zip)
Repository: material-ui
Issue: Non-persistent components aren't garbage collected
Labels: component: menu

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example:
[Example](https://mui.com/material-ui/react-menu/#basic-menu)
Steps:

1. Copy the example for a basic menu and run locally in your own app
2. Start the app and note the DOM Node count, manually garbage collect to confirm the count is correctly low
3. Open and close the menu and note the DOM Node count increase
4. Manually garbage collect and note they stay higher than before the menu was first opened
5. Continue steps 3 and 4 and watch the DOM Node count continue every higher each time


### Current behavior 😯

It seems like the components that don't persist (like menus and tool tips) that they are not garbage collected, or that I'm implementing them very wrong.

If it's a rarely clicked button, that's not so much of an issue, but we have a large virtualised list of Accordions with these components in the summary whose data is changing quite regularly. Scrolling through this list dramatically increases the DOM nodes and the tooltips become detached and sit in memory forever until a page refresh.

I can understand if it stays in memory because the button calling the menu is still there and it's not inefficient, but to keep creating new nodes every time while not clearing out the old ones appears wrong.

Is this a known issue, or have I just implemented it wrong?

### Expected behavior 🤔

Dom Nodes should not continue to increase on multiple open/close events on the same component

### Context 🔦

_No response_

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: Windows 10 10.0.19045
  Binaries:
    Node: 19.4.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD
    npm: 9.2.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: master_preferences
    Edge: Spartan (44.19041.1266.0), Chromium (111.0.1661.62)
  npmPackages:
    @emotion/react: ^11.7.0 => 11.10.4
    @emotion/styled: ^11.6.0 => 11.10.4
    @mui/base:  5.0.0-alpha.97
    @mui/core-downloads-tracker:  5.10.5
    @mui/icons-material: ^5.2.0 => 5.10.3
    @mui/lab: ^5.0.0-alpha.60 => 5.0.0-alpha.99
    @mui/material: ^5.2.1 => 5.10.5
    @mui/private-theming:  5.10.3
    @mui/styled-engine:  5.10.5
    @mui/styled-engine-sc: ^5.1.0 => 5.10.3
    @mui/system:  5.10.5
    @mui/types:  7.2.0
    @mui/utils:  5.10.3
    @types/react:  18.0.20
    react: ^17.0.2 => 17.0.2
    react-dom: ^17.0.2 => 17.0.2
    styled-components: ^5.3.3 => 5.3.5
```
</details>
Repository: stable-diffusion-webui
Issue: [Bug]: Composable Diffusion is not aligned with official implementation 
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

https://github.com/energy-based-model/Compositional-Visual-Generation-with-Composable-Diffusion-Models-PyTorch/blob/45abaa4395c7f427e9207bba2b7aabd440709922/composable_diffusion/composable_stable_diffusion/pipeline_composable_stable_diffusion.py#L539

In official implementation (and in [paper](https://arxiv.org/pdf/2206.01714.pdf), see Algorithm 1), the combination happens on ϵ (i.e. the predicted noise).

https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/22bcc7be428c94e9408f589966c2040187245d81/modules/sd_samplers_kdiffusion.py#L160

In current implementation, the combination happens on x (i.e. the scores given by sampler after a step), this may degrade output quality.

### Commit where the problem happens

22bcc7be428c94e9408f589966c2040187245d81
Repository: storybook
Issue: [Feature Request]: <Stories of>
Labels: feature request,addon: docs,block: other

### Is your feature request related to a problem? Please describe

I have a standalone docs file that's used to document two related components using `<Story of={} />`, `<Source of={} />` etc. I'd like to first present the two components, and then render all their stories.

### Describe the solution you'd like

With a single component I'd render `<Stories />`. In this case I'd like to be able to render

```mdx
<Stories of={StoriesA} />
<Stories of={StoriesB} />
```

### Describe alternatives you've considered

_No response_

### Are you able to assist to bring the feature to reality?

no

### Additional context

_No response_