sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: deno
Issue: Publish deno_cli as a lib crate 
Labels: suggestion,custom runtime

Hi, I'd like to embed Deno into my application and have access to module resolution, typescript and the Nodejs stdlib support offered by Deno.

Currently, Deno offers the ability to use the `deno_core`, `deno_runtime`, etc crates to build-your-own JavaScript runtime - however this lacks all the work that has gone into compatibility, resolution, which are vital for any modern application.

I have had limited success achieving this by forking the Deno repo and modifying the `./cli` crate with a `lib.rs`. This also appears to be what supabase do in order to embed Deno.

Essentially, this is just adding a `lib.rs` to the `./cli` crate and obtaining the arguments programmatically rather than via the CLI arguments 

**What would be awesome**

```rust
use deno_cli::*;

async fn main() -> anyhow::Result<()> {
  let deno = Deno::builder(DenoOptions::default()).build()?;

  deno.eval_blocking(DenoEvalOptions {
    cwd: env::cwd()?,
    code: "console.log('Hello World')",
    exts: vec![] // <- this would be great, as would making extensions available to workers
  })?

  Ok(())
}
```

**What problem does this solve?**

When using Deno as a plugin runtime that transfers a lot of data (for instance a bundler calling out to JavaScript), using inter-process communication and/or shared memory is quite slow/difficult when compared to integrating Deno into the process directly and leveraging the shared memory space.

This is why most applications that use Nodejs as a plugin runtime build their applications as napi extensions.

**Extras**:
- Deno cannot be spawned more than once per process (I guess it's because of the lazy global/static variables?), so embedding it requires maintaining a connection to the running Deno instance - this is a problem because...
- Extensions/ops supplied to the main Deno instance (main JS thread) are not propagated to the JS worker threads and it appears the type signatures make it non-trivial to clone/move extensions into workers. Would be great if extensions could work within workers too
- There are many dependencies that are used by Deno which can conflict with dependencies in an existing project (like swc). I've looked at various ways of addressing this but ultimately the "easiest" approach I found was turning Deno into a library, building it separately as a `cdylib`, embedding the binary within a wrapping Rust crate that has no dependencies and handles the bindings to the binary. It's gross but it works.
Repository: electron
Issue: PDF viewer: open <embed/> shadow DOM to allow customisation of the UI
Labels: enhancement :sparkles:,component/pdf-viewer

### 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 feature request that matches the one I want to file, without success.

### Problem Description

Sometimes it's helpful to be able to customise the PDF viewer UI (eg: hide the Download button, add other buttons, etc.)
Due to shadow DOM encapsulation of the <embed> element, this is currently not possible.

### Proposed Solution

Please consider opening the shadow DOM <embed/> PDF viewer to allow customisation of the UI.
This could be done either by default, or by turning on a preference flag.

### Alternatives Considered

Using custom PDF viewers, PDF.js based, but this has performance issues and is hard to maintain.

### Additional Information

_No response_
Repository: PowerToys
Issue: Start file path from Explorer directly in the workspace
Labels: Needs-Triage

### Description of the new feature / enhancement

I need a folder every morning which is in the same file path. I would find it useful to be able to configure the Explorer in a new workspace so that it starts exactly at this file path. Currently it always fetches the default file path.

### Scenario when this would be used?

For people who want to open the same folder with the file every morning or restart without having to navigate through explorer.

### Supporting information

_No response_
Repository: react
Issue: Bug: Images with `loading="lazy"` remounted with react are all loaded
Labels: Status: Unconfirmed

<!--
  Please provide a clear and concise description of what the bug is. Include
  screenshots if needed. Please test using the latest version of the relevant
  React packages to make sure your issue has not already been fixed.
-->

React version: 18.3.1

## Steps To Reproduce

Open DevTools Network tab and check "disable cache" to see how much data is requested.

1. Render a long list of `<img>` tags with `loading="lazy"` (placed after the `src` attribute)
2. (only a few top images are loaded, you can see max few hundred kb downloaded)
3. Unrender the list
4. Render the list again
5. (all of them are requested, you can see many mb being downloaded)

<!--
  Your bug will get fixed much faster if we can run your code and it doesn't
  have dependencies other than React. Issues without reproduction steps or
  code examples may be immediately closed as not actionable.
-->

Link to code example: https://codesandbox.io/p/sandbox/react-18-forked-2f9q8l?workspaceId=1b03e581-57eb-43f2-80b8-0d9e38ede5b5 (additional explanation below)

<!--
  Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a
  repository on GitHub, or provide a minimal code example that reproduces the
  problem. You may provide a screenshot of the application if you think it is
  relevant to your bug report. Here are some tips for providing a minimal
  example: https://stackoverflow.com/help/mcve.
-->

## The current behavior

Under certain circumstances, all the images are loaded when remounted with React, despite `loading="lazy"` being specified.

The example code above, provides two ways in which the images are removed from DOM and then added again: one using react state, and the other using simple native DOM methods. Turns out that only when React renders the list (and only when it's done for the second+ time), the lazy loading is broken. With DOM methods, you can remount the images many times and every time only few top images are loaded.

There's also a button to switch the position of `loading="lazy"` attribute to be before or after `src=`. It shows that order makes difference and issue occurs only when the `loading` attribute is placed after `src`.

There used to be a bug in Firefox that caused the lazy loading to not work when loading attribute is placed after src, but it is gone and was never a problem in Chrome. Yet, somehow, the way in which React adds the nodes to DOM, reproduces the bug even in Chrome.

I am personally experiencing it in Chrome version 131.0.6778.70 (64bit, windows).

## The expected behavior

No matter the order of attributes, the behavior should be as per the standard browser behavior. It shouldn't matter that it's React appending the nodes or which time it's doing it.
Repository: go
Issue: x/pkgsite: std's reflect expands with zero subpackages in the directory view
Labels: help wanted,pkgsite

### What is the URL of the page with the issue?

https://pkg.go.dev/std

### What is your user agent?

Mozilla/5.0 (X11; Linux x86_64; rv:132.0) Gecko/20100101 Firefox/132.0

### Screenshot

![img-2024-11-13-10-29-54](https://github.com/user-attachments/assets/a790f518-4dc7-47f6-b0f3-c9b32c995149)


### What did you do?

Tried expanding a number of std packages in the directory view to see subpackages.

### What did you see happen?

Any package with the arrow pointing right should expand with subpackages when clicking on the arrow.

### What did you expect to see?

Most packages do that, except reflect, which expands into nothing.

This might be because reflect only has internal sub-packages:

```
$ go list reflect/...
reflect
reflect/internal/example1
reflect/internal/example2
```
Repository: go
Issue: x/build/cmd/coordinator: older dashboard pages omit LUCI builders in detailed views (page 2, x/ repo commits) but don't make it apparent it's WAI
Labels: Builders,NeedsFix,FixPending,Friction

### What did you do?

Navigate to https://build.golang.org/?page=1&branch=master.

### What did you see happen?

Only a small number of builders are displayed:

![image](https://github.com/user-attachments/assets/7d4eaabb-d1f5-4f00-bf3d-327a6cac215d)


### What did you expect to see?

All builders.
Repository: tauri
Issue: [feat] Expose `WindowEvent::KeyboardInput` in Rust
Labels: type: feature request

### Describe the problem

I want to be able to react to key events coming from the application event loop.

I am building a shortcut system for my Desktop app, on macOS. I would like to be able to trigger hotkeys, even if the application doesn't have any windows open. This rules out any js key listener solutions, because they are tied to windows. Plus, this feels like something that should be done over in Rust-land, anyway.

The current recommended solution is to use [rdev](https://crates.io/crates/rdev). This works up to a point (see https://github.com/tauri-apps/tauri/issues/11670), but requires my app to ask for full access to all OS-level keyboard inputs (Accessibility), which is a permission I would rather not depend on.

In reality, this is something that should be solvable by propagating events from the event loop. I scoured through `Tao` a bit and found key event types, so this seems to be within the realm of possibility?

### Describe the solution you'd like

I want to be able to register a key event handler on my app. I envision this would look something like this, but that's of course up for debate:

```rust
tauri::Builder::default()
    .on_key_event(|app, event|{ }))
    .run()
```

I can imagine plug-ins might want to do this too, so maybe we should have a system to register (and unregister) multiple handlers.

### Alternatives considered

- Binding to key event listeners in js, but this can only be done on windows. Besides, imho this is something to be solved on the Rust side, using the application event loop.

- Using `rdev`, but this requires my app to ask for full keyboard monitoring on an OS-level, which is not a permission I want to ask for, really.

  In addition, people have to twiddle with [device_event_filter](https://docs.rs/tauri/latest/tauri/struct.Builder.html#method.device_event_filter), which is neither intuitive nor easy to find.

### Additional context

I've searched through the Discord and issue list, and it seems more people have been requesting this.
Repository: PowerToys
Issue: Alt-Tab map leaves remapped keys pressed
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.85.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

A while back I had some help mapping Ctrl-D to act like Alt-Tab. I took a little bit, but I got it to work, and it has worked really well.

Not that long ago, sometime around April of this year but it is hard to be sure when, I started having what I thought was a different issue. My right Ctrl key kept sticking. I thought this was a keyboard switch issue, but after a long and convoluted process I found that the Alt-Tab mapping to Ctrl-D was leaving the right Ctrl key as if it had been pressed down.

As I said, this hotkey worked perfectly for quite a while. Part of what stumped me about this was that it doesn't matter what machine I use. They have different versions of PowerToys though 0.85.1 is the most recent. Whatever keyboard I do use, once the Alt-Tab behavior has finished, the right Ctrl - and only the r Ctrl - acts as if it is still being pressed. Tapping the Ctrl key releases it. 

The left Alt button also says it is being pressed even after I release Ctrl-D, but it seems like that might be normal for Alt-Tab. I used Switch Hitter to discover all this.

As I said, this worked well for a long while, and now on 3 different machines, 4 different keyboards, many different versions of PowerTools, the same right Ctrl issues always happens. My only thought - I keep my machines updated. Is this somehow caused my updates to Windows, and can that be overcome?

![Image](https://github.com/user-attachments/assets/eae8a99d-6304-4b26-9d67-6055ed2c3599)

### ✔️ Expected Behavior

Ctrl-D would (and has) functioned as Alt-Tab does.

### ❌ Actual Behavior

When the Ctrl-D hotkey is used and then released, the right Ctrl key acts as if it is being pressed.

### Other Software

_No response_
Repository: storybook
Issue: [Bug]: Not able to run storybook 8.4.2 tests with vitest, compilation error with react-swc
Labels: bug,addon: test

### Describe the bug

I am able to start storybook, and also able to see the coverage with the command `test-storybook --coverage --verbose`

but when i run vitest tests with `vitest --project=storybook` 
I am getting below error

```
[plugin:vite:react-swc] × Expected ';', '}' or <eof>
   ╭─[/__vitest_test__/__test__/2aa264b0-e93d-45d5-9477-c86b6ca530ae/C%3A%2FUsers%2FAkshay%2FDocuments%2Fcode%2Fz%2Fstorybook-vitest%2Fsrc%2Fcomponents%2FErrorDisplay.stories.tsx:2:1]
 1 │ 
 2 │       html {
   ·       ──┬─ ─
   ·         ╰── This is the expression part of an expression statement
 3 │         padding: 0;
 4 │         margin: 0;
 5 │       }
   ╰────


Caused by:
    Syntax Error
/__vitest_test__/__test__/2aa264b0-e93d-45d5-9477-c86b6ca530ae/C%3A%2FUsers%2FAkshay%2FDocuments%2Fcode%2Fz%2Fstorybook-vitest%2Fsrc%2Fcomponents%2FErrorDisplay.stories.tsx:2:1
1  |  
2  |        html {
   |            ^
3  |          padding: 0;
4  |          margin: 0;```
```

I am using storybook 8.4.2

### Reproduction link

https://codesandbox.io/p/github/jainaks01-bh/storybook-test-vitest/draft/blazing-water

### Reproduction steps

running command below gives error mentioned above 

https://github.com/jainaks01-bh/storybook-test-vitest

`npm run test`

### System

```bash
Storybook Environment Info:

  System:
    OS: Windows 11 10.0.22631
    CPU: (16) x64 AMD Ryzen 7 7730U with Radeon Graphics
  Binaries:
    Node: 22.7.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.22 - C:\Program Files\nodejs\yarn.CMD
    npm: 10.8.2 - C:\Program Files\nodejs\npm.CMD <----- active
  Browsers:
    Edge: Chromium (128.0.2739.42)
  npmPackages:
    @storybook/addon-coverage: ^1.0.4 => 1.0.4
    @storybook/addon-essentials: ^8.4.2 => 8.4.2
    @storybook/addon-interactions: ^8.4.2 => 8.4.2
    @storybook/addon-links: ^8.4.2 => 8.4.2
    @storybook/addon-onboarding: ^8.4.2 => 8.4.2
    @storybook/blocks: ^8.4.2 => 8.4.2
    @storybook/experimental-addon-test: ^8.4.2 => 8.4.2
    @storybook/react: ^8.4.2 => 8.4.2
    @storybook/react-vite: ^8.4.2 => 8.4.2
    @storybook/test: ^8.4.2 => 8.4.2
    @storybook/test-runner: ^0.19.1 => 0.19.1
    before-storybook: file: => 0.0.0
    chromatic: ^11.18.1 => 11.18.1
    eslint-plugin-storybook: ^0.11.0 => 0.11.0
    msw-storybook-addon: ^2.0.4 => 2.0.4
    storybook: ^8.4.2 => 8.4.2
```

### Additional context

_No response_
Repository: excalidraw
Issue: Revert arrow binding when moving single arrow
Labels: enhancement,UX/UI,Arrow Binding

As of now, there is no way to rebind an arrow other than dragging the point handle, which is frustrating as one needs to manually adjust every single point. It's especially annoying with slight adjustments, which lead to slightly different arrow length / angle, so it needs to be additionally manually repositioned. Instead, rebinding the arrow should be as simple as dragging it, as we've had it before.

**Technical details**
1. don't bind when moving non-arrow element
2. don't bind when moving multiple arrows or an arrow + other element(s)

**Now**

https://github.com/user-attachments/assets/e9fe82b4-08ad-4968-8eae-96c869081a95

**Before / After**

https://github.com/user-attachments/assets/9b1a8a05-7c6a-4f18-95f6-add99c51a8c0
Repository: deno
Issue: OpenTelemetry epic
Labels: feat

- [x] Land initial support for user created traces + exporting with OTLP
- [x] Land initial support for exporting `console.log` with OTLP (with associated traces)
- [x] Land initial support for user created metrics + exporting with OTLP
- [ ] Configure trace sampling through `OTEL_TRACES_SAMPLER`
- [ ] Respect `OTEL_SDK_DISABLED`
- [ ] Respect `OTEL_PROPAGATORS`
- [x] Ensure telemetry is flushed in all cases:
  - [x] `console.log("foo"); // Program naturally exits here`
  - [x] `console.log("foo"); Deno.exit(0);`
  - [x] `console.log("foo"); throw new Error("uncaught");`
    - [x] Ensure that "uncaught" is also collected by logging
  - [x] Web worker logs something and immediate calls `self.close()`
  - [x] Web worker logs something and calls `Deno.exit()` (`self.close()` alias in workers?)
  - [x] Web worker logs something and the main worker immediately calls `worker.terminate()`
  - [x] Web worker logs something and throws an exception.

Then there is a bunch of work to auto instrument built in APIs. A very basic initial list that will be expanded:

- [ ] `Deno.serve` / `node:http` (server)
  - [x] Create traces for incoming requests
    - Ensure that users can set `http.route` attribute on the automatic span
  - [ ] Propagation of trace ID from incoming headers
  - [ ] Metrics for latency
- [ ] `fetch` / `node:http` (client)
  - [x] Create traces for outbound requests
  - [ ] Propagation of trace ID into outgoing headers
  - [ ] Metrics for latency
  - [ ] Metrics for connection pool
Repository: ollama
Issue: AMD Radeon 780M GPU (Pop OS !) System 76
Labels: bug,linux,amd,gpu

### What is the issue?

Hi,

I would like to ask your help.
I am running Ollama with the following GPU, but it seems that it is not picking up my GPU. Is there any advice ?

AMD Ryzen™ 7 7840U processor.

When I **run ollama serve**, it gives me this error. Any advice ?

Thanks
```
2024/11/13 17:40:14 routes.go:1189: INFO server config env="map[CUDA_VISIBLE_DEVICES: GPU_DEVICE_ORDINAL: HIP_VISIBLE_DEVICES: HSA_OVERRIDE_GFX_VERSION:11.0.0 HTTPS_PROXY: HTTP_PROXY: NO_PROXY: OLLAMA_DEBUG:false OLLAMA_FLASH_ATTENTION:false OLLAMA_GPU_OVERHEAD:0 OLLAMA_HOST:http://127.0.0.1:11435 OLLAMA_INTEL_GPU:false OLLAMA_KEEP_ALIVE:5m0s OLLAMA_LLM_LIBRARY: OLLAMA_LOAD_TIMEOUT:5m0s OLLAMA_MAX_LOADED_MODELS:0 OLLAMA_MAX_QUEUE:512 OLLAMA_MODELS:/home/ihshan/.ollama/models OLLAMA_MULTIUSER_CACHE:false OLLAMA_NOHISTORY:false OLLAMA_NOPRUNE:false OLLAMA_NUM_PARALLEL:0 OLLAMA_ORIGINS:[http://localhost https://localhost http://localhost:* https://localhost:* http://127.0.0.1 https://127.0.0.1 http://127.0.0.1:* https://127.0.0.1:* http://0.0.0.0 https://0.0.0.0 http://0.0.0.0:* https://0.0.0.0:* app://* file://* tauri://* vscode-webview://*] OLLAMA_SCHED_SPREAD:false OLLAMA_TMPDIR: ROCR_VISIBLE_DEVICES: http_proxy: https_proxy: no_proxy:]"
time=2024-11-13T17:40:14.880+07:00 level=INFO source=images.go:755 msg="total blobs: 0"
time=2024-11-13T17:40:14.880+07:00 level=INFO source=images.go:762 msg="total unused blobs removed: 0"
time=2024-11-13T17:40:14.881+07:00 level=INFO source=routes.go:1240 msg="Listening on 127.0.0.1:11435 (version 0.4.1)"
time=2024-11-13T17:40:14.881+07:00 level=INFO source=common.go:135 msg="extracting embedded files" dir=/tmp/ollama1477910346/runners
time=2024-11-13T17:40:14.949+07:00 level=INFO source=common.go:49 msg="Dynamic LLM libraries" runners="[rocm cpu cpu_avx cpu_avx2 cuda_v11 cuda_v12]"
time=2024-11-13T17:40:14.949+07:00 level=INFO source=gpu.go:221 msg="looking for compatible GPUs"
time=2024-11-13T17:40:16.902+07:00 level=INFO source=gpu.go:610 msg="no nvidia devices detected by library /usr/lib/x86_64-linux-gnu/libcuda.so.560.35.03"
time=2024-11-13T17:40:22.056+07:00 level=WARN source=amd_linux.go:61 msg="ollama recommends running the https://www.amd.com/en/support/linux-drivers" error="amdgpu version file missing: /sys/module/amdgpu/version stat /sys/module/amdgpu/version: no such file or directory"
time=2024-11-13T17:40:22.057+07:00 level=INFO source=amd_linux.go:296 msg="unsupported Radeon iGPU detected skipping" id=0 total="512.0 MiB"
time=2024-11-13T17:40:22.057+07:00 level=INFO source=amd_linux.go:399 msg="no compatible amdgpu devices detected"
time=2024-11-13T17:40:22.057+07:00 level=INFO source=gpu.go:386 msg="no compatible GPUs were discovered"
time=2024-11-13T17:40:22.057+07:00 level=INFO source=types.go:123 msg="inference compute" id=0 library=cpu variant=avx2 compute="" driver=0.0 name="" total="30.6 GiB" available="23.7 GiB"
```


### OS

Linux

### GPU

AMD

### CPU

Other

### Ollama version

0.4.1
Repository: rust
Issue: `//@ {unset-,}{rustc,exec}-env` parsing is a footgun
Labels: E-hard,T-bootstrap,C-bug,A-compiletest,E-needs-design

Apparently

```
//@ rustc-env: RUSTC_BOOTSTRAP=1
```

is not the same as

```
//@ rustc-env:RUSTC_BOOTSTRAP=1
```

compiletest will parse the former as an env var called `⌴RUSTC_BOOTSTRAP` (incl. the whitespace).
Repository: flutter
Issue: Mac framework_tests_impeller is 2.08% flaky
Labels: P1,c: flake,team-framework,triaged-framework

<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
  "name": "Mac framework_tests_impeller"
}
-->

The post-submit test builder `Mac framework_tests_impeller` had a flaky ratio 2.08% for the past (up to) 100 commits, which is above our 2.00% threshold.

One recent flaky example for a same commit: https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20framework_tests_impeller/3866
Commit: https://github.com/flutter/flutter/commit/4de32b870212f33610be0ec122001d695f373a77

Flaky builds:
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20framework_tests_impeller/3866
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20framework_tests_impeller/3802
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20framework_tests_impeller/3801

Recent test runs:
https://flutter-dashboard.appspot.com/#/build?taskFilter=Mac%20framework_tests_impeller

Please follow https://github.com/flutter/flutter/blob/master/docs/infra/Reducing-Test-Flakiness.md#fixing-flaky-tests to fix the flakiness and enable the test back after validating the fix (internal dashboard to validate: go/flutter_test_flakiness).
Repository: flutter
Issue: Mac_x64 build_tests_1_4 is 2.08% flaky
Labels: P2,c: flake,team-tool

<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
  "name": "Mac_x64 build_tests_1_4"
}
-->

The post-submit test builder `Mac_x64 build_tests_1_4` had a flaky ratio 2.08% for the past (up to) 100 commits, which is above our 2.00% threshold.

One recent flaky example for a same commit: https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_x64%20build_tests_1_4/4301
Commit: https://github.com/flutter/flutter/commit/95a9b97f88a841497ea986b059c594d9321a08ce

Flaky builds:
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_x64%20build_tests_1_4/4301
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_x64%20build_tests_1_4/4270

Recent test runs:
https://flutter-dashboard.appspot.com/#/build?taskFilter=Mac_x64%20build_tests_1_4

Please follow https://github.com/flutter/flutter/blob/master/docs/infra/Reducing-Test-Flakiness.md#fixing-flaky-tests to fix the flakiness and enable the test back after validating the fix (internal dashboard to validate: go/flutter_test_flakiness).