sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: tensorflow
Issue: tf.linalg.expm fails to support half/float16 data type, which is inconsistent with doc
Labels: stat:awaiting tensorflower,type:bug,comp:ops,2.17

### Issue type

Bug

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

Yes

### Source

source

### TensorFlow version

2.17.0

### Custom code

Yes

### OS platform and distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

According to the documentation: https://www.tensorflow.org/api_docs/python/tf/linalg/expm
tf.linalg.expm is expected to accept float16 input, but it fails on float16 when actually running the following code.

### Standalone code to reproduce the issue

```shell
import tensorflow as tf
import numpy as np
input = tf.constant(np.random.randn(1,1), dtype='float16')
out = tf.linalg.expm(input)
```
```


### Relevant log output

```shell
tensorflow.python.framework.errors_impl.NotFoundError: Could not find device for node: {{node MatrixSolve}} = MatrixSolve[T=DT_HALF, adjoint=false]
All kernels registered for op MatrixSolve:
  device='XLA_CPU_JIT'; T in [DT_FLOAT, DT_DOUBLE, DT_HALF]
  device='XLA_GPU_JIT'; T in [DT_FLOAT, DT_DOUBLE, DT_HALF]
  device='GPU'; T in [DT_COMPLEX128]
  device='GPU'; T in [DT_COMPLEX64]
  device='GPU'; T in [DT_DOUBLE]
  device='GPU'; T in [DT_FLOAT]
  device='CPU'; T in [DT_COMPLEX128]
  device='CPU'; T in [DT_COMPLEX64]
  device='CPU'; T in [DT_DOUBLE]
  device='CPU'; T in [DT_FLOAT]
 [Op:MatrixSolve] name:
```
Repository: bitcoin
Issue: Mining Interface doesn't allow for Bitcoin Core to create blocks when it wants
Labels: Mining

Finally getting around to reviewing the mining interface, and sadly its missing some critical features that a new mining protocol should have. Specifically, one of the key goals of replacing `getblocktemplate` is that Bitcoin Core should be able to push work to clients at opportune times. This includes the ability to create a new block in between validating a new block and updating the mempool for a full CNB run. Sadly, forcing the client of the interface to explicitly call CNB makes this impossible.
Repository: three.js
Issue: CCDIKSolver constraint limits
Labels: Addons

### Description

When using CCDIK Solver with GLTF models, the constraints only works well when it's an interval between [-π, π] ( -180° and 180°).

My problem is when bone have already an offset rotation like π by default (Seems pretty common with the mixamo model I found on internet).

In the case of an offset of -π on the bone for example, if we want a -45 +45° amplitude constraint on x axis, we should have : 
```
{
      target: 10,
      effector: 9,
      links: [
        {
          index: 8,
          rotationMin: new Vector3(-Math.PI - Math.PI/4, 0, 0)), // - Offset
          rotationMax: new Vector3(-Math.PI + Math.PI/ 4, 0, 0)) // + Offset
        }
      ]
    },
```
-Math.PI - Math.PI/4 equivalent to -225°
-Math.PI + Math.PI/4 equivalent to -135°

But in this case, as the value seems to exceed the intervals [-π, π] , the constraint doesn't work properly.

I've tried to invert rotationMin and rotationMax, but it doesn't work.

Is this a known limitations of CCDIKSolver ? 



### Reproduction steps

1. Load a model with default bone rotation near limits of interval [-π, π] 
2. Add IK constraint


### Code

```js
// code goes here
```


### Live example

https://codesandbox.io/p/sandbox/zm9zjk?file=%2Fsrc%2FApp.js

### Screenshots

_No response_

### Version

r169

### Device

_No response_

### Browser

_No response_

### OS

_No response_
Repository: opencv
Issue: OpenCL pow with integer order fails on kernel compilation stage
Labels: bug,category: core,category: ocl

### System Information

Platform: Linux + NVIDIA OpenCL (GF 1080)
Become visible after https://github.com/opencv/opencv/pull/26061

### Detailed description

```
[ RUN      ] OCL_PowFixture_iPow.iPow/0, where GetParam() = (640x480, 8UC1)
1 error generated.
OpenCL program build log: core/arithm
Status -11: CL_BUILD_PROGRAM_FAILURE
-D dstT=uchar -D DEPTH_dst=0 -D rowsPerWI=1 -D OP_POWN -D UNARY_OP -D DOUBLE_SUPPORT
<kernel>:422:1: error: call to 'pown' is ambiguous
PROCESS_ELEM;
^~~~~~~~~~~~
<kernel>:226:31: note: expanded from macro 'PROCESS_ELEM'
#define PROCESS_ELEM storedst(pown(srcelem1, srcelem2))
                              ^~~~
<kernel>:48:64: note: expanded from macro 'storedst'
#define storedst(val) *(__global dstT *)(dstptr + dst_index) = val
                                                               ^~~
cl_kernel.h:3546:25: note: candidate function
double __OVERLOADABLE__ pown(double a, int b);
                        ^
cl_kernel.h:6311:24: note: candidate function
float __OVERLOADABLE__ pown(float a, int b);
                       ^
cl_kernel.h:3538:26: note: candidate function
float2  __OVERLOADABLE__ pown(float2 x, int2 a)    ;
                         ^
cl_kernel.h:3540:26: note: candidate function
float3  __OVERLOADABLE__ pown(float3 x, int3 a)    ;
                         ^
cl_kernel.h:3542:26: note: candidate function
float4  __OVERLOADABLE__ pown(float4 x, int4 a)    ;
                         ^
cl_kernel.h:3543:26: note: candidate function
float8  __OVERLOADABLE__ pown(float8 x, int8 a)    ;
                         ^
cl_kernel.h:3544:26: note: candidate function
float16 __OVERLOADABLE__ pown(float16 x, int16 a) ;
                         ^
cl_kernel.h:3547:27: note: candidate function
double2  __OVERLOADABLE__ pown(double2 x, int2 a)    ;
                          ^
cl_kernel.h:3549:27: note: candidate function
double3  __OVERLOADABLE__ pown(double3 x, int3 a)    ;
                          ^
cl_kernel.h:3551:27: note: candidate function
double4  __OVERLOADABLE__ pown(double4 x, int4 a)    ;
                          ^
cl_kernel.h:3552:27: note: candidate function
double8  __OVERLOADABLE__ pown(double8 x, int8 a)    ;
                          ^
cl_kernel.h:3553:27: note: candidate function
double16 __OVERLOADABLE__ pown(double16 x, int16 a) ;
                          ^

[ PERFSTAT ]    (samples=100   mean=1.07   median=1.06   min=1.00   stddev=0.04 (4.0%))
[       OK ] OCL_PowFixture_iPow.iPow/0 (129 ms)
```

### Steps to reproduce

-

### Issue submission checklist

- [X] I report the issue, it's not a question
- [ ] 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
- [ ] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: opencv
Issue: estimateAffinePartial2D without scaling
Labels: feature

### Describe the feature and motivation

I use [estimateAffinePartial2D](https://docs.opencv.org/4.x/d9/d0c/group__calib3d.html#gad767faff73e9cbd8b9d92b955b50062d) function to stabilize a set of images of a fixed camera dedicated to coastline monitoring. The camera zoom is fixed. There are small camera movements due to for example the thermal dilation of the structure on which the camera is installed.

The stabilization result with estimateAffinePartial2D is quite good, but it could be really better if scaling factor was not computed and left to 1, as it would better suit the camera configuration.

It would be great to have a boolean parameter in estimateAffinePartial2D, in which the user can specifiy if scaling factor has to be computed or not. Otherwise, it might be more simple to implement an other function called for example 'estimateRigidBody2D' that would compute a rigid body (translation + rotation) transformation from matching points.





### Additional context

_No response_
Repository: pytorch
Issue: Dynamo x autograd.Function: leverage compiled autograd on graph break in backwards
Labels: triaged,oncall: pt2,module: compiled autograd,dynamo-autograd-function

There are four quadrants (see table below); we're talking about quadrant III. When we are torch.compiling an autograd.Function, we trace the forward and backward into subgraphs. If the forward can be traced into a subgraph, but the backward cannot, we graph break on the forward.

With compiled autograd in the loop, we don't actually need to graph break on the forward: we can put a black box into the backward graph and rely on compiled autograd to read it, like how we handle backward hooks today.

<meta charset="utf-8"><b style="font-weight:normal;" id="docs-internal-guid-328eaa92-7fff-09c1-9f67-4aa95a98e8d3"><div dir="ltr" style="margin-left:0pt;" align="left">
  | forward safe | forward unsafe
-- | -- | --
backward safe | II) HOP capture | I) graph break in forward
backward unsafe | III) (this issue!) add a compiled autograd integration | IV) graph break in forward





cc @ezyang @chauhang @penguinwu @xmfan @yf225
Repository: ollama
Issue: Pull Private Huggingface Model
Labels: feature request

Hi, so I believe it's now possible to pull huggingface models directly by prepending hf.co to the pull statement. I would just like to get clarity on how this works with private models? I have my huggingface token set as an environment variable, but I can't seem to pull a private model.
Repository: pytorch
Issue: [PT2] Don't graph break on loss.backward()
Labels: triaged,oncall: pt2,module: dynamo,module: compiled autograd

@vmoens mentioned this recently in a talk on TorchRL pain points but I didn't see an existing issue.

We can actually support loss.backward() in Dynamo. There are a couple of cases (ranging from easy to difficult):

1) If the only differentiable inputs to a torch.compile region are graph leaves, then we can handle all of this inside Dynamo: allow_in_graph some call to compute gradients in the graph and Dynamo can update the .grad field of the inputs. This essentially requires the full model to be compile able.
2) If any inputs are differentiable and not leaves: maybe we can do something with compiled autograd here. What if we could trigger compiled autograd and then inline the graph we get from that into the graph that Dynamo is producing?
 

cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames @rec @xmfan @yf225
Repository: deno
Issue: `util.inspect` behaves differently from Node.js when using proxies
Labels: bug,ext/console

Version: Deno 2.0.0

The following code throws in Deno, while it returns a string in Node.js
```js
import util from "node:util"
util.inspect(new Proxy({ x: 1 }, { ownKeys: () => undefined }))
```
Repository: pytorch
Issue: Update auto_functionalized_v2 to pass view subgraphs
Labels: triaged,module: functionalization,oncall: pt2,module: pt2-dispatcher

In Inductor, auto_functionalization_v2 needs to reconstruct views given some base tensors. The way we do that today is that we pass the (sizes, strides, storage_offsets) of the views to auto_functionalization_v2 and then generate .as_strided() calls into the Inductor post_grad_graph.

Our current design has a couple of issues:
- as_strided calls in inductor may be inefficient, since they need to realize the tensor
- To avoid generating as_strided calls in inductor, we store some information about if the view is an alias or a select/slice/alias in the auto_functionalized_v2 HOP. This logic doesn't work for more complicated subgraphs

Instead, we should pass subgraphs that represent how to reconstruct the views to the auto_functionalized HOP.





cc @bdhirsh @ezyang @chauhang @penguinwu @yf225
Repository: rust
Issue: Tracking issue for all the ways in which -C compiler flags can alter the ABI
Labels: T-compiler,C-tracking-issue,A-ABI,A-target-feature

If a `-C` flag alters the ABI, mixing crates built with different flags causes UB. This issue is gathering all the ways in which this can happen, so that we can figure out what to do with them. The general goal is to make it impossible to alter these flags without realizing that they are "special" and need to be set consistently across all crates. Ideally rustc can even check that they are set consistently, though that will not cover dynamic linking.

- `-Ctarget-features` can affect the ABI in a bunch of ways
  - https://github.com/rust-lang/rust/issues/116558
  - https://github.com/rust-lang/rust/issues/116344
  - https://github.com/rust-lang/rust/issues/131058
  - https://github.com/rust-lang/rust/issues/131819
  - https://github.com/rust-lang/rust/issues/64609
  - https://github.com/rust-lang/rust/issues/89586
- https://github.com/rust-lang/rust/issues/131300
- https://github.com/rust-lang/rust/issues/129893
- `-Cllvm-args` can set all sorts of flags, some of which can [change the ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/-C.20flags.20that.20change.20ABI/near/477359366)

Flags that are sus:
- `-Cno-redzone` [could potentially be a problem](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/stabilizing.20compiler.20flags.20for.20Rust-for-Linux/near/477650067)
- Probably `-Clink-arg(s)` can also do bad shenanigans... but it can't really affect ABI, can it? The ABI is already baked into the object files at this point.

This list might be incomplete!
Repository: pytorch
Issue: auto_functionalized_v2 doesn't support export
Labels: oncall: pt2,oncall: export

When we implemented auto_functionalized_v2, it was easier to add support for it to compile and then worry about export later. Today, export is still using auto_functionalized_v1.

The main delta is that auto_functionalized_v2 supports reinplacing custom ops that mutate inputs, where the inputs may be views of other tensors. It needs a backend (like Inductor) to actually do the reinplacing.

The main thing to do to get auto_functionalized_v2 to work with export is to develop a BC serialization scheme for it. We should do https://github.com/pytorch/pytorch/issues/138220 as a part of that work so that we don't need to break BC in the future when we implement that.



cc @ezyang @chauhang @penguinwu @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4
Repository: terminal
Issue: On keypress or output, openconsole should scroll down like conhost
Labels: Product-Conhost,Area-Interaction,Issue-Bug,In-PR

### Windows Terminal version

1.22.2702.0

### Windows build number

10.0.19045.5011

### Other Software

cmd.exe
bash.exe (wsl1)


### Steps to reproduce

get some output from dir or from ls -alR so that the windows scrolls.
then scroll up
then write anything.
conhost.exe scrolls to the input line. openconsole.exe does not.

also, if a program outputs data while you are "scrolled up", conhost scrolls down.

This is a matter of taste and preference and If I where you I would put a flag in the **Terminal scrolling** section.


### Expected Behavior

Scroll to the last line on keypress or on output.

### Actual Behavior

The scroll stays where it is.

I repeat: this is not a big deal... and it's a matter of taste.. but I would put the flag in the preferences.
Repository: react
Issue: Bug: Uncaught runtime error with 'removeChild' and long lists
Labels: Status: Unconfirmed

React version: 18.3.1

## Steps To Reproduce

1. `$ npx create-react-app my-app`
2. `$ cd my-app`
3. Replace the contents of App.js with the code listed below
4. `$ npm run start`
5. Open the page in Google Chrome or Edge (issue does not reproduce in Firefox/Safari)
6. Click one of the "x" labels
7. Click "hide"

```js
// App.js
import { useState } from 'react';

function App() {
  const [show, setShow] = useState(false);
  return (
    <div>
      {Array(950).fill().map(() => <span onClick={() => setShow(true)} key={`rng_${Math.random()}`}>x</span>)}
      <div>
        {show && (
          <div>
            <button onClick={() => setShow(false)}>Hide</button>
          </div>
        )}
      </div>
    </div>
  );
}

export default App;
```

Link to code example: https://codesandbox.io/p/sandbox/sleepy-resonance-29sgks

## The current behavior
It fails with "Failed to execute 'removeChild on 'Node': [..]"
This error message typically indicates that somebody or something has manipulated the DOM outside of React. However, as you can see in the very small reproducible example, this should not be the case.

I am able to reliably reproduce this on Google Chrome, but **not** Safari or Firefox. I tested on two different computers (both running OSX).
I could reproduce with a project set up with three separate environments; using vite, create-react-app, and inside codesandbox.
I also tried downgrading to react 17.0.2, and same problem there.

If the size of the list is reduced, the crash either stops or does not happen as often.

## The expected behavior
I should be able to re-render components based on state.
Repository: ollama
Issue: add module/plug-in system to ollama
Labels: feature request

llm > go code >  ollama add-on
no ollama recompil but fast evolution without you have more work...
Repository: pytorch
Issue: No guards for frozen dataclasses and readonly configs
Labels: triaged,topic: not user facing,oncall: pt2,module: dynamo,module: guards,dynamo-triage-june2024

### 🚀 The feature, motivation and pitch

Currently, a guard will be put for a frozen dataclass:
```
TORCH_LOGS="+guards" python -c """from dataclasses import dataclass
import torch

@dataclass(frozen=True)
class MyDC:
    x: int

@torch.compile(fullgraph=True)
def func(dc: MyDC, t):
    return dc.x + t

func(MyDC(0), torch.randn(()))
"""
```
gives a guard for
```
V1017 16:30:38.479000 75647 torch/_dynamo/guards.py:2314] [0/0] [__guards] | | +- GuardManager: source=L['dc'].x, accessed_by=GetAttrGuardAccessor(x)
V1017 16:30:38.479000 75647 torch/_dynamo/guards.py:2314] [0/0] [__guards] | | | +- EQUALS_MATCH: L['dc'].x == 0                                                #   # <string>:10 in func
```

This is unnecessary as `dc.x` cannot be changed (`dc` can be guarded but `dc.x` is frozen).

The same would apply for readonly configs from omegaconf (when #138224 is fixed, this code will show guards for x):
```python
import torch
from omegaconf import DictConfig

@torch.compile(fullgraph=True) # this will break currently
def func(dc, t):
    return dc.x + t

cfg = DictConfig({'x': 0}, flags={'readonly': True})
func(cfg, torch.randn(()))
```

### Alternatives

I guess someone could hack their way through a frozen dataclass and that could lead to some errors but is it that much of a risk?

### Additional context

_No response_

cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames @rec
Repository: Python
Issue: Add TSP problem in Graph Data Structure
Labels: enhancement

### Feature description

I will add the Traveling Salesman Problem (TSP) Implementation to the Graph Data Structure file. As it's a must do problem when solving graphs in DS.

Kindly assign this issue to me.
Repository: flutter
Issue: [Impeller] adjustment to DlImageFilter APIs required for coverage computation
Labels: P2,e: impeller,team-engine,triaged-engine

In https://github.com/flutter/engine/pull/55843 I attempted to switch the impeller dispatcher to use the DL mechanism for filter bounds computation. Specifically, using `get_input_device_bounds` transform the coverage limit from the parent coordinate space to the child coordinate space:

There are two current issues with this:

1. This API accepts a Skia 3x3 matrix, while the Impeller canvas stores a 4x4. 
2. This API automatically rounds out the result coverage, whereas we'd like the dispatcher to be able to choose between a RoundOut and a RoundIn

FYI @flar
Repository: PowerToys
Issue: Powertoys not opening & keyboard delayed by 1-2 seconds
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.85.1

### Installation method

PowerToys auto-update, Microsoft Store

### Running as admin

No

### Area(s) with issue?

General

### Steps to reproduce

Not sure

### ✔️ Expected Behavior

Keyboard works properly, and PowerToys settings window opens

### ❌ Actual Behavior

Keyboard is delayed by 1-2 seconds in non-admin apps, and no PowerToys windows open.

### Other Software

Any application not running as Admin
Repository: material-ui
Issue: [Autocomplete] renderInput is using an old api
Labels: component: autocomplete,enhancement

### Steps to reproduce

The props passed through renderInput use the old API InputProps and InputLabelProps.

![image](https://github.com/user-attachments/assets/dcb78273-8ab8-4659-8930-bc8eeca9f13d)
![image](https://github.com/user-attachments/assets/a53ebb02-f39a-4fe4-ba24-24f73d454596)


### Current behavior

_No response_

### Expected behavior

_No response_

### Context

_No response_

### Your environment

<details>
  System:
    OS: Windows 11 10.0.22621
  Binaries:
    Node: 20.17.0 - C:\Program Files\nodejs\node.EXE
    npm: 9.8.1 - C:\Program Files\nodejs\npm.CMD
    pnpm: 9.9.0 - C:\Program Files\nodejs\pnpm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Chromium (127.0.2651.74)
  npmPackages:
    @emotion/react: ^11.11.4 => 11.13.3
    @emotion/styled: ^11.11.5 => 11.13.0
    @mui/icons-material: ^6.1.3 => 6.1.3
    @mui/lab: 6.0.0-beta.11 => 6.0.0-beta.11
    @mui/material: ^6.1.3 => 6.1.3
    @mui/material-nextjs: ^6.1.3 => 6.1.3
    @mui/styled-engine-sc: ^6.1.3 => 6.1.3
    @mui/system: ^6.1.3 => 6.1.3
    @mui/utils: ^6.1.3 => 6.1.3
    @mui/x-data-grid-pro: ^7.20.0 => 7.20.0
    @mui/x-date-pickers: ^7.20.0 => 7.20.0
    @mui/x-date-pickers-pro: ^7.20.0 => 7.20.0
    @mui/x-license: ^7.20.0 => 7.20.0
    @types/react: ^18.2.66 => 18.3.5
    react: ^18.2.0 => 18.3.1
    react-dom: ^18.2.0 => 18.3.1
    typescript: ^5.2.2 => 5.5.4
</details>


**Search keywords**: autocomplete, api
Repository: flutter
Issue: [packages] Scrub Android plugins for pre-API 21 support
Labels: team,platform-android,package,P2,c: tech-debt,team-android,triaged-android

The current stable version of Flutter now requires API 21+, but most of our plugins have not been updated to reflect that, and still support API 19+. We have some tech debt related to older API support, and it would be good to find an clean out proactively (examples we've seen so far include https://github.com/flutter/packages/pull/7876/ and https://github.com/flutter/packages/pull/7874/files#r1802064758, but those are just things we've hit randomly so an audit would almost certainly turn up more)

This would look something like:
- Ensure that all the Android plugin implementation packages require Flutter 3.24+ (already true for many)
- Update them to `minSdkVersion 21` (this should not be a breaking change as long as Flutter itself requires 21, but IIRC `minSdkVersion` *can* trigger behavior changes—although I don't remember if that's true at the level of our setting, or only at the level of the client app building them)
- Update the app-facing package README support table to say 21+ (some are probably quite stale; we don't currently have any checks in CI that these match the implementation package, which is a tracked issue).
- Scrub for any references to `Build.VERSION` that reference `KITKAT` or `LOLLIPOP` to see what's still needed in code.
- Delete or migrate any robolectric tests that reference api 20 or below. Tests that are verifying removed api behavior should be deleted, tests that verify apis work should be migrated. 
- Ideally search any Java/Kotlin code for other references to KitKat, Lollipop, 19, 20, and 21 to try to catch things that aren't specifically `Build` references (like the second example above).