sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: java-design-patterns
Issue: Translate to Hindi
Labels: info: help wanted,type: feature,epic: documentation

This task tracks the translation of the patterns. More information about the translation process is available at https://github.com/iluwatar/java-design-patterns/wiki/15.-Support-for-multiple-languages

Acceptance criteria

- The patterns have been translated
- The patterns can be browsed in Github and on the website https://java-design-patterns.com
Repository: java-design-patterns
Issue: Translate to Indonesian
Labels: info: help wanted,type: feature,epic: documentation

This task tracks the translation of the patterns. More information about the translation process is available at https://github.com/iluwatar/java-design-patterns/wiki/15.-Support-for-multiple-languages

Acceptance criteria

- The patterns have been translated
- The patterns can be browsed in Github and on the website https://java-design-patterns.com
Repository: java-design-patterns
Issue: Translate to Japanese
Labels: info: help wanted,type: feature,epic: documentation

This task tracks the translation of the patterns. More information about the translation process is available at https://github.com/iluwatar/java-design-patterns/wiki/15.-Support-for-multiple-languages

Acceptance criteria

- The patterns have been translated
- The patterns can be browsed in Github and on the website https://java-design-patterns.com
Repository: java-design-patterns
Issue: Translate to Korean
Labels: info: help wanted,type: feature,epic: documentation

This task tracks the translation of the patterns. More information about the translation process is available at https://github.com/iluwatar/java-design-patterns/wiki/15.-Support-for-multiple-languages

Acceptance criteria

- The patterns have been translated
- The patterns can be browsed in Github and on the website https://java-design-patterns.com
Repository: java-design-patterns
Issue: Translation to Marathi
Labels: info: help wanted,type: feature,epic: documentation

This task tracks the translation of the patterns. More information about the translation process is available at https://github.com/iluwatar/java-design-patterns/wiki/15.-Support-for-multiple-languages

Acceptance criteria

- The patterns have been translated
- The patterns can be browsed in Github and on the website https://java-design-patterns.com
Repository: java-design-patterns
Issue: Translation to Portuguese
Labels: info: help wanted,type: feature,epic: documentation

This task tracks the translation of the patterns. More information about the translation process is available at https://github.com/iluwatar/java-design-patterns/wiki/15.-Support-for-multiple-languages

Acceptance criteria

- The patterns have been translated
- The patterns can be browsed in Github and on the website https://java-design-patterns.com
Repository: java-design-patterns
Issue: Translation to Turkish
Labels: info: help wanted,type: feature,epic: documentation

This task tracks the translation of the patterns. More information about the translation process is available at https://github.com/iluwatar/java-design-patterns/wiki/15.-Support-for-multiple-languages

Acceptance criteria

- The patterns have been translated
- The patterns can be browsed in Github and on the website https://java-design-patterns.com
Repository: java-design-patterns
Issue: Translation to Vietnamese
Labels: info: help wanted,type: feature,epic: documentation

This task tracks the translation of the patterns. More information about the translation process is available at https://github.com/iluwatar/java-design-patterns/wiki/15.-Support-for-multiple-languages

Acceptance criteria

- The patterns have been translated
- The patterns can be browsed in Github and on the website https://java-design-patterns.com
Repository: java-design-patterns
Issue: Translation to Chinese
Labels: info: help wanted,type: feature,epic: documentation

This task tracks the translation of the patterns. More information about the translation process is available at https://github.com/iluwatar/java-design-patterns/wiki/15.-Support-for-multiple-languages

Acceptance criteria

- The patterns have been translated
- The patterns can be browsed in Github and on the website https://java-design-patterns.com
Repository: rust
Issue: core::array::from_fn segfaults (v1.64, v1.63)
Labels: C-bug,A-array

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

Git  git@github.com:mvniekerk/ga-perf.git , branch segfault_array_from_fn

I expected to see this happen: It to initialize an array using a function

Instead, this happened: It segfaulted

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

Also checked on Docker images for 1.63, 1.64 

`rustc --version --verbose`:
```
rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: aarch64-apple-darwin
release: 1.64.0
LLVM version: 14.0.6

```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
    Finished dev [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/rust`
[1]    35557 segmentation fault  cargo run

```

</p>
</details>
Repository: godot
Issue: Godot crashes regularly on Mac since updated to macos Ventura
Labels: bug,platform:macos,topic:editor,needs testing,crash

### Godot version

3.5.1

### System information

Mac os 13 2.3 GHz Dual-Core Intel Core i5 Intel Iris Plus Graphics 640 1536 MB

### Issue description

Godot editor crashes sometimes when pushing the Play Scene button. The scene starts playing, but the editor crashes in the background....

### Steps to reproduce

As described, simply play a scene in macos ventura...

### Minimal reproduction project

_No response_
Repository: stable-diffusion-webui
Issue: [Feature Request]: Load last generation params should include chosen script and assoc. params
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 ?

I love your repo, thanks to you and your devs for your great work.

The load last generation parameter button should load the used script and its parameters. It would be a BIG help. I dont know if this is a lot of work, but it would make my life (and those of many others probably) a lot easier.

Another idea is a settings option that loads last generation parameters on launch. Some checkbox in the Settings.

### Proposed workflow

I love your repo, thanks to you and your devs for your great work.
 
The load last generation parameter button should load the used script and its parameters. It would be a BIG help. I dont know if this is a lot of work, but it would make my life (and those of many others probably) a lot easier.

Another idea is a settings option that loads last generation parameters on launch. Some checkbox in the Settings.  

### Additional information

_No response_
Repository: stable-diffusion-webui
Issue: [Feature Request]: Add "job duration" to Filename tags
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 ?

I would like to add a "[job_duartion]" or "[render_time]" or a more suitable tag to the filename patterns.
This tag would show how much time it took the image to be completed.

This information would be helpful when comparing Sampler performance across multiple batches.

Optionally it would contain the iterations per second info.

### Proposed workflow

1. Go to settings tab
2. Saving images/grids section
3. In the Image filename pattern box, add the tag (e.g. [sampler]-[steps]-[job_duration])
4. the output image contains the time it took to process (e.g. Euler-40-00:05|3.12it/s)


### Additional information

_No response_
Repository: rust
Issue: Broken compilation with `&(dyn Trait + '_)`
Labels: A-resolve,A-lifetimes,P-high,T-compiler,regression-from-stable-to-stable,C-bug

### Code

I tried this code:

```rust
pub trait AsStr {
    fn as_str(&self) -> &str;
}

fn foo(bar: &(dyn AsStr + '_)) -> &'_ str {
    bar.as_str()
}
```

I expected to see this happen: code compiles successfully.

Instead, this happened:
```
error[E0106]: missing lifetime specifier
 --> src/main.rs:5:36
  |
5 | fn foo(bar: &(dyn AsStr + '_)) -> &'_ str {
  |             -----------------      ^^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say which one of `bar`'s 2 lifetimes it is borrowed from
help: consider introducing a named lifetime parameter
  |
5 | fn foo<'a>(bar: &'a (dyn AsStr + 'a)) -> &'a str {
  |       ++++       ++              ~~       ~~

For more information about this error, try `rustc --explain E0106`.
```

### Version it worked on

It most recently worked on Rust 1.63.0.

### Version with regression

It is broken on current stable, i.e. 1.64.0.

Here's the output by `cargo-bisect-rustc`:

> searched nightlies: from nightly-2022-06-24 to nightly-2022-08-05
> regressed nightly: nightly-2022-07-15
> searched commit range: https://github.com/rust-lang/rust/compare/87588a2afd9ca903366f0deaf84d805f34469384...c2f428d2f3340a0e7d995f4726223db91b93704c
> regressed commit: https://github.com/rust-lang/rust/commit/f1a8854f9be2e5cad764d630a53d26c7b72f8162
> 
> <details>
> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.6.4</summary>
> 
> 
> Host triple: x86_64-unknown-linux-gnu
> Reproduce with:
> ```bash
> cargo bisect-rustc --end=1.64.0 -- check 
> ```
> </details>
> 

It seems to have been found previously by `gluon` developers and fixed in their own code [in this commit](https://github.com/gluon-lang/gluon/commit/f30127bf5e27520d41a654154381c2e9601d2f3e), and today popped up also [on URLO](https://users.rust-lang.org/t/possible-to-use-cargo-timings-on-a-project-that-uses-gluon/83458).

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"BGR360"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: vscode
Issue: Feature: identify Inlay Hints text (e.g. info in tooltip)
Labels: under-discussion,inlay-hints

<!-- ⚠️⚠️ 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. -->
Enhancement Proposal: Some way to identify that a given chunk of text is `inlayHints` and not actually present in the document being edited. 

Maybe a small help (?) or info (i) icon in the tooltip which explicitly identify this text snippet as a non-code inlayHint and how to disable it. Perhaps something like:

>This is an inlayHint provided by the [whatever] vscode extension. See Editor > Inlay Hints (`editor.inlayHints.enabled`) in settings for more.

inlayHints are enabled by default and inject text inline into the visual editor --  feels like it'd be helpful to breadcrumbs for how to disable them.  As novice Rust user, I recently mistook the inline text provided by rust-analyzer as actual code.  After going through dozens of rust-analyzer settings I finally figured out these were "inlay hints".

![image](https://user-images.githubusercontent.com/145113/198894184-a049b2b8-d399-4ad7-b452-d233859f960e.png)

[Example video](https://user-images.githubusercontent.com/145113/198289144-90c80e88-acc4-40fe-a4c7-5a430b197a42.mov
) of having no way to differentiate between text which is code and text which is Inlay Hints.
Repository: pytorch
Issue: Different behaviour in sparse matmul
Labels: module: sparse,triaged

The same code with and without the utilization of a **sparse** tensor gives an error:

The following is a working example of the code **without** sparse tensor:
``` python
a = torch.randn(2, 3, 3).requires_grad_(True)
print(a)

b = torch.randn(3, 1, requires_grad=True)
print(b)

y = torch.matmul(a, b)
print(y)

y.sum().backward()
print(a.grad)
```

This is the same example code with a sparse tensor utilization:
``` python
a = torch.randn(2, 3, 3).to_sparse().requires_grad_(True)
print(a)

b = torch.randn(3, 1, requires_grad=True)
print(b)

y = torch.matmul(a, b)
print(y)

y.sum().backward()
print(a.grad)
```

The code with the sparse variant gives the following error:

```
NotImplementedError                       Traceback (most recent call last)
 Cella 22 in <cell line: 7>()
      [4] b = torch.randn(3, 1, requires_grad=True)
      [5] print(b)
----> [7] y = torch.matmul(a, b)
      [8] print(y)
     [10] y.sum().backward()

NotImplementedError: Tensors of type SparseTensorImpl do not have is_contiguous
```

I'm not very confident that I am not wrong, but I think that it is better if matmul for dense and sparse tensor follows the same behaviour.  
If I do not understand something, how can I replicate the same behaviour in the sparse case? 

Thank you! 

### Versions

Collecting environment information...
PyTorch version: 1.11.0+cu113
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Could not collect
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.12 (tags/v3.9.12:b28265d, Mar 23 2022, 23:52:46) [MSC v.1929 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.19041-SP0
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to:
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] Could not collect
[conda] Could not collect

cc @nikitaved @pearu @cpuhrsch @amjames @bhosmer
Repository: rust
Issue: LLVM debug info stack overflow
Labels: I-crash,A-LLVM,T-compiler,C-bug

When creating several thousand shaded variables, LLVM throws an error. Code example:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=cf2ac581d487507c7a3282b424f734f5

The version of rustc is 1.64, stable.
Repository: neovim
Issue: statusline: add items for info hidden with cmdheight=0 (showcmd etc)
Labels: enhancement,statusline

### Feature already in Vim?

_No response_

### Feature description

Cause with `cmdheight=0` option, some informations (printed on cmdline previously) are hidden.

I think it would be great if we could add more statusline items to print those things. (e.g. `showcmd`. I don't know if there are more options)
Repository: rust
Issue: Confusing error with incompatible functions in trait impl when function parameter is `impl Trait`
Labels: A-diagnostics,T-compiler

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e0bc1be874a87460648739de7863a87e))

```rust
trait ExampleTrait {
    fn impl_arg(x: impl IntoIterator<Item = i32>);
}

struct ExampleImpl;

impl ExampleTrait for ExampleImpl {
    fn impl_arg(x: Vec<i32>) {}
}
```

The current output is:

```
error[E0049]: method `impl_arg` has 0 type parameters but its trait declaration has 1 type parameter
 --> src/lib.rs:8:16
  |
2 |     fn impl_arg(x: impl IntoIterator<Item = i32>);
  |                    -----------------------------
  |                    |
  |                    expected 1 type parameter
  |                    `impl Trait` introduces an implicit type parameter
...
8 |     fn impl_arg(x: Vec<i32>) {}
  |                ^ found 0 type parameters
```

Which leaks the fact that `impl` introduces an implicit type parameter, and is quite unfriendly to newcomers.

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error[E0053]: method `impl_arg` has an incompatible type for trait
 --> src/lib.rs:8:20
  |
8 |     fn impl_arg(x: Vec<i32>) {}
  |                    ^^^^^^^^
  |                    |
  |                    expected `impl IntoIterator<Item = f32>`, found struct `Vec`
  |                    help: change the parameter type to match the trait: `impl IntoIterator<Item = f32>`
  |
note: parameter in trait expects any type that implements `IntoIterator<Item = f32>`, but this implementation expects the concrete type `Vec<i32>`
 --> src/lib.rs:2:20
  |
2 |     fn impl_arg(x: impl IntoIterator<Item = i32>);
  |                    -----------------------------
  |                    |
  |                    many different types can implement `IntoIterator<Item = i32>`
```

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions. The output might also be
different depending on the Edition.
-->


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"ffmancera"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: node
Issue: http2 unhandled error read ECONNRESET     at TLSWrap.onStreamRead 
Labels: http2

### Version

Node.js v18.8.0

### Platform

Linux 5.4.0-1089-azure #94~18.04.1-Ubuntu SMP Fri Aug 5 12:34:50 UTC 2022 x86_64 Linux

### Subsystem

http2

### What steps will reproduce the bug?

Initialize an http2 server like so

```js
const http2 = require('http2');
const server = http2.createSecureServer(certFiles);
server.on('error', (err) => console.error(err));
server.on('stream', async (stream, headers) => {
//...
    stream.on('error', (err) => {
      console.error("ERROR: HTTP2 STREAM ERROR", err);
      if(!stream.destroyed) {
        stream.respond({
          ':status': 400
        })
      }
    })
//...
})
```

Create a client connection and terminate it abruptly

This will crash the server with the following error:

```
node:events:491
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)
Emitted 'error' event on TLSSocket instance at:
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -104,
  code: 'ECONNRESET',
  syscall: 'read'
}

Node.js v18.8.0

```


### How often does it reproduce? Is there a required condition?

Whenever a client connection is abruptly closed

### What is the expected behavior?

I expect the error should be caught in one of the error catching blocks:

either:

```js
server.on('error', (err) => console.error(err));
```

or:

```js
    stream.on('error', (err) => {
      console.error("ERROR: HTTP2 STREAM ERROR", err);
      if(!stream.destroyed) {
        stream.respond({
          ':status': 400
        })
      }
    })
```

### What do you see instead?

Node crashes with the error:

```js
node:events:491
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)
Emitted 'error' event on TLSSocket instance at:
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -104,
  code: 'ECONNRESET',
  syscall: 'read'
}
```

### Additional information

_No response_
Repository: deno
Issue: Reenable "run_watch_external_watch_files" when upgrading to XL runner for macOS
Labels: tests,--watch

Ref https://github.com/denoland/deno/pull/16477
Repository: godot
Issue: TextureButton displaying focus texture when in disabled state
Labels: bug,topic:gui

### Godot version

v3.5.stable.official [991bb6ac7]

### System information

Ubuntu 22.04.1 LTS

### Issue description

When using the TextureButton UI control and changing the "BaseButton" property "disabled" to true, the button shows the "Focused" image when clicked on or navigated to using the "tab" key.  It appears that the TextureButton (and maybe all buttons) are still in the keyboard focus traversal tree.  If they are disabled the expected behavior is for them not to be clickable or have focus applied to them, and certainly not change their image.



### Steps to reproduce

1. Create a UI Scene with at least 1 texture button.
2. Specify the texture button with a "Focused" image in addition to a "Disabled" image so that they can be clearly identified
3. Make the texture button "Disabled" from the properties in the inspector
4. Click on the disabled button and see that the image changes (from a disabled state to a focused state)


### Minimal reproduction project

[texture-bug.zip](https://github.com/godotengine/godot/files/9896947/texture-bug.zip)
Repository: next.js
Issue: CSS is not removed from browser when removed in css file with HMR
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.4.0: Mon Feb 21 20:35:58 PST 2022; root:xnu-8020.101.4~2/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.10.0
      npm: 8.19.2
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.0.1-canary.2
      eslint-config-next: 13.0.0
      react: 18.2.0
      react-dom: 18.2.0

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

Chrome 107.0.5304.87

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

_No response_

### Describe the Bug

When adding css in for example the `global.css ` file the styles is applied as expected with HMR. But when removing the css the styles is still present in the browser. This only happens in `next dev` and when styles is injected with HMR. The page needs to be refreshed for the css to be removed.

### Expected Behavior

The css should be removed from the browser then it's removed from the css file.

### Link to reproduction

https://github.com/alexanderalmstrom/next13-tailwind

### To Reproduce

1. Add some css to `app/global.css` for example setting a background or text color on html or body.
2. Remove the css from `global.css`.