sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: net/http: add .MaxConnLifespan or .SetMaxConnLifespan() to Transport
Labels: Proposal

Currently there is no way to signal to a client via the http.Transport struct that a connection should not be used beyond a specific timeout since it was originally created.

Such a feature is useful to some authors as upstreams referenced via dns gain more ip addresses over time and scale-out horizontally. When this occurs it may be in the client's best interest to rebalance connections amongst the available upstream nodes to avoid creating hot nodes in the upstream

It is a naive implementation as really there is no need to reset connections in such a situation until there are indeed more upstreams available to connect to. In addition there's no need to kill all connections in such topologies repeatedly, just the ones we intend to move over to the newly available upstream ips. ( more discussion on the connection pool FIFO behavior being problematic for maintaining the fewest number of connections necessary can be found [here](https://github.com/golang/go/issues/23427#issuecomment-1116977666) )

Despite these drawbacks the benefits are clear for persons who accept the overhead of creating new connections in such a fashion if they wish to avoid hot partitions and do not have load-balancing capabilities offered by traditional expensive cloud provider appliances and mesh framework sidecar proxies. In short this is beneficial for the exact same reasons it's beneficial in https://pkg.go.dev/database/sql 's package via the SetConnMaxLifetime function. An argument can be made this is a tradeoff, but it appears to be one people need. It seems safest to provide something in the net/http.Transport struct rather than encourage people to implement their own transport or adopt an alternative.

This is also beneficial in situations where the maintainers know the upstream server will attempt to close the connections after a max lifetime / idle rate but for some edge cases such as network congestion or an event equivalent to complete packet loss. When the latter occurs and the client has only idle connections it can take quite a few seconds to recover and finally start sending requests again to the new upstream instances ( depending on the idle connection pool max size, keep alive settings, and the client's throughput/burst behaviors )

---

This would successfully address https://github.com/golang/go/issues/23427 's concerns.

An example toy implementation adding MaxConnLifespan as a data member has already been created and a PR is open with passing tests: https://github.com/golang/go/pull/46714/ .

Minor tweaking to the above is required if exposing a way to mutate the MaxConnLifetime value over time is a desirable feature. By adding this functionality to the existing mechanisms for computing idle timeouts we also make sure the clients close the connections without maintaining them actively in the connection pool just to close them whenever the client finally gets around to using the connection again assuming we have a high idle connection timeout.
Repository: godot
Issue: Vulkan: GPUParticles3D unrotate with Transform Align: Y to Velocity when velocity reaches 0
Labels: documentation,topic:particles

### Godot version

Godot 4, alpha14 official [106b68050]

### System information

Windows

### Issue description

Using damping on child particles casues them to unrotate when velocity reaches 0 when using the Transform Align: Y to Velocity setting. It does however work as expect if one instead uses the Particles Flags, Align Y toggle.

Unsure why there are two and one is better than the other. 

### Steps to reproduce

Add A GPU Particle system, preferable with the new turbulence so particles fly around in different direction.
Add a 2ND GPU particle system, make the first one use the 2nd one as a sub emittor.
Add a "flat" box to the 2nD GPU particle and set it to Transform Align: Y to Velocity, also set damping to min/max 5/5 so that the child particles reach 0 velocity. Watch how at 0 velocity the sub emittors particles snap back to unrotated.

Attached project with it already setyp.

### Minimal reproduction project

[particle_align_rotation_bug.zip](https://github.com/godotengine/godot/files/9331028/particle_align_rotation_bug.zip)
Repository: godot
Issue: Setting text with long length on `TextEdit` node is unstable (freezes and low FPS)
Labels: bug,regression,topic:gui,performance

### Godot version

4.0.alpha13

### System information

Arch AMD64

### Issue description

I have `TextEdit` nodes for various debug displays and if I use str() or var2str() on a large dictionary (643 Vector2 keyed and valued entries)  then set the `text` property of the node to that on every _process() call, the game either freezes or drops to 1-5FPS

e.g.
```
extends TextEdit
func _process(_delta):
    text = ''
    text = str(large_dictionary)
```

This wasn't a problem in 3.4.4 stable which I ported this project from.

As a workaround I've done something like the following and theres no performance issues at all:
_"res://util/DebugTextEditBase.gd":_
```
extends TextEdit
var _text:
	set(value):
		if value == text:
			print("text hasnt changed")
			return
		text = value
		_text = value
	get:
		return text
```
_My other debug TextEdit node scripts:_
```
extends "res://util/DebugTextEditBase.gd"
func _process(delta):
	var __text = ''
	__text = 'building'
	__text = 'a'
	__text = 'debug'
	__text = str(dictionary)
	__text = 'string'
       _text = __text
```

It would be nicer if I could override inherited members and not just methods, with new setters and getters.
And even nicer if the `text` member of `TextEdit` was more performant like it was in 3.4.4 - perhaps simply by doing the same check.

Also a note that this was happening on `Label` nodes to, before I changed to `TextEdit` for syntax highlighting, so perhaps a general issue with the new `TextServer`

If you would like any more information please ask, thanks.

### Steps to reproduce

See above

### Minimal reproduction project

_No response_
Repository: rust
Issue: Tracking Issue for Vec::push_within_capacity
Labels: T-libs-api,C-tracking-issue

Feature gate: `#![feature(vec_push_within_capacity)]`

This is a tracking issue for `Vec::push_within_capacity`

It enables pushing into a Vec if there is any capacity left and otherwise returns the value. I.e. it avoids implicit resizing. This can be useful when one wants to explicitly control it (e.g. via `try_reserve`) or uses a Vec in an unsafe manner where moving the elements would be a problem.

### Public API

```rust
// alloc::Vec

impl Vec<T, A> {
    pub fn push_within_capacity(&mut self, value: T) -> Result<(), T>;
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Implementation: #89123
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

- [ ] naming (e.g. `push_in_capacity`)
- [ ] may become redundant due to larger-scale work in https://github.com/rust-lang/rfcs/pull/3271

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: vscode
Issue: Changing focus to another editor causes text to get selected sometimes
Labels: bug,editor-core

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.70.1
- OS Version: 12.5 (21G72)

Steps to Reproduce:

1. Create two editors side by side
2. Click to change the focus from one editor to the other

https://user-images.githubusercontent.com/2737650/184494443-30668344-ae42-4372-b4c3-be0c6edd8cf2.mp4

I'm seeing this on VSCode desktop as well, but I tried to reproduce it on vscode.dev to make sure it wasn't caused by any settings or extensions.
Not sure what the intended behaviour should be in this case but I think it should at least be consistent.

Related/possible duplicate: #147105
Repository: vscode
Issue: Support no-code language server integration
Labels: feature-request,api

<!-- ⚠️⚠️ 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. -->

I created a VSCode extension that integrates a language server. This is pretty much a textbook example extension.

```js
import {workspace} from 'vscode'
import {LanguageClient, TransportKind} from 'vscode-languageclient/node.js'

let client

export async function activate(context) {
  const run = {
    module: context.asAbsolutePath('out/remark-language-server.js'),
    transport: TransportKind.ipc,
  }

  const serverOptions = {
    run,
    debug: {...run, options: {execArgv: ['--inspect=6009']}}
  }

  const clientOptions = {
    documentSelector: [{scheme: 'file', language: 'markdown'}],
    synchronize: {
      fileEvents: [
        workspace.createFileSystemWatcher(
          '**/.remark{ignore,rc,rc.cjs,rc.js,rc.json,rc.mjs,rc.yaml,rc.yml}'
        ),
        workspace.createFileSystemWatcher('**/package.json')
      ]
    }
  }

  client = new LanguageClient('remark', serverOptions, clientOptions)

  await client.start()
}

export async function deactivate() {
  if (client) {
    await client.stop()
  }
}
```

All of this is boilerplate with some configuration options. In addition to handling the language server, the extension developer is responsible for proper teardown and building the extension. Also this small extension adds ~350kB of minified JavaScript to the bundle.

It would be nice if language server integrations could be specified in `package.json`, replacing the extension bundle. This way developers can focus solely on the language server functionality, and extension size can be decreased.

```jsonc
{
  "name": "vscode-remark",
  "displayName": "remark",

  // This line would no longer be needed
  // "main": "out/extension.js",

  "contributes": {
    "languageServer": {
      // Defaults to displayName
      // "name": "remark",
      "serverOptions": {
        "run": {
          "module": "out/remark-language-server.js",
          "transport": "ipc"
        },
        // Inherits properties from run
        "debug": {
          "options": {
            "execArgv": [
              "--inspect=6009"
            ]
          }
        }
      },
      "clientOptions": {
        "documentSelector": [
          {
            "scheme": "file",
            "language": "markdown"
          }
        ],
        "synchronize": {
          "fileEvents": [
            "**/package.json",
            "**/.remark{ignore,rc,rc.cjs,rc.js,rc.json,rc.mjs,rc.yaml,rc.yml}"
          ]
        }
      }
    },
    // …
  },
}
```

Of course there are many more options that are unused here. Some functionality still requires extensions to manually initialize a client. Each accepted option should be considered separately to be supported this way.
Repository: rust
Issue: The safety requirements of CStr::from_ptr have been made more strict than they used to be
Labels: A-docs

<!--

Thank you for finding a documentation problem! 📚

Documentation problems might be grammatical issues, typos, or unclear wording, please provide details regarding the documentation including where it is present.

Note: If your issue is for one of these, please use their dedicated issue tracker instead:

- The Rust Book: https://github.com/rust-lang/book/issues
- Rust by Example: https://github.com/rust-lang/rust-by-example/issues
- The Edition Guide: https://github.com/rust-lang/edition-guide/issues
- The Cargo Book: https://github.com/rust-lang/cargo/issues
- The Clippy Book: https://github.com/rust-lang/rust-clippy/issues
- The Reference: https://github.com/rust-lang/reference/issues
- The Rustonomicon: https://github.com/rust-lang/nomicon/issues
- The Embedded Book: https://github.com/rust-embedded/book/issues

All other documentation issues should be filed here.

Or, if you find an issue related to rustdoc (e.g. doctest, rustdoc UI), please use the bug report or blank issue template instead.

-->

### Location

`CStr::from_ptr`

### Summary

#95948 introduced incompatible changes to the `CStr` docs. Namely, the docs now require immutability for the whole lifetime of `'a`, instead of just while it's borrowed. See also [this discussion on urlo](https://users.rust-lang.org/t/is-this-technically-sound/79783). This is relevant to our crate, `ltptr`, which provides bound lifetimes for raw pointers and uses those in conversions: https://docs.rs/ltptr/0.1.4/ltptr/trait.FromLtPtr.html
Repository: node
Issue: http2 ERR_SSL_CIPHER_OPERATION_FAILED
Labels: http2

### Version

18.7.0

### Platform

Linux 5.19.1

### Subsystem

_No response_

### What steps will reproduce the bug?

import http2 module and create Secure Server.

I could reproduce the bug with a TLS checker: https://www.ssllabs.com/ssltest/index.html

### How often does it reproduce? Is there a required condition?

Occurs everytime the test is running, it runs for a few times, then at the end when checking a bit deeper, node just crashes

### What is the expected behavior?

The test should finish

### What do you see instead?

The test aborts after node threw the error

### Additional information

The code was just a simple 

```js
const http = require("http2");
http.createSecureServer(options, (req, res) => {res.end("Hello");}).listen(443);
```

Here is the output of the logs

```console
node:events:491
      throw er; // Unhandled 'error' event
      ^

Error: C0A7EDD8DA7F0000:error:1C800066:Provider routines:ossl_cipher_generic_stream_update:cipher operation failed:../deps/openssl/openssl/providers/implementations/ciphers/ciphercommon.c:470:

Emitted 'error' event on TLSSocket instance at:
    at TLSSocket._emitTLSError (node:_tls_wrap:904:10)
    at TLSWrap.onerror (node:_tls_wrap:435:11) {
  library: 'Provider routines',
  reason: 'cipher operation failed',
  code: 'ERR_SSL_CIPHER_OPERATION_FAILED'
}

Node.js v18.7.0
```
Repository: godot
Issue: Godot 4 TileSet one-way collision is not one-way only
Labels: topic:core,documentation,topic:physics,topic:2d

### Godot version

v4.0.alpha.14.official

### System information

Linux Mint, Vulkan

### Issue description

When setting the collisions of a tile in a TileSet as one-way, the engine does not apply it correctly. Normally, a character should be able to jump to a higher platform from below "through" it, but any other type of collision should be detected and the engine should prevent the character from going through the obstacle.

In the code example that I attach you can see how the character can cross the area on his right. In this case, the character should hit that raised area and be stopped.

### Steps to reproduce

1. Create a Godot 4 project
2. Create a map with a TileMap, and use a Tile with the one-way collision enabled
3. Add a CharacterBody2D node as the player, set its movement and collisions
4. Try to hit a tile from the side

### Minimal reproduction project

https://github.com/svprdga/Godot-4-One-way-collision-error
Repository: pytorch
Issue: Complex-Valued Gaussian distributions
Labels: module: distributions,triaged,module: complex,module: random

### 🚀 The feature, motivation and pitch

I had been working on complex-valued variational auto encoders (CVAE) and for this purpose I required complex-valued Gaussian distributions. I coded my own implementation based on [1] and used it successfully. I essentially model it as a composite real-valued distribution. Would it be of interest if I created a PR to add this functionality?

[1] P. J. Schreier and L. L. Scharf, Statistical signal processing of complex-valued data: the theory of improper and noncircular signals. Cambridge: Cambridge University Press, 2010. Accessed: Feb. 13, 2022. [Online]. Available: https://doi.org/10.1017/CBO9780511815911


### Alternatives

_No response_

### Additional context

_No response_

cc @fritzo @neerajprad @alicanb @nikitaved @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @pbelevich
Repository: rust
Issue: Tracking Issue for uefi-std
Labels: T-libs-api,C-tracking-issue

Feature gate: `#![feature(uefi_std)]`

This is a tracking issue for Std support for UEFI environment. I have been working on implementing this as a part of my Google Summer of Code 2022 project. Information about the current state of this implementation can be found at `src/doc/rustc/src/platform-support/unknown-uefi.md`. A PR has already been opened [here](https://github.com/rust-lang/rust/pull/100316)

For those who are wondering how a target like UEFI can benefit from std support, here are a few examples:
1. Writing UEFI shell applications. This includes stuff like benchmarks, self-test utilities, etc. Many drivers should also be able to use std.
2. Finding UEFI target bugs. During this work, I have found 3 numeric tests that cause CPU exceptions for UEFI (they are fixed now. Also, I have found 2 additional bugs (which seem like bugs in llvm soft-float) which went unnoticed because there was no easy way to do any broad testing.
3. Provide a stable interface for library developers. The current std contains some functions under std::os::uefi::env to provide access to the underlying SystemTable and SystemHandle, which are essential for writing anything for UEFI.

# Public API
APIs I propose to add under `std::os::uefi::env`:

1. `pub fn get_system_table() -> NonNull<c_void>`
2. `pub fn get_system_handle() -> NonNull<c_void>`
3. `pub fn boot_services() -> Option<NonNull<c_void>>`

APIs I propose to add under `std::os::uefi::ffi` (Just re-export `std::os::windows::ffi`)

1. trait `OsStrExt`
2. trait `OsStringExt`

# Implementation History
- https://github.com/rust-lang/rust/pull/105861
- https://github.com/rust-lang/rust/pull/116207
- https://github.com/rust-lang/rust/pull/116341
- https://github.com/rust-lang/rust/pull/117174
- https://github.com/rust-lang/rust/pull/117177
- https://github.com/rust-lang/rust/pull/120351
- https://github.com/rust-lang/rust/pull/120419
- https://github.com/rust-lang/rust/pull/120640
- https://github.com/rust-lang/rust/pull/120889
- https://github.com/rust-lang/rust/pull/120938
- https://github.com/rust-lang/rust/pull/123196
Repository: neovim
Issue: scroll not working propetly
Labels: bug-vim

### Neovim version (nvim -v)

any

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

any

### Operating system/version

all

### Terminal name/version

any

### $TERM environment variable

default

### Installation

any

### How to reproduce the issue

set sj=-100 

### Expected behavior

scroll full page and set cursor top

### Actual behavior

scroll half page and set cursor on center buffer.

Not work propetly in Nvim and Vim. 

Trying set scroll to page flip (emacs default behavior), cursor set in center page and scroll half page. 

in Vim opened issue, but who cares... https://github.com/vim/vim/issues/1527
Repository: go
Issue: proposal: x/sync/singleflight: Add Group.ForgetUnshared 
Labels: Proposal

After #44505, it's now easier to fix #31697.

I am able to re-unify "internal/singleflight" and "golang.org/x/sync/singleflight" APIs, the last missing piece is `Group.ForgetUnshared`, which is implemented in the former, but not the later.

I propose we add this method to `golang.org/x/sync/singleflight.Group`:

```
// ForgetUnshared tells the Group to forget about a key if it is not
// shared with any other goroutines. Future calls to Do for a forgotten key
// will call the function rather than waiting for an earlier call to complete.
// Returns whether the key was forgotten or unknown--that is, whether no
// other goroutines are waiting for the result.
func (g *Group) ForgetUnshared(key string) bool
```
to unblock #31697.
Repository: storybook
Issue: Change Storybook intermediate loading state "Webpack app" 
Labels: bug,needs triage

**Describe the bug**
Storybook has an intermediate loading state that flashes "Webpack app" as the application boots up. Change this to be more Storybook specific. For example: "Storybook loading..."

See the title bar:
![2022-08-13 14 21 27](https://user-images.githubusercontent.com/263385/184506175-68d1ec4f-0bd4-412c-87a0-75b1c9898faf.gif)

Some search engines don't seem to run JavaScript so it remains "Webpack app"
<img width="528" alt="image" src="https://user-images.githubusercontent.com/263385/184506141-7ec5ba8d-ba57-4940-ac4a-1bc71b6da9b9.png">


**To Reproduce**
On any Storybook (like this [one](https://storybook.js.org/design-system)), `CMD + R` and look at the tab title.


**System**
Happens for local and statically built Storybooks.