sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Add `context.dependOnListenable(Listenable listenable)`
Labels: c: new feature,framework,c: proposal,P3,team-framework,triaged-framework

### 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

Right now, if you have mutable state bound to the widget tree via an inherited widget, you can trivially subscribe to it from anywhere with a valid reference to context:
```dart
  Widget build(BuildContext context) {
    final FooData foo = context.dependOnInheritedWidgetOfExactType<FooController>()!.data;
    return FooView(foo);
  }
```

But this is needlessly opinionated-why can I only subscribe to listenable state if it's held by the widget tree? Lets say I decide to refactor my `FooController` from an inherited widget to some other state management solution. This is much more verbose and not very isomorphic to the `InheritedWidget` solution:
```dart
  Widget build(BuildContext context) {
    // Could be slightly simplified by using `ValueListenable` and `ValueListenableBuilder`...
    return ListenableBuilder(
      listenable: myState.fooController,
      builder: (context, child) {
        final FooData foo = myState.fooController.data;
        return FooView(foo);
      },
    );
  }
```

Add dependencies on a couple more pieces of state and this immediately becomes an unreadable nightmare.

Ideally, my app code would look more or less the same regardless of where I chose to hold my state. I often find myself using provider to bind widget-tree-agnostic listenable state to the widget tree just to avoid `*Builder` verbosity.

### Proposal

Provide the following two functions:
```dart
abstract class BuildContext {
  ...
  /// Subscribes to a listenable and triggers rebuilds whenever
  /// it notifies its listeners.
  /// For convenience this could return the listenable instead of void,
  /// but that feels out of keeping with things like `ListenableBuilder`.
  void dependOnListenable(Listenable listenable) { ... }
  
  /// Convenience method for the sub case of ValueListenables.
  T dependOnValueListenable<T>(ValueListenable<T> valueListenable) { ... }
  ...
}
```

Now our example from earlier looks like the following:
```dart
  Widget build(BuildContext context) {
    context.dependOnListenable(myState.fooController);
    final FooData foo = myState.fooController.data;
    return FooView(foo);
  }
```

This is a little awkward because we reference `myState.fooController` twice. This looks even cleaner in the `ValueListenable` case:
```dart
  Widget build(BuildContext context) {
    // Now assuming that `FooController` implements `ValueListenable<FooData>`.
    final FooData foo = context.dependOnValueListenable(myState.fooController);
    return FooView(foo);
  }
```

I'll admit I don't understand the inner workings of the build cycle well so maybe there are serious gotchas here that I'm not aware of. If so please let me know and I'm happy to try and work through it here!
Repository: godot
Issue: Constant freezing in Godot and very long start-up times
Labels: topic:core,needs testing,performance

### Godot version

4.1.1.stable

### System information

Windows 11 - 4.1.1.stable - Vulkan (Forward+)

### Issue description

Opening the project manager in Godot as well as editing the project in the editor is painfully slow and has constant freezing issues. It is likely due to the high startup time for the Godot servers:

```
BENCHMARK:
        - register_core_types :  0.004062  sec.
        - servers :  70.432877  sec.
        - register_editor_types :  0.001205  sec.
        - scene :  0.061486  sec.
        - editor_register_and_generate_icons_all :  0.063672  sec.
        - editor_register_and_generate_icons_with_only_thumbs :  0.000644  sec.
        - editor_register_fonts :  0.001264  sec.
        - create_editor_theme :  0.151104  sec.
        - create_custom_theme :  0.151117  sec.
        - project_manager :  0.185759  sec.
        - startup_begin :  70.69265  sec.
```

### Steps to reproduce

Run in the command line:

Godot_v4.1.1-stable_win64.exe --verbose --benchmark

### Minimal reproduction project

Occurs in all projects
Repository: stable-diffusion-webui
Issue: [Bug]: identical settings/seed yet changed output between webui restarts
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

I noticed ever since I started using local that the images that I save to use hires fix on, when I go back to do them look different than the original ones I saved, and I can't figure out the behavior. 

I haven't changed any of my settings, and I'm not even sure if I'm doing anything between the same seeds randomly changing output, but in the last experience I know for a fact that I restart the webui and the image I get now looks different.

I have these related settings enabled

Stable Diffusion
```

Enable quantization in K samplers for sharper and cleaner results. This may change existing seeds

Make K-diffusion samplers produce same images in a batch as when making a single image

Random number generator: NV
```
Optimizations

```
Cross attention otpimization: InvokeAI

Pad prompt/negative prompt to be same length
 
Persistent cond cache
 
Batch cond/uncond
```

This is on an 6800XT on linux. From what I can tell, it doesn't happen every time with every image, but not sure. Maybe there is some known issue or it's amd related or something. I used colab before with t4 and that never happened there, no matter how many times I restarted it was awlays the same image with identical settings.

### Steps to reproduce the problem

1. start webui, gen some images or run some xyz. 
2. close webui and then start it again
3. generate with the same settings and seed and have different outputs.

before -> after
![image](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/15861396/5b3b403e-db36-4eec-b85a-377b3d055115) ![image](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/15861396/b3abde15-3387-47e1-8535-f6f6a48b0679)



### What should have happened?

Same image result across every restart

### Sysinfo

[sysinfo-2023-09-19-20-02.txt](https://github.com/AUTOMATIC1111/stable-diffusion-webui/files/12665968/sysinfo-2023-09-19-20-02.txt)


### What browsers do you use to access the UI ?

Google Chrome

### Console logs

```Shell
There is no related log
```


### Additional information

_No response_
Repository: rust
Issue: On MacOS `std::fs::copy` does not modify the timestamp of the destination
Labels: O-macos,C-bug,T-libs

I was just debugging different behavior between Linux and MacOS builds in our CI, and it turns out, it came to `sqlite-sys` crate using `build.rs` script that uses `std::fs::copy`, which on MacOS seems to be using `fcopyfile` call which preserves the modification, access, and creation timestamps from the source file to the destination file by default.

This is an inconsistency with implementations on other platforms, I believe.

It seems that `COPYFILE_STAT` flag could be turned off on that call, but that will also prevent mode from being copied, which seems copied on other implementations. So AFAICT making behavior consistent would cost an extra syscall.

Unless I'm mistaken somewhere altogether (happens a lot), at very least this should be explicitly documented.

Personally, I would prefer this being made consistent. As unreliable as they can sometimes be mtimes are often used for things like caching, and it's no fun to hunt down weird caching bugs etc. that happen only on one platform.
Repository: flutter
Issue: [Impeller] Remove `release()` calls for vulkan resources.
Labels: engine,P2,c: tech-debt,e: impeller,team-engine,triaged-engine

The shutdown sequence for the vulkan backend is a bit loosy goosy.  Originally there were race conditions in the vulkan backend surrounding using the vulkan device from background threads after the device has been shutdown.  This was remedied by adding the `DeviceHolder` class.  That way the device can be checked if it is still alive while it is being used.  This has lead to cleanup code like `PipelineVK::~PipelineVK`:

```c++
PipelineVK::~PipelineVK() {
  std::shared_ptr<DeviceHolder> device_holder = device_holder_.lock();
  if (device_holder) {
    descriptor_set_layout_.reset();
    layout_.reset();
    render_pass_.reset();
    pipeline_.reset();
  } else {
    descriptor_set_layout_.release();
    layout_.release();
    render_pass_.release();
    pipeline_.release();
  }
}
```

Nothing is leaked when `release()` is used because all of the vulkan objects are just opaque pointers that get cleaned up when vulkan shuts down.

The downsides to how things work today is:
1) It's hard to reason about what is actually happening and in what order things are shutdown
1) `release()` is unfortunately an overloaded name from C++'s smart pointers which has different semantics

We should remove all instances of `release()`.  Doing so would require a more deterministic shutdown sequence.

If we had that, we may be able to remove `DeviceHolder` also.  That is a bit complicated from our usage of injected thread pools, but should be possible.  We can just null out the device reference instead.

```c++
ContextVK::~ContextVK {
  auto latch = Latch::Make();
  thread_pool_->PostTask([&]() {
    object_->SetVulkanDevice({});
    latch.Signal();
  });
  latch.Wait();
  vulkan_device_.reset();
}
```

cc @matanlurey
Repository: godot
Issue: Cannot close "Failed to build project" (C#) dialog with keyboard
Labels: bug,topic:editor,usability,topic:dotnet

### Godot version

v4.2.dev5.mono.official [e3e2528ba]

### System information

Godot v4.2.dev5.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 6GB (NVIDIA; 31.0.15.3640) - Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz (4 Threads)

### Issue description

When a C# project build fails, a "Failed to build project" dialog is displayed. This dialog doesn't get keyboard focus, so the only way to close the dialog is to use mouse. However, the dialog can be ignored and it goes away if the next build succeeds.

![kuva](https://github.com/godotengine/godot/assets/49998025/71b773b5-3749-4ba5-8727-65eb835b5bd2)

In my opinion this is a quite annoying usability problem as the build failing is a common event. Either give the dialog keyboard focus so that it can be easily closed or even better, remove the dialog altogether as (in my opinion) the dialog doesn't contain any useful information. If the build fails, I can see it from Output. Maybe the "Failed to build project" text could be moved from the dialog to Output.

### Steps to reproduce

Any C# project that doesn't compile.

### Minimal reproduction project

N/A
Repository: node
Issue: `Promise.resolve('import("node:fs")').then(eval)` throws `TypeError: Invalid host defined options`
Labels: confirmed-bug,esm

### Version

v20.7.0

### Platform

Linux PIG-2016 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

### Subsystem

esm

### What steps will reproduce the bug?

```sh
node -e 'Promise.resolve(`import("node:fs")`).then(eval)'
```

### How often does it reproduce? Is there a required condition?

_No response_

### What is the expected behavior? Why is that the expected behavior?

it shouldn't throw.

### What do you see instead?

these DONT throw
```sh
node -e 'Promise.resolve(`import("node:fs")`).then(x=>globalThis.eval(x))'
node -e 'Promise.resolve(`import("node:fs")`).then(x=>(0,eval)(x))'
node -e 'Promise.resolve(`34`).then(eval)'
node -e 'Promise.resolve().then(eval)'
node -e 'eval(`import("node:fs")`)'
node -e 'globalThis.eval(`import("node:fs")`)'
node -e '(0,eval)(`import("node:fs")`)'
node -e '`import("node:fs")`.replace(/^.*$/s,eval)'
```

these DO throw
```sh
node -e 'Promise.resolve(`import("node:fs")`).then(eval)'
node -e 'Promise.resolve(`import("node:fs")`).then((0,eval))'
node -e 'Promise.resolve(`import("node:fs")`).then(globalThis.eval)'
```

```js
jcbhmr@PIG-2016:~$ node
Welcome to Node.js v20.7.0.
Type ".help" for more information.
> Promise.resolve('import("node:fs")').then(eval)
Promise {
  <pending>,
  [Symbol(async_id_symbol)]: 234,
  [Symbol(trigger_async_id_symbol)]: 233
}
> Uncaught TypeError: Invalid host defined options
    at eval (eval at processTicksAndRejections (node:internal/process/task_queues:95:5), <anonymous>:1:1)
    at eval (<anonymous>)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
>
```

### Additional information

deno version of the same thing DOESN'T throw:
```js
jcbhmr@PIG-2016:~$ deno
Deno 1.36.3
exit using ctrl+d, ctrl+c, or close()
REPL is running with all permissions allowed.
To specify permissions, run `deno repl` with allow flags.
> Promise.resolve('import("node:fs")').then(eval)
Promise {
  [Module: null prototype] {
    Dir: [class Dir],
    Dirent: [class Dirent],
    F_OK: 0,
    O_APPEND: 8,
    O_CREAT: 512,
    O_DIRECTORY: 1048576,
    O_DSYNC: 4194304,
    O_EXCL: 2048,
    O_NOCTTY: 131072,
...
```
Repository: pytorch
Issue: InstanceNorm does not catch dim mismatch
Labels: module: nn,triaged,actionable

### 🐛 Describe the bug

InstanceNorm with a specified input C works on tensors of arbitrary dimensions/channels (with the number of channels not necessarily matching C) without throwing a dimension mismatch error. For example:

```
m = torch.nn.InstanceNorm1d(64)
input = torch.randn(4, 80, 300)
output = m(input)
```

### Versions

PyTorch v2.0

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: next.js
Issue: Unable to run `localFont()` in jest: (0 , local_1.default) is not a function
Labels: bug,Font (next/font)

### Link to the code that reproduces this issue

https://github.com/arthur-zhao-anrok/next_bug_repro_repo

### To Reproduce

1. `cd reproduction-app/`
2. `npm install`
3. `npm run test`

### Current vs. Expected behavior

Current behavior: the test errs out with the following error:

```
/Users/xxxx/Github/next_bug_repro_repo/reproduction-app/app/font_util.js:4
var aktivGrotesk = (0, local_1.default)({
                                       ^

TypeError: (0 , local_1.default) is not a function
    at Object.<anonymous> (/Users/arthurzhao/Github/next_bug_repro_repo/reproduction-app/app/font_util.js:4:40)
    at Module._compile (node:internal/modules/cjs/loader:1119:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1173:10)
    at Module.load (node:internal/modules/cjs/loader:997:32)
    at Module._load (node:internal/modules/cjs/loader:838:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:18:47

Node.js v18.8.0
```

Expected behavior: the test should run successfully.


### Verify canary release

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

### Provide environment information

```bash
Operating System:
   Platform: darwin
   Arch: arm64
   Version: Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T6000

Binaries:
   Node: 18.8.0
   npm: 8.18.0
   Yarn: 4.0.0-rc.38
   pnpm: N/A

Relevant Packages:
   next: 13.5.1-canary.1
   eslint-config-next: N/A
   react: 18.2.0
   react-dom: 18.2.0
   typescript: 5.1.3
    
Next.js Config:
   output: N/A
```


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

Font optimization (next/font)

### Additional context

I tested my reproduction against both the canary release and v13.4.10.

In my actual production project, I used `localFont()` in a module called `theme.ts` that is used by multiple frontend components. It works well in production when those frontend components were used as part of the Next.js frontend app.

However, when I used Jest to test the modules that relies on `theme.ts`, the tests would err out when importing those modules. I ended up mocking `next/font/local` to circumvent the issue.

Similar issue on StackOverflow: https://stackoverflow.com/questions/76659367/typeerror-0-local-default-is-not-a-function-when-using-next-font-local-in-j
Repository: godot
Issue: New Item List Scroll while Key Press in File System
Labels: bug,usability,topic:input,topic:gui

### Godot version

4.1.1 stable official

### System information

Godot v4.1.1.stable - Windows 10.0.19045 - Vulkan (Mobile) - dedicated NVIDIA GeForce GT 1030 (NVIDIA; 31.0.15.3734) - AMD Ryzen 3 3100 4-Core Processor (8 Threads)

### Issue description

Right click to create a new file in file system, then choose something, next time you right click and use arrow key up/down to select any item, the selection goes through all the item instead of 1 step. it's a keystore, not holding.

### Steps to reproduce

In File System> Right Click to create a new item using mouse
then right click to create a new item but use arrow keys to select something
 

### Minimal reproduction project

Empty project will do.
Repository: pytorch
Issue: FSDP: ShardedStateDict support for world_size = 1
Labels: oncall: distributed,module: fsdp

### 🐛 Describe the bug

When iterating with FSDP code, it's sometimes useful to set world_size = 1 to sanity check some things before launching larger job. However, this currently requires switching the state_dict code logic to use FULL_STATE_DICT instead of ShardedStateDict, which is a bit inconvenient from developer velocity perspective.

This can be repro'd by setting world_size = 1 + using StateDictType.ShardedStateDict, and trying to load in a checkpoint.

### Versions

main

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin
Repository: pytorch
Issue: [FSDP] UnpicklingError when calling save_state_dict in distributed run
Labels: oncall: distributed,triaged,module: fsdp

### 🐛 Describe the bug

we are using multi-nodes training with FSDP, and we got the following error during checkpointing through `torch/distributed/checkpoint/state_dict_saver.py`
```
File "/opt/ml/code/checkpoints.py", line 153, in _save
checkpoint.save_state_dict(
  File "/opt/conda/lib/python3.10/site-packages/torch/distributed/checkpoint/state_dict_saver.py", line 119, in save_state_dict
return distW.all_reduce("write", write_data, finish_checkpoint)
  File "/opt/conda/lib/python3.10/site-packages/torch/distributed/checkpoint/utils.py", line 236, in all_reduce
final_result = self.broadcast_object(result)
  File "/opt/conda/lib/python3.10/site-packages/torch/distributed/checkpoint/utils.py", line 88, in broadcast_object
dist.broadcast_object_list(
  File "/opt/conda/lib/python3.10/site-packages/torch/distributed/distributed_c10d.py", line 1451, in wrapper
return func(*args, **kwargs)
  File "/opt/conda/lib/python3.10/site-packages/torch/distributed/distributed_c10d.py", line 2277, in broadcast_object_list
object_list[i] = _tensor_to_object(obj_view, obj_size)
  File "/opt/conda/lib/python3.10/site-packages/torch/distributed/distributed_c10d.py", line 1970, in _tensor_to_object
return _unpickler(io.BytesIO(buf)).load()
_pickle.UnpicklingError: invalid load key, '\x00'.
```
originally, we thought that it only happened when we overwrite checkpoint to an existing folder, but we recently observed the error occurred even when writing to fresh folder. thus this error is non-deterministic. it might be related to these issues https://github.com/pytorch/pytorch/issues/109396 

### Versions

```
Collecting environment information...
PyTorch version: 2.0.1
Is debug build: False
CUDA used to build PyTorch: 11.8
ROCM used to build PyTorch: N/A
```

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin
Repository: material-ui
Issue: [material-ui][Tooltip] Repositioning happening after the initial load
Labels: bug 🐛,component: tooltip,package: material-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example:

https://codesandbox.io/s/mfmmvq?file=/Demo.tsx

This is just the straight codesand box from the docs here: 

https://mui.com/material-ui/react-tooltip/#basic-tooltip

Mouse over the icon and see that there is a slight repositioning after the tooltip comes in. 


Code Sandbox: 

https://github.com/mui/material-ui/assets/2467377/d0b35037-0550-4899-a55f-a357ba371a2d

Curiously enough, it only happens on the CodeSandbox (also my environment), not on the Mui website. 

Mui Website: 


https://github.com/mui/material-ui/assets/2467377/4b497131-117a-48c1-a89e-164dbeecf1a6







### Current behavior 😯

There is a slight reposition after the tooltip appears. 

### Expected behavior 🤔

There should not be a reposition. 

### Context 🔦

It's bugging me. 

Could be related to this issue: https://github.com/mui/material-ui/issues/8040

### 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>