sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Screen-space effect upscaling doesn't work properly (SSAO/GI)
Labels: bug,topic:rendering,confirmed,topic:3d

### Tested versions

From 4.0

### System information

Godot v4.3.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 (NVIDIA; 32.0.15.5599) - Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz (16 Threads)

### Issue description

Some post-processing effects don't upscale properly when rendered at half resolution.
For global illumination (voxel GI/SDFGI) it looks like upscaling doesn't work at all and results in low resolution looking image.
![image](https://github.com/user-attachments/assets/96434fce-a721-466a-9a4b-0cf1848a2b58)

For SSAO there are pixelated artifacts that result in weirdly doubled offset pixels.
![image](https://github.com/user-attachments/assets/4f88ab44-c531-4d0c-a5bc-bfa747f62886)


### Steps to reproduce

Add WorldEnvironment node to the scene
Enable SSAO and SDFGI

### Minimal reproduction project (MRP)

[screen-effect-upscale-bug.zip](https://github.com/user-attachments/files/16679060/screen-effect-upscale-bug.zip)
Repository: stable-diffusion-webui
Issue: [Bug]: API and Render Progress
Labels: bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [X] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [X] The issue has not been reported before recently
- [X] The issue has been reported before but has not been fixed yet

### What happened?

When using the API with multiple clients—potentially hundreds—all having direct access, it becomes impossible to identify which progress updates correspond to which jobs. This makes it difficult to accurately display each user's position in the queue and to show the correct render progress for their images. The current API's progress reporting is incomplete for this use case.

I suggest adding a queue endpoint to the API that shows pending or waiting jobs. Additionally, the API should allow for the inclusion of a custom field (e.g., client_job_id_info) where the client can add random text. This would enable each client to attach a custom ID or session identifier, making it easier to track if their job is currently processing.

### Steps to reproduce the problem

Kick off 2 jobs from the same client at same time, how do I know which was picked up first and what is processing

### What should have happened?

See above

### What browsers do you use to access the UI ?

Google Chrome

### Sysinfo

N/A

### Console logs

```Shell
N/A
```


### Additional information

_No response_
Repository: react
Issue: [DevTools Bug]: Inconsistent behavior; React dev tools does not recognize a react website; 'service worker(inactive)'
Labels: Type: Bug,Status: Unconfirmed,Component: Developer Tools

### Website or app

https://healthbridge-silk.vercel.app/

### Repro steps

I have a two profiles on my chrome browser one personal other work related.
1. Installed dev tool extension about a few months back on work profile.
2. Installed the same extension on my personal profile.
3. Works flawlessly on my work profile but in my personal profile has error "service worker(inactive)"

On my personal profile it does not recognize any react websites and on clicking the extension gives "Page does not seem to be using react". Works flawlessly on my work profile.

Image from my personal account:
![Screenshot_20240820_223428](https://github.com/user-attachments/assets/ef86ea22-a0f2-4cbb-80c2-97aab630afe2)

Image from my work account:
![image](https://github.com/user-attachments/assets/599160ca-61a5-4b7d-9924-04aed66a6aea)


EDIT: I checked the extension errors in my personal account and here is a screen shot of it:
There are no stack traces for any of the errors.
![image](https://github.com/user-attachments/assets/0b1805c9-4ce0-4ae6-96a0-e1d2e0ef5b04)



### How often does this bug happen?

Every time

### DevTools package (automated)

_No response_

### DevTools version (automated)

_No response_

### Error message (automated)

_No response_

### Error call stack (automated)

_No response_

### Error component stack (automated)

_No response_

### GitHub query string (automated)

_No response_
Repository: flutter
Issue: [webview_flutter] Support background color on macOS
Labels: platform-mac,p: webview,package,P2,team-macos,triaged-macos

Split from https://github.com/flutter/flutter/issues/41725 as the initial implementation as landed/published does not support this feature.

`NSView` doesn't have the same color and opacity controls that UIView does, so setting the background color will need alternate implementation (likely involving making the webview layer-backed).
Repository: flutter
Issue: [webview_flutter] Support getting and setting scroll position on macOS
Labels: platform-mac,p: webview,package,P2,team-macos,triaged-macos

Split from https://github.com/flutter/flutter/issues/41725 as the initial implementation as landed/published does not support this feature.

WKWebView doesn't expose a scrollView on macOS, so the code for getting and setting scroll position doesn't work. Currently they throw UnimplementedError; we should look into implementing those with JS calls on macOS as a polyfill instead for consistency of API support.
Repository: ollama
Issue: Model Library: Ability to update model manifest via editor
Labels: feature request

# TLDR

Direct updates of small, text-based files like parameters, template, license and system message **within the Ollama library** to avoid the time-consuming and bandwidth-heavy process of pulling, updating and pushing all tags of a model. This would simplify updates without affecting already existing possibilities with ollama-push.

# Details

Currently, when changes to a manifest/modelfile need to be made (e.g. template or parameters), all `N` tags of a model need to be pulled, updated and then pushed `N` times respectively.
This can be quite time consuming (especially for 70B+ models and with many quantizations) as well as somewhat wasteful regarding bandwidth of the Ollama library - especially since things like the template are often shared between all tags, so just one single object would need to be updated.

Perhaps updating purely text-based, small files/objects like parameters, license, system message and template could be done directly in the Ollama library, like the model readme can (by the author).  That would leave the fine-grained control via ollama-push untouched and not complicate anything there.
That's just what came to mind first though, there might be other sensible approaches as well.

Since the library is not open source as far as I'm aware, I can't help with contributing there myself, so here's a feature request to hopefully keep an eye on this topic. Many thanks!
Repository: flutter
Issue: [webview_flutter] Support scroll listener on macOS
Labels: platform-mac,p: webview,package,P2,team-macos,triaged-macos

Split from https://github.com/flutter/flutter/issues/41725 as the initial implementation as landed/published does not support this feature.

See also https://github.com/flutter/flutter/issues/153774 about scrolling itself.

The scroll position listener doesn't work on macOS. A JS polyfill would be more dangerous than for getting and setting the scroll position, since a listener would require injecting a script into every page on load, and could thus affect page behavior.
Repository: godot
Issue: Physics Interpolation affects Camera2D position smoothing on higher framerates
Labels: bug,confirmed,topic:physics,topic:2d

### Tested versions

- Reproducible in 4.2.stable, 4.3.stable

### System information

ArchLinux 6.10.2-arch1-1.1-g14 - KDE Plasma 6.1.4 - Godot 4.3.stable.arch_linux

### Issue description

When physics interpolation is activated, the camera smoothing actually goes faster than when it's deactivated for the same speed.

### Steps to reproduce

1. Have a monitor with a refresh rate higher than 60Hz
2. Set up a 2D platformer, with a Camera2D that has Position Smoothing turned on
3. Test the camera's physics
4. Go to settings, turn on physics interpolation
5. Test again

### Minimal reproduction project (MRP)

[test.zip](https://github.com/user-attachments/files/16679694/test.zip)
Repository: next.js
Issue: MQTT.JS example: the useEffect return cause client closure
Labels: examples

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
the useEffect return cause client closure and so the mqtt client is not usable in the other pages. 

return () => {
      if (client) {
        topicHandlers.forEach((th) => {
          client.unsubscribe(th.topic);
        });
        client.end();
      }
    };
```


### Which example does this report relate to?

mqtt.js

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

### Describe the Bug

the useEffect return cause client closure and so the mqtt client is not usable in the other pages. 

### Expected Behavior

the useEffect return cause client closure and so the mqtt client is not usable in the other pages. 

### To Reproduce

Use the example
Repository: flutter
Issue: When discovering iOS devices: `ProcessException: Resource temporarily unavailable`
Labels: c: crash,good first issue,P2,team-tool,triaged-tool

As of today (8/20), on 3.24.0: 221 reports from 102 unique clients (top 20ish crasher)

From flutter commands (looking at first 20 reports): `flutter daemon`

```
ProcessException: Resource temporarily unavailable  Command: /usr/bin/xcrun simctl list devices booted iOS --json
at _ProcessImpl._start(process_patch.dart:402)
at Process.start(process_patch.dart:38)
at _runNonInteractiveProcess(process_patch.dart:579)
at Process.run(process_patch.dart:49)
at LocalProcessManager.run(local_process_manager.dart:72)
at ErrorHandlingProcessManager.run.<anonymous closure>(error_handling_io.dart:669)
at _run(error_handling_io.dart:564)
at ErrorHandlingProcessManager.run(error_handling_io.dart:668)
at _DefaultProcessUtils.run(process.dart:312)
at SimControl._listBootedDevices(simulators.dart:162)
at SimControl.getConnectedDevices(simulators.dart:187)
at IOSSimulatorUtils.getAttachedDevices(simulators.dart:75)
at IOSSimulators.pollingGetDevices(simulators.dart:49)
at PollingDeviceDiscovery._initTimer.<anonymous closure>(device.dart:498)
at _rootRun(zone.dart:1391)
at _CustomZone.run(zone.dart:1301)
at _CustomZone.runGuarded(zone.dart:1209)
at _CustomZone.bindCallbackGuarded.<anonymous closure>(zone.dart:1249)
at _rootRun(zone.dart:1399)
at _CustomZone.run(zone.dart:1301)
at _CustomZone.bindCallback.<anonymous closure>(zone.dart:1233)
at Timer._createTimer.<anonymous closure>(timer_patch.dart:18)
at _Timer._runTimers(timer_impl.dart:398)
at _Timer._handleMessage(timer_impl.dart:429)
at _RawReceivePort._handleMessage(isolate_patch.dart:184)
```
Repository: rust
Issue: Overly conservative async capture analysis when values are borrowed
Labels: WG-async,I-async-nominated

There's probably a bug filed already but [this code](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=41fec3d02ac841085788c4e058765e7b) does not compile, though it really ought to:

```rust
use std::sync::Mutex;

async fn foo(m: &Mutex<u32>) {
    let lock = m.lock().unwrap();
    if condition(&lock) {
        drop(lock);
        return bar().await;
    }
    
    drop(lock);
    return bar().await;
}

async fn bar() { }

fn is_send<T: Send>(t: T) { }

fn condition(x: &u32) -> bool {
    false
}

fn main() {
    let m = Mutex::new(22);
    is_send(foo(&m));
}
```

I believe the problem is specific to the `&lock`, which causes the capture analysis to get nervous -- even though `lock` is dropped. This is distilled from real-world code within Amazon.

Error you get today:

```
error: future cannot be sent between threads safely
  --> src/main.rs:26:13
   |
26 |     is_send(foo(&m));
   |             ^^^^^^^ future returned by `foo` is not `Send`
   |
   = help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `MutexGuard<'_, u32>`, which is required by `impl Future<Output = ()>: Send`
note: future is not `Send` as this value is used across an await
  --> src/main.rs:9:22
   |
6  |     let lock = m.lock().unwrap();
   |         ---- has type `MutexGuard<'_, u32>` which is not `Send`
...
9  |         return bar().await;
   |                      ^^^^^ await occurs here, with `lock` maybe used later
note: required by a bound in `is_send`
  --> src/main.rs:18:15
   |
18 | fn is_send<T: Send>(t: T) { }
   |               ^^^^ required by this bound in `is_send`
```

I'm nominated for async just to get some eyes on this. I'd be interested to discuss fixes, I have a few thoughts, though I'd have to look at the code too.
Repository: vscode
Issue: [Accessibility] Support audio cue for commented range
Labels: accessibility,under-discussion,comments

Type: <b>Feature Request</b>

CC @meganrogge 

I (and other blind programmers in a professional setting) do code-review a lot and I encounter the need where I have to navigate the source code and commented ranges.

Sighted people can visually see from where to where the comments are applied in their current editor. Following the successful implementation of other audio cues, such as error, warning, etc., could you please consider supporting commented ranges via audio cue?

## Some Considerations

1. This audio cue needs to be designed in the least distruptive mannaer because sometimes users may mix multiple audio cues simultaneously. White noise might be a possible option.

1. This audio cue should be disabled by default to avoid any confusion against the existing audio cues

1. Info on this audio cue could be included in the Accessible Help for the comment thread for its discoverability

VS Code version: Code - Insiders 1.93.0-insider (e2b54301a5745870f6b95d81c91fb3e9557d4f08, 2024-08-20T08:04:15.567Z)
OS version: Windows_NT x64 10.0.22631
Modes:


<!-- generated by issue reporter -->
Repository: godot
Issue: RootMotionTrack randomly modifying animated model's root bone pose in Editor
Labels: bug,needs testing,topic:animation,topic:3d

### Tested versions

Godot 4.3, 4.2.2, 4.2.1

### System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated GeForce GTX 1060 6GB - Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz (12 Threads)

### Issue description

I have a 3D character model that uses Root Motion in its animation. At random, the model will be offset by the Root Motion and end up floating in the air or standing several dozen feet away from its actual origin point.

To fix it, I have to:
-Go to the Animation Player
-Unassign the Root Motion Track
-Play animations where the model is at the correct point of origin- sometimes going to a different animation and then back again
-Then setting the Root Motion Track again

Information:
-The character model is using a saved Animation Library, derived from its own Animations
-The character uses several Animation Trees that are linked to its Animation Player. Only one is Active at a time.
-Each Animation Tree has the same Root Motion Track selected, matching the Animation Player
-Toggling "Show Rest Only" on the Skeleton3D works as it should, and turning it off returns the character to the incorrect position
-Neither playing any given animation nor any amount of scripted movement has an effect on the offset
-Animations played through the Animation Player have no effect on the offset
-The issue never triggers in-game, only in the editor. The issue remains in effect when going in-game

### Steps to reproduce

I can't determine what the circumstances under which it keeps reoccurring, but it can be achieved manually:
-Import an animated model with Root Motion in the animations
-Leave the Root Motion Track empty
-Play an animation that includes Root Motion
-Assign the Root Motion Track when the model is moved away from its origin point in the animation

But the issue crops up randomly. I haven't been able to catch when it happens, so I can't figure out why.

### Minimal reproduction project (MRP)

"If the reproduction steps are not project dependent (e.g. the bug is visible in a brand new project), you can write "N/A" in the field."
N/A
Repository: ollama
Issue: Microsoft Phi-3.5 models
Labels: model request

- [Phi-3.5-mini-instruct](https://huggingface.co/microsoft/Phi-3.5-mini-instruct)
- [Phi-3.5-MoE-instruct](https://huggingface.co/microsoft/Phi-3.5-MoE-instruct)
- [Phi-3.5-vision-instruct](https://huggingface.co/microsoft/Phi-3.5-vision-instruct)
Repository: pytorch
Issue: vmap tests aren't erroring on fallback usage
Labels: triaged,module: vmap,module: functorch

### 🐛 Describe the bug

When writing tests, I seemed to notice that even if the test triggered the fallback (and i didn't add any annotations), it still wouldn't error.

cc: @zou3519 @guilhermeleobas 

### Versions

N/A

cc @zou3519 @samdow @kshitij12345 @janeyx99
Repository: vscode
Issue: Transparent image grid isn't intuitive
Labels: bug,help wanted,image-preview

I created this tiny file:

![glyph_a_0_13px_Hack___Powerline_Extra_Symbols____Hack_NF_](https://github.com/user-attachments/assets/c7906481-5182-4cc6-b948-adb1e6bfb03a)

When I zoom in and out it looks like there are dark squares on the image since the grid scales with zoom:

![Recording 2024-08-20 at 13 29 13](https://github.com/user-attachments/assets/fef71493-4634-4b3e-b07e-a3a3b28634ba)

It's much more clear if the transparency grid doesn't scale like this:

![Recording 2024-08-20 at 13 30 13](https://github.com/user-attachments/assets/dc02ea3f-9413-4417-90fc-0918ee624b6d)
Repository: go
Issue: x/tools/gopls: make docs discoverable
Labels: Documentation,gopls,Tools

A Google search for "[gopls features](https://github.com/golang/tools/blob/master/gopls/doc/features/README.md)" or "[Gopls: Code transformation features](https://github.com/golang/tools/blob/master/gopls/doc/features/transformation.md)" still after several weeks doesn't turn up gopls' lovingly rewritten documentation. We should fix that.

Related: @hyangah will add a feature to VS Code to make the "Browse gopls feature documentation" command more prominent.
- https://github.com/golang/vscode-go/issues/3498

Also, @hyangah wonders whether the gopls markdown documentation should be canonically hosted not at GitHub but in pkg.go.dev. (I vaguely recall @rsc saying there was some reason we should not rely on pkgsite's markdown feature, but I forget what it was.) @hyangah suggested alternatively hosting them at go.dev/something.
Repository: rust
Issue: Tracking Issue for `lazy_get`
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(lazy_get)]`

This is a tracking issue for `LazyCell/Lock::get[_mut]()`, allowing you to extract a reference from a `Lazy` only if it is initialized, approved in ACP https://github.com/rust-lang/libs-team/issues/429.

<!--
Include a short description of the feature.
-->

### Public API
```rust
impl<T, F> core::cell::LazyCell<T, F> {
    pub fn get(this: &Self) -> Option<&T>;
    pub fn get_mut(this: &mut Self) -> Option<&mut T>;
    pub fn force_mut(this: &mut Self) -> &mut T;
}
impl<T, F> std::sync::LazyLock<T, F> {
    pub fn get(this: &Self) -> Option<&T>;
    pub fn get_mut(this: &mut Self) -> Option<&mut T>;
    pub fn force_mut(this: &mut Self) -> &mut T;
}
```

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] ACP: https://github.com/rust-lang/libs-team/issues/429
- Implementation:
  - [ ] https://github.com/rust-lang/rust/pull/129334
  - [ ] https://github.com/rust-lang/rust/pull/130476
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: flutter
Issue: [web] support semantic-only rendering mode
Labels: engine,platform-web,c: rendering,P2,team-web,triaged-web

Not all browser environments fully support WebGL. For example, [Clarity](https://clarity.microsoft.com/) (described [here](https://github.com/flutter/flutter/issues/145954#issuecomment-2299704046)) can run web apps but WebGL content is rendered as black pixels. Similar limitations apply to some web/ads crawlers.

It should be relatively easy for Flutter web to have a mode that makes rendering into WebGL a noop. The semantics tree can still be fully rendered, and we already have a mode where we make the semantics tree visible for debugging. This mode could be sufficient for use-cases such as heat maps and indexing, while reducing the requirement that the browser provide a full-featured WebGL implementation.
Repository: ui
Issue: [bug]: AreaChart overflow to negative for curving.
Labels: bug

### Describe the bug

The AreaChart component overflowing to negative for make a 'curve'. I do not think this is intended behavior.

### Affected component/components

AreaChart

### How to reproduce

1. Add default AreaChart component
2. Set the charData's last 10-15 to zero (both mobile & desktop)
3. Open the chart
4. Change the range of it in select to "Last 7 days" and back to "Last 3 Months"

![Screenshot from 2024-08-21 00-22-23](https://github.com/user-attachments/assets/a0be66a2-5cfc-4d59-9b3b-0ae62b9e5c33)


### Codesandbox/StackBlitz link

_No response_

### Logs

```bash
-no logs-
```


### System Info

```bash
Firefox 129.0.1
Ubuntu 22.04
```


### Before submitting

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