sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Unexpected normals when colliding with Tilemap
Labels: enhancement,discussion,documentation,topic:physics,needs testing,topic:2d

### Tested versions

- Reproduced in 4.3 Dev 5
- Reproduced in 4.2.1 Stable

### System information

Godot v4.2.1.stable - Windows 10.0.19045 - Vulkan (Mobile) - dedicated AMD Radeon RX 6600 XT (Advanced Micro Devices, Inc.; 31.0.22023.1014) - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)

### Issue description

While creating a node to monitor contacts on a CharacterBody2D I've noticed that raycasts that are going downward are sometimes being reported as having a horizontal normal. This should not be possible, the tilemap is a flat surface with many boxes, but with no gaps between the tiles. This happens in every direction, but for simplicity i'll focus on when it happens moving downwards.

I think the raycast is clipping through the corner of one tile, and into the wall of a surrounding tile somehow.

![image](https://github.com/godotengine/godot/assets/4250341/15a1c269-aba5-4835-9409-344c1aeda815)
In the above snippet of the repro project, the white arrows show the general direction of the raycasts.

And on some frames the following normal occurs sometimes. (the direction of the red arrow shows the normal, which shouldn't be possible with a circle colliding on a flat surface.)
![image](https://github.com/godotengine/godot/assets/4250341/8b5567f9-5aa0-4d2f-b075-d201f2f3d01f)

Sorry, wish I could explain it a bit better but I hope the images and project help to realize the issue here.

I've isolated the contact checker script and made a reproduction of the issue.

(Also, is there no way to get contacts for Characterbody2D nodes? It feels like getting contacts on these nodes would be a very common usecase, with no obvious solution. And its even more confusing considering the tilemap tutorial mentions adding data to tiles that would need to be accessed through querying contacts.)

Here is a screenshot of the issue occurring at runtime.
![image](https://github.com/godotengine/godot/assets/4250341/c357aee2-447d-471f-9fba-116129ad1ee3)


### Steps to reproduce

Rub a colliding body against a flat tilemap's surface and shoot a raycast at the colliding points. Occasionally a completely incorrect normal will be reported.

### Minimal reproduction project (MRP)

[reproduction_normalissue.zip](https://github.com/godotengine/godot/files/14814817/reproduction_normalissue.zip)
Repository: ollama
Issue: Support for OpenSUSE Tumbleweed and Leap in installer script
Labels: feature request,linux,install

### What are you trying to do?

To install ollama on OpenSUSE Tumbleweed and Leap.
My laptop has AMD and Nvidia Video Cards.

Adapting the installation script to make the installation work correctly on OpenSUSE as well.
curl -fsSL https://ollama.com/install.sh | sh



### How should we solve this?

To install graphic packages on opensuse as prerequisites.

Adapting the installation script to make the installation work correctly on OpenSUSE as well.

### What is the impact of not solving this?

I had to install the packages manually.

### Anything else?

I used this command to install nvidia-smi: "zypper in nvidia-compute-utils-G06"
Repository: PowerToys
Issue: FancyZones does not resize PotPlayer.
Labels: Issue-Bug,Product-FancyZones,Needs-Triage,Area-App Compat

### Microsoft PowerToys version

0.79.0

### Installation method

GitHub, PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

FancyZones

### Steps to reproduce

1. Install PotPlayer (currently on 240315, issue began before latest update)
2. Try using it with FancyZones (currently on 0.79.0, issue began before latest update)

### ✔️ Expected Behavior

When dragged into another zone, PotPlayer should activate FancyZones, showing the number of the zone it is being dragged to, and resize itself to fit in the zone.

### ❌ Actual Behavior

It is freely movable and resizable within the entire desktop space, as if it is on the exclude list, but it is not.

### Other Software

_No response_
Repository: transformers
Issue: Enhance Generality of Trainer Class
Labels: Feature request

### Feature request

In the current version of the transformers library's Trainer class, the model can only report a total loss during the training and evaluation stages. However, in practical applications, we often wish to observe the changes in different types of loss function values in multi-task learning. For example, we might add a Contrastive loss on top of the MLE loss. I suspect that adding the feature to record different losses could enhance the generality of the code.

### Motivation

Multi-task learning is a common technique for improving model performance and generalization ability. In this case, in order to observe the effectiveness of different objective functions more finely, we need to record other losses apart from the total loss.

### Your contribution

Yes, I can submit a PR.
Repository: godot
Issue: TileMap shows misleading debug visuals for physics shapes
Labels: enhancement,topic:physics,topic:2d

### Tested versions

4.3.dev

### System information

Window 10

### Issue description

Context issues and discussion why I make this issue:
https://github.com/godotengine/godot/issues/89458
https://github.com/godotengine/godot/issues/84163
https://github.com/godotengine/godot-proposals/discussions/9400
https://github.com/godotengine/godot/issues/90067
... and like a few hundred more as at least every day a new one shows up.

TileMap physics debug currently draws
- for every single tile
- for every single physics body of that tile
- for every single collision shape of that body
- a single polygon on the canvas item.

This is very inefficient for performance but while performance is an issue it is not the main issue.

Not giving users the full information is the real issue. An uninformed users can not fix problems in their own project.

Because the TileMap physics debug uses just a flat color for the polygon all adjacent polygons melt visually together.

![317779532-38ea64a7-6461-4140-a99d-55fe01b8cb0b](https://github.com/godotengine/godot/assets/52464204/26e5ac1c-e4dc-40fe-bfc2-90fc4f9d5724)


This creates this misleading situation for users that they think they have created a "perfect" collision shape with tiles.

All they created with tiles is a messy layout full of edge seam problems that causes physics bugs. They only notice this when their shapes get "randomly" stuck on seams or the rays return the wrong surface normals due to internal edge collisions.

Fixing this general seam problem with TileMap will require at lot of work but fixing the debug visuals to not obscure or convey misleading information should be easy to fix. 

Compare to navigation that uses similar shapes as physics.

![nav_mesh](https://github.com/godotengine/godot/assets/52464204/2dc61b66-9859-4261-add6-9751da1914db)


Navigation adds (if default edge lines are enabled in ProjectSettings) an additional polyline around the outline of the shape and it also colorizes all polygons slightly randomly so they are easier to distinguish, especially when they are partly obstructed by other things.



Yes this costs more performance but in my experience for a user to see that a problem happens exactly on a polygon edge or a transition between two seperated polygons is very valuable information for bug fixing. Performance in the editor comes secondary and is its own topic. Add options to toggle the debug and everyone is happy.

So I would suggest to change the physics debug to make it similar to navigation. At least the polygon edges should be visible.

### Steps to reproduce

Turn on TileMap debug visuals for collision.

### Minimal reproduction project (MRP)

N/A
Repository: puppeteer
Issue: [Bug]: Browser.close does not shutdown the process immediately
Labels: bug,upstream,confirmed,P3

### Error string

MaxListenersExceededWarning: Possible EventEmitter memory leak detected.

### Bug behavior

- [X] Flaky
- [ ] PDF

### Background

The code example above is a simplified version of our Lambda function. Basically. we don't do anything tricky, only load the page, giving it reasonable time to load while monitoring the ready state of the page and its source code, and get the data from it.

The crawler works great except sometimes the browser freezes. In most cases, we catch this when closing the browser. We scrape hundreds of thousands of pages and weren't able to make it work reliably reusing the same browser instance, even with periodical restarts. Therefore, we close and open the browser on each crawl.

At some point, it freezes on the `browser.close()` so we had to implement a timeout function and try to kill the process, which doesn't work well. Even after sending the `SIGKILL` signal, the process stays. Probably in a zombie state or just stucks somewhere, I don't know and we have no instruments to investigate. Must be an upstream bug in the chrome itself.

### Expectation

There should be a way to get rid of a faulty process. Disregarding the nature of the failure, we should be able to kill it and start a new one.

### Reality

The fact we're sending SIGKILL and it brings us nowhere tells me the child process is spawned incorrectly and wasn't properly detached from its parent. When something goes wrong, such processes stay as long as their parent, which can take forever as we have no control over Lambda's lifecycle (almost). The only solution I can think of is to call `exit` in the main function, which will forcefully restart the Lambda. Then we handle a faulty response and restart the job.

We started seeing this problem after upgrading to 112+. We are on 122 now but the picture is the same.

<img width="1626" alt="Screenshot 2024-03-31 at 17 22 51" src="https://github.com/puppeteer/puppeteer/assets/126732/2fa0ea68-544e-446b-8295-10465c5bd9c3">

### Puppeteer configuration file (if used)

_No response_

### Puppeteer version

22.4.1

### Node version

20.11.1

### Package manager

npm

### Package manager version

10.2.4

### Operating system

Linux
Repository: neovim
Issue: Autoload not picking up files if `~/.local/share/nvim/site` directory not present at startup
Labels: bug,runtime,has:workaround,startup

### Problem

I use `plug-vim` on neovim and have the plugin recommends the following snippet on the config to automatically install Plug on the first startup: https://github.com/junegunn/vim-plug/issues/1270#issuecomment-2019290236

After reporting, the plugin author found the cause of the issue: https://github.com/junegunn/vim-plug/issues/1270#issuecomment-2019290236

I suggested a workaround by manually sourcing `Plug` after installing it (https://github.com/junegunn/vim-plug/issues/1270) but maybe this is an actual bug in neovim.

### Steps to reproduce

With a fresh install of neovim:
- Add the snippet to automatically install Plug to the `init.lua` file
- Start neovim

### Expected behavior

On first startup, `Plug` should be installed and the `:PlugInstall` command should install all plugins.

Instead the `:PlugInstall` command is not found.

### Neovim version (nvim -v)

v0.9.5

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

no

### Operating system/version

macOS 14.4

### Terminal name/version

tmux 3.4

### $TERM environment variable

screen-256color

### Installation

Homebrew
Repository: vscode
Issue: `${userHome}` in a task command creates bad paths
Labels: bug,tasks

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 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.87.2
- OS Version: Windows_NT x64 10.0.22631

Steps to Reproduce:

1. Create a tasks.json with a task command that looks like this:
```json 
"command": "${userHome}/myfolder/my.exe",
"type": "process"
```
2. The variable works if you set it to be type shell and the default shell is pwsh and not git bash. But if set to type process it results in a path like:
```
/c:/Users/myuser/myfolder/my.exe
```
With an error like: "The terminal process could not be started: The path to the executable shell file "\c:\Users\myuser\myfolder\my.exe" does not exist.

NOTE: The task does work if I use `${env:USERPROFILE}` instead of `${userHome}`, as env:USERPROFILE results in a path like `C:\Users\myuser/myfolder/my.exe` to be executed.
Repository: stable-diffusion-webui
Issue: [Bug]: Error: CUDA error: the launch timed out and was terminated CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect. For debugging consider passing CUDA_LAUNCH_BLOCKING=1. Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.
Labels: bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [ ] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [ ] The issue exists in the current version of the webui
- [ ] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

Error: CUDA error: the launch timed out and was terminated CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect. For debugging consider passing CUDA_LAUNCH_BLOCKING=1. Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

### Steps to reproduce the problem

Error: CUDA error: the launch timed out and was terminated CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect. For debugging consider passing CUDA_LAUNCH_BLOCKING=1. Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

### What should have happened?

Error: CUDA error: the launch timed out and was terminated CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect. For debugging consider passing CUDA_LAUNCH_BLOCKING=1. Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

### What browsers do you use to access the UI ?

Google Chrome

### Sysinfo

Error: CUDA error: the launch timed out and was terminated CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect. For debugging consider passing CUDA_LAUNCH_BLOCKING=1. Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

### Console logs

```Shell
Error: CUDA error: the launch timed out and was terminated CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect. For debugging consider passing CUDA_LAUNCH_BLOCKING=1. Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.
```


### Additional information

Error: CUDA error: the launch timed out and was terminated CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect. For debugging consider passing CUDA_LAUNCH_BLOCKING=1. Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.
Repository: godot
Issue: Camera3D.unproject_offset does not work with FRUSTRUM_PROJECTION projection type.
Labels: bug,topic:rendering,topic:3d

### Tested versions

- Reproducible in 4.x

### System information

Windows 11 - Godot 4.1-stable

### Issue description

Cameras with frustrum projection don't work properly with unproject_offset. I've tried looking around to see if anyone else is having this issue. Unfortunately for me frustrum projection is a kind of obscure feature and I'm using it in doubly obscure ways. The most helpful document I ran into was [Deprecate Camera3D's PROJECTION_FRUSTUM projection mode](https://github.com/godotengine/godot-proposals/issues/8536), which explained some of the known jank. Ideally, I would be using custom projection matrices. For now, I'd be satisfied with just a tip to get the screen position under frustrum projection, but it would be nice if the function worked with frustrum projection out of the box.

### Steps to reproduce

Download the MRP. Launch the test scene and rotate the camera with the arrow keys. If the camera's project is changed to perspective or orthographic, the sprite will be placed over the cube (as long as the cube is on screen, I didn't bother adding checks otherwise for the mrp). In frustrum project though, the sprite gets offset. It appears that unproject_offset is basing it's calculations off of the fov variable, which would line up with the claim from the deprecation request: "None of the code paths in Camera3D actually explicitly handles PROJECTION_FRUSTUM."

### Minimal reproduction project (MRP)

[CameraProjectionTest.zip](https://github.com/godotengine/godot/files/14816963/CameraProjectionTest.zip)
Repository: material-ui
Issue: [colorManipulator] Support the `oklch` color notation
Labels: package: system,customization: css

<img width="500" alt="Screenshot 2024-03-31 at 13 50 16" src="https://github.com/mui/material-ui/assets/67129314/1f00c182-ce37-47a3-a9d5-afe6df1bd210">

I was experimenting with converting the branding theme palette from HEX codes to the `oklch()` notation, but the current version of the MUI System doesn't support it, even though it does already support `color(display-p3...)`. 

I'm also a bit unsure whether this is System or Pigment CSS scope, so I'll leave that open for now. 

Ultimately, this seems like the best color notation to use at the moment[^1], providing the same great readability that HSL has, but supporting the p3 and other color spaces. I'm super interested in converting the website & documentation to use it (and, of course, Material UI v7 should potentially use it as well). I think in the meantime I'll use `color(display-3)`.

[^1]: https://evilmartians.com/chronicles/oklch-in-css-why-quit-rgb-hsl

**Search keywords**: oklch, color notation, p3, wide-gamut
Repository: next.js
Issue: App Router: Application crashes with client-side exeption on dynamic import failure
Labels: bug,Lazy Loading

### Link to the code that reproduces this issue

https://github.com/Txhawks/missing-chunk-error

### To Reproduce

The reproduction imports a `Foo` component using `next/dynamic`. When the network request to `foo.js` fails, the whole app comes down crashing.

1. Navigate to https://missing-chunk-error.vercel.app/
2. In the Network tab in the dev tools, block the request for `201.e0005a340046428d.js`
3. Reload the page, which will result in a `ChunkLoadError: Loading chunk 38 failed.` client-side error.

This isn't limited to Vercel and can be reproduced locally with `next build && next start` as well.

### Current vs. Expected behavior

As explained above, any failure in loading a component with `next/dynamic` causes an error that is entirely irrecoverable in the client, and which crashes the entire app. Even Doing something like this doesn't help:

```tsx
'use client';

import dynamic from "next/dynamic";

let Foo: React.ComponentType = () => null;

try {
  const TempFoo = dynamic(() => import("./foo"), { ssr: false });
  Foo = TempFoo;
}
catch (e) {
  console.error(e);
}

export default function ComponentPicker() {
  return <Foo />;
}
```

Dynamic imports are susceptible to network flaws and causing of an irrecoverable client error for something like this makes applications extremely brittle.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 20.10.0
  npm: 10.2.3
  Yarn: 1.22.19
  pnpm: 8.15.4
Relevant Packages:
  next: 14.2.0-canary.50 // Latest available version is detected (14.2.0-canary.50).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.3
Next.js Config:
  output: N/A
```


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

App Router, Dynamic imports (next/dynamic)

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

next start (local)

### Additional context

I've seen #54008, and this does seem similar, but seems to not be the same. I tried against `13.5.5` which the issue mentions, and it fails in the same way there.
Repository: ollama
Issue: Add additional language translation layers with special model
Labels: feature request,model request

### What are you trying to do?

Many models are very good with specific tasks but they lack support of other languages. Their output in other language than english is very poor.

### How should we solve this?

The input could go first to translation layer with specific model for translation from any language to english,
then the choosen model gets the input in english and outputs in english.
The english output goes through another translation layer to convert from english to any language.

### What is the impact of not solving this?

Only choosing models that work with specifc language (but still these are not perfect).

### Anything else?

This model could be used for translation:
https://huggingface.co/facebook/mbart-large-50-many-to-many-mmt

That would be awesome functionality.
Repository: material-ui
Issue: [colorManipulator] Alpha function not working with the `hsl()` notation
Labels: package: system,customization: css

### Steps to reproduce

StackBlitz repro: https://stackblitz.com/edit/react-ue9j7k-o6j3ve?file=Demo.js (inspect the Checkbox)

### Current behavior

The theme file can receive colors in many formats, including `hsl()` and `hsla()`, and the System's `alpha()` function should be able to modify the alpha channel for all of them. That doesn't seem to be the case with `hsl()` at the moment. If my color shade is defined like this in the theme:

```jsx
const blue = {
  main: 'hsl(210 20 10)',
};
```
And I use the `alpha()` function like so:
```jsx
bgcolor: alpha(theme.palette.primary.main, 0.2)
```
I see this on the dev tools:
```css
background-color: hsla(210, undefined%, undefined%, 0.2)
```

### Expected behavior

I would expect the `alpha()` function to work the same as it does with HEX color values or even `color(display-p3)`.

### Context

I want to define all of the branding theme colors in HSL, a much easier to read/manipulate color notation, instead of HEX codes.

**Search keywords**: color manipulator, alpha function, hsl
Repository: storybook
Issue: [Bug]: Embedding story is not working in version 8
Labels: bug,needs triage

### Describe the bug

If you check this documentation page: https://storybook.js.org/docs/sharing/embed, and select version 8, the embedded stories are not showing. But, it is working on version 7.6

### To Reproduce

1. Just embed story with url format based on documentation https://storybook.js.org/docs/sharing/embed


### System

```bash
Storybook 8.0.0
```


### Additional context

_No response_