sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: deno
Issue: feat: `deno flamegraph`
Labels: cli,suggestion

In order to analyse application performance, it can be useful to view a flamegraph, much like what `cargo flamegraph` is doing (https://github.com/flamegraph-rs/flamegraph). I suggest to have `deno flamegraph` that outputs a similar SVG file for the JavaScript side.

Deno can already do benchmarks with `deno bench` and perhaps someone has a good idea how to integrate these two related features?
Repository: next.js
Issue: Cancel rendering route error on opening recently closed tab in Safari 16, 15, 14, 13
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://github.com/renatoruk/cancel-rendering-route-nextjs

### To Reproduce

1. run `next build`
2. run `next start`
3. open  **Safari 13, 14, 15 or 16** (Safari **17** works normally)
4. open a new tab with `[id]` page with an arbitrary value (e.g. `localhost:3000/1`)
5. close the newly opened tab (`localhost:3000/1`)
6. Go to "History -> *Reopen Last Closed Tab*" (or CMD + Shift + T)

### Current vs. Expected behavior

Observing the console, "Cancel rendering route" error occurs, along with react errors [425](https://react.dev/errors/425?invariant=425) and [423](https://react.dev/errors/423?invariant=423).

I expect that not to happen, but I suspect the culprit is Safari which creates a `popstate` event by opening a recently closed tab. This is visible in 00:50 in the video below ("Cancel rendering route video") where the app from the repo is opened in Safari 16.0.

However, the Safari 17.2.1 does not create a `popstate` event in the same scenario and thus the error does not happen.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.2.0: Wed Nov 15 21:55:06 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6020
Binaries:
  Node: 18.18.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.1.1-canary.10 // Latest available version is detected (14.1.1-canary.10).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Routing (next/router, next/navigation, next/link)

### Which stage(s) are affected? (Select all that apply)

next build (local)

### Additional context

Currently, the app is tested on version `14.1.1-canary.10`, but the error can be reproduced also on version `12.3.4` so it's not a new bug.

I tried to tackle the bug myself and the furthest I got was somewhere along the lines of [onPopState](https://github.com/vercel/next.js/blob/canary/packages/next/src/shared/lib/router/router.ts#L900) function inside `shared/lib/router/router.ts` . I saw inconsistencies between shallow value being true or false if the popstate event occurred on initial page rendering, but I could not point where exactly the issue was. I wonder if the router should somehow disregard the `popstate` event and instead treat the page as a freshly opened, completely disregarding that it was opened as "previously closed tab".

Cancel rendering route video (Safari 16.0)

https://github.com/vercel/next.js/assets/12981417/846d596c-9238-417c-b210-9ca529acfe45

No cancel rendering route error video (Safari 17.2.1)

https://github.com/vercel/next.js/assets/12981417/de35b464-d390-4851-89f0-43f3a980c83b
Repository: electron
Issue: [Bug]: BrowserView setBound not resizing
Labels: platform/macOS,bug :beetle:,status/confirmed,has-repro-gist,macos sonoma,28-x-y,29-x-y

### 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

28.2.0

### What operating system are you using?

macOS

### Operating System Version

MacOS 14.3

### What arch are you using?

x64

### Last Known Working Electron version

27.3.0

### Expected Behavior

When I have more than one BrowserView in a BrowserWindow and when I want to resize one BrowserView to zero for width and height using `BrowserView.setBounds` API, it correctly resizing to zero.

### Actual Behavior

When I use `BrowserView.setBounds` API to resize one BrowserView to zero for width and height, the BrowserView keep its actual size and show the default backgroundColor of the webpage instead.

### Testcase Gist URL

https://gist.github.com/doctolivier/b504c40cb57b5abc29fded32709049ac

### Additional Information

In the gist Fiddle, we can see that the view1 keep its size and show white background on Electron 28 and MacOS 14.x (arm64 & x64)
I only have this bug on MacOS 14.x and Electron 28.x, I cannot reproduce on MacOS 13.x and Windows.
Repository: ollama
Issue: If you have multiple GPUs then the new default `split_mode = "layer"` option in the wrapped `llama.cpp`  server may effect you alot!
Labels: performance,nvidia

I'm not sure why the `llama.cpp` devs have made the new default `split_mode = "layer"`, but it runs ***MUCH*** worse for me and I only get around 60% of the tokens/s that I get with `split_mode = "row"` (using 2x RTX A6000 and an NvLink bridge).

The only difference I can see is that using `split_mode = "layer"` seems to allocate the VRAM much more evenly.

I'm also seeing nothing move through the NvLink bridge now unless I set `main_gpu = 0`, but this doesn't really have any effect on the poor performance of `split_mode = "layer"`.

See https://github.com/ollama/ollama/pull/2190 for more details and the fix.
Repository: vscode
Issue: Webviews Opened with 'Beside' become orphaned instead of closing
Labels: bug,webview

<!-- ⚠️⚠️ 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.85.2
- OS Version: Mac M1 / Sonoma 14.2.1

Steps to Reproduce:

1. Clone https://github.com/microsoft/vscode-extension-samples
2. `cd` into vscode-extension-samples/webview-codicons-sample
3. `npm install`
4. `npm run compile`
5. Run
6. execute _catCodicons.show_
7. If you split it to any other location, the new one is blank. Close and relaunch the app, and the one in the sidebar is still visible, taking up space, but has no content.

This mimics the behavior we're seeing of opening a NEW webview that has a viewLocation set to 'beside' (except our new one has content since we're creating it that way) and then closing / reopening the application.

When these new webviews are opened as a normal editor, closing the application closes these windows. When a webview is opened 'beside' another editor, closing the application does not close these windows. It leaves them 'orphaned' or 'zombied'. When you relaunch the application, the space is still reserved, but nothing shows. 

I understand we may be able to resolve it by serializing / deserializing state, but is there a reason they don't close like a normal webview? (I'd prefer they close in this instance, like the others)
Repository: flutter
Issue: Consider moving inner classes in `FlutterRenderer` into separate files
Labels: platform-android,engine,P2,c: tech-debt,team-engine,triaged-engine

[`shell/platform/android/io/flutter/embedding/engine/renderer/FlutterRenderer.java`](https://github.com/flutter/engine/blob/main/shell/platform/android/io/flutter/embedding/engine/renderer/FlutterRenderer.java) has 8 `class`es, each of which are not always used for every code path.

It makes viewing the file (and reviewing changes to it) cumbersome as it's not clear what the scope is without careful reading.

For example, see https://github.com/flutter/engine/pull/50033/files.

I'm not saying let's create 8 files... but probably something between 1 and 8 :)
Repository: vscode
Issue: Add "discovery" as a kind for TestRunProfiles
Labels: api,under-discussion,testing

The testing API currently allows for `TestRunProfiles` with 3 different options for `kind`: run, debug, or coverage. With the Python extensions upcoming changes to custom args which expands functionality, we would need a `discovery` kind of profile (see proposal for custom args [here](https://github.com/microsoft/vscode-python/issues/21845)). Looking to have this profile be configurable the same way the `run` button is in the test view when you have multiple configs. Have the discover button (the refresh button) have a dropdown that lists the different configuration options, a default, and a click through option to edit the configs.
Repository: material-ui
Issue: [material-ui] Add console warnings when closer to v7 deprecation removals
Labels: deprecation,package: material-ui

To make deprecations more noticeable, we'll add console warnings time before v7 is released.

**Search keywords**:
Repository: flutter
Issue: [Impeller] remove thread local storage for the command buffer pool
Labels: P3,c: tech-debt,e: impeller,team-engine,triaged-engine

See `impeller/renderer/backend/vulkan/command_pool_vk.cc`

We use thread local storage to own the command buffer pool but this creates tricky situations for the shutdown of contexts.

For example, having a static ContextVK for tests that uses absl::NoDestructor will crash since the destructor for the thread will still be called.

Thread local storage is also adding the undue overhead of thread synchronization.

Alternatively we can find the objects in the engine who can safely own and dish out the command buffer pool to a given thread.  I've done it before as part of a PR that got dropped for other reasons.
Repository: flutter
Issue: [camera] Provide API for camera list change notification
Labels: c: new feature,p: camera,package,team-ecosystem,P2,triaged-ecosystem

On an increasing number of platforms we support, the list of cameras is dynamic, since cameras can be added and removed (already true for Windows and web, will be true for macOS, will be true for iOS and Android if/when external camera support is added). Currently there's no way for a plugin client to know when `getAvailableCameras` would return different results, or when a camera that may have previously been found is gone.

We should have some kind of stream or callback-based API for tracking changes to the available device list over time.
Repository: go
Issue: runtime: TestReadMetricsCumulative failures
Labels: NeedsInvestigation,compiler/runtime

```
#!watchflakes
default <- pkg == "runtime" && test == "TestReadMetricsCumulative"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/ui/b/8758124500513543937)):

    === RUN   TestReadMetricsCumulative
        metrics_test.go:543: /cpu/classes/user:cpu-seconds decreased: 12.036168 < 12.063208
    --- FAIL: TestReadMetricsCumulative (0.02s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: vscode
Issue: Focus indicator is cropped on checkboxes under a dropdown of multi select command parameter in command center.
Labels: bug,polish,quick-pick,confirmed

<!-- ⚠️⚠️ 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.85.2
- OS Version: Windows 11 Enterprise (Windows_NT x64 10.0.22631.3007)

```
Version: 1.85.2 (user setup)
Commit: 8b3775030ed1a69b13e4f4c628c612102e30a681
Date: 2024-01-18T06:40:10.514Z
Electron: 25.9.7
ElectronBuildId: 26354273
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.22631
```

**Description**
We are making a VS Code extension. During our accessibility test, the tester reports that the focus indicator is not _properly visible_ on all checkboxes. I checked and see the left border of the focus indicator is cropped.

![image](https://github.com/microsoft/vscode/assets/5415452/77245583-632f-470b-93d0-1ee9179184ab)
Repository: go
Issue: proposal: build: promote windows/arm64 to first class port
Labels: OS-Windows,Proposal,Proposal-Hold,arch-arm64

### Proposal Details

We (@qmuntal, @gdams, and I--Microsoft folks) think the windows/arm64 port is at a point where it fits https://go.dev/wiki/PortingPolicy#first-class-ports and can be promoted.

Specifically: the windows/arm64 builders have been running for a while and don't seem to have unreasonable maintenance problems, and the builders are operated by the Go team.

I'm raising this proposal to see if it's time, or to find out if there's anything we can help with to get it there.

Follows up on this comment and issue:

* https://github.com/golang/go/issues/53383#issuecomment-1163441070
* https://github.com/golang/go/issues/53541
Repository: rust
Issue: Add lint to detect lifetime parameters that could be replaced by `'static`
Labels: A-lints,A-lifetimes,T-lang,T-compiler,C-feature-request

### Code

```Rust
pub fn foo<'a>() -> &'a i32 {&0}
```


### Current output

```Shell
empty
```


### Desired output

```Shell
warning: lifetime parameter `'a` is unnecessary
 --> src/lib.rs:1:12
  |
1 | pub fn foo<'a>() -> &'a i32 {&0};
  |            ^^ unnecessary lifetime parameter
  |
  = help: consider removing `'a`, using `'static` instead
```


### Rationale and extra context

In some cases lifetime parameters might as well be `'static` because of subtyping. Using a `'static` lifetime can simplify the signature by avoiding generics and help teach beginners that the only reason this works is because of static promotion. Adding something about static promotion to the warning could also make sense. I'm not too happy with my "desired output".

This is also related to the `unused_lifetimes` lint, but that doesn't catch this either and it's not exactly "unused".

Credit goes to @estebank for the suggestion in https://github.com/rust-lang/rust/issues/48998#issuecomment-372911479

### Other cases

_No response_

### Rust Version

```Shell
rustc 1.75.0 (82e1608df 2023-12-21)
binary: rustc
commit-hash: 82e1608dfa6e0b5569232559e3d385fea5a93112
commit-date: 2023-12-21
host: x86_64-pc-windows-msvc
release: 1.75.0
LLVM version: 17.0.6
```


### Anything else?

_No response_
Repository: puppeteer
Issue: [Feature]: Changing Screen-cast Quality 
Labels: feature,P3

### Feature description

Right now Puppeteer gives the ability to record screen-casts with https://pptr.dev/api/puppeteer.page.screencast/. However if you do a screen-cast of around 5 mins (with `window-size=1920,1080`) the file size is around, 10MB and takes a while for the screen-cast to finish the recording. 

It would be nice to expand the [ScreencastOptions](https://pptr.dev/api/puppeteer.screencastoptions) with the ability to set the frame-rate. This way users can opt for lower frame rates if they just need a screen-cast for debugging purposes for example.
Repository: storybook
Issue: [Bug]: Adding Storybook to NextJS 14 app with typescript freezes the build step at linting and type checking
Labels: bug,nextjs

### Describe the bug

Following the official documentation [here](https://storybook.js.org/recipes/next), I added Storybook to my existing NextJS project and after the storybook installation was completed, the storybook server started and worked fine. But the next thing when I try to build my project with `npm run build` which would in turn run `next build`, the build process gets stuck at `Linting and checking validity of types` forever.

Version Info:
```
"next": "14.0.1",
"storybook": "^7.6.10",
"typescript": "^5.2.2"
```

### To Reproduce

_No response_

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 14.3
    CPU: (8) arm64 Apple M2
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 19.8.1 - ~/.nvm/versions/node/v19.8.1/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 9.5.1 - ~/.nvm/versions/node/v19.8.1/bin/npm <----- active
  Browsers:
    Chrome: 120.0.6099.234
    Safari: 17.3
  npmPackages:
    @storybook/addon-essentials: ^7.6.10 => 7.6.10 
    @storybook/addon-interactions: ^7.6.10 => 7.6.10 
    @storybook/addon-links: ^7.6.10 => 7.6.10 
    @storybook/addon-onboarding: ^1.0.11 => 1.0.11 
    @storybook/blocks: ^7.6.10 => 7.6.10 
    @storybook/nextjs: ^7.6.10 => 7.6.10 
    @storybook/react: ^7.6.10 => 7.6.10 
    @storybook/test: ^7.6.10 => 7.6.10 
    storybook: ^7.6.10 => 7.6.10
```


### Additional context

_No response_
Repository: godot
Issue: GradientTexture2D repeat option is broken (differently in 4 vs 3)
Labels: discussion,topic:rendering

### Tested versions

Texture repeat has been broken for some time. Often in v3 clicking the 'repeat' flag in the editor does nothing. The system looks like it was overhauled in v4, the GradientTexture2D has a 'Repeat' option but it doesn't affect the way it's rendered. (v4 always repeats, v3 never repeats)

### System information

Godot v4.2.1.stable - Ubuntu 20.04.6 LTS (Focal Fossa) - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3050 Laptop GPU () - 12th Gen Intel(R) Core(TM) i7-12700H (14 Threads) and Godot 3.5.2.stable - Ubuntu 20.04.6 LTS (Focal Fossa) - GLES3 - dedicated NVIDIA GeForce RTX 3050 Laptop 

### Issue description

Using the repeat option in GradientTexture2D does not work.

In v4 the texture aways repeats
In v3 the texture never repeats (unless you use a script to set the `repeat` flag)

### Steps to reproduce

Run the reproduction projects. One texture has repeat enabled, the other has it disabled, both repeat in v4 and neither repeats in v3

Setting the option in the editor may work sometimes, but never saves. (try reloading or running the project)

### Minimal reproduction project (MRP)

[texture_flags_not_saved.zip](https://github.com/godotengine/godot/files/14056514/texture_flags_not_saved.zip)

### Workaround

In v3 you can work around this issue by adding a script that sets the texture flag on the resource after it's loaded:

```
const MAT = preload("res://path/to/mat.tres")

func _ready():
	MAT.albedo_texture.flags &= ~Texture.FLAG_REPEAT
	MAT.albedo_texture.flags |= Texture.FLAG_REPEAT
```
Repository: flutter
Issue: Use GuardedBy in the Android engine code
Labels: platform-android,engine,P2,c: tech-debt,team-engine,triaged-engine

Context: https://github.com/google/error-prone/blob/master/docs/bugpattern/GuardedBy.md
Repository: neovim
Issue: Include Tree-sitter query linter in CI
Labels: ci,treesitter

## Problem

We have no validation in CI that bundled parsers and queries are in alignment. This can lead to problems like https://github.com/neovim/neovim/pull/27191.

## Solution

Run a lint job in CI that validates all of the queries in `runtime/queries` against the bundled parsers.
Repository: flutter
Issue: [Impeller] Skia gold link sometimes doesn't show updated goldens.
Labels: engine,dependency: skia,P3,e: impeller,team-engine,triaged-engine

Happened on this PR: https://github.com/flutter/engine/pull/50035
Others have previously experienced this.

According to @jonahwilliams, Skia gold doesn't like when you change history/force push.
Repository: flutter
Issue: Build timeouts based on average run times
Labels: team-infra,P2,triaged-infra

### Type of Request

infra task

### Infrastructure Environment

LUCI

### What is happening?

There are a class of build failures that are due to some step getting stuck, and the build eventually times out (~60mins or more). And a number of these failing builds would/could succeed on a rerun.

Many of our builds have comparatively short average runtimes compared to the timeouts (8mins vs 60+mins). If we can establish per build timeouts that are based on the average runtimes for the build, we can rerun these builds much earlier.

Here is an example of one of these failures: https://ci.chromium.org/ui/p/flutter/builders/prod/Windows_arm64%20run_debug_test_windows/1321/overview

### Steps to reproduce

Step 1:
Step 2:
..
Step n:


### Expected results

I expect to see X when Y is finished.
Repository: kubernetes
Issue: Publish finer-grained failure reason for podFailurePolicy
Labels: kind/feature,sig/apps,triage/accepted,wg/batch

### What would you like to be added?

When a Job failure is triggered via PodFailurePolicy, we currently set a generic reason on the failure condition, which is "PodFailurePolicy"

It would be great if the reason is more specific about the failure reason, which exact rule failed the job. There are few ways of doing that: 

1) Add a `Reason` field to `PodFailurePolicyRule` to allow users to _optionally_ decide what reason should show up on the condition when the rule is triggered. We verify that it should be a single word with a specific length limit (because reasons are typically machine readable codes).

2) In the case of onExitCodes to have the code appended to the reason, like "PodFailurePolicy-ExitCode143". But this will be tricky to do for the OnPodConditions case.

My preference is the first option.



### Why is this needed?

This will give higher order APIs that use Job as a building block (such as JobSet) control in how they react to the child Job failure based on the container exit code. See https://github.com/kubernetes-sigs/jobset/pull/381 for more details.


/wg batch
/sig apps