sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: Buffer preserves window-local options if first shown in minimal floating window
Labels: bug,options

### Problem

If the first showing of a buffer is done inside floating window with `style = 'minimal'`, then later showing this same buffer in normal window will use those "minimal" window-local options (like no number column, for example).

### Steps to reproduce

1. Create config file:
```lua
-- Initialize buffers
local buf_id_1 = vim.api.nvim_create_buf(true, false)
local buf_id_2 = vim.api.nvim_create_buf(true, false)
vim.api.nvim_buf_set_lines(buf_id_1, 0, -1, false, { 'This is buffer 1' })
vim.api.nvim_buf_set_lines(buf_id_2, 0, -1, false, { 'This is buffer 2' })

-- Show first buffer in normal window with number column
vim.wo.number = true
vim.api.nvim_win_set_buf(0, buf_id_1)

-- Show second buffer in floating window without number column
local float_opts = { relative = 'editor', row = 1, col = 1, width = 10, height = 10, style = 'minimal' }
local float_win_id = vim.api.nvim_open_win(buf_id_2, false, float_opts)
vim.api.nvim_win_close(float_win_id, true)
```
2. Execute `nvim -u <path-to-config-file>`. This should show first buffer with number column.
3. Type `:bnext`. This will show second buffer and will remove number column. Going back and forth between first and second buffers will consistently apply their first window-local options.

**Note**: This doesn't depend on whether the buffer is the one with which floating window is initialized. The following third paragraph with creating floating window still produces the same behavior:
```lua
local float_opts = { relative = 'editor', row = 1, col = 1, width = 10, height = 10, style = 'minimal' }
local float_win_id = vim.api.nvim_open_win(buf_id_1, false, float_opts)
vim.api.nvim_win_set_buf(float_win_id, buf_id_2)
vim.api.nvim_win_close(float_win_id, true)
```

### Expected behavior

Executing `:bnext` show the second buffer without affecting current window-local options.

The following modifications of config file work as expected:
- Completely removing paragraph with showing floating window.
- First showing second buffer in normal window. So modifying second paragraph like this:
```lua
vim.wo.number = true
vim.api.nvim_win_set_buf(0, buf_id_2)
vim.api.nvim_win_set_buf(0, buf_id_1)
```

### Neovim version (nvim -v)

NVIM v0.10.0-dev-1011+g7bf0963d4

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

No, doesn't have Neovim's floating windows

### Operating system/version

EndeavourOS Linux x86_64 (6.4.12-arch1-1)

### Terminal name/version

st-0.9

### $TERM environment variable

st-256color

### Installation

appimage
Repository: flutter
Issue: Add an `example/` to the `package` template
Labels: tool,P2,c: tech-debt,team-tool,triaged-tool

We don't make `example/` for the `package` template.

One thing to clean up in `create.dart` is to disconnect the `generateApp` platforms from `_generatePackage`. Currently, they are the same leading to the os-directories not being created in the `example/` folder, and thus the example not being able to run.

(We ran into this in https://github.com/flutter/flutter/pull/130494, after that PR is merged also `_generatePackageFfi` would benefit from not having the same platforms as the example folder.)
Repository: vscode
Issue: Add option to turn off rich content notebook search results
Labels: feature-request,search

This would be helpful for those who want to find and replace metadata. 

NOTE: This feature requires notebook search to be enabled by default.
Repository: stable-diffusion-webui
Issue: [Feature Request]: Workaround for when Interrupt or Skip buttons not working on batch/scripts and other generation processes
Labels: enhancement

In  ->Settings->User Interface->Quick Settings List
add option to add the ->Settings->Actions->Unload SD Checkpoint to free VRAM 
or 
on the main page put a red x next to the checkpoint refresh button which when clicked Unloads SD Checkpoint which will force an error and stop an unresponsive batch or script when interrupt button doesn't do the job.
Repository: stable-diffusion-webui
Issue: [Feature Request]: display busy / idle rate
Labels: enhancement

### Is there an existing issue for this?

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

### What would your feature do ?

Would be nice if webui displayed current busy / idle rate for e.g. last 1-5 minutes, current status - if it's rendering something, loading model e.t.c, and how many images are still going to be rendered till the end of batch. When there are more than one users working or if you've refreshed the page and previous task is still running in background it' would be nice to see what's going on on the server - especially if you don't have access to the terminal.

### Proposed workflow

1. Go to .... 
2. Press ....
3. ...


### Additional information

_No response_
Repository: go
Issue: proposal: embed: add `String` and `Bytes` aliases
Labels: Proposal

### Reasoning

Embedding is really nice, but I've had multiple occasions where I've removed embeds of type `string` or `[]byte` from a file and accidentally left in the `_ "embed"` import. `goimports` can't remove it because it can't know about the usage of a `_` import, and `go build` doesn't complain about it because, again, it's a `_` import and so it's technically used, kind of. This problem doesn't apply to `embed.FS` usage because the import is actually fully used, then.

### Proposal

Add the following declarations to the `embed` package:

```go
package embed
type String = string
type Bytes = []byte
```

Use of these types would _not_ be required, but using them would allow the import to be a regular import when not using `embed.FS`:

```go
package example

import (
  "embed"
)

//go:embed file.txt
var file embed.String
```

Making them aliases would also allow them to be used elsewhere without needing conversions, just like existing `string` and `[]byte` embeds.

### Alternative

I don't know if it's possible because it's comment related, but maybe a check could be added to `go vet` that would warn about accidentally left in `_ "embed"` imports without any actual `//go:embed` comments in the file. I think this is less ideal because it would still not be caught by `go build` like a normally accidentally left in import, but I'd be fine with it if other's disagree.
Repository: deno
Issue: Update deno cache without argument to work like fmt and lint
Labels: important for fresh

While using on a Deno Fresh project, using `deno cache dev.ts` entry point doesn't cache `.ts` and `.tsx` files that are dynamically referenced.  I would propose that `deno cache` with no file argument caches all files discovered like `deno fmt` and `deno lint`.  Here's the commands I currently type:

Format all: `deno fmt`
Lint all: `deno lint`
Cache all: `deno task cache` which runs `find -regex '.*\\.[tj]sx?'| xargs deno cache`.  I would rather type `deno cache`.

I've looked at the Rust code base but was unable to figure out how to implement given the SubCommand layers and other abstractions.  If someone could point me in a direction in the codebase, I would be happy to try again.
Repository: flutter
Issue: [packages tool] Validate update-dependency Gradle version with AGP version
Labels: package,P2,team-android,triaged-android

https://github.com/flutter/packages/pull/4757 adds the `android-dependency` option to the `flutter/packages` tool command `update-dependency` with an option to update the Gradle version used in plugin example apps. This command & options should eventually validate the chosen Gradle version to update the plugin example apps with agains the AGP version used in those same plugin example apps, to avoid introducing Gradle <-> AGP conflicts as each AGP version only supports certain AGP versions. See https://developer.android.com/build/releases/gradle-plugin for more information on Gradle/AGP compatibility.
Repository: material-ui
Issue: [material-next] Support modal and non-modal option for components
Labels: on hold,component: dialog,component: drawer,component: menu,component: select,component: snackbar,component: SwipeableDrawer,component: autocomplete

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

This is part of the https://github.com/mui/material-ui/issues/38630 effort.

All components that involve a floating element should provide a prop to control whether that element should behave like a modal or not:

- Autocomplete
- Dialog
- Drawer
- Menu
- Select
- Snackbar
- Swipeable Drawer

### Motivation 🔦

The usage of modal or non-modal floating elements should be made in userland, as it varies from use case to use case.

This same issue was raised in https://github.com/mui/material-ui/issues/17353#issuecomment-727710338.
Repository: godot
Issue: Cracking noise when closing the game by stopping the project from the editor
Labels: bug,platform:macos,topic:audio

### Godot version

3.5.2

### System information

macOS Ventura 13.5.1, Macbook Pro M1

### Issue description

I was in the process of developing a jam game, and it had no sounds at all. I ran the game from the editor. Sometimes when I closed the game (by hitting stop in the editor), I heard a short cracking noise, similar to if an audio file had a final sample far from zero. But the problem is there were no audio files in the game at that moment.

### Steps to reproduce

This issue happens only from time to time, I guess some garbage values get into the audiobuffer.

### Minimal reproduction project

Sorry if it's too difficult to diagnose...
Repository: pytorch
Issue: _foreach_copy_ with scalar second arg
Labels: feature,module: optimizer,triaged,actionable,module: mta

### 🚀 The feature, motivation and pitch

There are a lot of uses (specifically in the optimizer) for launching a single kernel to fill multiple tensors with a scalar. Other foreach ops can handle scalar args and broadcasting as well. 

### Alternatives

_No response_

### Additional context

_No response_

cc @vincentqb @jbschlosser @albanD @janeyx99 @crcrpar @mcarilli
Repository: axios
Issue: Passing ResponseType of 'json' to get() no longer parses the JSON in v0.21.4
Labels: priority::low

### Describe the bug

If you pass a response type of 'json' with a get request, it should automagically return the response.data as a parsed JSON object. Currently it comes back as a JSON string like if you set the ResponseType to 'text'.

![image](https://github.com/axios/axios/assets/111521858/e3cc4469-d449-40c0-a39b-9b6b3efab1b4)

### To Reproduce

Call an API endpoint that returns JSON, and set the responseType on the get request to 'json'.

### Code snippet

```js
const instance = axios.create({
  baseURL: '/api',
  transformResponse: responseTransformer,
  responseType: 'json',
});

const response = await instance.get("my/endpoint", { responseType: 'json' });

typeof response === 'string' // true
```


### Expected behavior

In version 0.21.1, the requests were being parsed correctly, and I was getting a JS object back.




### Axios Version

0.21.4

### Adapter Version

_No response_

### Browser

Chrome

### Browser Version

116.0.5845.140

### Node.js Version

14.19.3

### OS

Fedora 37

### Additional Library Versions

_No response_
Repository: go
Issue: proposal: Go for Windows should generate PDBs
Labels: OS-Windows,Proposal

Chromum uses Go for various build tools, including the up-and-coming siso build tool. Windows has a rich set of tools (better than on Linux in many ways) for debugging and profiling. All Windows executables should generate PDB files (Windows debug-information files) to let them use these tools. Go does not generate PDBs
 and therefore these powerful and standard tools cannot be used with Go executables. This disconnect between Windows expectations and what Go provides makes adoption of Go on Windows more difficult, and means that some performance problems will be unnecessarily difficult to investigate.

Details: Virtually every EXE and DLL on Windows ships with a link to a PDB that contains, at the very least, the names of functions in the binary. Here is an example for notepad:

>dumpbin C:\Windows\System32\notepad.exe /headers | find /i "rsds"
    BDD4ADCD cv            24 0002B4E4    2A0E4    Format: RSDS, {67D551E7-B9BB-3B68-E823-F5B998BD9453}, 1, notepad.pdb

The PDB isn't actually shipped, but it can be obtained (in an automated way) from symbol servers that are published by Microsoft, Chrome, Firefox, and other companies (https://randomascii.wordpress.com/2013/03/09/symbols-the-microsoft-way/).

Go binaries, on the other hand, lack this information:

>dumpbin third_party\siso\siso.exe /headers | find /i "rsds"

This means that windbg, VS, ETW, and many other amazing tools can do very little with Go programs.

ETW profiling in particular (https://randomascii.wordpress.com/2015/09/24/etw-central/) is tremendously powerful. It allows viewing of CPU usage (both sampled and based on context switches), disk I/O, memory allocations, and many other performance-relevant attributes, all on a unified timeline with configurable ways of drilling into the available information.
 ETW sampling can seamlessly straddle the user-mode/kernel-mode boundary, making kernel calls appear just like function calls in the tables. ETW's context-switch graphs allow diagnosing of where a thread is waiting and what it is waiting on.

While integrated profiling with -cpuprofile (supported by siso) is nice, it is not a substitute for ETW profiling.

Concretely, I am currently trying to understand some suboptimal performance in siso (Googler-only link - b/298409062) but siso's -cpuprofile option doesn't make this easy to do. Simultaneously I am looking at ETW profiles (from a user) that show that most of the time in Chrome's setup process is being spent in KiPageFault - this is information that no user-mode profiler could reveal.

The Go team should consider giving their build tools an option (on by default!) to generate basic PDBs that can be consumed by standard Windows tools. The lld-link linker already generates rich PDBs (with stack frame, type, and inlining information) and generating just function name information would be simple in comparison, and could reuse the expertise and code of the lld-link project.

TL;DR - Support of PDBs is expected on Windows and it would be great if Go could satisfy that expectation.
Repository: tensorflow
Issue: FAILED: //tensorflow/tools/proto_splitter/cc:saved_model_splitter_test on mac arm64 wheels
Labels: stat:awaiting tensorflower,type:bug,subtype:macOS,TF 2.13

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

2.14rc0

### Custom code

No

### OS platform and distribution

macOS

### Mobile device

_No response_

### Python version

3.9

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Test is failing.
This checkin the regression started:

```
commit e1e4de39de51064a359320f9b32936bf1599d4a0Author: Laura Pak <lpak@google.com>Date:   Tue Apr 26 16:51:30 2022 -0700    Update highwayhash from fd3d9af80465e4383162e4a7c5e2f406e82dd968 to c13d28517a4db259d738ea4886b1f00352a3cc33.    PiperOrigin-RevId: 444703993
```


Reverting that fixes the issue.

### Standalone code to reproduce the issue

```shell

bazel --bazelrc='./tensorflow/tools/ci_build/osx/arm64/.macos.bazelrc'  test //tensorflow/tools/proto_splitter/cc:saved_model_splitter_test
```


### Relevant log output

```shell
The test is failing with:

INFO: From Testing //tensorflow/tools/proto_splitter/cc:saved_model_splitter_test:==================== Test output for //tensorflow/tools/proto_splitter/cc:saved_model_splitter_test:dyld[1906]: symbol not found in flat namespace 

'__ZNK11highwayhash11HighwayHashILj16EEclERA4_KyPKcmPy'==================================================================================================== 

Test output for //tensorflow/tools/proto_splitter/cc:saved_model_splitter_test:dyld[1942]: symbol not found in flat namespace '__ZNK11highwayhash11HighwayHashILj16EEclERA4_KyPKcmPy'==================================================================================================== Test output for //tensorflow/tools/proto_splitter/cc:saved_model_splitter_test:dyld[1976]: symbol not found in flat namespace '__ZNK11highwayhash11HighwayHashILj16EEclERA4_KyPKcmPy'================================================================================
```
```


cc @learning-to-play , @nitins17 and @mihaimaruseac
Repository: node
Issue: import.meta.main
Labels: feature request,esm,never-stale

Deno just added this.

Should we?

https://github.com/denoland/deno/pull/1835
Repository: node
Issue: Dynamic import does not show location of SyntaxError
Labels: promises,errors,esm

```js
// syntax-error.mjs
console.log([
  'str1'
  'str2'
]);
```

Perform a dynamic import with `node -e "import('./syntax-error.mjs').catch(console.error)"`, the output does not help identify the error and could be seen by users as if node.js itself had a SyntaxError:
```
SyntaxError: Unexpected string
    at Loader.moduleStrategy (internal/modules/esm/translators.js:83:18)
    at async link (internal/modules/esm/module_job.js:37:21)
```

Now create and run a loader.mjs script:
```js
import './syntax.mjs';
```

Running loader.mjs produces useful output:
```
file:///usr/src/npm/failures/syntax-error.mjs:3
	'str2'
	^^^^^^

SyntaxError: Unexpected string
    at Loader.moduleStrategy (internal/modules/esm/translators.js:83:18)
```

I was not able to find a way to catch the error of a dynamic import and show the complete SyntaxError.  Interestingly `node --unhandled-rejections=strict -e "import('./syntax-error.mjs')"` or running `await import('./syntax-error.mjs')` from `node --experimental-repl-await`  both display the location of the SyntaxError.
Repository: node
Issue: Invalidate cache when using import
Labels: feature request,esm

How do I invalidate the cache of `import`?

I have a function that installs missing modules when an import fails, but the `import` statement seems to preserve the failure while the script is still running.

```js
import('some-module').catch(
  // this catch will only be reached the first time the script is run because resolveMissingModule will successfully install the module
  () => resolveMissingModule('some-module').then(
    // again, this will only be reached once, but it will fail, because the import seems to have cached the previous failure
    () => import('some-module')
  )
)
```

The only information I found in regards to import caching was this documentation, which does not tell me where the “separate cache” used by `import` can be found.

> ### No require.cache
> `require.cache` is not used by `import`. It has a separate cache.
> — https://nodejs.org/api/esm.html#esm_no_require_cache
Repository: node
Issue: add API for "package dir"
Labels: feature request,esm

See https://github.com/nodejs/node/issues/33460.

tl;dr: it turns out that there's a number of tools that need to be able to locate a package's root directory, and with "exports", they can no longer rely on `package/package.json` working, nor `package/`.

If we could provide this API, then CJS could `path.join` it, and ESM could use `URL`, to get whatever file the tool needs to `fs.readFile`.

Adding this new API would bypass questions about "should `package.json` be an implicit part of a package's API", as well as avoid reliance on ESM-only or CJS-only mechanisms. By providing the package root dir rather than its `package.json`, we would not be encouraging or discouraging any patterns of "where to store metadata" - instead, we'd be correctly leaving that choice up to userland.

Example solution: `module.packageDir(specifier)` and `module.packageDirSync(specifier)` (sync access is critical for many use cases).
Repository: node
Issue: Empty path matching in patterns
Labels: module

@ljharb brought up in the exports patterns PR that it would be worthwhile to ensure the `*` matching in exports patterns permits empty matches to ensure consistency with all other wildcard schemes.

I agree this conceptual integrity could make sense, and in addition such a feature could be added as a fully backwards compatible change to exports patterns so I would be glad to see this land either way.

One benefit I really liked of _not_ matching the null match is that currently:

```js
{
  "exports": {
    "./": "./sub/"
  }
}
```

will cause `import.meta.resolve('pkg/')` to resolve into the `sub/` folder. As a result this means `import.meta.resolve('pkg/')` is not a reliable way to get a package root (and also relates to the package.json resolution discussion previously).

If we now use patterns here:

```js
{
  "exports": {
    "./*": "./sub/*"
  }
}
```

then as currently written, `import.meta.resolve('pkg/')` will throw a `PACKAGE_PATH_NOT_EXPORTED` error because the empty string match is not permitted and thus this "reserves" this space for us to treat it as a special package base resolution case which seems a really useful property for a resolver to have to me in being able to resolve the base of any package this way.

On the other hand I do not have any conceptual arguments against matching the empty string pattern other than that I simply can't think of a single use case in which it is useful. If the argument is purely one of conceptual consistency being important I'm all for that though, but would be concerned about invalidating a perfectly good use case in the name of that.
Repository: node
Issue: Portable resolver test suite
Labels: module,esm

This was brought up in https://github.com/nodejs/modules/issues/451#issuecomment-575282242 for resolver stability, that having tests available for tools and userland resolvers would be a great help in ensuring that they are compliant with the Node.js ES module resolver.

If we could move the resolution tests into something resembling an independent test suite that could easily be run against any async resolver function that could assist the ecosystem in this transition process.

So -

1. Do we agree this would be a useful thing to provide? There were no objections when this was discussed previously in the meeting I believe.
2. If so, how would we offer such a portable test suite in a useful way? Suggestions re useful patterns here would be welcome.
Repository: node
Issue: Remove restriction on '/' prefixes
Labels: module

Given that we have self referential packages, and `"imports"` in `package.json`. In addition since `//` is reserved I think we should remove the reservation since it will by the default URL parser be treated as protocol relative.
Repository: PowerToys
Issue: PowerToys/Custom keycombination-info
Labels: Needs-Triage

### Description of the new feature / enhancement

An info window like for the Windows key-combinations, but customizable and also with the powerToys combinations 

### Scenario when this would be used?

Everytime when you forgot about the Key-combination of a fature

### Supporting information

_No response_