sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: electron
Issue: [Feature Request]: Splitting Electron into a small EXE and a large DLL
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

N/A

### Proposed Solution

Splitting the large electron.exe into smaller EXE and larger DLL files, with most of the code placed within the DLL while the EXE acts as a shell to load the DLL, offers two benefits:
1、The EXE can speed up the application startup by preloading the DLL. In our product's testing (used by several million users), preloading resulted in a 180ms improvement in the PCT50 startup speed.
2、If the EXE is used as a launcher, the DLL and other program files can be placed in a versioned subdirectory. This structural design provides advantages for installation, uninstallation, and upgrades. During installation and uninstallation, there are often mysterious file occupation issues. Isolating the files in a versioned directory can increase the success rate of installation and uninstallation. Keeping a separate EXE outside the versioned directory maintains a unified entry point for the application. In certain scenarios, such as OEM pre-installation, maintaining a fixed location for the EXE is necessary. In the context of updates, having a separate EXE launcher is beneficial for implementing silent updates.

Additionally, Chrome follows a similar approach.
c:\Program Files\Google\Chrome>tree /F

└─Application
    │  chrome.exe
    │  chrome.VisualElementsManifest.xml
    │  chrome_proxy.exe
    │  initial_preferences
    │
    ├─124.0.6367.158
    │  │  124.0.6367.158.manifest
    │  │  chrome.dll
    │  │  chrome.dll.sig
    │  │  chrome.exe.sig
    │  │  chrome_100_percent.pak
    │  │  chrome_200_percent.pak
    │  │  chrome_elf.dll
    │  │  chrome_pwa_launcher.exe
    │  │  chrome_wer.dll
    │  │  d3dcompiler_47.dll
    │  │  dxcompiler.dll
    │  │  dxil.dll
    │  │  elevation_service.exe
    │  │  eventlog_provider.dll
    │  │  icudtl.dat
    │  │  libEGL.dll
......



### Alternatives Considered

N/A

### Additional Information

I would like to know how the official community perceives this Feature Request. If the community deems this feature feasible, I am interested in taking up its development. Could you please advise me on the appropriate process to follow? For instance, should I start by submitting an RFC (Request for Comments) document?
Repository: pytorch
Issue: Can not use torch.compile with dynamic=Ture when using multi-threads
Labels: triaged,module: multithreading,oncall: pt2,module: dynamic shapes

### 🐛 Describe the bug

When running a model processed by torch.compile in a multi-threaded environment, the following error will be reported:
`RuntimeError: Detected that you are using FX to symbolically trace a dynamo-optimized function. This is not supported at the moment.`
There is a case where the same model is run in multiple threads:
```
model = torch.compile(model, dynamic=True)

thread = threading.Thread(
    target=run_sharing_model,
    args=(model, dataloader, ...)
)
```

Is this error expected and is it possible to support this case?

### Error logs

RuntimeError: Detected that you are using FX to symbolically trace a dynamo-optimized function. This is not supported at the moment.

### Minified repro

_No response_

### Versions

torch 2.4.0.dev20240417+cpu

cc @albanD @chauhang @penguinwu @ezyang @bobrenjc93 @msaroufim @bdhirsh @anijain2305
Repository: tauri
Issue: [bug] tauri does not deliver WindowEvent::Focused when unstable feature is enabled
Labels: type: bug,status: needs triage

### Describe the bug

tauri does not deliver `WindowEvent::Focused` when `unstable` feature is enabled.

### Reproduction

https://github.com/topecongiro/tauri-bug-focused-event

### Expected behavior

The mwe app emits the following output on switching the focus of the window:

```
event = Ready
event = WindowEvent { label: "main", event: Focused(true) }
event = WindowEvent { label: "main", event: Focused(false) }
```

### Full `tauri info` output

```text
[✔] Environment
    - OS: Windows 10.0.19045 X64
    ✔ WebView2: 124.0.2478.97
    ✔ MSVC: Visual Studio Build Tools 2022
    ✔ rustc: 1.77.2 (25ef9e3d8 2024-04-09)
    ✔ cargo: 1.77.2 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 21.7.3
    - yarn: 1.22.19
    - npm: 10.5.0

[-] Packages
    - tauri [RUST]: 2.0.0-beta.19
    - tauri-build [RUST]: 2.0.0-beta.15
    - wry [RUST]: 0.39.5
    - tao [RUST]: 0.28.0
    - tauri-cli [RUST]: 1.5.6
    - @tauri-apps/api [NPM]: 2.0.0-beta.11
    - @tauri-apps/cli [NPM]: 2.0.0-beta.17

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: pytorch
Issue: torch.compile does not support strided NestedTensor
Labels: triaged,module: nestedtensor,oncall: pt2

### 🐛 Describe the bug

Internal xref: https://fb.workplace.com/groups/1075192433118967/posts/1426726281298912/

Repro script: https://gist.github.com/ezyang/ff84e2d4b90bb6f9d83171b1582a237c

One log from TORCH_LOGS=graph_breaks:

```
    self._load_attr(inst)                                                                                                                                     
  File "/data/users/ezyang/b/pytorch/torch/_dynamo/symbolic_convert.py", line 1345, in _load_attr
    result = BuiltinVariable(getattr).call_function(                                                                                                          
  File "/data/users/ezyang/b/pytorch/torch/_dynamo/variables/builtin.py", line 946, in call_function
    return handler(tx, args, kwargs)                                                                                                                          
  File "/data/users/ezyang/b/pytorch/torch/_dynamo/variables/builtin.py", line 712, in <lambda>
    tx, [v.realize() for v in args], kwargs
  File "/data/users/ezyang/b/pytorch/torch/_dynamo/variables/builtin.py", line 712, in <listcomp>
    tx, [v.realize() for v in args], kwargs
  File "/data/users/ezyang/b/pytorch/torch/_dynamo/variables/lazy.py", line 58, in realize          
    self._cache.realize()           
  File "/data/users/ezyang/b/pytorch/torch/_dynamo/variables/lazy.py", line 24, in realize         
    self.vt = VariableBuilder(tx, self.source)(self.value)
  File "/data/users/ezyang/b/pytorch/torch/_dynamo/variables/builder.py", line 302, in __call__  
    vt = self._wrap(value)                                                     
  File "/data/users/ezyang/b/pytorch/torch/_dynamo/variables/builder.py", line 444, in _wrap   
    return type_dispatch(self, value)                                          
  File "/data/users/ezyang/b/pytorch/torch/_dynamo/variables/builder.py", line 1273, in wrap_tensor
    unimplemented("torch.compile does not support strided NestedTensor")
  File "/data/users/ezyang/b/pytorch/torch/_dynamo/exc.py", line 216, in unimplemented                       
    raise Unsupported(msg)
torch._dynamo.exc.Unsupported: torch.compile does not support strided NestedTensor                       
                                                                                                                                                              
from user code:
   File "/home/ezyang/local/b/pytorch-env/lib/python3.10/site-packages/optimum/bettertransformer/models/encoder_models.py", line 293, in torch_dynamo_resume_i
n_forward_at_292
    if hidden_states.is_nested:
```

I wonder if it's actually exercising nested codepath at all though lol, maybe onlyt eh query is failing?

### Versions

main

cc @cpuhrsch @jbschlosser @bhosmer @drisspg @soulitzer @msaroufim @bdhirsh @anijain2305 @chauhang
Repository: vscode
Issue: Goto implementation UI has a contrast issue?
Labels: bug,themes,accessibility,list-widget

I find this representation to lack contrast:

![image](https://github.com/microsoft/vscode/assets/900690/5b2c9a93-9202-48a8-be85-cedbdd8420d5)

I am not sure it meets our a18y requirements?

This is the "Find Implementations" peek UI.
Repository: node
Issue: `assert.ok()` becomes slow when using the Hooks API
Labels: confirmed-bug,assert

### Version

v20.13.1

### Platform

_No response_

### Subsystem

Mac/Linux

### What steps will reproduce the bug?

```sh
node --import ./hook.mjs file.mjs
```

hook.mjs:
```js
import { isMainThread } from 'worker_threads';
import module from 'module';

if (isMainThread) {
	module.register(import.meta.url, import.meta.url);
}

export const load = async (
	url,
	context,
	nextLoad,
) => {
	if (url.endsWith('/file.mjs')) {
		return {
			shortCircuit: true,
			format: 'module',
			// Originally, this is from esbuild compiling the input. But inlining the compiled code here demonstrates that's not the issue.
			source: 'import assert from"assert";const startTime=Date.now();console.log("start time:",Date.now()-startTime);try{assert.ok(false)}finally{console.log("end time:",Date.now()-startTime)}',
		};
	}
	return await nextLoad(url, context);
};
```

file.mjs: https://github.com/privatenumber/node-bug-slow/blob/develop/file.mjs
(The minimal reproduction requires a file with a massive comment so I decided not to paste here)


I uploaded the minimal reproduction here as well:
https://github.com/privatenumber/node-bug-slow

And it takes 1.3s to run on GitHub Actions:
https://github.com/privatenumber/node-bug-slow/actions/runs/9057737597/job/24882195019

### How often does it reproduce? Is there a required condition?

Consistently.

But the reproduction is fragile. Deleting a space here and there would make it run expectedly under 10ms.

### What is the expected behavior? Why is that the expected behavior?

It should take under 10ms.

### What do you see instead?

The `assert.ok(false)` call takes around 600ms for me, and 1.5s on GitHub Actions.

### Additional information

Originally reported in https://github.com/privatenumber/tsx/issues/548
Repository: godot
Issue: Editor freezes and window remains blank after Mesa update
Labels: bug,topic:rendering,topic:editor

### Tested versions

-  Reproducible in 4.2.2 and 4.1.1

### System information

Kubuntu 20.04 - OpenGL API 4.6 (Core Profile) Mesa 24.0.6 - kisak-mesa PPA - Compatibility - Using Device: AMD - AMD Radeon Vega 10 Graphics (radeonsi, raven, LLVM 15.0.7, DRM 3.35, 5.4.0-181-generic) - i3 window manager

### Issue description

The project selection windows works fine, but once I choose the project  to load the editor freezes and remains 'unrendered' when opening any project. This happened after a Mesa update from kisak PPAs. Here are the full logs:

```
Godot Engine v4.2.2.stable.official.15073afe3 - https://godotengine.org
/lib/x86_64-linux-gnu/libxkbcommon.so.0: undefined symbol: xkb_utf32_to_keysym
/lib/x86_64-linux-gnu/libxkbcommon.so.0: undefined symbol: xkb_keymap_key_get_mods_for_level
OpenGL API 4.6 (Core Profile) Mesa 24.0.6 - kisak-mesa PPA - Compatibility - Using Device: AMD - AMD Radeon Vega 10 Graphics (radeonsi, raven, LLVM 15.0.7, DRM 3.35, 5.4.0-181-generic)

Project is missing: /media/lorenzo/ext/Progetti Godot/sectoria-client/project.godot
Project is missing: /media/lorenzo/ext/Progetti Godot/Dummy/project.godot
Editing project: /home/lorenzo/ext/ProgettiGodot/test
Godot Engine v4.2.2.stable.official.15073afe3 - https://godotengine.org
/lib/x86_64-linux-gnu/libxkbcommon.so.0: undefined symbol: xkb_utf32_to_keysym
/lib/x86_64-linux-gnu/libxkbcommon.so.0: undefined symbol: xkb_keymap_key_get_mods_for_level
Vulkan API 1.3.274 - Forward+ - Using Vulkan Device #2: AMD - AMD Radeon RX 5500M (RADV NAVI14)
```

Let me know if I there is any option that could give a more detailed logging of what's being loaded. I believe this is related to the Mesa version as the window frame buffer seems broken, meaning that its content is filled with random "fragments" of other windows that were opened before. Also, it used to work before updating the drivers but Ubuntu ships with a very old stable Mesa version.

### Steps to reproduce

Open any project in the described setup, I will attach an empty project which causes this issues, although I am convinced this is not related to the project itself.

### Minimal reproduction project (MRP)

[test.zip](https://github.com/godotengine/godot/files/15286673/test.zip)
Repository: vscode
Issue: redo command doesn't focus cursor
Labels: bug,editor-commands,editor-api


Type: <b>Bug</b>

Running redo command with the extension API `commands.executeCommand` or with ctrl+shift+P > Redo does not focus the cursor at the point of insertion/deletion.

VS Code version: Code 1.89.1 (dc96b837cf6bb4af9cd736aa3af08cf8279f7685, 2024-05-07T05:13:33.891Z)
OS version: Windows_NT x64 10.0.22631
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|12th Gen Intel(R) Core(TM) i9-12900K (24 x 3187)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|undefined|
|Memory (System)|63.75GB (43.51GB free)|
|Process Argv|--crash-reporter-id 2855bf14-016e-4c0e-b252-619601ce1536|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (24)</summary>

Extension|Author (truncated)|Version
---|---|---
project-manager|ale|12.8.0
vscode-eslint|dba|2.4.4
gitlens|eam|14.9.1
copilot|Git|1.190.0
copilot-chat|Git|0.15.1
output-colorizer|IBM|0.1.2
google-search|kam|0.0.1
vscode-autohotkey-plus-plus|mar|5.0.3
python|ms-|2024.6.0
hexeditor|ms-|1.10.0
powershell|ms-|2024.2.1
typst-lsp|nva|0.13.0
material-icon-theme|PKi|5.2.0
vscode-yaml|red|1.14.0
rust-analyzer|rus|0.3.1950
crates|ser|0.6.6
even-better-toml|tam|0.19.2
vscode-autohotkey2-lsp|thq|2.4.5
pdf|tom|1.2.2
miniutils|und|0.0.1
utils|und|0.0.1
errorlens|use|3.17.0
vscode-lldb|vad|1.10.0
vim|vsc|1.27.2

(1 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
tftest:31042121
vscorecescf:30445987
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
welcomedialogc:30910334
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
2e7ec940:31000449
pythontbext0:30879054
accentitlementsc:30995553
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
g316j359:31013175
pythoncenvpt:31043157
a69g1124:31038041
dvdeprecationcf:31040882
pythonprc:31039816
dwnewjupytercf:31039676

```

</details>

<!-- generated by issue reporter -->
Repository: stable-diffusion-webui
Issue: [Bug]: handle high resolution
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
- [X] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

if i have in img2img an image that is about 1800pix
or i generate i image 1024 and hires it 2times
16GB VRAM is fully used and it need 5min to calculate

a serious question, why you dont copy and paste the part of fooocus,  it handle very easy 9GB and 20times faster !



### Steps to reproduce the problem

...

### What should have happened?

...

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

_No response_

### Sysinfo

RTX4060 16GB
i7 4GHZ
64GB RAM
win10

### Console logs

```Shell
...
```


### Additional information

please you can do it  ;)
Repository: node
Issue: `test-pipe-file-to-http` is flaky (timeout)
Labels: arm,flaky-test

### Test

`test-pipe-file-to-http`

### Platform

Linux ARMv7

### Console output

```console
not ok 3838 parallel/test-pipe-file-to-http
  ---
  duration_ms: 360062.48700
  severity: fail
  exitcode: -15
  stack: |-
    timeout
  ...
```


### Build links

- https://ci.nodejs.org/job/node-test-binary-armv7l/11465/RUN_SUBSET=js,nodes=ubuntu2004-armv7l/

### Additional information

_No response_
Repository: node
Issue: `test-buffer-tostring-rangeerror` is flaky (timeout)
Labels: flaky-test,linux

### Test

`test-buffer-tostring-rangeerror`

### Platform

Linux x64

### Console output

```console
not ok 1244 parallel/test-buffer-tostring-rangeerror
  ---
  duration_ms: 120073.76400
  severity: fail
  exitcode: -15
  stack: |-
    timeout
    (node:2934155) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
    (Use `node --trace-deprecation ...` to show where the warning was created)
  ...
```


### Build links

- https://ci.nodejs.org/job/node-test-commit-linux-containered/43366/nodes=ubuntu2204_sharedlibs_withoutintl_x64/

### Additional information

_No response_
Repository: pytorch
Issue: all_gather with gloo backend does not work in inference mode
Labels: oncall: distributed,triaged,module: c10d

### 🐛 Describe the bug

A minimal reproducible example:

```python
import torch
import torch.distributed as dist
dist.init_process_group(backend='gloo')
# dist.init_process_group(backend='nccl')
# torch.cuda.set_device(dist.get_rank())
with torch.inference_mode():
    data = [torch.ones((3, 3))] * dist.get_world_size()
    obj = data[dist.get_rank()]
    dist.all_gather(data, obj)
    # dist.broadcast(obj, src=0)
```

The error is:

> E           RuntimeError: Inplace update to inference tensor outside InferenceMode is not allowed.You can make a clone to get a normal tensor before doing inplace update.See https://github.com/pytorch/rfcs/pull/17 for more details.

It looks strange, that `nccl` backend works in this case. `broadcast` works, too. Only `all_gather` does not work.

### Versions

pytorch 2.3.0

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @wconstab @yf225 @chauhang @d4l3k
Repository: stable-diffusion-webui
Issue: [Feature Request]: merge pnginfo_interface into extras_interface
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

![image](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/167966/a8292248-d859-4990-a60c-ada2b000690b)


### Proposed workflow

1. Go to .... 
2. Press ....
3. ...


### Additional information

_No response_
Repository: flutter
Issue: Delete the allow_deprecated_api_calls GN affordance.
Labels: P3,c: tech-debt,team-engine,triaged-engine

This was originally added to GN to account for using the deprecated OpenGL API on Darwin platforms. But this means that all TUs on Darwin don't warn on use of [[deprecated]] APIs.

We no longer use OpenGL on iOS and the deprecations can be suppressed where they are used instead of globally. This affordance can be deleted and the indivudial call sites fixed.
Repository: create-react-app
Issue: Property 'toBeInTheDocument' does not exist when using cra inside a monorepo
Labels: needs triage,issue: bug report

There is an issue with types when using create-react-app inside a monorepo.

Here are the steps to reproduce the bug:

```bash
pnpm init
# create a pnpm-workspace.yaml file
cat pnpm-workspace.yaml
packages:
  - "apps/**"
# create a react app, node_modules will be created on the app folder, not the monorepo root
pnpm create react-app@latest apps/test-app test --template typescript
# at this point, if we run start, everything goes as planned
pnpm --filter test-app start
# we delete the apps/test-app/node_modules folder and mimic a real monorepo install
rm -fr apps/test-app/node_modules
pnpm install
# now node_modules is at the monorepo root, but ...
pnpm --filter test-app start # we'll get error: Property 'toBeInTheDocument' does not exist on type 'JestMatchers<HTMLElement>'.
```

I found that adding this dependency fixes the issue

```json
  "dependencies": {
    "@testing-library/jest-dom": "^5.17.0",
    "@testing-library/react": "^13.4.0",
    "@testing-library/user-event": "^13.5.0",
    "@types/testing-library__jest-dom": "^5.14.9", <-- ADD THIS
    "@types/jest": "^27.5.2",
    "@types/node": "^16.18.97",
    "@types/react": "^18.3.2",
    "@types/react-dom": "^18.3.0",
    "react": "^18.3.1",
    "react-dom": "^18.3.1",
    "react-scripts": "5.0.1",
    "typescript": "^4.9.5",
    "web-vitals": "^2.1.4"
  }
```

Run install again:

```bash
pnpm install # it works!
```
Repository: react
Issue: Bug: eslint-plugin-react-hooks documentation might be misleading
Labels: Status: Unconfirmed

Splits from https://github.com/WordPress/gutenberg/issues/61598 & https://github.com/WordPress/gutenberg/pull/61599

The current explanation about "[additionalHooks](https://github.com/facebook/react/tree/main/packages/eslint-plugin-react-hooks#advanced-configuration)" under `react-hooks/exhaustive-deps` might be misleading. The regex in the example catches more than needed.

This:
```json
"additionalHooks": "(useMyCustomHook|useMyOtherCustomHook)"
```

Will catch also things like this:
```js
function App() {
	const data1 = useMyCustomHook2();
	const data2 = useMyOtherCustomHookTest();

	// ...
}
```

This might be the reason why Gutenberg used the same approach (which caused the bug mentioned above):
https://github.com/WordPress/gutenberg/blob/2df566c771dba22eec2841081a00963a2e56658c/packages/eslint-plugin/configs/react.js#L37-L42
Repository: flutter
Issue: `flutter daemon` occasionally terminates when trying to invoke `adb` to list devices
Labels: P2,team-tool,triaged-tool

This issue tracks solving the root issue discussed in #125971. To summarize the issue, `flutter daemon` occasionally exits when trying to run `adb devices -l` due to the command completing with an error. Source of this call: https://github.com/flutter/flutter/blob/ce822ec8bb15e44de72f5a449c00dedcc21d74e8/packages/flutter_tools/lib/src/android/android_device_discovery.dart#L70-L80

See https://github.com/flutter/flutter/issues/125971#issuecomment-2101093702, which includes the exception that comes from invoking `adb devices -l`. Specifically, we see 

```
daemon still not running
error: cannot connect to daemon at tcp:5037: Connection refused"}}]
```

While it's not clear what the root cause of this failure is, it's possible that the flutter tool could prevent or workaround it. See https://github.com/flutter/flutter/issues/125971#issuecomment-2101147423. It's possible we can use something like `adb reconnect`, which should restart the connection to the server from the host side.