sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Font Hinting (or positioning) seems slightly off.
Labels: bug,topic:gui

### Tested versions

4.2.1 stable

### System information

Windows 10, Vulkan forward +, Nvidia 3070

### Issue description

When using a strongly hinted font, such as Tahoma, where the vertical lines should be pixel perfect, I've noticed that I can't seem to get pixel perfect hinted fonts in Godot.

Here are the import settings I'm using, which should be pixel perfect for a font at size 24:
![image](https://github.com/godotengine/godot/assets/7751182/92056465-8ba9-4a3d-a195-a35127afc06d)

If you zoom in, you can see the vertical lines are not pixel perfect:
![image](https://github.com/godotengine/godot/assets/7751182/43a79c62-87da-4e55-9a12-25e728df0f3f)

Though the horizontal lines do seem correct, which makes me wonder if the font is actually importing properly, but being positioned off pixel horizontally when displayed in the controls.

For comparison, this is how the font looks in the ttf viewer in Windows:
![image](https://github.com/godotengine/godot/assets/7751182/32351e0b-f2ef-4b28-91ee-553dbc9c0475)

And zoomed in:
![image](https://github.com/godotengine/godot/assets/7751182/5c903d61-c212-4dbf-8696-1a65e6b6aa30)


Notice everything is pixel perfect here for the vertical and horizontal lines with font size 24.


### Steps to reproduce

Use a font that has strong hinting, such as Tahoma.
In the import settings, set hinting to "Normal".
Might need to set subpixel positioning to "Disabled" (didn't seem to change anything, but I've heard it helps).
Use the font in a theme and set it to one of the sizes that hints well, like 24 or 12.

### Minimal reproduction project (MRP)

[test_font_hint(add own tahoma.ttf).zip](https://github.com/godotengine/godot/files/15005295/test_font_hint.add.own.tahoma.ttf.zip)

I've included a test project, but you will have to supply your own copy of tahoma.ttf, as I don't think it's legal to redistribute it.  Should be on any copy of Windows, though.  I couldn't find another font that had hinting this strong to use as an example.
Repository: vscode
Issue: Slow  edits and completions when editing Python code
Labels: bug,perf

Reported by @ale-dg here https://github.com/microsoft/vscode/issues/206119#issuecomment-1996165888

Yes, but consider I did not use Pylance. Would you like me to test with it? I just activated it and opened the log trace for python and just for indexing it finishes its memory.

2024-03-13 17:51:01.092 [info] [Info - 17:51:01] (4192) Heap stats: total_heap_size=1220MB, used_heap_size=1156MB, total_physical_size=1218MB, total_available_size=2900MB, heap_size_limit=4096MB

2024-03-13 17:51:01.108 [info] [Warn - 17:51:01] (4192) Workspace indexing has hit its upper limit: 2000 files
Repository: pytorch
Issue: [FSDP] Unreleased reserved memory after FSDP wrap
Labels: oncall: distributed

### 🐛 Describe the bug

When I was fine-tuning lLama2-70b on Intel GPU (64G/card, 8 cards), I met out of memory issue after FSDP wrap. Here is the printed log before and after FSDP wrap:

>===memory_allocated before fsdp:  0.0 GB
===memory_reserved before fsdp:  0.0 GB
===memory_allocated after fsdp:  33.494 GB 
===memory_reserved after fsdp:  59.779  GB 

The allocated memory is exactly from the base model weights (70b * 4 byte / 8), while there is 26GB reserved memory unreleased. I think that's why OOM happens.

### Case verification based on one decoder layer
To verify the case, I simplified the question and tested the dummy model (with only one decoder layer) on 2 cards. Here is the printed log:

> all params for one decoder layer: 202383360
weight memory: 202383360 * 4 byte / 2 card / (1024)^3 = 0.377 GB
=======fsdp memory_allocated before wrap:  0 GB
=======fsdp memory_reserved before wrap:  **0 GB**
model = FSDP (model) # wrap here
=======fsdp memory_allocated after wrap:  0.381 GB
=======fsdp memory_reserved after wrap:  **2.502 GB**

In this case, the allocated memory is also compatible with base model weights, while there are still increased reserved memory unreleased.  I found that the unreleased memory comes from three parts: `_sync_module_params_and_buffers`, `FlatParamHandle.flatten_tensors`, and `FlatParamHandle._get_shard` in FSDP wrap:

>**=== part 1: sync module**
=======fsdp memory_allocated before sync module:  0.758 GB
=======fsdp memory_reserved before sync module:  **0.775 GB**
=======fsdp memory_allocated after sync module:  0.758 GB
=======fsdp memory_reserved after sync module:  **1.367 GB**
**=== part2: flat params**
=======fsdp memory_allocated before flat:  0.758 GB
=======fsdp memory_reserved before flat:  **1.367 GB**
=======fsdp memory_allocated after flat:  1.512 GB
=======fsdp memory_reserved after flat:  **2.123 GB**
**=== part3: get shard**
=======fsdp memory_allocated before shard:  1.512 GB
=======fsdp memory_reserved before shard:  **2.123 GB**
=======fsdp memory_allocated after shard:  1.135 GB
=======fsdp memory_reserved after shard:  **2.502GB**

Should this situation be expected? Does Pytorch have plan to fix this issue for more efficient memory management.

Although I can use  `torch.cuda.empty_cache()` to overcome this problem, would it be ok?

Hope this problem solved officially, thank you!!


cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @wconstab @yf225 @chauhang
Repository: electron
Issue: [Bug]: IndexedDB corrupted and reset when no disk space
Labels: platform/linux,bug :beetle:,has-repro-gist,30-x-y

### 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 bug report that matches the one I want to file, without success.

### Electron Version

30.0.0

### What operating system are you using?

Other Linux

### Operating System Version

Debian 12

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

IndexedDB should preserve its existing data when not able to perform any more writes.

### Actual Behavior

IndexedDB becomes corrupted and Chromium resets it, deleting all existing data.

### Testcase Gist URL

https://gist.github.com/shadow-light/e00da7bf774f343917627b72a03e075c

### Additional Information

Please see the Gist for clear instructions on reproducing this. It happens every time for me.

This is a big problem for novice users who run out of disk space. I've had several cases of users losing all their data due to low disk space. I could only reproduce on Linux when there was absolutely no space, but I suspect it might occur earlier than that on different OSs.

I doubt Chromium will be interested in prioritising a fix for this, since browser data is expected to be transient. But on Electron the IndexedDB has been set to be unlimited, offering persistent data. If this can't be fixed then developers should be dissuaded from using IndexedDB and rely on an alternative like SQLite instead.

LevelDB appears to offer a method for recovering as much data from a corruption as possible, but Chromium appears to not use it and just wipes the whole database.
Repository: flutter
Issue: In dark mode, the CupertinoTextField cannot display text colors
Labels: a: text input,framework,f: cupertino,has reproducible steps,P3,workaround available,found in release: 3.19,team-text-input,triaged-text-input,found in release: 3.22

### Steps to reproduce

In dark mode, the CupertinoTextField cannot display text colors

### Expected results

In dark mode, the CupertinoTextField can display text colors

### Actual results

In dark mode, the CupertinoTextField cannot display text colors

### Code sample

```
import 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        useMaterial3: true,
        colorScheme: const ColorScheme.dark(),
      ),
      themeMode: ThemeMode.dark,
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return const Scaffold(
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            CupertinoTextField(),
          ],
        ),
      ),
    );
  }
}

```

### Screenshots or Video

<details open>
<summary>Screenshots / Video demonstration</summary>

[Upload media here]

</details>


### Logs

<details open><summary>Logs</summary>

```console
[Paste your logs here]
```

</details>


### Flutter Doctor output

*
Repository: PowerToys
Issue: Configuration screen in FancyZones
Labels: Issue-Bug,FancyZones-Layouts,FancyZones-Settings,Product-FancyZones,Needs-Triage,Needs-Team-Response

### Microsoft PowerToys version

0.80.1

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

FancyZones Editor

### Steps to reproduce

![FancyZones](https://github.com/microsoft/PowerToys/assets/129181634/beb579ad-a344-4da3-9553-93ab9ac2132d)
Hello, sorry for my bad english. I want to report a problem that i'm having with FancyZones Editor. When I am at work i have 3 screens in 1920x1080 and at home i have 1 screen in 5120x1440. When I installed PowerToys I was at work. When I run FancyZones at home there is an issue because FancyZones remember the configuration that i have at work but don't recognize actual configuration (1 screen). So I can't do anything to adjust and apply my personalization screen. My computer is Windows 11. Thank you so much for reading. And thank you for your tool, it's very appreciable. 

### ✔️ Expected Behavior

_No response_

### ❌ Actual Behavior

_No response_

### Other Software

_No response_
Repository: pytorch
Issue: DISABLED test_precompilations (__main__.TestMaxAutotune)
Labels: triaged,module: flaky-tests,skipped,module: inductor

Platforms: linux, slow



This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_precompilations&suite=TestMaxAutotune&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/23908947988).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 6 failures and 2 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_precompilations`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `inductor/test_max_autotune.py`

cc @clee2000 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler @amjames @desertfire @chauhang
Repository: pytorch
Issue: DISABLED test_transpose_infer_shape (__main__.TORCH_NN_MODULE)
Labels: module: onnx,triaged,module: flaky-tests,skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_transpose_infer_shape&suite=TORCH_NN_MODULE&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/23905052995).

Over the past 3 hours, it has been determined flaky in 4 workflow(s) with 4 failures and 4 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_transpose_infer_shape`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `onnx/test_fx_to_onnx_with_onnxruntime/TestFxToOnnxWithOnnxRuntime_op_level_debug_False_dynamic_shapes_False_model_type_TorchModelType.py` or `onnx/test_fx_to_onnx_with_onnxruntime`

cc @clee2000
Repository: flutter
Issue: Add keyboard support for the CupertinoDatePicker
Labels: c: new feature,framework,f: date/time picker,f: cupertino,c: proposal,P2,team-design,triaged-design

### Use case

We use `CupertinoDatePicker` with `time` mode to let users pick a time.

One of our customers wants to set the time quickly. By tapping the native `UIDatePicker`, we found that the numeric keyboard has shown up since iOS 14. So one can type "1234" to set "12:34" directly.

There is an issue posted before iOS 14: https://github.com/flutter/flutter/issues/28633

<details><summary>Sample code</summary>

```dart
import 'package:flutter/material.dart';
import 'package:flutter/cupertino.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatefulWidget {
  const MyApp({super.key});

  @override
  State<MyApp> createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  var _selectedDate = DateTime.now();

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      home: Scaffold(
        body: Column(
          children: [
            Center(
              child: Text("$_selectedDate"),
            ),
            SizedBox(
              height: 250,
              child: CupertinoDatePicker(
                mode: CupertinoDatePickerMode.time,
                initialDateTime: _selectedDate,
                onDateTimeChanged: (value) {
                  setState(() {
                    _selectedDate = value;
                  });
                },
              ),
            ),
          ],
        ),
      ),
    );
  }
}
```
</details>

### Proposal

Add the new `UIDatePicker` experiences into `CupertinoDatePicker`.

1. Allow focusing on the `CupertinoDatePicker` (related: https://github.com/flutter/flutter/issues/49811)
2. Show up the numeric keyboard
3. Accept the input value and change it to a valid `DateTime`
4. Allow arrow keys of a hardware keyboard

https://github.com/flutter/flutter/assets/6398934/34fa12dc-b87a-453d-b161-b9bf0f5ed1c2
Repository: PowerToys
Issue: File Explorer file type filter
Labels: Needs-Triage

### Description of the new feature / enhancement

In command prompt it is possible to do a "dir *.txt" list only .txt files of a directory, but in the graphical interface of the file explorer there is no option to perform such filtering.
It would be nice if it could be possible to do so and not only in the current directory, but in the selected window (meaning that navigation through subfolders still display only .txt files)

### Scenario when this would be used?

when browsing folders with a lot of files of multiples types, sorting by type is useful but not as user friendly as "showing only files of a given type"

### Supporting information

_No response_
Repository: rust
Issue: Fix for `non_upper_case_globals` should replace all usages
Labels: A-diagnostics,T-compiler,C-bug,A-suggestion-diagnostics,D-invalid-suggestion

<!--
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 in a test for clippy.

```rust
thread_local! {
    static fooFOO: Cell<usize> = unreachable!();
}
fooFOO.set(9);
println!("{}", fooFOO.get());
```

I applied the fixes suggested by clippy and rustc.

I expected to see this happen:
```rust
thread_local! {
    static FOO_FOO: Cell<usize> = unreachable!();
}
FOO_FOO.set(9);
println!("{}", FOO_FOO.get());
```

Instead, this happened:
```rust
thread_local! {
    static FOO_FOO: Cell<usize> = unreachable!();
}
fooFOO.set(9);
println!("{}", fooFOO.get());
```

So the changes in identifiers don't propagate to all usages. 

### Meta

`rustc --version --verbose`:

rustc 1.79.0-nightly (385fa9d84 2024-04-04)
binary: rustc
commit-hash: 385fa9d845dd326c6bbfd58c22244215e431948a
commit-date: 2024-04-04
host: aarch64-apple-darwin
release: 1.79.0-nightly
LLVM version: 18.1.2

<details><summary>Backtrace</summary>
<p>

```
FAILURES:
    tests/ui/thread_local_initializer_can_be_made_const.rs

test result: FAIL. 1 failed; 983 filtered out;

thread 'main' panicked at tests/compile-test.rs:178:6:
called `Result::unwrap()` on an `Err` value: tests failed

Location:
    /Users/cc/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ui_test-0.22.2/src/lib.rs:395:13
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: core::result::Result<T,E>::unwrap
             at /rustc/385fa9d845dd326c6bbfd58c22244215e431948a/library/core/src/result.rs:1077:23
   4: compile_test::run_ui
             at ./tests/compile-test.rs:172:5
   5: compile_test::main
             at ./tests/compile-test.rs:315:9
   6: core::ops::function::FnOnce::call_once
             at /rustc/385fa9d845dd326c6bbfd58c22244215e431948a/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```

</p>
</details>
Repository: kubernetes
Issue: Kubelet restart cause running pod restart with UnexpectedAdmissionError when pods have initContainers and external devices like GPU 
Labels: kind/bug,sig/node,triage/needs-information,needs-triage

### What happened?

When restarting kubelet, it will restart the running pods with UnexpectedAdmissionError when pods' initContainers and containers both use external devices like GPU 

### What did you expect to happen?

Restart kubelet should not cause running pods to restart

### How can we reproduce it (as minimally and precisely as possible)?

1. create some pods with nvidia.com/gpu and initContainers which also use GPUs
2. wait until initContainers exit
3. restart kubelet

### Anything else we need to know?

there was an issue and a fix for running pods with devices, but it looks like the initContainers is not counted as should skip containers.

the fix has cherry-picked to v1.25.16

- issue: https://github.com/kubernetes/kubernetes/issues/118559
- fix: https://github.com/kubernetes/kubernetes/pull/118635
- cherry-pick v1.25 since v1.25.14: https://github.com/kubernetes/kubernetes/pull/119707

Related Issues:
- Completed Pod will also be affected: https://github.com/kubernetes/kubernetes/issues/117955
- memory manager related kubelet restart cause UnexpectedAdmissionError: https://github.com/kubernetes/kubernetes/issues/123971

### Kubernetes version

<details>

```console
$ kubectl version
# 1.25.16
```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: flutter
Issue: Inconsistent SliverAppBar behavior with scroll bar
Labels: framework,waiting for PR to land (fixed),f: scrolling,has reproducible steps,P2,team-framework,triaged-framework,found in release: 3.19,found in release: 3.22

### Steps to reproduce

1. Open this [dartpad](https://dartpad.dev/?id=12ab524b77adc962eb8ddebb73d637e1) in a desktop browser (i have tested with edge and firefox) and click run
2. scroll far down using the scroll bar (do not scroll using the mouse wheel)
3. scroll a bit up using the scroll bar

### Expected results

Since `SliverAppBar.floating = true` it should reappear and expand as soon as the scroll view is scrolled up again. (at least, this would match the behavior on android)

### Actual results

The appbar remains hidden until the scrollview is scrolled all the way to the top again, or the user scrolls up using the mouse wheel (any amount, as long as the scroll view is not already at the top. this fixes the behavior for the scroll bar as well).

### Code sample

https://dartpad.dev/?id=12ab524b77adc962eb8ddebb73d637e1

### Screenshots or Video

<details open>
<summary>Screenshots / Video demonstration</summary>

https://github.com/flutter/flutter/assets/26089559/81559463-f38e-4cf2-af22-17fae8018473

</details>


### Logs

_No response_

### Flutter Doctor output

tested in dartpad with Dart 3.3.3, Flutter 3.19.5
Repository: rust
Issue: Proc macro fn cannot be exported except from the crate root
Labels: A-macros,C-bug,A-proc-macros,WG-macros

...that's all I've got, tbh.

it's mentioned as a limitation but I have no idea why. I genuinely looked for an issue about this but couldn't find one? maybe my issue-finding-fu is just weakened by this late hour. this makes me feel obligated to open a bug.

```
   Compiling pgrx-macros v0.12.0-alpha.1 (/home/jubilee/pgrx/pgrx-macros)
error: functions tagged with `#[proc_macro_attribute]` must currently reside in the root of the crate
  --> pgrx-macros/src/operators.rs:20:1
   |
20 | pub fn opname(_attr: TokenStream, item: TokenStream) -> TokenStream {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: could not compile `pgrx-macros` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `pgrx-macros` (lib) due to 1 previous error
```

why this?

I have a macro crate with 1200 lines in its lib.rs already! and it's only 1200 because half of the macros have poor-to-zero documentation!

### Meta

`rustc --version --verbose`:
```
rustc 1.77.2 (25ef9e3d8 2024-04-09)
binary: rustc
commit-hash: 25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04
commit-date: 2024-04-09
host: x86_64-unknown-linux-gnu
release: 1.77.2
LLVM version: 17.0.6
```