sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: cv2.inter_linear_exact behaves differently on m2 vs intel.
Labels: bug,category: imgproc,needs investigation

### System Information

OpenCV python version: 4.9.0.80
Operating System: Ventura 13.0.1
Python version: Python 3.9.18
Chip: Intel i7 and M2



### Detailed description

I resize a tensor of size 3x45x55 -> 3x22x27 using `cv2.INTER_LINEAR_EXACT`. 

For some reason, the result is different when I use an M2 Mac vs intel Mac.

### Steps to reproduce

I have provided bins and the resize op that gives different outputs between m2 and intel in the zip.
```python
import cv2
import numpy as np

num_channels = 3
input_height = 45
input_width = 55
output_height = 22
output_width = 27
output_shape = (num_channels, output_height, output_width)
output_img_shape = (output_height, output_width, num_channels)
input_arg_img_shape = (input_height, input_width,num_channels)


test_path = "/Users/enochxu"
input_img_path = f"{test_path}/input_img_float.bin"
input_img_float = np.fromfile(input_img_path, dtype=np.float64).reshape(input_arg_img_shape)

output_img = cv2.resize(
    input_img_float,
    output_img_shape[1::-1],
    interpolation=cv2.INTER_LINEAR_EXACT
)
print(output_img.shape)
output_img.tofile(f"{test_path}/output_img_float.bin")
```
A histogram will show differences between the two outputs.
```python
import matplotlib.pyplot as plt

intel_output_path = f"{test_path}/output_img_float_intel.bin"
intel_output = np.fromfile(intel_output_path, dtype=np.float64).reshape(output_img_shape)
print(intel_output.shape)
m2_output_path = f"{test_path}/output_img_float_m2.bin"
m2_output = np.fromfile(m2_output_path, dtype=np.float64).reshape(output_img_shape)

output_diff = m2_output - intel_output
plt.hist(output_diff.flatten())
```
[resizebug.zip](https://github.com/opencv/opencv/files/14285689/resizebug.zip)

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [ ] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: flutter
Issue: [Revert] Extend 24 hour intervals for revert PRs
Labels: team-infra,P2,triaged-infra

### Type of Request

feature request

### Infrastructure Environment

Autosubmit

### What is happening?

The revert bot only supports reverts that happen within 24 hours. I see two possible paths:

1. Extend revert interval to 48 hours (for everyone)
2. Extend revert interval for senders from GitHub apps.

My use case is for FRoB. Google testing will often find reverts over the weekend, but people aren't working on the weekend. 

For 2, we could allowlist "flutter-roll-on-borg" to create reverts after a longer period of time.

\cc @ricardoamador 

### Steps to reproduce

_No response_

### Expected results

_No response_
Repository: go
Issue: runtime: stronger affinity between G ↔ P ↔ M ↔ CPU?
Labels: Performance,NeedsInvestigation,compiler/runtime,Scalability

Currently the runtime makes some attempts to maintain affinity between these resources:

* When Gs are descheduled, they are usually placed on the local P run queue, to run again on the same P later (if they aren't stolen).
* Ps remain on the same M until they stop.
* Ms don't do anything to explicitly attempt CPU affinity, but OS schedulers generally do this.

There are cases where we explicitly do not maintain affinity:

* Gs are occasionally placed on the global run queue, making them more likely to move to different P (this is intentional, but perhaps not ideal).
* Stopped Ps have no affinity to an M. This is most notable across STW. STW stops all Ps. When the world starts again, the Ps all move to arbitrary Ms.
* GC mark workers are started during a STW, and schedule with high priority, making them likely to run on a P that was previously running a G, even if there are idle Ps. This forces the G to move to a different P.

The lack of perfect affinity is typically readily evident when viewing an execution trace, where you can see Gs moving around, even when there are idle resources. It is especially evident across a STW, but movement can be seen during normal execution as well.

In this example below, we can see G11 through G19 all moving between threads several times (thanks @aktau for raising this).
![image](https://github.com/golang/go/assets/1293187/88fa52d0-c2ef-4005-a07c-de4d8a7c9332)

These migrations are certainly a (minor) annoyance when viewing traces.

They may also be a source of performance degradation. For example, CPU caches are likely empty after a migration, causing additional cache misses. Perhaps it could even have NUMA effects if a Gs allocations came from a P's mcache with spans that the OS has placed on one NUMA node, and then moving to a different M/CPU makes memory access slower.

None of these potential performance effects have been measured to determine if they are noticeable. e.g., migration will clearly have cache effects, but migration tends to occur in 10ms intervals, or much longer. It isn't clear that cache effects would be noticeable at these long time scales. More research is required.

cc @mknyszek @aclements @aktau
Repository: flutter
Issue: [Impeller] Turn `IMPELLER_PLAYGROUND_[LINE|POINT]` into real ImGui widgets.
Labels: engine,c: proposal,P3,e: impeller,team-engine,triaged-engine

These started off as test-only ImGui macros that are actually just enclosed ImGui widgets with static state, and were changed into a separate struct/draw routine in [this PR](https://github.com/flutter/engine/pull/50602).

We could turn them into real ImGui widgets by using ImGui's actual identity/storage features.
Repository: transformers
Issue: load_state_dict doesnt support torch._subclasses.fake_tensor.FakeTensorMode
Labels: Feature request

### System Info

- `transformers` version: 4.36.0
- Platform: Linux-6.5.0-15-generic-x86_64-with-glibc2.31
- Python version: 3.11.5
- Huggingface_hub version: 0.19.4
- Safetensors version: 0.4.0
- Accelerate version: 0.24.1
- Accelerate config:    not found
- PyTorch version (GPU?): 2.3.0a0+git78a84f1 (True)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using GPU in script?: <fill in>
- Using distributed or parallel set-up in script?: no

### Who can help?

_No response_

### Information

- [ ] The official example scripts
- [ ] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

When PyTorch's `FakeTensorMode` is active, the underlying storage is changed to be `UntypedStorage` as a way to not really allocate the memory for the parameters.

As a consequence, transformers's `get_tensor` failed with `ValueError: could not determine the shape of object type 'torch.storage.UntypedStorage'`

```python
from torch._subclasses import fake_tensor
import transformers

fake_mode = fake_tensor.FakeTensorMode(allow_non_fake_inputs=False)
with fake_mode:
    fake_model = transformers.AutoModel.from_pretrained("sshleifer/tiny-gpt2") 
```

Error:

```bash
Loading checkpoint shards:   0%|                                           | 0/19 [00:00<?, ?it/s]
Traceback (most recent call last):
  File "/opt/pytorch/test_mixtral.py", line 9, in <module>
    model = AutoModelForCausalLM.from_pretrained(model_id)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/ptca/lib/python3.11/site-packages/transformers/models/auto/auto_factory.py", line 566, in from_pretrained
    return model_class.from_pretrained(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/ptca/lib/python3.11/site-packages/transformers/modeling_utils.py", line 3694, in from_pretrained
    ) = cls._load_pretrained_model(
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/ptca/lib/python3.11/site-packages/transformers/modeling_utils.py", line 4079, in _load_pretrained_model
    state_dict = load_state_dict(shard_file)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/ptca/lib/python3.11/site-packages/transformers/modeling_utils.py", line 510, in load_state_dict
    return safe_load_file(checkpoint_file)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/ptca/lib/python3.11/site-packages/safetensors/torch.py", line 310, in load_file
    result[k] = f.get_tensor(k)
                ^^^^^^^^^^^^^^^
ValueError: could not determine the shape of object type 'torch.storage.UntypedStorage'
```

### Expected behavior

`transformers` `get_tensor` should be able to load fake tensors from a fakefied checkpoint
Repository: node
Issue: Add API to worker thread to check whether main thread is TTY
Labels: feature request,worker

### What is the problem this feature will solve?

In worker threads, `process.stdout.isTTY` and `process.stderr.isTTY` are `undefined`. However, they do forward stdout/stderr to the main thread, and the main thread could potentially be `isTTY === true`. This makes sense as some things don't work, like raw mode. However, things that produce colors would want to be able to detect that the main thread is TTY, so colors can be shown when logged from a worker thread.

### What is the feature you are proposing to solve the problem?

Add an API to worker threads to check whether stdout/stderr in the main thread is TTY.

This is needed for color packages like [`chalk`](https://github.com/chalk/chalk) to be able to support showing colors when running in worker threads.

Relevant issue: https://github.com/nodejs/node/issues/26946

### What alternatives have you considered?

_No response_
Repository: vscode
Issue: usability: callstack UI should not scroll
Labels: bug,debug

<!-- ⚠️⚠️ 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. -->


when debugging code with long callstack lines (eg c++ templates where line length can easily exceed 10,000 characters), much of the callstack UI is invisible without scrolling to the right making it next to useless:

![image](https://github.com/microsoft/vscode/assets/1088194/c1372e24-db25-4486-b1b1-694eb44f7ec5)

![image](https://github.com/microsoft/vscode/assets/1088194/97e6347e-01dc-4268-a913-c7073c6cedc1)


NOTE:
- the horizontal scrollbar is tiny.
- the filenames & line numbers (eg 'epoll_reator.ipp' 806:1) are not visible unless the window is scrolled all the way to the right
- the module/function names are not visible when the window is scrolled
- the 'Load More Stack Frames' UI is inaccessible, requiring precise scrolling to the middle of the window.

REQUEST:
- lock the filename/line-number UI to the right-side of the VIEW (not the content)
- have the content of the window (the actual callstack lines) scroll _under_ the above filename/line-number UI
- lock the "Load More Stack Frames" UI to the center of the VIEW (not the content)
Repository: vscode
Issue: notebook cell output maintains mouseover when scrolling away, breaking scrolling and other behavior
Labels: bug,notebook-output


<!-- 🪓 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.86.1
- OS Version: OSX 14.3

In a VSCode notebook, I have a cell output with a blue border, with CSS to turn it red when hovered. The cell output has a scrollable area. The cell output has been wrapped in vscode-error-overlay in order to allow scrolling inside of the notebook properly.

However, when I hover my mouse into the cell output, and then scroll away so that the mouse is no longer over the cell output, the cell continues to be treated as being hovered. Its border stays red and any scroll events that it accepts are passed to it instead of wherever the mouse actually is on the screen. This causes the scrolling of the notebook to be broken. See this video, where I scroll up away from my nested scrollable area, and then try scrolling down but the scrolling is passed to the cell output that I originally started scrolling on. Moving the mouse fixes the issue, so it only happens if you scroll up and down without moving the mouse. The scroll in this case is down with a wheel.

https://github.com/microsoft/vscode/assets/5554373/98f612b3-0fd2-43d0-b453-e074246d8258
Repository: kubernetes
Issue: Allow disabling Kubelet Pods/containers log cleanup
Labels: sig/node,kind/feature,lifecycle/rotten,needs-triage

Log lifecycle management is part of Kubelet attributions. 

It is done [here](https://github.com/kubernetes/kubernetes/blob/252e1d2dfee63e3165c4277ce1709d635df5132f/pkg/kubelet/kuberuntime/kuberuntime_container.go#L1267) and basically, when a Pod doesn't exists anymore it will remove any logs from the filesystem.

On some cases, the logs from the container runtime are not being shipped externally and there may be a need to disable this behavior (being the responsibility of the cluster admin to set some log rotation and cleanup). As an example, a Pod that is deleted by a bad actor will have all of its logs gone. Those lost logs may be required for a future forensics.

The request here is to add a flag/config on kubelet that allows the cluster admin to disable this cleanup, which means, when a Pod is deleted, no request to the container runtime will be made to remove its logs, skipping the `removeContainerLog` function call.

Thanks

/sig node
/kind feature
Repository: flutter
Issue: [flutter_tools] ProcessException: Failed to find "C:\flutter\bin\cache\dart-sdk\bin\dartaotruntime.exe" in the search path
Labels: P2,team-tool,triaged-tool

Top crasher on `beta/3.19.0-0.4.pre`

Command: `flutter --no-color run --machine --track-widget-creation --device-id=0c463b4b0602 --start-paused --dart-define=flutter.inspector.structuredErrors=true lib\main.dart`

```
ProcessPackageException: ProcessException: Failed to find "C:\flutter\bin\cache\dart-sdk\bin\dartaotruntime.exe" in the search path.  Command: C:\flutter\bin\cache\dart-sdk\bin\dartaotruntime.exe
at LocalProcessManager.start(local_process_manager.dart:56)
at ErrorHandlingProcessManager.start.<anonymous closure>(error_handling_io.dart:686)
at _run(error_handling_io.dart:556)
at ErrorHandlingProcessManager.start(error_handling_io.dart:685)
at DefaultResidentCompiler._compile(compile.dart:874)
at DefaultResidentCompiler._recompile(compile.dart:734)
at _RecompileRequest._run(compile.dart:420)
at _CompilationRequest.run(compile.dart:394)
at DefaultResidentCompiler._handleCompilationRequest(compile.dart:780)
at _rootRunUnary(zone.dart:1407)
at _CustomZone.runUnary(zone.dart:1308)
at _CustomZone.runUnaryGuarded(zone.dart:1217)
at _BufferingStreamSubscription._sendData(stream_impl.dart:339)
at _DelayedData.perform(stream_impl.dart:515)
at _PendingEvents.handleNext(stream_impl.dart:620)
at _PendingEvents.schedule.<anonymous closure>(stream_impl.dart:591)
at _rootRun(zone.dart:1391)
at _CustomZone.run(zone.dart:1301)
at _CustomZone.runGuarded(zone.dart:1209)
at _CustomZone.bindCallbackGuarded.<anonymous closure>(zone.dart:1249)
at _rootRun(zone.dart:1399)
at _CustomZone.run(zone.dart:1301)
at _CustomZone.runGuarded(zone.dart:1209)
at _CustomZone.bindCallbackGuarded.<anonymous closure>(zone.dart:1249)
at _microtaskLoop(schedule_microtask.dart:40)
at _startMicrotaskLoop(schedule_microtask.dart:49)
at _runPendingImmediateCallback(isolate_patch.dart:118)
at _RawReceivePort._handleMessage(isolate_patch.dart:185)
```
Repository: kubernetes
Issue: [APF] Separate Events requests from non-Events
Labels: sig/api-machinery,kind/feature,triage/accepted

### What would you like to be added?

Adding separate `prioritylevel`s for Events to avoid resource competitions to non-event requests.

I currently think two ways of separation:

Option 1:

Create a new FS and PLC for events. The new FS will catch all events regardless of requestors. PLC will have a minimum `nominalConcurrencyShares`

| Name | Nominal Shares | Lendable | Borrowing Limit | Min Shares |
| ---- | -------------: | -------: | -----------------------: | --: |
| event |  5 |   100% | none | 0 |

Rules
```
  rules:
  - nonResourceRules:
    resourceRules:
    - apiGroups:
      - '*'
      clusterScope: true
      namespaces:
      - '*'
      resources:
      - events
      verbs:
      - '*'
    subjects:
    - group:
        name: '*'
      kind: Group
    - user:
        name: '*'
      kind: User
```

Option 2:

Create a mirror of existing FSs and PLCs for event counterparts

| Name | Nominal Shares | Lendable | Borrowing Limit | Min Shares |
| ---- | -------------: | -------: | -----------------------: | --: |
| node-high-events       |  5 |  100% | none | 0 |
| system-events          |  2 |  100% | none | 0 |
| workload-high-events   |  2 |  100% | none | 0 |
| workload-low-events    | 5 |  100% | none | 0 |
| global-default-events  |  2 |  100% | none | 0 |


The numbers of "Nominal Shares" need more thoughts to be more reasonable but they should be minimum with the hope to use borrowed concurrent shares. I am inclined to Option 1 for its simplicity. 

### Why is this needed?

In my tests that add a few hundreds of nodes to the cluster, I noticed if the machine that hosts `apiserver` & `etcd` is too small, `apiserver` can be easily stressed out and starts responding 429s and 504s (also, nodes became NotReady due to missing lease renews). However, in fact, the majority of the resources were consumed to serve event requests. If I removed events entirely, the cluster was able to survive the whole test more healthily. 

AIUI, event requests are less critical but voluminous so they likely compete currency shares with non-event requests when apiserver is under stress. It's more ideal to process Events when apiserver has free capacity.

To give a sense of competition, I observed POST requests of 3k non-event and 9.3k event from kubelet (also a few thousands from scheduler and controller-manager etc) in a test adding 200 nodes to a k8s cluster. Worth mentioning POST requests have to hit the ETCD so they are pretty expensive in terms of the duration occupying the concurrency shares as well as the machine resources.

Most importantly, event requests are resilient to temporary failures. For example, events are stored in client side up to [1000](https://github.com/kubernetes/client-go/blob/v0.29.1/tools/record/event.go#L43) before dropping. So it seems relatively safe to reject or throttle event requests.
Repository: rust
Issue: Tracking Issue for `derive_skip`
Labels: T-libs-api,C-tracking-issue

This is a tracking issue for https://github.com/rust-lang/libs-team/issues/334.
The feature gate for the issue is `#![feature(derive_skip)]`.

### 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

- [x] Implement the APC (#121053)
- [ ] 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
- How to deal with unhandled/typo arguments (e.g. `#[skip(Degub)]`
- Support for 3rd party derives, or just builtins
- Should `#[skip = "Debug"]` work?
- Handling `#[skip]` when not all derives support it
- Interaction with `StructuralPartialEq`

### Implementation history

- Initial implementation (#121053)
Repository: godot
Issue: Setting AnimatedSprite2D.autoplay string in `_ready()` works, but issues a contradictory warning
Labels: bug,topic:animation

### Tested versions

- Reproducible in v4.3.dev3.official [36e943b6b]

### System information

Windows 10

### Issue description

When using `AnimatedSprite2D`, setting the autoload string to `""` in the `_ready` function works to prevent autoloading.

However, in the debugger I get warnings like (this is a built-in script):
```
W 0:00:02:0689   movie_loop.tscn::GDScript_d5yvq:15 @ _ready(): Setting autoplay after the node has been added to the scene has no effect.
  <C++ Source>   scene/2d/animated_sprite_2d.cpp:449 @ set_autoplay()
  <Stack Trace>  movie_loop.tscn::GDScript_d5yvq:15 @ _ready()
```

I do not know the intended behavior / intended timing of when autoplay is supposed to start, but I've been using the _ready function as a opportunity to dynamically affect autoplaying on these AnimatedSprite2D nodes so I'd like to know sooner than later if that capability will be 'fixed' in a future version. :)

### Steps to reproduce

1. Add an AnimatedSprite2D with an animation set to autoload.
2. Attach a script like this one:  
```gdscript
extends AnimatedSprite2D

@export var wait_to_start := 5.0

# The purpose of this snippet is to delay when the node starts autoplaying by wait_to_start seconds.
func _ready():
	if wait_to_start != 0 and autoplay != "": 
		get_tree().create_timer(wait_to_start).timeout.connect(play.bind(autoplay))
		autoplay = ""
```
3. Start the scene; the autoplay is delayed.
4. View the debugger; the debug warning is present.

### Minimal reproduction project (MRP)

[autoplay_warning_bug.zip](https://github.com/godotengine/godot/files/14271971/autoplay_warning_bug.zip)