sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: tensorflow
Issue: check failed: !PyErr_Occurred() when constructing two uint64 tensors
Labels: stat:awaiting tensorflower,type:bug,comp:eager,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?

When running the following code, tensorflow will directly raise program abort with the error message: `./tensorflow/python/eager/pywrap_tensor_conversion.h:58] Check failed: !PyErr_Occurred()`

```
import os
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '3'
os.environ['CUDA_VISIBLE_DEVICES'] = ''
import warnings
warnings.filterwarnings("ignore")
import tensorflow as tf

lower1 = -1
try:
    lower1 = tf.constant(lower1, dtype='uint64')
except:
    ...
lower2 = -2
lower2 = tf.constant(lower2, dtype='uint64')
```

It seems the problem occurs when TensorFlow tries to construct **two uint64 tensors**. Although it is invalid to convert negative int to unsigned, an exception is more proper as program abort will directly kill the process.

Indeed, only constructing one uint64 tensor will properly raises an OverFlow exception. 
This issue only occurs when repeatedly constructing two uint64 tensors.
Another weird thing is that, **if I change the value of `lower2` to either `-1` or `-3` instead of `-2`**, this issue does not occur.


### Standalone code to reproduce the issue

```shell
import os
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '3'
os.environ['CUDA_VISIBLE_DEVICES'] = ''
import warnings
warnings.filterwarnings("ignore")
import tensorflow as tf

lower1 = -1
try:
    lower1 = tf.constant(lower1, dtype='uint64')
except:
    ...
lower2 = -2
lower2 = tf.constant(lower2, dtype='uint64')
```
```


### Relevant log output

```shell
F ./tensorflow/python/eager/pywrap_tensor_conversion.h:58] Check failed: !PyErr_Occurred() 
Aborted (core dumped)
```
Repository: bitcoin
Issue: Increasing self-hosted runner raw performance
Labels: Brainstorming

_disclaimer_: The following should **not** replace us investigating and fixing the root causes of timeouts and intermittent test runtime performance.

Now seems an opportune time to open a discussion on some investigation I have been doing into our self-hosted runners, as our CI has been struggling again recently.

I wanted to see what the cost/benefit implications would be on upgrading our self-hosted runners would look like. Hooking up a single [Hetzner AX52](https://www.hetzner.com/dedicated-rootserver/ax52/) (70 €/month) as a self-hosted runner saw each job run on average 3-5x faster (result image shown at end), which is not surprising in itself.

IIUC correctly we currently have about 25 low powered, shared vCPU x86_64 runners (plus a sprinkling of ARM ones). If we had the appetite, and could find the funding, we might consider:

1. upgrade the x86_64 runners to 12 dedicated CPU servers. At 70€ this would total 840€ per month, or 10080€ per year, vs current spend of ~3840€, so 2.5x more cost for 3-5x more speed. This feels like a decent return.

alternatively

2. Bump our current (shared vCPU) runners to the next "level" up. If e.g. [these](https://github.com/maflcko/bitcoin-core-qa-assets/wiki/Persistent-workers#set-up-servers) are the runners in use for us today, we could increment the CPX21s to CPX31s, and the CPX31s to CPX41s for a monthly cost of 505.6€ vs a current spend of 320€. I did not test performance gains of this path.

We could also" just spend more" buying larger numbers of the same (low-powered) runners, but IMO this would not be as effective as reducing the runtime of CI jobs, and eliminating CI run timeouts. Moving away from vCPUs feels like the correct choice, if we can, as it's possible that random contention on these could contribute to "random" timeouts and failures.

Additional thoughts in no particular order:

- I have likely not considered all the benefits of having larger numbers of lower powered runners. Comments welcomed on this.
  - These more powerful runners also (all) come with (some) more disk space, so we could potentially do things like configure total ccache size (across all jobs) to be something like 100's of GB, and try and maximize those cache hits!
- I am not sure what the developer tradeoff is for "CI startup time" (i.e. when a job is picked up by a runner) vs "CI runtime".
- Shold we employ a more scientific approach, which could be to caclulate total compute/€ and just get whatever wins out by that metric.

I'd be curious to hear thoughts on whether this is something worth us looking at any further, or if folks have investigated this before and what they found.

#### AX52 test

1. A typical CI run using current runners (on a good day):

![image](https://github.com/user-attachments/assets/d90bae58-0a96-460c-ad5d-210b1f9278c5)

2. Jobs run using a single AX52 runner:

![image](https://github.com/user-attachments/assets/60c7a80a-9e80-49c3-93b1-81f1e10bb6e2)
Repository: TypeScript
Issue: Removing optional modifier in homomorphic mapped types does not work in generic contexts since 5.5.x
Labels: Bug,Fix Available

### 🔎 Search Terms

optional modifier, required fields, generic, NonNullable, strictNullChecks, homomorphic mapped types

### 🕗 Version & Regression Information

- This changed between versions 5.4.5 and 5.5.2
- This changed in commit or PR e418f8d12c5f1b6c10fc3127764f34dad44d4586 (as reported by `every-ts`)


### ⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.5.4#code/MYewdgzgLgBApgDwIYFsAOAbOMC8MA8AKvAlHGACYQzQBOAlmAOYB8AFAJQBcMSYAnrhYwA3gCgYMAPRSYAJTiYkwRkxgB3elAAWvATTRwVAM3rAaAVwBGAWij9DMEMZgADOqtcwUSANZxqHWx7Q2pQWlojWCQmJEYAOglpWRDsYjwPZgBuMSTUmABlEBQ4AHk0KHpwJAxcURgAbX9BRhhCAF0Afh4ARhgAXxzJPIdsAEEMDAUARwt6SIo6kUbmmFbm50LisoqqsBr2m26YPsHcyXyZuYWANRqLALqJqbhZ+bgKJrh+Teer94o7RySRkMAAwsUlIxqK0AKzxAAs8QQABoYFYLLBTGBsHD4vCEElQJBYAgeP9bvdHngLJQ4NiPucYJEoBZaGAYAgcoMgA

### 💻 Code

```ts
const example = <T extends string>(): any => {
  // Replacing with any specific sub-type of `string` makes the types correct again.
  // type T = string;

  type SomeOptional = { [key in T]?: 1 };
  
  type AllRequired = { [key in keyof SomeOptional]-?: 1 };

  type RequiredValues = AllRequired[keyof AllRequired];

  // Complains in 5.4.x, but fine in 5.5.x
  const x: RequiredValues = undefined

  return x;
};
```

### 🙁 Actual behavior

Using `-?` leaves the fields marked as optional, and taking the values of the resulting type gives a union with `undefined`.

### 🙂 Expected behavior

Using `-?` makes all fields required, and taking the values of the resulting type gives a union of field types.

### Additional information about the issue

Requires a `--strictNullChecks`  flag.

Replacing `keyof SomeOptional` with `NonNullable<keyof SomeOptional>` or `keyof SomeOptional as keyof SomeOptional` fixes the issue. It looks like this problem is limited to homomorphic mapped types.

Using `Required<{ [P in keyof SomeOptional]: 1; }>` in place of `{ [key in keyof SomeOptional]-?: 1 }` results in the same behaviour.
Repository: terminal
Issue: ColorTool.exe -c results in a misaligned chart  
Labels: Product-Colortool,Issue-Bug,Area-UserInterface

### Windows Terminal version

1.20.11781.0

### Windows build number

10.0.19045.4780

### Other Software

TCC v31.01.15 x64 command line

### Steps to reproduce

Run ```ColorTool.exe -c``` to display the color chart

![image](https://github.com/user-attachments/assets/af4880b4-2900-4469-85fa-83a28dc38fd9)


### Expected Behavior

A properly-aligned table

### Actual Behavior

This [see image]:
![image](https://github.com/user-attachments/assets/3857b26c-3cfc-44fa-960d-791336eeceda)

It was possible to fix the alignment with ```sed```:
![image](https://github.com/user-attachments/assets/b6561f08-04c6-4dd4-a6cd-c827b1dd241a)

...but not in such a way that preserved the ANSI colors, which is the whole point of displaying this table.

I tried redirecting the output to a file so I could maybe fix it in postprocessing, but ```ColorTool.exe``` seems to detect if it is being redirected or piped, and the output has no color!!  Perhaps ```ColorTool``` uses direct screen writes for changing colors, so they don't appear in a way that can be captured by redirect/pipe.

![image](https://github.com/user-attachments/assets/c0b22907-6162-4d39-bbc1-f771f75c09ab)


If this chart would align properly, I'd have never fallen into the ```sed``` {and ```perl```} holes in trying to fix this 😂
Repository: PowerToys
Issue: workspaces show screen number on screen image at top of editor
Labels: Issue-Bug,Needs-Triage,Needs-Team-Response,Product-Workspaces

### Microsoft PowerToys version

0.84.0

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Workspaces

### Steps to reproduce

create a workspace with 3 screens, I have a laptop connected to two additional monitors via a docking station.   I also use duet and have a monitor on my ipad but have not really tested/used that with workspaces.

place several apps on the monitors and save the workspace.

launch the editor, you can see the screens at the top but there is no indication as to what screen number they are.

![image](https://github.com/user-attachments/assets/90d3798d-7b6a-46e2-a7c4-689c8aad67b9)

Additionally it would be more consistent if the screen numbers where the same as what is shown in system/display.  (not a requirement just icing on the cake.

![image](https://github.com/user-attachments/assets/3262192c-071e-4b3f-8657-8aa460eb270b)



### ✔️ Expected Behavior

to see screen numbers under or above the images at the top of the editor

### ❌ Actual Behavior

no indication as to which image is which screen.

### Other Software

_No response_
Repository: PowerToys
Issue: I hope you can add the auto-hide desktop icon function.
Labels: Needs-Triage

### Description of the new feature / enhancement

![image](https://github.com/user-attachments/assets/e7c8130f-060e-4b67-8bdd-564b06e46808)

### Scenario when this would be used?

It's all about improving the aesthetic customization of the system desktop

### Supporting information

![image](https://github.com/user-attachments/assets/af895cd9-d3c6-498b-87dc-e1f10dbd2ce9)
Repository: tauri
Issue: [feat] window.alert api should work within iframes in mac
Labels: type: feature request,platform: macOS

### Describe the problem

`window.alert`, `prompt` and `confirm` APIs wont work in iframe in macos. It works in webkit in linux though.

### Describe the solution you'd like

The apis should work in all platforms as expected.

This was fixed in windows, wors as expected in Linux.

### Alternatives considered

_No response_

### Additional context

More details can be found here: 
https://discord.com/channels/616186924390023171/1258736272814374964

from @FabianLars 

> Hmm, it's probably just macos being stricter again as always. There are 3 obj-c callbacks (for alert [here](https://developer.apple.com/documentation/webkit/wkuidelegate/1537406-webview)) we should be able to use to overwrite the behavior / expose a callback to the devs.
> With the current semi feature freeze due to RC i doubt we can get it in for 2.0.0 but should be possible soon after.
Repository: PowerToys
Issue: PowerToys Workspaces: do not resize window more than it allows, if the window has size limits (KeePass 2)
Labels: Issue-Bug,Needs-Triage,Product-Workspaces

### Microsoft PowerToys version

0.84.0

### Installation method

Microsoft Store

### Running as admin

No

### Area(s) with issue?

Workspaces

### Steps to reproduce

Prerequisites:
- Have [KeePass 2](https://keepass.info/download.html) installed;
- Create/open and save password database with password protection;
- Create a PowerToys Workspace with KeePass window captured in it, save workspace;
- Close KeePass from system tray.

Reproduction steps:
1. Run Workspace with KeePass window included.

### ✔️ Expected Behavior

1. PowerToys Workspaces should not resize window if it does not allow this to use;
2. Such a window with size restrictions should be placed at center of app's window that supposed to be here.

<details><summary>Details</summary>
<p>

![2024-09-09_17-17-17](https://github.com/user-attachments/assets/e0f99264-763f-4fe9-8a84-62d5cccebb6f)

</p>
</details> 

### ❌ Actual Behavior

1. Firstly, KeePass spawns password protection dialog box instead of the main window:
<details><summary>Details</summary>
<p>

![2024-09-09_17-16-57](https://github.com/user-attachments/assets/38ef9c16-ec6a-41d8-98bc-368a659b5671)

</p>
</details> 

2. See the window is resized despite the fact this dialog box does not allow user to do so;

3. After entering password, KeePass window appears normally.

### Other Software

- Windows 11 23H2;
- Three Full HD 27" monitors;
- KeePass app at the center one.

<details><summary>Details</summary>
<p>

![2024-09-09_17-34-22](https://github.com/user-attachments/assets/9d70c745-45a3-4539-b518-bc6f513636c9)

</p>
</details>
Repository: PowerToys
Issue: Issue with FancyZones screen assignment
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.84.0

### Installation method

GitHub, PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

FancyZones

### Steps to reproduce

I work from home part of my weeks, as well as in the office for the rest of the week. I have 2 different monitor setups in both locations. In the office I have 3 identical monitors (that I'm sure to plug into the same display outs from my computer every time), while at home I have a single super ultrawide. 
I mention this because the issue that I'm having relates to the behavior that I see when switching back to my work setup after being at home. The layouts that I have assigned to a per-monitor basis always seem to either unassign themselves or assign the correct layouts to the incorrect screens.
I have other issues with my monitors (unrelated to PowerToys) that come up every time I come back to my work setup. Because of that I wouldn't think much of this issue here as well if it weren't for the fact that this used to work flawlessly before the update prior to this most current one.
Sorry I didn't add any screenshots, but I've already corrected the issue by reassigning the layouts, and anyone looking into this wouldn't know that the layouts were assigned to the wrong screens anyway.

### ✔️ Expected Behavior

I was expecting the layouts to assign themselves back to the monitors in which they were assigned before my move to and from home.

### ❌ Actual Behavior

The layouts either apply the correct layouts to the incorrect monitors, or are assigned some random layout. Typically they're the former behavior.

### Other Software

_No response_
Repository: ui
Issue: [bug]: inferred type of 'MenubarMenu' cannot be named without a reference
Labels: bug

### Describe the bug

`next build` gives the following error:

```
   Checking validity of types  .../src/components/ui/menubar.tsx:13:7
Type error: The inferred type of 'MenubarMenu' cannot be named without a reference to '.pnpm/@radix-ui+react-context@1.1.0_react@19.0.0-rc-a03254bc-20240905_types-react@19.0.0-rc.0/node_modules/@radix-ui/react-context'. This is likely not portable. A type annotation is necessary.

  11 | import { cn } from "@/lib/utils"
  12 |
> 13 | const MenubarMenu = MenubarPrimitive.Menu
     |       ^
  14 |
  15 | const MenubarGroup = MenubarPrimitive.Group
  16 |
```

### Affected component/components

MenuBar

### How to reproduce

1. execute 'next build'

### Codesandbox/StackBlitz link

_No response_

### Logs

```bash
Checking validity of types  .../src/components/ui/menubar.tsx:13:7
Type error: The inferred type of 'MenubarMenu' cannot be named without a reference to '.pnpm/@radix-ui+react-context@1.1.0_react@19.0.0-rc-a03254bc-20240905_types-react@19.0.0-rc.0/node_modules/@radix-ui/react-context'. This is likely not portable. A type annotation is necessary.

  11 | import { cn } from "@/lib/utils"
  12 |
> 13 | const MenubarMenu = MenubarPrimitive.Menu
     |       ^
  14 |
  15 | const MenubarGroup = MenubarPrimitive.Group
  16 |
```


### System Info

```bash
Node.js v22.8.0

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.0.0: Sat Jul 13 00:54:59 PDT 2024; root:xnu-11215.0.165.0.4~50/RELEASE_ARM64_T6031
  Available memory (MB): 131072
  Available CPU cores: 16
Binaries:
  Node: 22.8.0
  npm: 10.8.2
  Yarn: N/A
  pnpm: 9.9.0
Relevant Packages:
  next: 15.0.0-canary.146 // Latest available version is detected (15.0.0-canary.146).
  eslint-config-next: N/A
  react: 19.0.0-rc-a03254bc-20240905
  react-dom: 19.0.0-rc-a03254bc-20240905
  typescript: 5.5.4
Next.js Config:
  output: N/A
```
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: vscode
Issue: Notebook Diff Editor layout issues when cells have a horizontal scrollbar
Labels: bug,notebook-diff

When viewing diff of a notebook that contains cells with a horizontal scrollbar, the height of the editor calculated is incorrect.
We do not take the height of the scrollbar into account.
As a result the layout shifts causing poor ux

Q. Can we determine whether a scrollbar will be displayed
Q. Can we reserve a height for the editor even if scrollbar isn't displayed (resulting in the same height regardless of whether its displayed or not)
Repository: pytorch
Issue: Sympy bottleneck in eval_relation/assumptions getit
Labels: triaged,oncall: pt2,module: dynamic shapes,module: startup-tracing-compile

### 🐛 Describe the bug

![image](https://github.com/user-attachments/assets/fb402317-bc69-4885-9312-14bb810ccf9b)

Steps to reproduce:
1. Check out PyTorch and build at branch 'sympy-bottleneck-repro'
2. Check out torchrec at a reasonably recent version (I use caf0441a17d00eb326b15e1de48a72909e933b24)
3. Check out FBGEMM at https://github.com/pytorch/FBGEMM/pull/2967 or recent version (since my fix PR was landed). Build it in the directory `fbgemm_gpu`.

To repro the graph above, run:

```
time TORCH_COMPILE_CPROFILE=1 python torchrec/distributed/tests/test_pt2_multiprocess.py --num-features 300
```

You might also consider running without TORCH_COMPILE_CPROFILE=1 if you think cprofile is distorting the cost of lots of small Python calls.

### Versions

main

cc @chauhang @penguinwu @oulgen @jamesjwu @aorenste @anijain2305 @laithsakka
Repository: godot
Issue: Controller name returned on macOS does not match other platforms
Labels: platform:macos,needs testing,topic:input

### Tested versions

- Reproducible in 4.3. Introduced with commit [07313a08f41146e30005acfa784bdf005d23750b](https://github.com/godotengine/godot/commit/07313a08f41146e30005acfa784bdf005d23750b) 

### System information

Godot v4.3.stable - macOS 14.6.1 - Vulkan (Forward+) - integrated Apple M1 Max - Apple M1 Max (10 Threads)

### Issue description

With the switch to using GCController, the controller name returned no longer matches other platforms. For instance, "PS5 Controller" becomes "DualSense Wireless Controller". This causes a problem when using this value in GDScript to determine controller icon sets across platforms: checking for an additional value on Mac doesn't seem to be a robust solution.

Unfortunately, there doesn't seem to be a way to associate an IOHIDDevice with GCController: so a robust code solution doesn't appear to be possible. SDL works around this by doing string compares and translating the GCController vendorId to the original ids (eg. 0x0ce6 (PS5 controller) 0x054c (Sony)). What I wonder is - should the same thing be done in Godot, or should the differences be handled in the game code? 

_Some notes_:

This is an entry point to seeing how SDL handles this:

https://github.com/libsdl-org/SDL/blob/6e885d96193a4b0096fe7fed6d4e6c3e5f247283/src/joystick/apple/SDL_mfijoystick.m#L387

Here's a stack overflow detailing how you could tell if a IOHIDDevice would be handled by GCController, but I was unable to get the method mentioned to get a valid vendor or product id. I suspect the underlying API has changed, and this is not part of the exposed interface anyway - so even it worked, I suspect it might be risky from an app store review perspective.

https://stackoverflow.com/questions/33509296/supporting-both-gccontroller-and-iohiddeviceref


 

### Steps to reproduce

Use `var controller_name := Input.get_joy_name(device)`, and compare the results from other platforms with that on macOS.

### Minimal reproduction project (MRP)

It's really just the returned value from `Input.get_joy_name(device)`.
Repository: terminal
Issue: Restoring exited panes should not restart them
Labels: Area-TerminalControl,Product-Terminal,Issue-Task

# Description of the new feature/enhancement

* Have session persistence enabled
* Have a pane that has exited but wasn't closed, because the termination behavior is "never", etc.
* Restart Windows Terminal
* Suddenly all those tabs are running again

We should avoid restarting such tabs.

# Proposed technical implementation details (optional)

The state.json should store whether a pane has exited. If it had then it should not restart it automatically.
Repository: ui
Issue: [feat]: Docs on Custom themes / components for CLI
Labels: area: request

### Feature description

As mentioned in https://x.com/shadcn/status/1831771732690215413, you can have your own registry to distribute custom themes or components.

I have looked at the code and can reverse engineer how we might be able to do this ourselves, but it's not clear exactly what all is required for setup. I see that it's all JSON files in the registry which turn into code, but some things like https://ui.shadcn.com/r/styles/default/toast.json have ```import type {\n  ToastActionElement,\n  ToastProps,\n} from \"@/registry/default/ui/toast\"``` which that `registry/default` seems to be substituted at runtime.

Additionally, it's not clear what the side effects are of each ItemType (https://github.com/shadcn-ui/ui/blob/078dfe66072c4ca780bbc99d4ad4b13b1f44fe7e/apps/www/registry/schema.ts#L16-L26).

It would be nice to have a more curated set of documentation which explained how folks can use this to write their own registries and use the shadcn cli to distribute their own code. Simple examples like https://raw.githubusercontent.com/mindtown-ai/dynamic-prompt/main/schema.json make sense, but not when intra-registry components start to come in to play.

### Affected component/components

_No response_

### Additional Context

Additional details here...

### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues and PRs