sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [Camera] setting different ResolutionPreset between camera preview and camera photo
Labels: c: new feature,p: camera,package,c: proposal,team-ecosystem,P2,triaged-ecosystem

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

Hello,

I'm developing a Flutter app that utilizes object detection AI, similar to [object_detection_flutter](https://github.com/am15h/object_detection_flutter).

In the code, the AI model predicts based on the camera preview image, rather than the image obtained after calling [camera.takePicture()](https://pub.dev/documentation/camera/latest/camera/CameraController/takePicture.html). The AI model requires a low-resolution image, usually 512x512, for faster processing. Therefore, regardless of the image's original quality, it must be resized to a low resolution, which is more efficiently done using the low-resolution preview image rather than a high-resolution one. Setting ResolutionPreset.medium or ResolutionPreset.high in the [ResolutionPreset enum](https://pub.dev/documentation/flutter_better_camera/latest/camera/ResolutionPreset.html) works much better for this purpose.

However, the issue arises from the inability to set camera presets separately for the preview image and the photo image. As a result, if we configure a low-resolution preset for high AI performance, we end up with a low-quality photo after using takePicture(), and vice versa.

It would be immensely beneficial if these presets could be configured independently for the preview and photo images.

### Proposal

```
cameraController = CameraController(
  cameras[0], 
  previewResolutionPreset: ResolutionPreset.medium,
  photoResolutionPreset: ResolutionPreset.ultraHigh
  enableAudio: false
);
```
Repository: rust
Issue: Misleading error message when missing a colon
Labels: A-diagnostics,T-compiler,A-suggestion-diagnostics,D-invalid-suggestion

### Code

```Rust
use std::env;

#[derive(Debug, thiserror::Error)]
pub enum UriParseError {
    #[error("failed to locate 'parser_util' binary, is PARSER_UTIL_BIN set?")]
    BinNotFound(#[from] env::VarError),
}

/// Reads the `PARSER_BIN_UTIL` environment variable to get the path to the `parser_util` binary.
pub fn get_bin() -> Result<String, UriParseError> {
    env:var("PARSER_UTIL_BIN")
}
```


### Current output

```Shell
error: struct literal body without path
  --> crates/runix/src/uri_parser.rs:10:51
   |
10 |   pub fn get_bin() -> Result<String, UriParseError> {
   |  ___________________________________________________^
11 | |     env:var("PARSER_UTIL_BIN")
12 | | }
   | |_^
   |
help: you might have forgotten to add the struct literal inside the block
   |
10 ~ pub fn get_bin() -> Result<String, UriParseError> { SomeStruct {
11 |     env:var("PARSER_UTIL_BIN")
12 ~ } }
   |
```


### Desired output

```Shell
error: missing colon in path separator
  --> crates/runix/src/uri_parser.rs:10:51
   |
10 |   pub fn get_bin() -> Result<String, UriParseError> {
11 | |     env:var("PARSER_UTIL_BIN")
   |       ___^
12 | | }
   | |
   |
help: you might have forgotten to include a second colon
   |
10   pub fn get_bin() -> Result<String, UriParseError> {
11 ~     env::var("PARSER_UTIL_BIN")
12   }
   |
```


### Rationale and extra context

_No response_

### Other cases

_No response_

### Anything else?

_No response_

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: Godot freezes when saving the project on Linux.
Labels: bug,platform:linuxbsd,topic:editor,needs testing

### Godot version

4.1.1.stable.flatpak

### System information

Fedora 38 (Worstation), Wayland, Mesa Intel® UHD Graphics (ICL GT1), Vulkan

### Issue description

Godot freezes when saving any project when under Linux, it happens often and I couldn't figure out a clear reason as to why.

[Gravação de tela de 2023-07-19 22-26-18.webm](https://github.com/godotengine/godot/assets/119557151/c5762439-7307-458d-9587-f79bd3dab4ad)


### Steps to reproduce

Save a project.

### Minimal reproduction project

N/A
Repository: pytorch
Issue: torch.nn.TransformerDecoderLayer lacks parameter validation check
Labels: module: nn,triaged

### 🐛 Describe the bug

### Description:
torch.nn.TransformerDecoderLayer lacks parameter validation check, and when invalid values are given, they are used in subsequent computations, leading to errors such as division by zero.

### Examples:
input:
```
p = torch.nn.TransformerDecoderLayer(d_model=10, nhead=0)
```
error_message:
```
Traceback (most recent call last):
  File "D:\PythonProjects\venv\lib\site-packages\IPython\core\interactiveshell.py", line 3508, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-32-6f43c243aac4>", line 1, in <module>
    p = torch.nn.TransformerDecoderLayer(d_model=10, nhead=0)
  File "D:\PythonProjects\venv\lib\site-packages\torch\nn\modules\transformer.py", line 653, in __init__
    self.self_attn = MultiheadAttention(d_model, nhead, dropout=dropout, batch_first=batch_first,
  File "D:\PythonProjects\venv\lib\site-packages\torch\nn\modules\activation.py", line 968, in __init__
    self.head_dim = embed_dim // num_heads
ZeroDivisionError: integer division or modulo by zero

```


### Versions

PS D:\PythonProjects\venv\Lib\site-packages\torch\utils> python collect_env.py
Collecting environment information...
PyTorch version: 2.0.1+cu117
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 11 家庭中文版
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect
Libc version: N/A

Python version: 3.10.11 (tags/v3.10.11:7d4cc5a, Apr  5 2023, 00:38:17) [MSC v.1929 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.22621-SP0
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 4070 Laptop GPU
Nvidia driver version: 532.03
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture=9
CurrentClockSpeed=2200
DeviceID=CPU0
Family=207
L2CacheSize=16384
L2CacheSpeed=
Manufacturer=GenuineIntel
MaxClockSpeed=2200
Name=13th Gen Intel(R) Core(TM) i9-13900HX
ProcessorType=3
Revision=

Versions of relevant libraries:
[pip3] numpy==1.24.3
[pip3] torch==2.0.1+cu117
[pip3] torchaudio==2.0.2+cu117
[pip3] torchvision==0.15.2+cu117
[conda] Could not collect

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @bhosmer @cpuhrsch @erichan1 @drisspg
Repository: rust
Issue: Return-position impl Trait is not satisfied by divergent/never type
Labels: A-diagnostics,A-trait-system,T-lang,A-docs,F-never_type,T-types

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
pub fn foo() -> impl Iterator<Item = u32> {
    loop {}
    // or panic!(), etc.
}

// Equivalent code modulo cut elimination
pub fn bar() -> impl Iterator<Item = u32> {
    bar_helper()
}
fn bar_helper() -> std::iter::Empty<u32> {
    loop {}
}
```

I expected to see this happen:

Module should compile without error. If `foo` or `bar` are invoked, they
should diverge. In particular, `foo` and `bar` should be equivalent in
terms of both static and dynamic semantics.

In general, `fn foo() -> T { loop {} }` should compile for any type `T`,
because `loop {}` should be at type `!` and `!` should be a subtype of
every type. This seems to be the case for all proper types that I've
tried, including uninhabited ones like `std::convert::Infallible`, but
not when `T` is actually a return-position `impl Trait`.

Instead, this happened:

```
error[E0277]: `()` is not an iterator
 --> src/lib.rs:1:17
  |
1 | pub fn foo() -> impl Iterator<Item = u32> {
  |                 ^^^^^^^^^^^^^^^^^^^^^^^^^ `()` is not an iterator
  |
  = help: the trait `Iterator` is not implemented for `()`
```

This is surprising, because I'm not sure where the unit type is coming
from. If I replace `impl Iterator<Item = u32>` with `impl Default`, or
another trait that `()` does implement, then it compiles without error.
But if I use `impl Trait` for a trait that `()` does not implement, then
it raises this compile-time error.

The fact that `bar` compiles makes it feel especially weird that `foo`
does not compile, because they should be equivalent. Yes, there's more
type information (I've used `std::iter::Empty<u32>` as a specific type
implementing `Iterator<Item = u32>`), but I don't see why that should
matter. The error given by rustc wasn't a "ambiguous type; specify type
annotations" kind of error.

Playground with these examples and a few more:
<https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=e8061b7ffb50afef8b230892d458d26b>

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-unknown-linux-gnu
release: 1.70.0
LLVM version: 16.0.2
```

Also exists in nightly 2023-07-18.
Repository: next.js
Issue: NextJs image with 'height:auto' broke layout at some iphone navigators
Labels: bug,Image (next/image)

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Using image like this broke layout at iphone some navigators if 'height' was not specified.
```
![image](https://github.com/vercel/next.js/assets/1494145/b89459e8-8bbc-4cc9-b106-3abf0d96accd)


### Which area(s) of Next.js are affected? (leave empty if unsure)

Image optimization (next/image, next/legacy/image)

### Link to the code that reproduces this issue or a replay of the bug

image tag generated by next/image with height:auto or without height broke layout at some iphone navigators

### To Reproduce

Dont specify image height

### Describe the Bug

Broke wrapper with display grid configuration with height as 'auto'

### Expected Behavior

The grid column dont render

### Which browser are you using? (if relevant)

Iphone 12 Chrome

### How are you deploying your application? (if relevant)

_No response_
Repository: pytorch
Issue: FSDP with gradient checkpointing lead to redundant allgathers during backward
Labels: triaged,module: fsdp

### 🐛 Describe the bug

While training huggingface Llama 13B with FSDP with full shard and gradient checkpointing enabled on a single node, I observed that the backward pass has two allgathers per layer. Compared to non checkpointed training, this additional allgather also affects the overlap between the reduce scatter and gradient computation.  I think ideally only one allgather is needed to gather the weights per FSDP module. 

Trace: (browm is reduce scatter, blue is allgather)
![allgather](https://github.com/pytorch/pytorch/assets/21034047/96d6527f-94cb-4c94-9256-42127eb663c0)


```python3
        model = FSDP(model,
                    sharding_strategy=ShardingStrategy.FULL_SHARD,
                    sync_module_states=True,
                    mixed_precision=mixed_precision,
                    auto_wrap_policy=functools.partial(transformer_auto_wrap_policy, transformer_layer_cls={LlamaDecoderLayer}),
                    limit_all_gathers=True,
                    device_id=dev,
                    param_init_fn=param_init_fn,
                    )
```



### Versions

I'm using pytorch nightly: `2.1.0.dev20230709+cu121`

cc @zhaojuanmao @mrshenli @rohan-varma @awgu
Repository: stable-diffusion-webui
Issue: [Feature Request]: add Implement Paradigms Sampler to Automatic 1111
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 ?

pull req for script extension to automatic1111
Implement Paradigms Sampler to Automatic 1111

![image](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/113190973/23d4654d-e6af-42f5-9062-857aa89a5c4f)

https://github.com/AndyShih12/paradigms

### Proposed workflow

1. Go to .... 
2. Press ....
3. ...


### Additional information

_No response_
Repository: pytorch
Issue: Turn indexing with a scalar tensor into an copy into a view and avoid a D2H synchronization.
Labels: module: bc-breaking,triaged,module: numpy,module: advanced indexing,topic: bc breaking

### 🚀 The feature, motivation and pitch

Today, this triggers a cuda synchronization:
```
import torch

torch.set_default_device('cuda')

def f(x, y):
    return x[y]

inps = (torch.randn(5), torch.tensor(0))
torch.cuda.set_sync_debug_mode(2)
f(*inps)
```

The reason why is that when the tensor is a 0-dim value, instead of launching a gather kernel, we move the tensor to the hsot and do a slice instead (https://github.com/pytorch/pytorch/pull/105518/files#diff-2574bfb0ffa78d685fb7bd2ebc0c64b1a5f87dd55ec74ae67b41b31adc566020L466).

We could just fix this, but unfortunately, this does change the semantics. In particular, now, this operation would create a copy instead of a view, which could cause issues for downstream in-place operations.

I think these are bad semantics, for 3 reasons:

1. Cuda synchronizations are very bad in general. They're slow, prevent the use of many different features (streams, cudagraphs, don't play well with collectives, etc.), and should strongly be avoided. This, however, is a very implicit coercion we're doing. It's not obvious at all that if the tensor is 3-dim/2-dim/1-dim it doesn't do a sync, but if the tensor is 0-dim it does do a sync. In addition, it makes this much harder to trace and compile/not composite compliant in general.

2. Moreover, it's *not* consistent!!

Why should `x[torch.tensor(0)]` return a view but `x[torch.tensor([0])` return a copy? Why should the first one do a synchronization and the second one doesn't?

To drive this point home further, we also diverge from Numpy semantics here.

```
import numpy as np
x = np.ones(5)
y = np.array(1)
z = x[y]
z += 1
print(x)
>>> array([1., 1., 1., 1., 1.])
```

3. It's actually *slower* than just doing the index operator on GPUs! Benchmarking `x[torch.tensor(0)]` vs. `x[torch.tensor([0])`, we see that the first takes `35 us` per iteration while the second one takes `8 us`.

PS: I've also done a brief survey of use cases with this pattern I could find (https://github.com/search?q=%2F%28%5Cw%2B%29%5C%5Btorch.tensor%5C%28%2F+language%3APython&type=code), and I couldn't find many use cases of this code path at all.


cc: @ezyang @zou3519 @ngimel 

cc @ezyang @gchanan @mruberry @rgommers
Repository: storybook
Issue: [Documentation]: Contradictory explanations between play function docs and eslint-plugin-storybook
Labels: documentation

### Describe the problem

The play function in storybook suggests we pass the destructured canvasElement to the play function of another story, but storybook eslint suggests we pass the full context

Example from https://storybook.js.org/docs/react/writing-stories/play-function
<img width="807" alt="image" src="https://github.com/storybookjs/storybook/assets/56601823/51391e7c-971e-47bd-bb79-c895bec74cce">

From https://github.com/storybookjs/eslint-plugin-storybook/blob/main/docs/rules/context-in-play-function.md
<img width="868" alt="image" src="https://github.com/storybookjs/storybook/assets/56601823/0c821cd1-9b5d-46d7-9f0d-c9574ae69e79">

### Additional context

Both work fine, though
Repository: vscode
Issue: option to create non-existent file not shown when markdown-preview-editor enabled as default
Labels: bug,help wanted,markdown

<!-- ⚠️⚠️ 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

<!-- 🪓 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.80.1
- OS Version: Ubuntu Linux 22.04

Hello,
in a markdown document, when clicking a link to a non-existent markdown document, usually, VS code asks whether this new file should be created. However, this does not work when assigning the preview-editor as default.

Steps to Reproduce:
1. configure VS code to open markdown documents with preview editor:
		"workbench.editorAssociations": {
			"*.md": "vscode.markdown.preview.editor"
		} 
2. open a markdown document and create a link to a non-existent file:
   ![grafik](https://github.com/microsoft/vscode/assets/5305673/fa87555d-cbe4-4be1-abf7-ded4477d109e)
3. click the link. An error message is thrown:
  ![grafik](https://github.com/microsoft/vscode/assets/5305673/a010106f-dd07-489c-889f-46509624d373)

Expected behavior: Instead of throwing an error message, VS Code should ask the user whether the non-existent file should be created. This is the default behavior when vscode.markdown.preview.editor has not been configured for opening *.md files.

Thank you very much for your help
Kind regards
Deb
Repository: electron
Issue: [Feature Request]: Mouse Events in Main process
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

Currently, Electron does not offer support for mouse events in the main process. This limitation hinders the ability to perform certain tasks that require monitoring and handling mouse movements directly from the main process.

### Proposed Solution

To address this issue, I suggest introducing a dedicated Mouse API in Electron. This API should enable developers to access and handle mouse events within the main process, thereby providing more flexibility and control over mouse-related interactions in Electron applications.

### Alternatives Considered

As an alternative, one could explore third-party libraries or workarounds to detect mouse movements from the main process. However, relying on external solutions might lead to compatibility issues or suboptimal performance, making an official Mouse API within Electron a more robust and integrated solution.

### Additional Information

A similar ticket addressing this concern was found in the Electron repository: [Issue #22058](https://github.com/electron/electron/issues/22058). Acknowledging this existing issue emphasizes the importance of adding mouse events support to the main process.
Repository: godot
Issue: [3.x] Debugger doesn't show stack variables in specific conditions
Labels: bug,topic:core,topic:gdscript,topic:editor,crash

### Godot version

v3.5.2.stable.official [170ba337a]

### System information

Ubuntu 22.04.2 LTS, GLES2

### Issue description

debugger doesn't show stack variables with autoload and resource with overridden _get method in the same scene:

```gdscript
# game.gd
extends Node


export var resource : Resource


func _ready() -> void:
	var foo := 2023
	var bar := "hello world"

```

```gdscript
# resource.gd
extends Resource


var _data := {}


func _get(property: String):  # Variant
	return _data[property]
```

```gdscript
# managers.gd
extends Node
```

the way to fix this is comment _get method in resource.gd or remove autoload from project settings.

### Steps to reproduce

1. launch attachment
2. add breakpoint in game.gd

### Minimal reproduction project

[New Game Project.zip](https://github.com/godotengine/godot/files/12103077/New.Game.Project.zip)
Repository: godot
Issue: Tilemap Navigation on Tiles doesn't support costs
Labels: enhancement,discussion

### Godot version

4.1.1

### System information

Godot v4.1.1.stable - Windows 10.0.19044 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1650 (NVIDIA; 31.0.15.3667) - AMD Ryzen 5 2600X Six-Core Processor (12 Threads)

### Issue description

I wanted to use Tilemap Navigation for creating my Navmesh/NavRegions for the NavigationServer2D and noticed that you cannot give costs values to the Navigation set on a tile. 

So you cannot use different weighted Nav-tiles, wich is sad.


### Steps to reproduce

Set up a tilemap, set up the navigation

### Minimal reproduction project

Since this is a missing element, you only need to create a projec,t, create a tileset, and try set up navigation on a tile
Repository: rust
Issue: emscripten failure to run with ASYNCIFY=2
Labels: T-compiler,O-wasm,C-bug,O-emscripten

Due to the issues described in #113852 , I wanted to try the [new ASYNCIFY=2 option](https://v8.dev/blog/jspi) of emscripten.
https://github.com/benjamin-sieffert/emscripten-sleep-bug/tree/bi
The branch compiles OK but produces the following error in the browser:
```
Uncaught TypeError: Cannot read properties of undefined (reading '0')
    at sigToWasmTypes (sdl_emscripten_template.js:1:67512)
    at sdl_emscripten_template.js:1:68357
    at Object.instrumentWasmImports (sdl_emscripten_template.js:1:68498)
    at sdl_emscripten_template.js:1:71488
```
Tested against emscripten-releases@00c70008e4b87ac4eba15bf2ab3ef2a1d44fa334 with both `rustc 1.73.0-nightly (39f42ad9e 2023-07-19) + build-std` and `rustc 1.71.0 (8ede3aae2 2023-07-12)` yielding the same outcome.

When using the `emcc` directly to compile and bundle C code with `ASYNCIFY=2`, it works fine.