sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: transformers
Issue: Trainer sets `state.best_model_checkpoint` even when it doesn't save there; leads to training crash
Labels: bug

### System Info

- `transformers` version: 4.49.0.dev0
- Platform: Windows-10-10.0.22631-SP0
- Python version: 3.9.16
- Huggingface_hub version: 0.24.7
- Safetensors version: 0.4.5
- Accelerate version: 0.34.2
- Accelerate config:    not found
- PyTorch version (GPU?): 2.4.1+cu121 (True)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using distributed or parallel set-up in script?: No
- Using GPU in script?: Yes
- GPU type: NVIDIA GeForce RTX 3090

### Who can help?

@muellerz 
@SunMarc 
@seanswyi

### Information

- [ ] The official example scripts
- [X] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [X] My own task or dataset (give details below)

### Reproduction

`pytest tests/test_model_card.py::test_model_card` from `setfit` (link: https://github.com/huggingface/setfit/blob/main/tests/test_model_card.py#L15)

Apologies for not having a convenient ready-to-go `transformers`-only script. I'm afraid I don't have time for that right now.
In essence, the flow is as follows:
1. I start the trainer, with lots of evaluations (e.g. `eval_steps=1`, `eval_strategy="steps"`)
2. When evaluating, the new `_determine_best_metric` is called: https://github.com/huggingface/transformers/blob/f63829c87bd89a4a0cea45d81c1cd870996b30c4/src/transformers/trainer.py#L3070-L3075
3. With `args.metric_for_best_model` set, we only set the `best_metric` in the first evaluation: https://github.com/huggingface/transformers/blob/f63829c87bd89a4a0cea45d81c1cd870996b30c4/src/transformers/trainer.py#L3182
4. On the 2nd eval, we start comparing against the first. If the model is better, we now also set `best_model_checkpoint`: https://github.com/huggingface/transformers/blob/f63829c87bd89a4a0cea45d81c1cd870996b30c4/src/transformers/trainer.py#L3184-L3192 *but* we're not sure if we're even going to be saving at this step! If `args.save_strategy != SaveStrategy.BEST:`, then it's very possible that we're not saving.
5. The eventual crash occurs when "deleting old checkpoints", because there is no file at `best_model_checkpoint`: https://github.com/huggingface/transformers/blob/f63829c87bd89a4a0cea45d81c1cd870996b30c4/src/transformers/trainer.py#L2680-L2685


### Expected behavior

We should not be setting `best_model_checkpoint` unless we're confident that 1) `state.should_save` is True or 2) `args.save_strategy == "best"`. Then we'll avoid this crash.

- Tom Aarsen
Repository: PowerToys
Issue: Add ability to resize snapped windows together with others
Labels: Needs-Triage

### Description of the new feature / enhancement

When having a bunch of windows snapped, would be nice to be capable to resize all other windows avoiding overlapping others, following the same approach as the native Windows snip feature.

### Scenario when this would be used?

Whenever we have snapped windows covering the entire screen, frequently we need to re-accommodate those windows to better focus on a specific one, but it is not possible to do that without having to resize all the others.

### Supporting information

_No response_
Repository: PowerToys
Issue: Suggestions for the Workspace function
Labels: Needs-Triage,Needs-Team-Response,Product-Workspaces

### Description of the new feature / enhancement


Add an option to move windows without activating them.

Add a shortcut key to quickly move windows.

### Scenario when this would be used?

After the monitor wakes up from sleep mode, all windows are resized to the upper left corner.

### Supporting information

_No response_
Repository: flutter
Issue: Material Error: The control character U+0000 can only be used in strings and comments.
Labels: waiting for customer response,in triage

### Steps to reproduce

1. flutter run

```
󰍲 ekusi  …\herit   feat/purchase $   18:54 
 flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.27.1, on Microsoft Windows [Version 10.0.26120.1252], locale en-US)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 35.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.10.4)
[√] Android Studio (version 2024.1)
[√] VS Code (version 1.96.2)
[√] Connected device (4 available)
[√] Network resources
```



### Expected results

Run projects without any warnings.

### Actual results

Error: The control character U+0000 can only be used in strings and comments.

### Code sample

<details open><summary>Code sample</summary>

```dart
[Paste your code here]
```

</details>


### Screenshots or Video

![image](https://github.com/user-attachments/assets/8e837e1e-f2e6-4a09-a748-d0f008addcf5)



### Logs

<details open><summary>Logs</summary>

```console
[Paste your logs here]
```

</details>


### Flutter Doctor output

<details open><summary>Doctor output</summary>

```console
[Paste your output here]
```

</details>
Repository: godot
Issue: Using "DisplayServer.window_set_mode" to unminimise borderless windows causes them to be lost in window limbo
Labels: bug,topic:gui

### Tested versions

Reproducible in:
v4.3.stable.official [77dcf97d8]
v4.4.dev7.official [46c8f8c5c]

### System information

Godot v4.3.stable - Windows 10.0.19045 - GLES3 (Compatibility) - NVIDIA GeForce GTX 1050 (NVIDIA; 32.0.15.6094) - Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz (4 Threads)

### Issue description

After minimising a project with multiple borderless non-embedded subwindows, attempting to unminimise all windows through the use of `DisplayServer.window_set_mode(DisplayServer.WINDOW_MODE_WINDOWED)` causes the majority of subwindows to become uninteractable, and to disappear from the Windows taskbar. Even though they are still visible, it is as though they do not exist.

- I have been using `Win + D` to minimise all windows due to the lack of title bar and the MRP code not really allowing subwindows to take focus.
- I have tested various window flags and this issue only appears when the windows are borderless.
- It is not shown in the MRP, but this happens even if the windows are forced to native. 
- The project is set to compatibility rendering, as this is what my main project uses, however this issue can be reproduced using any rendering method.

I found the open issue https://github.com/godotengine/godot/issues/98508 which may be related but does not seem to be exactly the same, therefore I decided to open a separate issue. If these need to be merged at a later date I apologise in advance.

In my main project I did once receive the following error, but after editing the project further it has not appeared since. It also does not appear in the MRP. I have minimised and included it in case it proves useful, as it does seem to link to relevant code in the Godot source.

_error: E 0:00:19:0677 (...) Condition "!windows.has(p_window)" is true.
<C++ Source> platform/windows/display_server_windows.cpp:1982 @ window_set_mode()_

https://github.com/godotengine/godot/blob/77dcf97d82cbfe4e4615475fa52ca03da645dbd8/platform/windows/display_server_windows.cpp#L1982

### Steps to reproduce

- Run project.
- Press 'Win + D' to minimise all windows.
- Click on the program in the taskbar, you will see all windows present.
- Click any of the window previews in the taskbar popup to unminimise the project.
- Click the program on the taskbar again, you will see that the majority of subwindows have disappeared.
- These windows are visible on the desktop, but cannot be interacted with.

### Minimal reproduction project (MRP)

[minimisebug.zip](https://github.com/user-attachments/files/18378795/minimisebug.zip)
Repository: vscode
Issue: How to fix Microsoft Visual studio code, language pack issue from English to French at first launch.
Labels: bug,info-needed,l10n-platform,confirmation-pending

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

We are facing issue regarding the Microsoft Visual studio code --language pack, so we need to change the display language of the software to French(FR), so as per information provided on visual studio code page, we downloaded the language pack and also edited the argv.json file but even Tho keeping this files and folders priorly after installation, still at first launch we are getting English language only. Please refer attached image 1

![Image](https://github.com/user-attachments/assets/5f850a4f-9c2e-4081-9ba6-34ff5b6f1a7e)

. As we are getting French language at 2nd launch(Refer image 2),

![Image](https://github.com/user-attachments/assets/29faeab3-4274-44e1-aed8-f04a5905a8f4)
we also tried to add start process of code.exe and killed it so it gets launched at once into the script. but still even after keeping user data files, language package and also start process and kill through script still English language gets displayed.

Summary: On first launch we are getting English language even after keeping all the needed data in user context, but after closing the software and relaunch it manually then only it displays French lang. Not of first launch. Please help us understand if any additional parameters files to be added to make it work on first launch.
Repository: ollama
Issue: Ollama version doesn't properly truncate tokens to 512 max for official snowflake-arctic-embed-l model
Labels: bug

### What is the issue?

When using the official Ollama model of snowflake-arctic-embed-l (latest/335m - 21ab8b9b0545), if input is greater than 512 tokens, instead of truncating, the model encounters an error.

On a previous version (0.3.9) when you pass it more than 512 tokens, it returns only [0,0,0...] embeddings.
In 0.5.4, Ollama returns a 500 error and the logs show that "Process xxxxxx (ollama_llama_se) of user xxx dumped core"

Logs:
```
llama_model_load: vocab only - skipping tensors
ggml-cpu.c:8400: GGML_ASSERT(i01 >= 0 && i01 < ne01) failed
ggml-cpu.c:8400: GGML_ASSERT(i01 >= 0 && i01 < ne01) failed
SIGSEGV: segmentation violation
PC=0x7fcc733ecc57 m=5 sigcode=1 addr=0x207203fe0
signal arrived during ago violation
goroutine 8 gp=0xc0000f21c0 m=5 mp=0xc000100008 [syscall]:
runtime.cgocall(0x562b649d47d0, 0xc000073b90)
        runtime/cgocall.go:167
github.com/ollama/ollama/llama._Cfunc_llama_decode(0x7fcbf115bfa0, {0x2, 0x7fcbf0b80590, 0x0, 0x0, 0x7fcbf0b80da0, 0x7fcbf0b815b, 0x7fcbf0b81dc0, 0x7fcbf1144dc0})
...
```


I've checked my Ollama parameters and this occurs when "truncate": true. Other embedding models properly truncates the input and I see the INFO log in Ollama say "input truncated". I don't see this message with snowflake-arctic-embed-l.

When "truncate" is set to false, I get the expected "input length exceeds maximum context length".

https://ollama.com/library/snowflake-arctic-embed


### OS

Linux

### GPU

Nvidia

### CPU

Intel

### Ollama version

0.5.4
Repository: flutter
Issue: [ally][iOS] : ModalBottomSheet's DragHandle missing semantic information
Labels: platform-ios,a: accessibility,platform-mac,good first issue,has reproducible steps,P2,team-accessibility,triaged-accessibility,found in release: 3.27,found in release: 3.28

When using a screeneader you can tap on the DragHandle of ModalBottomSheet to dismiss it. iOS VoiceOver will only read 'dismiss' and provide no indication that this is a clickable element. (On Android TalkBack will say 'Dismiss, Double-Tap to activate'). Since, when navigating with a screenreader the DragHandle is tappable, it should be semantically indicated as a button. 

Steps to reproduce:
 1. run this:
 
```
 import 'package:flutter/material.dart';

/// Flutter code sample for [showModalBottomSheet].
///   showDragHandle: true was added by author of the issue

void main() => runApp(const BottomSheetApp());

class BottomSheetApp extends StatelessWidget {
  const BottomSheetApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData(
        colorSchemeSeed: const Color(0xff6750a4),
        useMaterial3: true,
      ),
      home: Scaffold(
        appBar: AppBar(title: const Text('Bottom Sheet Sample')),
        body: const BottomSheetExample(),
      ),
    );
  }
}

class BottomSheetExample extends StatelessWidget {
  const BottomSheetExample({super.key});

  @override
  Widget build(BuildContext context) {
    return Center(
      child: ElevatedButton(
        child: const Text('showModalBottomSheet'),
        onPressed: () {
          showModalBottomSheet<void>(
            showDragHandle: true,
            context: context,
            builder: (BuildContext context) {
              return SizedBox(
                height: 200,
                child: Center(
                  child: Column(
                    mainAxisAlignment: MainAxisAlignment.center,
                    mainAxisSize: MainAxisSize.min,
                    children: <Widget>[
                      const Text('Modal BottomSheet'),
                      ElevatedButton(
                        child: const Text('Close BottomSheet'),
                        onPressed: () => Navigator.pop(context),
                      ),
                    ],
                  ),
                ),
              );
            },
          );
        },
      ),
    );
  }
}
```

3. Use iOS VoiceOver 
4. Open ModalBottomSheet
5. Move semantic focus to the DragHandle -> No indication that this is a clickable element

![Screenshot_modalBottomSheet](https://github.com/user-attachments/assets/15b5992d-91be-423a-bf0e-e68906acac9a)
Repository: deno
Issue: Docker container uses massive amount of memory to boot (150MB)
Labels: needs investigation

`docker run -it --rm denoland/deno:2.1.5 repl`

150MB from `docker container stats`:
<img width="166" alt="image" src="https://github.com/user-attachments/assets/349ba074-082d-4595-a3cf-83b2be22a701" />

For reference, I observed the following for other container images:
- `docker run -it --rm python:3.12 python`: 11MB
- `docker run -it --rm node:22 node`: 11MB
Repository: pytorch
Issue: Multiple tests not run / run as no-ops by `run_test.py`
Labels: high priority,module: tests,triaged

### 🐛 Describe the bug

I noticed this while working on https://github.com/pytorch/pytorch/issues/126523

Basically the test suite runner `run_test.py` runs  each test file separately or in parallel. It boils down to e.g. executing: `python -bb distributed/optim/test_apply_optimizer_in_backward.py --shard-id=1 --num-shards=1 -v -vv -rfEX -p no:xdist --use-pytest -x --reruns=2`

However for some tests this does effectively nothing. For example https://github.com/pytorch/pytorch/blob/main/test/distributed/optim/test_apply_optimizer_in_backward.py does not contain any code to be executed. The only way the tests would be executed is by running the file with `pytest` instead of `python` or by calling `common_utils.run_tests` as is done in most tests.

I can't imagine this is intentional, is it?

It also applies to e.g. https://github.com/pytorch/pytorch/blob/main/test/distributed/optim/test_named_optimizer, https://github.com/pytorch/pytorch/blob/main/tools/test/test_executorch_signatures.py and a few others

Are the tests intended to be run with pytest instead of `run_test.py` now? It looks like some tests are not compatible with pytest (judging from some code in `run_test.py`).   
I also couldn't find How the tests on CI are executed to replicate that on our side.

### Versions

PyTorch 2.3.0 - main

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @mruberry @ZainRizvi @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o
Repository: storybook
Issue: [Bug]: composeStories() create errors on Next.js
Labels: bug,sev:S3,portable stories

### Describe the bug

I'm trying to get stories from /packages/canon but /website is isolated from the rest of the repo so I'm using relative paths to get stories. If you run the website on yarn dev and see the two pages I created you can see that on the client version using use client; the components appears correctly but I get an error in the terminal and a 500 error in the console.

This error doesn't seem to come from fetching the component as if you just console.log(composeStories) you'll see the same error.

Is there's something wrong in my setup? Or is this a bug on the function itself?

Thanks 🙏

### Reproduction link

https://codesandbox.io/p/github/cdedreuille/nextjs-compose-stories/main

### Reproduction steps

1. Go to https://codesandbox.io/p/github/cdedreuille/nextjs-compose-stories/main
2. It should install all dependencies
3. You should then see a website with two links on `:3000`
4. On the first link (client side) you should see 3 buttons but in the console you should see a 500 error.
5. You should also see in the terminal an error looking like:
```tsx
TypeError: Cannot read properties of null (reading '0')
    at __webpack_require__ (/project/workspace/website/.next/server/webpack-runtime.js:33:42)
    at __webpack_require__ (/project/workspace/website/.next/server/webpack-runtime.js:33:42)
    at __webpack_require__ (/project/workspace/website/.next/server/webpack-runtime.js:33:42)
    at __webpack_require__ (/project/workspace/website/.next/server/webpack-runtime.js:33:42)
    at eval (./app/test-client/page.tsx:7:74)
    at (ssr)/./app/test-client/page.tsx (/project/workspace/website/.next/server/app/test-client/page.js:184:1)
    at Object.__webpack_require__ [as require] (/project/workspace/website/.next/server/webpack-runtime.js:33:42)
```

### System

```bash
System:
    OS: macOS 15.2
    CPU: (16) arm64 Apple M3 Max
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.18.0 - ~/.nvm/versions/node/v20.18.0/bin/node
    Yarn: 3.8.1 - ~/.nvm/versions/node/v20.18.0/bin/yarn <----- active
    npm: 10.8.2 - ~/.nvm/versions/node/v20.18.0/bin/npm
  Browsers:
    Chrome: 131.0.6778.265
    Safari: 18.2
```

### Additional context

_No response_
Repository: vscode
Issue: Debt: add callback to verify state is changed inside of dispatchKeybinding call in smoketests
Labels: debt

To reduce smoketest flakiness, we should change the method `dispatchKeybinding` in the driver to verify the state has changed successfully on key dispatch before proceeding to further code execution. This issue is used to track this debt item.
Repository: godot
Issue: Selection Cube in Gridmap not selecting correctly in some workflows
Labels: bug,topic:editor,topic:3d

### Tested versions

4.3dev7

### System information

Windows 11 Godot 4.4dev7

### Issue description

When working with modular assets (e.g. floors, walls, corners), and hence having cells half the size of the asset size, with `centerX=centerY=CenterZ=false` for correct alignment, we get the following issue where the wall aren't selected:

https://github.com/user-attachments/assets/285de3ca-8aed-4e3f-9935-0ef21fac65f6

### Steps to reproduce

Above.

### Minimal reproduction project (MRP)

I will provide one later, as I start working on it.
Repository: pytorch
Issue: Tabulate not official dependency of PyTorch but needed by features like FlopCounterMode
Labels: triaged,dependency issue,module: flop counter

```
Traceback (most recent call last):
  File "/home/rzou/dev/ocu11/tutorials/recipes_source/torch_compile_user_defined_triton_kernel_tutorial.py", line 338, in <module>
    with FlopCounterMode() as flop_counter:
  File "/home/rzou/dev/ocu11/pt-ocu11/torch/utils/flop_counter.py", line 726, in __exit__
    print(self.get_table(self.depth))
          ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rzou/dev/ocu11/pt-ocu11/torch/utils/flop_counter.py", line 658, in get_table
    import tabulate
ModuleNotFoundError: No module named 'tabulate'
```
Repository: next.js
Issue: revalidateTag/revalidatePath do not work when directly followed by a redirect in a route handler
Labels: Navigation,dynamicIO

### Link to the code that reproduces this issue

https://github.com/WebDevSimplified/next-cache-redirect-bug

### To Reproduce

1. Run `npm run dev`
2. Navigate to http://localhost:3000
3. Note the random numbers being generated
4. Navigate to http://localhost:3000/revalidate
5. Notice the numbers are still the same cached versions even though `revalidateTag` was called with the proper tag.

### Current vs. Expected behavior

### Expected

When calling `revalidateTag` or `revalidatePath` in a route handler that redirects the user it should invalidate all caches for that tag or path.

### Current

When `revalidateTag`/`revalidatePath` is used within a route handler it does not actually invalidate the cache for that tag/path when followed by the `redirect` function. It is the same issue with other similar functions, such as, `notFound`, `forbidden`, etc. Using `NextResponse.redirect`, does work as expected, though, and the cached data is invalidated and refetched.

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Education
  Available memory (MB): 65300
  Available CPU cores: 24
Binaries:
  Node: 22.7.0
  npm: 10.9.0
  Yarn: 1.22.17
  pnpm: N/A
Relevant Packages:
  next: 15.2.0-canary.3 // Latest available version is detected (15.2.0-canary.3).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A
```


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

dynamicIO, Navigation

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

next dev (local), next start (local)

### Additional context

This seems very related to PR https://github.com/vercel/next.js/pull/70715. This PR was specifically focused on server actions and my best guess is the same problem exists in route handlers as well, but it was not addressed in this PR since this PR was focused solely on server actions.