sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [tooltip] Preventing from unnecessarily rerendering the children component
Labels: component: tooltip

### Summary

This RFC concerns the React `Tooltip` component and potential performance issues.

### Problem

The React `Tooltip` component unnecessarily rerenders the provided `children` component ~2-3 times on initial `Tooltip` render and every time the tooltip's visibility state toggles.

### Cause

There are a considerable number of code paths leading up to the final `cloneElement` call [here](https://github.com/mui/material-ui/blob/ef23952d1c05006e468dabb2a15e971ac085e5b5/packages/mui-material/src/Tooltip/Tooltip.js#L668) that create a large number of new references. This leads to the observed unnecessary rerendering behavior.

### Experimentation

I have tested this and confirmed that `Tooltip` indeed causes the `children` component to unnecessarily render at least 2-3 additional times.

As a PoC, I have also tested with a reduced-complexity (but-otherwise like-for-like) Tooltip component that proves that leveraging React memoization utils eliminates the problem. For example, the ultimate `cloneElement` call ends up looking something like this:

![image](https://github.com/mui/material-ui/assets/10605534/0605885e-b36e-45e8-b30f-f2501aa54f35)

I do not however possess the resources to delve any deeper into this (e.g. in-depth perf benchmarks). Apologies.

### Open Questions

1. Would the (likely significant) refactors be worth-it?
2. Would the performance gain of less `children` renders outweigh the performance loss of memoization?

### What are the requirements?

Zero unnecessary rerenders of the provided `children` component.

### What are our options?

With my current understanding, there is only one accepted way to achieve this - refactor `Tooltip` to use React memoization utils to prevent `childrenProps` from being a new reference or containing new references.

### Proposed solution

The crux of the solution is to extract out the `cloneElement` call and place it inside a `useMemo` call with the properties of `childrenProps` as the memoization dependencies.

This may require some additional uses of `useCallback` in order to ensure the event handler functions such as `handleEnter` and `onMouseEnter` are not new references.

### Resources and benchmarks

N/A

**Search keywords**: tooltip, react, performance, memoization
Repository: godot
Issue: Trying to add new atlas to tileset shows "Open File(s)" dialog instead
Labels: discussion,topic:editor,documentation,topic:2d

### Tested versions

- Reproducible in: v4.2.1.stable.official [b09f793f5], v4.2.stable.official [46dc27791]
- Not reproducible in: v4.1.3.stable.official [f06b6836a]

### System information

Godot v4.2.1.stable - Windows 10.0.19045 - Vulkan (Mobile) - dedicated NVIDIA GeForce GTX 960 (NVIDIA; 31.0.15.4601) - 13th Gen Intel(R) Core(TM) i5-13400 (16 Threads)

### Issue description

Trying to add a new atlas source via the "+" button in the TileSet window opens the "Open File(s)" dialog instead of adding a new atlas source. Since both the text in the TileSet window as well as the official documentation state that this should indeed create a new resource I assume this is a bug (as opposed to a change that now requires the user to create the resource separately).

Behavior in 4.2.1 and 4.2.0:

https://github.com/godotengine/godot/assets/159484964/3f0e5810-3977-4c73-b49f-917052a6e34a

Behavior in 4.1.3:

https://github.com/godotengine/godot/assets/159484964/238e6f0e-8f0f-46ea-b8c5-29fbc2782a5e



### Steps to reproduce

* Create a new project
* Create a new scene
* Add a new TileMap
* Add a new Tile Set to the TileMap
* Open the TileSet window
* Click on the "+" symbol
* Click on "Atlas"

### Minimal reproduction project (MRP)

[4_2_1_TilemapTest.zip](https://github.com/godotengine/godot/files/14318997/4_2_1_TilemapTest.zip)
Repository: ollama
Issue: Inconsistent OCR Results with LLaVA 1.6 and Ollama vs. LLaVA Online Demo
Labels: question

Hey there, I've posted this issue on [LLaVA repo](https://github.com/haotian-liu/LLaVA/issues/1116) already, not sure if this problem refers to an implementation issue in Ollama. Any idea?
Repository: node
Issue: consider allowing libnode.h (libnode.a/ libnode.lib) and libnode.wasm for nodejs
Labels: feature request

### What is the problem this feature will solve?

use `standard interpreter` in different languages outside of `nodejs`

### What is the feature you are proposing to solve the problem?

consider allowing `libnode.h` (`libnode.a`/ `libnode.lib`) and `libnode.wasm` for `nodejs runtime environment`. This makes nodejs environment available in other environments.

### What alternatives have you considered?

There is a lot of effort with some good, many half baked wrappers, codes, and efforts

- https://github.com/denoland/rusty_v8
- https://github.com/phpv8/v8js
- https://github.com/JavascriptNet/Javascript.Net
- https://github.com/denoland/rusty_v8
- https://github.com/plv8/plv8
- https://github.com/lazytiger/go-v8
- https://github.com/rubyjs/libv8
- https://github.com/pmed/v8-nuget
- https://github.com/dflemstr/v8-rs
- https://github.com/crossle/V8Android
- https://github.com/caoccao/Javet
- https://github.com/jdryg/v8-binaries
- https://github.com/xaxxon/v8toolkit
- https://github.com/dominiek/ruby-v8
- https://github.com/sol/v8
Repository: stable-diffusion-webui
Issue: [Feature Request]: ZLUDA support
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 ?

SD.NET has preliminarily supported the use of ZLUDA on amd gpu, and the efficiency is very high, which is three times that of rocm. Can the method of adapting SD.NET be used for preliminary adaptation now?

### Proposed workflow

https://github.com/lshqqytiger/ZLUDA
https://github.com/vladmandic/automatic/wiki/ZLUDA
https://github.com/vladmandic/automatic/commit/cc4438651f69973e055b63071bf1d0e3cc558eea
https://github.com/vosen/ZLUDA

### Additional information

_No response_
Repository: godot
Issue: Accidental frame selection when opening a spritesheet 
Labels: bug,topic:editor,confirmed,usability,topic:2d

### Tested versions

- Reproducible in: Godot v4.2.1.stable

### System information

Godot v4.2.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 (NVIDIA; 31.0.15.5123) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)

### Issue description

The problem is that one of the frames in a spritesheet is automatically selected when opening the respective spritesheet file using double-click, when trying to set the frames in an AnimatedSprite2D.

![image](https://github.com/godotengine/godot/assets/31389099/e9937504-b1d7-451c-bb37-8e1eb945412c)
![image](https://github.com/godotengine/godot/assets/31389099/0c41ce58-5069-47d3-9f87-720a612a473a)
![image](https://github.com/godotengine/godot/assets/31389099/0db8ebf2-4be1-461b-9f5b-ac5ffe8d34b0)

The selected frame is the one that was under the cursor when I double-clicked. As you can see in the last screenshot, a frame is already selected without any input from me, other than the initial double-click on the file that I wanted to open.

I expect the file to simply open without selecting any frame for me, just like when you open the spritesheet using the "open" button, which works fine.

### Steps to reproduce

- Open the project
- Open the node_2d.tscn scene
- Select AnimatedSprite2D
- In the properties window, click on SpriteFrames
- Down in the animation window, press on the grid icon (Add frames from sprite sheet) or press Ctrl + Shift + O
- Navigate to res://assets/spritesheets in the window that opens up
- Double click on paragon_of_time_separate_smearframes.png (You might need to do this a couple of times, for me the bug didn't trigger the first time)
- If the new window that pops up is under the cursor where you selected the paragon_of_time_separate_smearframes.png file, you should see that the frame under the cursor is automatically selected.


### Minimal reproduction project (MRP)

[Godot Spritesheet Bug Report.zip](https://github.com/godotengine/godot/files/14319321/Godot.Spritesheet.Bug.Report.zip)
Repository: next.js
Issue: Dynamic Sitemap Causing Google to Not Recognize /Robots.txt Error
Labels: bug

### Link to the code that reproduces this issue

https://codesandbox.io/p/live/23eb2f3a-0dec-47d2-88de-dd653d862461

### To Reproduce

### Set up a Next.js project with a dynamic sitemap.
- Deploy the project.
- Check for "/Robots.txt error" in Google Search Console.
- Try accessing both /robots.txt and /Robots.txt.

### Current vs. Expected behavior

### Expected Behavior:
- Google Search Console should recognize and access /robots.txt correctly, regardless of capitalization.

### Actual Behavior:
- Google Search Console reports a "/Robots.txt error".
- Accessing /Robots.txt (with a capital R) results in a "Page not found" error.

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #18~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb  7 11:40:03 UTC 2
Binaries:
  Node: 20.8.0
  npm: 10.1.0
  Yarn: 1.22.19
  pnpm: 8.14.0
Relevant Packages:
  next: 14.1.0
  eslint-config-next: 14.1.0
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 4.9.5
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Which stage(s) are affected? (Select all that apply)

Vercel (Deployed)

### Additional context

- Google Search Console is reporting a "/Robots.txt error" even though the file exists at /robots.txt.
- Accessing /robots.txt directly works, but accessing /Robots.txt (with a capital R) results in a "Page not found" error.
- It appears that the dynamic sitemap generation might be causing this issue.

#### My robots.js file
```js
export default function robots() {
  return {
    rules: [
      {
        userAgent: '*',
        allow: '/',
        disallow: ['/admin', '/admin/*', '/login']
      }
    ],
    sitemap: `${process.env.NEXT_PUBLIC_SITE_URL}/sitemap.xml`
  }
}
```

![image](https://github.com/vercel/next.js/assets/78682260/4a80dc21-675d-49d0-b26c-c315a25fc287)

### Request:
- Please investigate this issue to determine if it's a bug or a configuration issue.
- If it's a bug, please fix it in a future release.
- If it's a configuration issue, please provide guidance on how to resolve it.
Repository: angular
Issue: The new Angular.dev docs don't cover conditional content projection.
Labels: P3,area: docs

### Describe the problem that you experienced

The new Angular.dev docs **don't cover conditional content projection** and how we can **project dynamic content**(means content changes which is projected into the component) in the component.

### Enter the URL of the topic with the problem

https://angular.dev/guide/components/content-projection

### Describe what you were looking for in the documentation

_No response_

### Describe the actions that led you to experience the problem

_No response_

### Describe what you want to experience that would fix the problem

_No response_

### Add a screenshot if that helps illustrate the problem

_No response_

### If this problem caused an exception or error, please paste it here

_No response_

### If the problem is browser-specific, please specify the device, OS, browser, and version

_No response_

### Provide any additional information here in as much as detail as you can

_No response_
Repository: neovim
Issue: Terminal buffer's `bufhidden` behavior is inconsistent
Labels: bug,terminal

### Problem

When using the `bufhidden = "delete"` option in terminal buffers, the buffer gets correctly deleted when closed, but not when another buffer replaces it in its window.

### Steps to reproduce

1. Open Neovim: `nvim --clean`
2. Open a terminal buffer: `:terminal ls`
3. Set option: `:set bufhidden=delete`
4. Open new buffer in current window: `:enew`
5. Look at buffer list: `:ls`

You still see the terminal buffer in the buffer list but it should have been deleted.


### Expected behavior

You can see that `bufhidden = delete` does correctly delete the terminal buffer if you close its window along with the terminal buffer:

1. Open neovim: `nvim --clean`
2. Create a split: `:split`
3. Open a terminal buffer: `:terminal ls`
4. Set option: `:set bufhidden=delete`
5. Close split: `:q`

### Neovim version (nvim -v)

0.9.5

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

Vim always closes terminal buffers of finished commands when the buffers are hidden.

### Operating system/version

Fedora 37

### Terminal name/version

Kitty

### $TERM environment variable

xterm-kitty

### Installation

build from repo
Repository: tensorflow
Issue: `tf.raw_ops.LoopCond` aborts in Debug build
Labels: stat:awaiting tensorflower,type:bug,type:build/install,subtype: ubuntu/linux

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

tf 2.17

### Custom code

Yes

### OS platform and distribution

Linux Ubuntu 22.04 LTS

### Mobile device

_No response_

### Python version

3.11.7

### Bazel version

6.5.0

### GCC/compiler version

clang 16

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

`tf.raw_ops.LoopCond` aborts in Debug build(compiled with `--config=dbg`).
In release build, it does not crash.

### Standalone code to reproduce the issue

```shell
import tensorflow as tf

# it aborts only when compiled with `--config=dbg`
tf.raw_ops.LoopCond(input=True)
```


### Relevant log output

```shell
2024-02-18 02:37:24.039192: F tensorflow/core/graph/graph_partition.cc:644] Check failed: !frame_name.empty() 
Aborted (core dumped)
```
Repository: tensorflow
Issue: `tf.raw_ops.FakeQuantWithMinMaxArgs` aborts when `min>0` in Debug build
Labels: stat:awaiting tensorflower,type:bug,comp:ops,comp:core

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

tf 2.17

### Custom code

Yes

### OS platform and distribution

Linux Ubuntu 22.04 LTS

### Mobile device

_No response_

### Python version

3.11.7

### Bazel version

6.5.0

### GCC/compiler version

clang 16

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

`tf.raw_ops.FakeQuantWithMinMaxArgs` aborts when `min>0` in Debug build(compiled with --config=dbg).
It crashes [here](https://github.com/tensorflow/tensorflow/blob/e193d8ea7776ef5c6f5d769b6fb9c070213e737a/tensorflow/core/kernels/fake_quant_ops_functor.h#L86), 
```C++
eigen_assert(min <= 0.0f && "min should be <= 0.0");
```
and it doesn't seem to be consistent with [document](https://www.tensorflow.org/api_docs/python/tf/raw_ops/FakeQuantWithMinMaxArgs).
Note that `tf.raw_ops.FakeQuantWithMinMaxArgsGradient` has the same situation.


### Standalone code to reproduce the issue

```shell
import tensorflow as tf

# it aborts only when compiled with `--config=dbg`
tf.raw_ops.FakeQuantWithMinMaxArgs(
    inputs=tf.random.normal([1,1,1]),
    min=1,
    max=6,
    num_bits=8,
    narrow_range=False)
```


### Relevant log output

```shell
python: ./tensorflow/core/kernels/fake_quant_ops_functor.h:86: void tensorflow::FakeQuantWithMinMaxArgsFunctor<Eigen::ThreadPoolDevice>::operator()(const Device &, ConstFlat<float>, const float, const float, const int, const int, Flat<float>) [Device = Eigen::ThreadPoolDevice]: Assertion `min <= 0.0f && "min should be <= 0.0"' failed.
Aborted (core dumped)
```
Repository: tensorflow
Issue: C++ API `GatherV2` aborts with inappropriate input
Labels: awaiting review,type:bug,comp:runtime,comp:ops

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

tf 2.17

### Custom code

Yes

### OS platform and distribution

Linux Ubuntu 22.04 LTS

### Mobile device

_No response_

### Python version

3.11.7

### Bazel version

6.5.0

### GCC/compiler version

clang 16

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

C++ API `GatherV2` aborts with inappropriate input.
Suspected code location is [here](https://github.com/tensorflow/tensorflow/blob/e193d8ea7776ef5c6f5d769b6fb9c070213e737a/tensorflow/core/ops/array_ops.cc#L1240-L1242),
```C++
          c->set_output(0, c->UnknownShapeOfRank(c->Rank(params_shape) +
                                                 c->Rank(indices_shape) - 1 -
                                                 batch_dims));
```
which calls `UnknownShapeOfRank` with negative value due to lack of validity check.

### Standalone code to reproduce the issue

```C++
#include "tensorflow/cc/framework/scope.h"
#include "tensorflow/core/graph/graph.h"
#include "tensorflow/core/public/session.h"
#include "tensorflow/cc/ops/array_ops.h"
#include "tensorflow/cc/ops/standard_ops.h"

using namespace tensorflow;

int main() {
  SessionOptions options;
  ConfigProto & config = options.config;
  config.set_inter_op_parallelism_threads(1);
  config.set_intra_op_parallelism_threads(1);
  config.set_use_per_session_threads(false);
  std::unique_ptr<tensorflow::Session>
    session(tensorflow::NewSession(options));
  Scope scope = Scope::NewRootScope();

  auto params = ops::RandomUniformInt(scope, {1}, 0, 15);
  auto attrs = 
    ops::GatherV2::Attrs()
      .BatchDims(2);
  auto target = ops::GatherV2(scope.WithOpName("target"), params, 1, 1, attrs);

  GraphDef graph_def;
  TF_CHECK_OK(scope.ToGraphDef(&graph_def));

  Status status = session->Create(graph_def);
  if (!status.ok()) {
    LOG(WARNING) << "Could not create session: " << status.message();
  }

  std::vector<Tensor> outputs;
  status = session->Run({}, {"target"}, {""}, &outputs);
  if (!status.ok()) {
    LOG(WARNING) << "Could not run session: " << status.message();
  }

  return 0;
}
```


### Relevant log output

```shell
2024-02-18 03:14:31.909510: F tensorflow/core/framework/shape_inference.cc:705] Check failed: rank >= 0 (0 vs. -2)rank must not be negative
Aborted (core dumped)
```
Repository: rust
Issue: Tracking Issue for rust_has_provenance
Labels: B-RFC-approved,T-lang,B-RFC-implemented,C-tracking-issue

<!--
NOTE: For library features, please use the "Library Tracking Issue" template instead.

Thank you for creating a tracking issue! 📜 Tracking issues are for tracking a
feature from implementation to stabilisation. Make sure to include the relevant
RFC for the feature if it has one. Otherwise provide a short summary of the
feature and link any relevant PRs or issues, and remove any sections that are
not relevant to the feature.

Remember to add team labels to the tracking issue.
For a language team feature, this would e.g., be `T-lang`.
Such a feature should also be labeled with e.g., `F-my_feature`.
This label is used to associate issues (e.g., bugs and design questions) to the feature.
-->

This is a tracking issue for the RFC "Rust Has Provenance" (rust-lang/rfcs#3559).

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

(This RFC does not need any implementation.)

- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Formatting for new syntax has been added to the [Style Guide] ([nightly-style-procedure])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs
[nightly-style-procedure]: https://github.com/rust-lang/style-team/blob/master/nightly-style-procedure.md 
[Style Guide]: https://github.com/rust-lang/rust/tree/master/src/doc/style-guide

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

None (unless we want to bikeshed the term "provenance" itself...)

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->
Repository: neovim
Issue: Press/release key event support
Labels: enhancement,input,mappings

### Problem

The [Kitty keyboard protocol](https://sw.kovidgoyal.net/kitty/keyboard-protocol) supports sending press/repeat/release events for key presses. We currently do not enable this mode and termkey is not currently able to parse these events, but we certainly could.

A possible use case for press/release events would be to show a floating window only while a key is held down (e.g. for LSP hover or diagnostics).

Adding support to libtermkey is fairly straightforward (I already have a working prototype in a branch). The more difficult problem is plumbing this into Neovim's own event handling.

At least one question is how a press/release event should be represented. The TUI sends all key events to the core with `nvim_input`, so we need a way to represent the "press"/"release" event there. We should be able to leave "press" events as-is and only add special casing for "release" events (I'm not sure we need "repeat" events?).

We could limit press/release events only to the API (via `nvim_set_keymap`) so that we don't need to modify `:map` and friends.

Related: https://github.com/neovim/neovim/issues/14400