sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: bitcoin
Issue: Performance decrease after tapscript miniscript
Labels: RPC/REST/ZMQ,Descriptors

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

@eriknylund noticed while testing large multisigs that after 4f473ea515bc77b9138323dab8a741c063d32e8f `sendtoaddress` causes a timeout for much smaller (though still rather large) multisigs than before.

https://github.com/bitcoin/bitcoin/pull/28212#discussion_r1428484311

### Expected behaviour

Not sure, perhaps the performance decrease is justified. Ideally it would not slow down.

Since these descriptors don't involve any miniscript-specific operations, perhaps it's possible to return earlier in whatever parsing / signing algorithm is involved here. 

### Steps to reproduce

Run the large multisig test in the above mentioned PR before and after the commit.

### Relevant log output

_No response_

### How did you obtain Bitcoin Core

Compiled from source

### What version of Bitcoin Core are you using?

master@4f473ea515bc77b9138323dab8a741c063d32e8f

### Operating system and version

macOS and CI

### Machine specifications

_No response_
Repository: vscode
Issue: Replace in files global command should move focus
Labels: bug,search,confirmed

When running `workbench.action.replaceInFiles` <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>H</kbd> with global search view already visible it shows the "Replace" input but it doesn't focus it.

It would be consistent with editor find widget to do that (pressing <kbd>Ctrl</kbd>+<kbd>H</kbd> multiple times switches focus between "Search" and "Replace" inputs).
Repository: rust
Issue: Documentation example of lint warnings broken for rustc lints
Labels: C-enhancement,P-low,T-compiler,A-docs

Rustc lints have placeholder `{{produces}}` in examples that should generate actual warnings for documentation, but it currently not working, as can be seen on https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/let_underscore/static.LET_UNDERSCORE_DROP.html, for example; it should contain actual warning text instead of `{{produces}}`.

As of version presented on site:
```
1.76.0-nightly (a96d57bdb 2023-12-15)
```

Some description of how it should work: https://github.com/rust-lang/rust/blob/1c6a06183a1452c2772db370b572e38bac9c5d86/compiler/rustc_lint_defs/src/lib.rs#L769-L788
Repository: tauri
Issue: Unable to correctly obtain full screen attribute when monitoring window size changes
Labels: type: bug,status: needs triage

### Describe the bug

After listening to the onResized window in Vue's onMounted and obtaining the return value of appWindow. isFullscreen(), it was found that the value was incorrect. And sometimes the monitoring will be executed twice.

### Reproduction

_No response_

### Expected behavior

Obtain correct isFullscreen information

### Platform and versions

```text
[✔] Environment
    - OS: Windows 10.0.22621 X64
    ✔ WebView2: 120.0.2210.61
    ✔ MSVC: Visual Studio Professional 2022
    ✔ rustc: 1.71.0 (8ede3aae2 2023-07-12)
    ✔ cargo: 1.71.0 (cfd3bbd8f 2023-06-08)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 18.16.0
    - pnpm: 8.5.1
    - yarn: 1.22.17
    - npm: 9.5.1

[-] Packages
    - tauri [RUST]: 1.5.3
    - tauri-build [RUST]: 1.5.0
    - wry [RUST]: 0.24.6
    - tao [RUST]: 0.16.5
    - @tauri-apps/api [NPM]: 1.5.1 (outdated, latest: 1.5.2)
    - @tauri-apps/cli [NPM]: 1.5.6 (outdated, latest: 1.5.8)

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: Vue.js
    - bundler: Vite
```


### Stack trace

```text
test.vue

onMounted(async () => {
  const unlisten = await appWindow.onResized(async ({ payload: size }) => {
    console.log('payload: size', size)
    const isFull  = await appWindow.isFullscreen();
    console.log('isFull: ', isFull);
  });
})
```


### Additional context

_No response_
Repository: vscode
Issue: Use inline diff view for added and removed files by default
Labels: diff-editor

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
Half of the diff editor is wasted for added and removed files. It would be better to use inline view by default for these files. Workaround is to switch between side-by-side and inline views constantly.

I would also like the background color removed if possible. A small indicator would be sufficient to understand if the file is added or removed.

![image](https://github.com/microsoft/vscode/assets/8676450/4b6ffc10-fafd-4dce-8580-7058e5512dc9)
![image](https://github.com/microsoft/vscode/assets/8676450/964bd3ba-287e-4c01-a619-88d8a84f3ad6)
Repository: deno
Issue: Allow unstable feature flags to have different forms
Labels: cli,suggestion,node compat

In particular `--unstable-unsafe-proto` is unnecessarily long. It would be nice to have `--enable-proto` also as an alias which would correspond nicely to Node's `--disable-proto`
Repository: deno
Issue: console.log %c with background-color #FFFFFF overwrites the next background color
Labels: bug,ext/console

Version: Deno 1.39.0

**Code**
```js
console.log(`%c %c `, `background-color: rgb(255, 255, 255)`, `background-color: #FFAFC8`);
console.log(`%c %c `, `background-color: #FFFFFF`, `background-color: #FFAFC8`);
```

**Result**
<img width="351" alt="image" src="https://github.com/denoland/deno/assets/7000710/c913cba4-3a1b-48d4-ab36-8a50b33d3f80">

I'm using the VSCode integrated terminal

**Expected**
The two lines should be the same: a white block followed by a pink block.

**Additional notes**
If instead of FFAFC8 I use 74D7EE as the second color, it works as expected:
```js
console.log(`%c %c `, `background-color: rgb(255, 255, 255)`, `background-color: #74D7EE`);
console.log(`%c %c `, `background-color: #FFFFFF`, `background-color: #74D7EE`);
```
<img width="351" alt="image" src="https://github.com/denoland/deno/assets/7000710/20ec4534-d8f5-46a2-9204-cfb6f67b7b17">
Repository: neovim
Issue: Having manually set `cterm` / `gui` attributes at default color scheme blocks updating other attributes when changing 'background'
Labels: bug-vim,highlight

### Problem

Setting `cterm` / `gui` attribute for highlight group in `nvim --clean` prevents corresponding `cterm{fg,bg}` / `gui{fg,bg}` attributes to be updated after changing background.

### Steps to reproduce

1. `nvim --clean`
2. `:hi Comment cterm=underline`
3. `:hi Comment` and remember values of all attributes. On current `master` it would be `cterm=underline ctermfg=247 guifg=NvimLightGrey4`. Prior to default color scheme update (at 481a3158866638946c91fab28ae5bca97ff1e814) it was `cterm=underline ctermfg=14 guifg=#80a0ff`.
4. `:set bg=light` (assuming initial value was "dark").
5. `:hi Comment` and see which values have changed. On current `master` it is observed to be `cterm=underline ctermfg=247 guifg=NvimDarkGrey4`. Prior to default color scheme update it is `cterm=underline ctermfg=14 guifg=Blue`. Both of them have `guifg` changed while `ctermfg` remains the same.

------

This doesn't seem to be a new issue, because it is reproducible on at least 0.6.1.

### Expected behavior

Having highlight group partially manually updated should not restrict it to be updated according to the default color scheme. If reproduction steps are done without `:hi Comment cterm=underline`, this is the expected output:
- On current `master`: `ctermfg=239 guifg=NvimDarkGrey4`.
- On previous default color scheme: `ctermfg=4 guifg=Blue`.


### Neovim version (nvim -v)

NVIM v0.10.0-dev-1857+g7cae94e91

### Vim (not Nvim) behaves the same?

No

### Operating system/version

EndeavourOS Linux x86_64 (6.6.3-arch1-1)

### Terminal name/version

st-0.9

### $TERM environment variable

st-256color

### Installation

Both appimage and from source
Repository: godot
Issue: Huge FPS Spikes
Labels: topic:rendering,needs testing,performance

### Tested versions

all godot 4 versions

### System information

Godot v4.2.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce GT 1030 (NVIDIA; 31.0.15.3742) - AMD Ryzen 3 1300X Quad-Core Processor (4 Threads)

### Issue description

When you create high post-processing effects in Godot 4 it will create large fps spikes (doesn't mean it should perform better, i.e. it doesn't need to create large fps spikes, it needs to create low fps) but the production is fine. I tested on a better computer that computer can handle it but my computer can't.

### Steps to reproduce

-Open a new project
-Create some high post processing effects
-And run on debug

### Minimal reproduction project (MRP)

N/A
Repository: stable-diffusion-webui
Issue: [Bug]: SD WebUI memleak when switching models
Labels: bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [X] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

SD WebUI regularly gets OoM-killed on system RAM when using different models, even when they are supposedly already loaded in VRAM. It appears multiple copies of the models end up being copied to system RAM.

### Steps to reproduce the problem

1. Run SDUI
2. Go to settings and enable 2 or more models to be kept in VRAM simultaneously
3. Load a model, and use it.
4. Load a second model and use it.
5. Re-load the first model and use it.
6. repeat... Over those load, even then RAM consumption on image generation remains under control, whenever you switch models, several GB of additional RAM are consumed and never released

### What should have happened?

Ideally, I believe

* If VRAM is large enough, WebUI should have one copy of the model on the GPU VRAM and at most 1 copy in RAM.
* Between RAM and VRAM, 1 copy of a model should be loaded at a time. If the threshold of copies to be kept in memory is exceeded, occupied RAM should be released.

TLDR: SDUI should avoid keeping the same model in VRAM and RAM simultaneously. SDUI should respect the maximum amount of model data to be kept in VRAM & RAM combined. 

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

Mozilla Firefox

### Sysinfo

 * [sysinfo.txt](https://github.com/AUTOMATIC1111/stable-diffusion-webui/files/13692614/sysinfo.txt)


### Console logs

```Shell
* [console_log_sdui_bug.log](https://github.com/AUTOMATIC1111/stable-diffusion-webui/files/13692630/console_log_sdui_bug.log)
```


### Additional information

Running in a container with ROCm 5.7:

> version: v1.7.0-2-g007d64b6  •  python: 3.10.12  •  torch: 2.2.0.dev20231120+rocm5.7
Repository: angular
Issue: New `@async` block
Labels: feature,area: core,feature: under consideration

### Which @angular/* package(s) are relevant/related to the feature request?

core

### Description

Because nobody responded to the second comment on my last feature request Im opening a new one to get an opinion about it.

I also read the [blog post](https://blog.angular.io/use-angulars-new-deferrable-views-now-20ca9f64f1e5) about deferrable views, especially the last part "[Looking to the future](https://blog.angular.io/use-angulars-new-deferrable-views-now-20ca9f64f1e5#9bef)", which mentions that the community is interested in combining defer with data fetching.
Im definitely interested in this, so heres my idea:

A new `@async` block that essentially works like the async pipe, but with additional support for the `@loading` and `@error` blocks.

And to be clear, this wouldnt lazy load used components, but would simply load them normally. For that purpose Ive been thinking about a new trigger for the `@defer` block: `on fetch`, but thats probably a topic for another feature request.

### Proposed solution

```js
@async (entries; as results) {
  @for (entry of results; track entry.id) {
    <p>{{ entry.title }}</p>
  } @empty {
    <p>No entries</p>
  }
} @loading (minimum 200ms) {
  <p>Loading</p>
} @error {
  <p>Something went wrong</p>
}
```

### Alternatives considered

https://github.com/angular/angular/issues/53185
Repository: PowerToys
Issue: Have Windows Server stop throwing dll errors after 0.76
Labels: Help Wanted

### Description of the new feature / enhancement

So I have a unique request in that, I use PowerToys in my Home Lab on Windows Server, specifically Server Core, it is only a lab environment, and I'm not going to run it in production. In the newest version 0.76, the app will generate an error message on start-up stating that it cannot load the DLLs related to Mouse Highlighter, Mouse With Borders and Mouse Crosshairs, initially, I thought this wouldn't be a problem as I don't use those tweaks so I can disable them in the Settings. I only use Always on Top, Fancy Zones and Keyboard Manager, all three work great, all other tweaks are disabled, so I thought the DLLs would not get loaded.

The Settings app will not load but again, that isn't a problem for me as I usually set up PowerToys the way I like it on Desktop Experience and then copy the Local AppData folder to a shared location and then into the Default user profile for both Desktop Experience and Server Core.

What I would like to implement would be an option to ignore the OOBE (What displays the new changes when the app is updated) and DLL load error messages, so that the app will just start up automatically. Currently, the error messages need to be dismissed before PowerToys will load completely and if the app updates, it will try and open the OOBE which results in a crash, it only does this two or three times but then just skips it. I would simply like a toggle to disable the DLL load messages and OOBE, if a DLL load error occurs, it is logged to the Event Log via Windows Error Reporting which is just fine.

I realise it is an unorthodox request but I am a stickler for window placement so Fancy Zones is an awesome tool.

### Scenario when this would be used?

The ability to suppress the DLL load error messages could potentially be handy for not just people like me who use PowerToys in an unconventional setting. If a user has an issue with a PowerToys tweak where they know the DLL is going to fail, having the ability to ignore the error message and log it to another location, could be useful.

### Supporting information

I have provided a screenshot of the error message that appears along with another that shows PowerToys running on Server Core (Specifically Windows Server 2022 with the App Compatibility module installed).

![image](https://github.com/microsoft/PowerToys/assets/47334951/2360c3ca-5b3f-4fdc-88d7-9b35f9dd0881)
![image](https://github.com/microsoft/PowerToys/assets/47334951/53d7a424-1aa4-4662-9d26-71531cff698c)
Repository: TypeScript
Issue: Bad call hierarchy
Labels: Bug,Help Wanted

### 🔎 Search Terms

"show call hierarchy","call graph"

### 🕗 Version & Regression Information

VS Code Version: 1.85.0
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.6.5-3-MANJARO

### ⏯ Playground Link

https://www.typescriptlang.org/play?filetype=js#code/LYewJgrgNgpgdDAHgBxAJwC4GcAEBeHAMwgDsBjDASxBJwAoSBKHAbwCgdOcyasRY4UEAHMGOANQ4A5NIk4AUgGUA8gDk4WDGkolhlQgE86LDAC4cAIjQwAjhBiaAwjQxIMFgL6NGHLlgCGwMiwdD5cOCAARgBWcIShbB5sbMTkVDQ4AUEhzOzh1hgQaLRSWFhgUonJPCSaETH4rL6chOah+AB8rAVFtFnBMKFJHjhAA

### 💻 Code

```js
module.exports = function (n) {
    console.log(n + ' ' + JSON.stringify({t: "requestContext"}))
    sample()
    obj.f()
}

function sample() {
    return 'ssd'
}

const obj = {
    f: () => {return sample()}
} 
```


### 🙁 Actual behavior

- Some functions omitted
- Some functions repeated
- No deeper level
- 
![js_20231216_165449](https://github.com/microsoft/TypeScript/assets/19843654/0762e88d-c0aa-4de3-9fc4-efa6fd0b7c68)


### 🙂 Expected behavior

Complete list of all functions called inside selected function.

### Additional information about the issue

_No response_
Repository: ollama
Issue: CausalLM 14B support
Labels: model request

CausalLM 14B is a SOTA 14B chat model (take benchmarks with a grain of sault, fully compatible with LLaMA 2.

- GGML HF: https://huggingface.co/TheBloke/CausalLM-14B-GGUF
- HF: https://huggingface.co/CausalLM/14B

While it's probably the wrong place to post it, since ollama.ai/library doesn't have its own issue tracker, I had to contaminate the Github issue of the inference server with this request.
Repository: flutter
Issue: `StatefulShellRoute.indexedStack` should have a `routes` field for allowing navigations that go on top of the `StatefulShellRoute`
Labels: c: new feature,package,c: proposal,P3,p: go_router,team-go_router,triaged-go_router

### Use case

I have a `StatefulShellRoute.indexedStack` with a bottom navigator. When I click each of the bottom nav tabs, the main screen (above the bottom nav) changes with the correct routes, but the app we are developing has a requirement that some buttons in the home screen will lead to new screens that should navigate to be "on top" of the main screen (the screen that has the bottom nav).

Currently we can't do this using go_router, since we can't define child routes for the `StatefulShellRoute.indexedStack`, only branches, that will replace what's in the middle of the screen.

### Proposal

Add a `routes` filed to the `StatefulShellRoute.indexedStack` constructor, so we can defile child routes that will replace the whole screen when navigated to.
Repository: PowerToys
Issue: Filter out "run command" results in 'Program' search
Labels: Idea-Enhancement,Product-PowerToys Run,Needs-Triage

### Description of the new feature / enhancement

![image](https://github.com/microsoft/PowerToys/assets/39174017/ce91a536-52a6-43af-93f6-9980ec1d86c5)

I would like to be able to disable "Run command" results when searching for programs. For me, these are never wanted, always get priority over actual applications, and sometimes even lead to issues when I accidentally hit enter on them.

### Scenario when this would be used?

Whenever I search for something with Run, I never want "Run command" results.

### Supporting information

_No response_
Repository: electron
Issue: [Bug]: Unsanboxed preload running after page with content is loaded (ESM)
Labels: bug :beetle:,has-repro-comment

### 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.0.0

### What operating system are you using?

Windows

### Operating System Version

Windows 10 Family

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

Electron 28 added [support for ESM](https://github.com/electron/electron/pull/37535), the new [doc](https://www.electronjs.org/fr/docs/latest/tutorial/esm#unsandboxed-esm-preload-scripts-will-run-after-page-load-on-pages-with-no-content) states that:

> ### Unsandboxed ESM preload scripts will run after page load on pages with no content
>
> If the response body for a renderer's loaded page is completely empty (i.e. `Content-Length: 0`), its preload script will not block the page load, which may result in race conditions.
>
> If this impacts you, change your response body to have something in it (e.g. an empty `html` tag (`<html></html>`)) or swap back to using a CommonJS preload script (`.js` or `.cjs`), which will block the page load.

So for an HTML with content, I expect the preload to be run **before** the page loads:

![image](https://github.com/electron/electron/assets/32762018/cc628ab1-71fd-4db0-84f2-ff47ef34cc28)

### Actual Behavior

For the following HTML:

```html
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta http-equiv="Content-Security-Policy" content="script-src 'self';">
  </head>
	
  <body>
    <main>
      <p>
        There is nothing interesting to see here...
      </p>
    </main>
  </body>
</html>
```
Loaded as:

```js
new BrowserWindow({
  webPreferences: {
    nodeIntegration: false,
    contextIsolation: true,
    sandbox: false,
    preload: /*preload path */,
  }
});
```

With in `package.json`:

```json
"type": "module"
```
The JS file linked to my HTML shows the page is loaded before the preload.

![image](https://github.com/electron/electron/assets/32762018/ed0761bf-4cf1-4b74-9d72-05be5dfd9bca)

For context, `listen` is a function exposed on the preload with `contextBridge`.

### Testcase Gist URL

_No response_

### Additional Information

I can't see the `Content-Length` header in the response headers:

![image](https://github.com/electron/electron/assets/32762018/668d615e-8de3-4cd2-b50e-674e25af35b3)

The file is loaded from `http://localhost:3000/worker.html`
Repository: go
Issue: x/crypto/ssh: add fipsonly mode
Labels: Proposal,Proposal-Accepted

### Proposal Details

Similar to `crypto/tls/fipsonly` add `golang.org/x/crypto/ssh/fipsonly`

```
//go:build boringcrypto

// Package fipsonly restricts all SSH configuration to FIPS-approved settings.
//
// The effect is triggered by importing the package anywhere in a program, as in:
//
//	import _ "golang.org/x/crypto/ssh/fipsonly"
//
// This package only exists when using Go compiled with GOEXPERIMENT=boringcrypto.
```
Repository: fastapi
Issue: Old `HTTPValidationError` and `ValidationError` OpenAPI entry
Labels: bug

### Privileged issue

- [X] I'm @tiangolo or he asked me directly to create an issue here.

### Issue Content

Those lines need to be updated:

https://github.com/tiangolo/fastapi/blob/36c26677682c4245183912e00fc057c05cc6cf7a/fastapi/openapi/utils.py#L36-L61

They reflect how it was before 0.100.0, but with Pydantic V2, that's no longer true.
Repository: tauri
Issue: [feat] Change `tauri.conf.json` based on build profile (dev/release)
Labels: type: feature request

### Describe the problem

I'd like to change the bundle identifier based on a build-time configuration (for instance, `debug_assertions` or an environment variable) to enable plugins like `tauri-plugin-single-instance` and app configuration stored in `%LocalAppData%` to distinguish between release and debug builds.

### Describe the solution you'd like

A general solution would be loading a modified `tauri.conf.json` based on the build type, similar to how Tauri currently loads `tauri.<platform>.conf.json` depending on the platform.

For instance, there could be a `tauri.conf.dev.json` that's loaded for dev builds that overwrites the bundle identifier. This is also a pretty common pattern for `webpack.config.js` so it's not an entirely new pattern, at least for web developers.

### Alternatives considered

To resolve the app configuration issue, I'm currently using a function like this:
```rs
fn path(&app: AppHandle) -> PathBuf {
  let resolver = app.path_resolver();
  resolver
      .app_local_data_dir()
      .expect("unable to resolve app local data directory")
      .join(if cfg!(debug_assertions) { "dev" } else { "release" })
      .join("settings.yml")
}
```

but I don't have a good solution for other places the bundle identifier would be used.

### Additional context

_No response_