sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [docs-infra] Fix light/dark mode & RTL change speed regression
Labels: bug 🐛,performance,priority: important,regression,scope: docs-infra

### Steps to reproduce

The light/dark mode and RTL toggle is today x4 slower? than what good enough is at in production, and the RTL/LTR toggle in dev mode is x5-50 slower than what good enough is at? It used to be ok-ish:

## v4.12.4 - Dev: mode ~600ms, RTL: ~600ms, Prod: mode and RTL [~150ms](https://v4.mui.com/components/buttons/)

<img width="968" alt="v4 dark" src="https://github.com/user-attachments/assets/7a8f19cb-cf4a-412c-b97a-a7d7a37a2373">

## v5.0.6 - Dev: mode ~1,369ms, RTL, ~10,865ms, Prod: mode and RTL [~200ms](https://v5-0-6.mui.com/components/buttons/)

## v6.1.8 - Dev: mode ~2,253ms, RTL ~ 59,761ms, Prod: mode and RTL [~800ms](https://mui.com/material-ui/react-button/)

Material UI doesn't feel like a credible option for developers with this performance.

### Context

Same problem as #41117. Material UI is not usable like this, not truly. I mean, as a developer, this reinforces this story: I would only adopt Material UI for a new React project so that I can then contribute a fix to this. Otherwise, I wouldn't want to touch Material UI, there are better options out there nowadays, and it would only make sense to use the rich components of MUI anytime I can't find anything better.

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
```
</details>

cc @romgrk as related to performance on styled engine.
Repository: godot
Issue: CPUParticles2D with scale max or min as a non-one number, align Y axis flag on, damping maximum set to a non-zero number, and gravity set to any value below the damping max causes particles to scale up exponentially
Labels: bug,topic:2d,topic:particles

### Tested versions

- Reproducible in 4.0.stable, 4.3.stable, 4.4.dev5

### System information

Windows 10.0.19045 - Vulkan (Forward+) - integrated Intel(R) Iris(R) Xe Graphics (Intel Corporation; 32.0.101.6078) - 13th Gen Intel(R) Core(TM) i5-1340P (16 Threads)

### Issue description

This is a very weird and niche bug I encountered when messing with particle systems. Not setting any one of the flags mentioned in the title will make the problem disappear, but setting all as mentioned causes the particles to unexpectedly rapidly scale up to massive sizes, often larger than the furthest zoom-out can see. This can all be done in the editor. I expected this to cause the initial velocity of the particles to dampen, slowing them from fast to stopped, and I had the minimum and maximum scale flags set higher than 1 to vary the particle size.

### Steps to reproduce

1. Create a new scene
2. Add a CPUParticles2D node
3. Set Particle Flags > Align Y to on
4. Set damping maximum to a non-zero positive number
5. Set scale maximum to a positive number higher than one (or scale minimum to a positive number lower than one, this will cause particles to scale down exponentially, essentially the opposite effect as described in the title)
6. Set X or Y gravity to a px/s number lower than the damping maximum. (Setting both also has an odd effect)

### Minimal reproduction project (MRP)

[project.zip](https://github.com/user-attachments/files/17894381/project.zip)
Repository: svelte
Issue: Using Vite inline styles causes hydration mismatch errors
Labels: bug

### Describe the bug

When using a CSS import with `?inline` in the URL and including it in the page using a `svelte:element` tag (to force a specific CSS file to be inlined in the page), a hydration error is created in Svelte 5 that did not exist in Svelte 4. This breaks the CSS, as the page hydration stops (the MRE doesn't significantly change as it's too minimal, but in the site I'm actually building, the styles mess up entirely!).

This appears to happen because the `svelte:element` node has no defined previous or next siblings.



### Reproduction

[See MRE repo](https://github.com/mashedkeyboard/test-hydration-inline-import) - it's essentially just this file:
https://github.com/mashedkeyboard/test-hydration-inline-import/blob/main/src/routes/%2Bpage.svelte

### Logs

No notable content in server console. Browser console as below:

```
Navigated to http://localhost:5173/
[vite] connecting... [client:495:8](http://localhost:5173/@vite/client)
[vite] connected. [client:614:14](http://localhost:5173/@vite/client)
Source map error: No sources are declared in this source map.
Resource URL: http://localhost:5173/node_modules/.vite/deps/chunk-UGBVNEQM.js?v=f8c6c012
Source Map URL: chunk-UGBVNEQM.js.map

Source map error: No sources are declared in this source map.
Resource URL: http://localhost:5173/node_modules/.vite/deps/svelte_legacy.js?v=f8c6c012
Source Map URL: svelte_legacy.js.map

Source map error: No sources are declared in this source map.
Resource URL: http://localhost:5173/node_modules/.vite/deps/svelte_internal_client.js?v=f8c6c012
Source Map URL: svelte_internal_client.js.map

Source map error: No sources are declared in this source map.
Resource URL: http://localhost:5173/node_modules/.vite/deps/svelte.js?v=f8c6c012
Source Map URL: svelte.js.map

[svelte] hydration_mismatch
Hydration failed because the initial UI does not match what was rendered on the server [client.js:2684:15](http://localhost:5173/node_modules/@sveltejs/kit/src/runtime/client/client.js?v=f8c6c012)
```


### System Info

```shell
System:
    OS: Linux 6.1 Manjaro Linux
    CPU: (12) x64 AMD Ryzen 5 3600X 6-Core Processor
    Memory: 6.13 GB / 31.29 GB
    Container: Yes
    Shell: 3.7.1 - /bin/fish
  Binaries:
    Node: 18.20.4 - /bin/node
    Yarn: 1.22.22 - /bin/yarn
    npm: 10.8.3 - /bin/npm
    pnpm: 8.7.5 - ~/.local/share/nvm/v18.12.0/bin/pnpm
  Browsers:
    Chrome: Linux
    Chromium: 131.0.6778.69
  npmPackages:
    svelte: ^5.0.0 => 5.2.7
```


### Severity

blocking an upgrade
Repository: tauri
Issue: [bug] plugin: event.emit_to freezing app - because it's never get a response
Labels: type: bug,status: needs triage

### Describe the bug

I have a APP with a Main WebViewWindow and a Backend WebViewWindow (hidden).

When ever I send a emit_to from or to the Backend the Main WebViewWindow will unresponsive.

![Screenshot 2024-11-24 204331](https://github.com/user-attachments/assets/2929f160-94d5-4538-8760-7f2ec93f136f)
![Screenshot 2024-11-24 204350](https://github.com/user-attachments/assets/06497ee1-3344-41dd-91d1-a67e105895bd)
![Screenshot 2024-11-24 204309](https://github.com/user-attachments/assets/00533abe-e8c2-4e60-bfb5-a19c563179f8)


### Reproduction

A main window, sends a Job to the backend window. This will report its progress - sometimes very fast...

### Expected behavior

No freezing WebViewWindows....

### Full `tauri info` output

```text
pnpm run tauri info

> deeprsnest@1.0.0 tauri C:\data\DeepRsNest
> tauri "info"

WARNING: Only one package manager should be used, but found bun and pnpm.
         Please remove unused package manager lock files, will use bun for now!

[✔] Environment
    - OS: Windows 10.0.26100 x86_64 (X64)
    ✔ WebView2: 131.0.2903.63
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.82.0 (f6e511eec 2024-10-15)
    ✔ cargo: 1.82.0 (8f40fc59f 2024-08-21)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 20.18.0
    - pnpm: 9.13.2
    - npm: 10.9.0
    - bun: 1.1.34

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - @tauri-apps/api : 2.1.1
    - @tauri-apps/cli : 2.1.0

[-] Plugins
    - tauri-plugin-stronghold 🦀: 2.0.1
    - @tauri-apps/plugin-stronghold : 2.0.0
    - tauri-plugin-updater 🦀: 2.0.2
    - @tauri-apps/plugin-updater : 2.0.0
    - tauri-plugin-process 🦀: 2.0.1
    - @tauri-apps/plugin-process : 2.0.0
    - tauri-plugin-upload 🦀: 2.1.0
    - @tauri-apps/plugin-upload : 2.1.0
    - tauri-plugin-fs 🦀: 2.0.3
    - @tauri-apps/plugin-fs : 2.0.2
    - tauri-plugin-store 🦀: 2.1.0
    - @tauri-apps/plugin-store : 2.1.0
    - tauri-plugin-dialog 🦀: 2.0.3
    - @tauri-apps/plugin-dialog : 2.0.1
    - tauri-plugin-log 🦀: 2.0.2
    - @tauri-apps/plugin-log : 2.0.0
    - tauri-plugin-http 🦀: 2.0.3
    - @tauri-apps/plugin-http : 2.0.1
    - tauri-plugin-os 🦀: 2.0.1
    - @tauri-apps/plugin-os : 2.0.0
    - tauri-plugin-single-instance 🦀: 2.0.1
    - @tauri-apps/plugin-single-instance : not installed!

[-] App
    - build-type: bundle
    - CSP: default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'; connect-src ipc: http://ipc.localhost
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: SolidJS
    - bundler: Vite
```


### Stack trace

```text
no stacktrace available in console....
```


### Additional context

_No response_
Repository: ollama
Issue: Feature request : Do not update ollama when OS is on limited data connextion
Labels: feature request

Ollama is  a big software ( almost 1GB ) , when windows is on a limited internet connection ( I dont know if same option is available on other OSs)  , do not update , or at least prompt for updating.
Repository: godot
Issue: Using change_scene_to_file during a Node's _init causes the previous scene's Nodes to be created in the new scene
Labels: bug,discussion,topic:core,needs testing

### Tested versions

4.3.dev5

### System information

Godot v4.4.dev5 - Windows 10.0.26100 - Multi-window, 2 monitors - OpenGL 3 (Compatibility) - AMD Radeon RX 6700 XT (Advanced Micro Devices, Inc.; 32.0.12019.1028) - Intel(R) Core(TM) i5-9600K CPU @ 3.70GHz (6 threads)

### Issue description

Changing the current scene in a node's _init will make the Engine create the remaining Nodes in the new scene that was changed to.
https://imgur.com/a/h2MsqV9

### Steps to reproduce

See Video

1. Create Scene with script that changes the current scene in _init and with sub-nodes
2. Observe issue

### Minimal reproduction project (MRP)

[99651.zip](https://github.com/user-attachments/files/17952724/99651.zip)
Repository: neovim
Issue: allow zero-width WinSeparator, for extra horizontal space
Labels: enhancement,ui,display,options

### Problem

On my laptop I never have enough horizontal width. I'd like to remove vertical separator character used for `:vsplit`.

I'd imagine this might be useful for other separators, but I just care about `vert`.

I tried setting it to nothing with:
```
:set fillchars+=vert:
```
but get the error:
```
E1511: Wrong number of characters for field "vert:" fillchars+=vert:
```

### Expected behavior

Allow removing the separator with something like `:set fillchars+=vert:`. Or maybe `:set fillchars+=vert:<NULL>` to disambiguate it from being unset and/or the default value.
Repository: go
Issue: proposal: utf8: add ErrInvalid
Labels: Proposal

### Proposal Details

I propose the addition of the following sentinel error to the `utf8` package:
```go
// ErrInvalid indicates that invalid UTF-8 was encountered within a text string.
// Packages that return this error should usually wrap this error value within
// some local error type to provide further semantic context regarding where
// this error occurred.
var ErrInvalid = errors.New("invalid UTF-8")
```

Many higher-level formats are built on top of UTF-8 (e.g., XML, JSON, protobuf, etc.) where encountering an UTF-8 encoding problem is a possibility. In many cases such an error is not fatal and processing can still continue such that a function that returns a typical `(T, error)` result may provide a sensible while also returning an error that matches `utf8.ErrInvalid`. Even if it is fatal, it is often useful for metrics reporting purposes to specially identify invalid UTF-8 as a particular class of errors.

This could replace internal error values used by the "encoding/json/v2" prototype and also within the protobuf module (e.g., golang/protobuf#1228).
Repository: react
Issue: [Compiler Bug]: ESLint Compiler rules do not allow writing to external variable from effect-called function
Labels: Type: Bug,Status: Unconfirmed,Component: Optimizing Compiler

### What kind of issue is this?

- [ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [X] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhASwLYAcIwC4AEwBUYCAogGaUJyEC+BlMEGBAOiDAgIZ2cBudgDsRCAB458BACYJKPKABtClKMLpoIwggEEAFAEoiIgiTJUadfUYIBeAHwmdZgjyNCX9ADQEA2gC6hp6mBAD0YQQAkpQEAJ7QBBgQAG4IBHgAFmhgTOqa2gQARvK46ZykFNS0eJy+WekIMCwwBADmEAi5PADuPHEAdKFqGnhaOu7GwKFmPWjCMhA9A+L2HCAAjIKh9CEu3HiwOgA8MmgpDsdhZxee9CIg9EA

### Repro steps

1. Run ESLint with eslint-plugin-react-compiler with the Playground's link
2. Observe error "InvalidReact: Writing to a variable defined outside a component or hook is not allowed. Consider using an effect"

I assume functions called from effects should have the same liberties as the effects themselves, else we are forced to write big effects. I used `window` as the external variable as it represents a common use case, but any other name would work.

Notice the error only happens when the function which writes to `window` is defined after the `useEffect` which calls it. Invert the order and it's fine.

### How often does this bug happen?

Every time

### What version of React are you using?

18.3.1

### What version of React Compiler are you using?

eslint-plugin-react-compiler@npm:19.0.0-beta-0dec889-20241115
Repository: ollama
Issue: Tool calling parsing for llama3.2
Labels: bug

### What is the issue?

Llama 3.2 tool call outputs [are not in JSON](https://github.com/meta-llama/llama-models/blob/main/models/llama3_2/text_prompt_format.md) and so Ollama's tool parsing needs to be updated

### OS

_No response_

### GPU

_No response_

### CPU

_No response_

### Ollama version

_No response_
Repository: go
Issue: os/signal: sending SIGTSTP doesn't return to shell when non-SIGTSTP handler exists (OpenBSD)
Labels: OS-OpenBSD,NeedsInvestigation,compiler/runtime

### Go version

go version go1.20.1 openbsd/amd64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/peter/.cache/go-build"
GOENV="/home/peter/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="openbsd"
GOINSECURE=""
GOMODCACHE="/home/peter/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="openbsd"
GOPATH="/home/peter/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/openbsd_amd64"
GOVCS=""
GOVERSION="go1.20.1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="cc"
CXX="c++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1289460440=/tmp/go-build -gno-record-gcc-switches"
```


### What did you do?

```
package main

import (
        "os"
        "os/signal"
        "syscall"
        "time"
)

func main() {
        c := make(chan os.Signal, 1)
        signal.Notify(c, syscall.SIGINT, syscall.SIGTERM)
        go func() {
                <-c
                os.Exit(1)
        }()

        for {
                time.Sleep(time.Second)
        }
}
```

go build test.go
./test
Hit Ctrl-Z

### What did you see happen?

<Doesn't return to shell as expected>

### What did you expect to see?

```
^Z[1] + Suspended            ./test 
me@mymachine:~$ 
```
Repository: godot
Issue: `get_line_count()` is wrong when characters are hidden with "Characters After Shaping" behavior
Labels: bug,topic:gui

### Tested versions

4.3
4.4 dev5

### System information

Windows 10.0.19045 - Multi-window, 2 monitors - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 (NVIDIA; 32.0.15.6603) - Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 threads)

### Issue description

I'm using RichTextLabel for my dialogue system. I rely on `get_line_count()` returning only lines not hidden by `visible_characters`.

However unfolding `visible_characters` does not work that well with autowrap. The word will start appearing at the end of line and then jump to the next line as it gets wrapped. It looks very jarring and many people reported this problem when playtesting my game.

The problem is that the only way to fix it is changing `visible_characters_behavior` from the default Characters Before Shaping to Characters After Shaping. This makes `get_line_count()` always return all lines, even if hidden by `visible_characters`.

Though while testing this, I discovered another weird thing about `get_line_count()` - the `visible_characters` interaction only works if lines end with `\r`. If lines end with `\n`, the behavior is consistent between `visible_characters_behavior`, i.e. it always returns all lines 🙃

### Steps to reproduce

```GDScript
extends RichTextLabel

func _ready() -> void:
	for i in 10:
		append_text("line of text\r")

func _process(delta: float) -> void:
	visible_characters += 1
	prints(get_line_count())
```
Run this scripts. You will see 1, 2, 3... 10 being printed. If you change `visible_characters_behavior`, it will always print 10.

### Minimal reproduction project (MRP)

N/A
Repository: godot
Issue: VR right eye not rendering sky properly
Labels: bug,topic:rendering,topic:xr

### Tested versions

4.3 stable mono, 4.4 dev5 mono

### System information

Godot v4.4.dev5.mono - Windows 10.0.19045 - Multi-window, 1 monitor - Vulkan (Mobile) - dedicated Radeon RX 580 Series (Advanced Micro Devices, Inc.; 31.0.21921.1000) - AMD Ryzen 5 1600 Six-Core Processor (12 threads)

### Issue description

This issue seems to have a few open tickets which have led me on a crumb trail to #99448 though I'm not sure if this is related.

When using WorldEnvironment with Background set to Clear Color and defaults, AND Glow enabled, the right eye for my VR camera will not be able to render the background properly. This also happens with the Sky setting, but upon setting a material to it it will render properly.

### Steps to reproduce

- Set up VR cam and stuff
- Create WorldEnvironment
- Set Glow to enabled
- ???
- non profit

### Minimal reproduction project (MRP)

N/A
Repository: angular
Issue: Migration to lazy-loaded routes not working if Routes are exported as default
Labels: area: migrations

### Command

generate

### Is this a regression?

- [ ] Yes, this behavior used to work in the previous version

### The previous version in which this bug was not present was

this is a new migration schematic

### Description

using the new migration schematic
ng generate @angular/core:route-lazy-loading
results in 'Could not find any files to migrate under the path ...'
The Routes are exported as default, which causes the schematic to fail finding them. 



### Minimal Reproduction

trying to migrate the following route.ts file:

```
export default [
    {
        path: '',
        component: SomeComponent,
        children: [
          { path: 'index', component: IndexComponent },
          { path: 'index/:name', component: IndexDetailComponent, resolve: { index: indexDetailResolver } }
        ]
      }
] as Routes; 
```
using:
``
ng generate @angular/core:route-lazy-loading --path src/app/something
``

fails, because the migration schematic does not recognize the Routes, which are exported as default.

### Exception or Error

```text

```

### Your Environment

```text
"@angular/cli": "^19.0.1"
```

### Anything else relevant?

_No response_
Repository: godot
Issue: slowing down when saving a script
Labels: bug,topic:editor,performance

### Tested versions

version : 4.3
os : fedora
cpu : Intel® Core™ i3-4030U × 4
ram : 8,0 Gio
graphics : Intel® HD Graphics 4400

### System information

Godot v4.3.stable (77dcf97d8) - Fedora Linux 41 (Workstation Edition) - Wayland - GLES3 (Compatibility) - Mesa Intel(R) HD Graphics 4400 (HSW GT2) - Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz (4 Threads)

### Issue description

When saving gdscript files, the window for choosing the backup location is very slow to navigate from one directory to another.

### Steps to reproduce

The problem appears to be present in the project where there is a lot of file and sub-file

### Minimal reproduction project (MRP)

Necessitates a big project
Repository: TypeScript
Issue: Rethinking relationships between `{}` type, `object`, and primitives
Labels: Suggestion,Needs Proposal

### 🔎 Search Terms

empty object type, `{}`, type safety violation, unsound

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about [object types](https://www.typescriptlang.org/docs/handbook/2/objects.html) and [structural typing](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes-func.html#structural-typing)


### ⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.8.0-dev.20241124#code/GYVwdgxgLglg9mABFAhgawKYGcDyAjAKw2gAoAPALkTkOKgEpEBvAKEXcQHpPEAVACxhZEAJxgBzflAA2AT0RDEKPgGVEGESLgiAdGw4xgicogC85xAAZGrDncQQEWONIw6NWkSQDkAxXhEUSH5ELH44EGkAE0Q8DERwEQwUCH4UPFdvegBufXYAXxZClkcwLChqKiZ8sytclm5EACEQCqhBYSEwbygAGiUwGLCI6Ni3FlRMXFpSOBygA

### 💻 Code

```ts
function takesObject(x: object) {
    // This rightly is a TS error.
    if (x === 0) {
        console.error('This branch should be unreachable');
    }
}

const o: {} = 0;

// But this isn't, and should be.
takesObject(o);
```


### 🙁 Actual behavior

No error on `takesObject(o)`. `{}` can be assigned to type `object`, despite `{}` meaning "all nonnullish values", whereas `object` means only JS object types.

### 🙂 Expected behavior

Error on `takesObject(o)`. `{}` is a wider type than `object`.

### Additional information about the issue

This stems from a typescript-eslint investigation into making no-unnecessary-condition be more correct around possibly-falsy "object types", such as `{}`, or even `{ toFixed(): string}` (to which `number` may be assigned). See https://github.com/typescript-eslint/typescript-eslint/pull/10378. This also relates to previous (controversial) conversations about whether to flag the `{}` type with the linter, see, e.g. https://github.com/typescript-eslint/typescript-eslint/issues/8700. 

I'm wondering if this was simply an oversight in https://github.com/microsoft/TypeScript/pull/49119, which aimed to fix soundness holes with `{}`?