sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: transformers
Issue: FineWeb SLM Training doesn't start
Labels: trainer,Good Second Issue

### System Info

This is my dev env:
https://github.com/abhinand5/runpod-utils/blob/main/docker/torch-lm-dev/Dockerfile

Using the latest docker.

Torch 2.3.1
CUDA 12.1

### Who can help?

@ArthurZucker @younesbelkada 

### Information

- [X] The official example scripts
- [X] My own modified scripts

### Tasks

- [X] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

I am using a custom version of the [run_clm.py](examples/pytorch/language-modeling/run_clm.py). Where the only changes are:

1. Accepted YAML input along with JSON for parsing arguments
2. Ability to change attention implementation with an argument
3. Handling `validation_split_percentage` less than 1% for huge datasets (because 1% is actually a lot).

After the dataset is preprocessed, running the tokenizer and the values are cached...the training takes a ton of time to start. Waited one hour on 4 different occasions and killed the instance cuz as you know GPUs aren't cheap. 

It works when I reduce the max train samples to something small like 10000. See `DEBUGGING` in the YAML below.

Here is my config:

```yaml
# --- Model settings ---
model_name_or_path: abhinand/personal-model-init-fp16
model_revision: main

# --- Training settings ---
do_train: true
seed: 1337

# --- Cache and torch settings ---
cache_dir: /workspace/.cache
trust_remote_code: true
torch_dtype: bfloat16
attn_implementation: "flash_attention_2"

# --- Dataset settings ---
dataset_name: HuggingFaceFW/fineweb-edu
dataset_config_name: sample-10BT

# --- DEBUGGING ---
# max_train_samples: 1000
# max_steps: 60
# max_eval_samples: 1000
# -----------------

# --- Data processing settings ---
block_size: 2048
overwrite_cache: false
validation_split_percentage: 0.5

# --- Preprocessing settings ---
preprocessing_num_workers: 16
output_dir: ./outputs
overwrite_output_dir: true

# --- Evaluation settings ---
eval_strategy: steps
eval_steps: 50
per_device_train_batch_size: 8
per_device_eval_batch_size: 8
gradient_accumulation_steps: 16
eval_accumulation_steps: 16

# --- Optimizer settings ---
optim: adamw_torch_fused
learning_rate: 3.0e-4
adam_beta1: 0.9
adam_beta2: 0.95
adam_epsilon: 1.0e-8
max_grad_norm: 1.0
num_train_epochs: 1.0
lr_scheduler_type: cosine
warmup_ratio: 0.05
# warmup_steps: 500
weight_decay: 0.01

# --- Logging settings ---
logging_strategy: steps
logging_steps: 1
save_strategy: steps
save_steps: 50
save_total_limit: 5
save_safetensors: true
bf16: true
fp16: false
# bf16_full_eval: true

# --- Torch settings ---
torch_compile: false # not sure why it doesn't work with flash_attention_2
include_tokens_per_second: true
include_num_input_tokens_seen: true

# --- Hub settings ---
push_to_hub: true
hub_model_id: abhinand/personal-model-v0-test1
# hub_strategy: 
hub_private_repo: true
```

### Expected behavior

Training to start...
Repository: flutter
Issue: Flutter crash when intensively redrawing CustomPainter
Labels: c: crash,platform-android,engine,P2,needs repro info,team-engine,triaged-engine

### Steps to reproduce

We encountered a crash in the app related to custom painter redraws. The issue is most likely to occur when the app experiences lag due to heavy data processing. While the crash is not frequent during normal use, it can be consistently reproduced by rapidly clicking the screen multiple times per second, triggering frequent repaints.


### Expected results

Not crashing

### Actual results

App is crashing

### Code sample

Unable to provide, we will update this issue when succeeded

### Screenshots or Video

<details open>
<summary>Screenshots / Video demonstration</summary>

[Upload media here]

</details>


### Logs

<details open><summary>Logs</summary>

```console
[crashCallstack.txt](https://github.com/user-attachments/files/15904366/crashCallstack.txt)


```

</details>


### Flutter Doctor output

<details open><summary>Doctor output</summary>

```console
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.22.2, on Microsoft Windows [Version 10.0.19045.4529], locale pl-PL)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.7.4)
[√] Android Studio (version 2024.1)
[√] IntelliJ IDEA Community Edition (version 2023.3)
[√] VS Code (version 1.90.1)
[√] Connected device (3 available)
[√] Network resources

• No issues found!
```

</details>
Repository: godot
Issue: Instances of inherited scenes are not updated properly after changing any property
Labels: bug,topic:core

### Tested versions

Reproducible in: 4.3Beta1, 4.2, 4.1, 4.0

### System information

Godot v4.3.beta1 - Linux Mint 21.3 (Virginia) - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Laptop GPU () - Intel(R) Core(TM) i5-10500H CPU @ 2.50GHz (12 Threads)

### Issue description

This bug occurs when you change any property on a base scene that other scenes inherit from. 

**Expected behavior:** If there are no overrides set on the instance itself then you should be able to -> update property on base scene  -> see updated property in inherited scene  -> see updated property in instances of inherited scene.

**Current behavior:** Update property in base scene -> see updated property in inherited scene -> see previous value (incorrect) on instance of inherited scene. 

**Workarounds-** 
- Re-instantiate a scene. 
- Click the revert icon near property on instance.

_*Note: The small revert (or undo) icon appears on the instance of inherited scene even though no overrides were applied*
![image](https://github.com/godotengine/godot/assets/122749374/b0ef46bd-ad64-4c66-beb2-4425d83d5889)_

_*Note: This bug only occurs with already instantiated inherited scenes. Newly instantiated inherited scenes will have the correct updated value.*_


Gif of bug in action - 
![vid2](https://github.com/godotengine/godot/assets/122749374/4be06b56-9598-47ae-ae24-23425090febe)


Similar to: 
https://github.com/godotengine/godot/issues/43032
https://github.com/godotengine/godot/issues/90418
https://github.com/godotengine/godot/issues/60846




### Steps to reproduce

3 Scenes will be open in MRP. Main, Base, and Inherited.

1. Instantiate inherited scene as a child of Main.
2. Change any property on Base scene.
3. Check to see if property updated on Inherited Scene (not instance). It should show the correct property value.
4. Check to see if property updated on instance of Inherited scene (child of main).

### Minimal reproduction project (MRP)

[inheritedsceneminimalproject.zip](https://github.com/user-attachments/files/15904547/inheritedsceneminimalproject.zip)
Repository: node
Issue: Missing documentation for process.traceProcessWarnings
Labels: doc,process

### Affected URL(s)

From https://nodejs.org/docs/latest/api/process.html
To https://nodejs.org/docs/latest-v6.x/api/process.html

### Description of the problem

I wanted to set `--trace-warnings` programmaticaly at runtime from within node.

I noticed: https://github.com/nodejs/node/blob/67c19c2900506cd4c60016765e0b7954409dcf90/lib/internal/process/warning.js#L114-L115

So I can use `process.traceProcessWarnings = true` at runtime to toggle stack trace on warnings.

> [!IMPORTANT]
> However in the documentation, from version `6.X LTS` to latest `22.X`, this field `process.traceProcessWarnings` is never documented but the field `process.traceDeprecation` is documented (https://nodejs.org/docs/latest/api/process.html#processtracedeprecation).
>
> Btw, the documentation for the fields `process.traceDeprecation`, `process.noDeprecation` could mention that they are mutable, just like `process.throwDeprecation` does since `12.X LTS`:
> > `process.throwDeprecation` is mutable, so whether or not deprecation warnings result in errors may be altered at runtime.
>
> https://nodejs.org/docs/latest-v12.x/api/process.html#process_process_throwdeprecation
> By https://github.com/nodejs/node/pull/29495

It could be nice to document that.

> [!NOTE]
> Also I noticed the `process.noProcessWarnings` does not work like `process.noDeprecation`:
> it won't change the behavior if assigned at runtime. For this case, using the `--no-warnings` is the only option. 
> And I don't know why as this is not documented

Should I make a PR to add documentation
Repository: godot
Issue: Improvement notification export for GDExtensions
Labels: discussion,topic:gdextension

### Tested versions

- 4.2 stable

### System information

Windows 11 - 4.2

### Issue description

If user tries convert `@export_file("*.txt")` to Array:
```gdscript
extends Node

class_name NewScript

@export_file("*.txt") var files: Array[String]
```
LSP shows error:
![image](https://github.com/godot-rust/gdext/assets/1572963/4dabb2ac-4877-4901-b003-c9ff6892bb25)
And in console:
![image](https://github.com/godot-rust/gdext/assets/1572963/5646095d-a992-49d2-ab98-738840f9773b)

But if user does it in rust:
```rs
#[derive(GodotClass)]
#[class(init, base=Node)]
struct Foo {
    base: Base<Node>,
    #[export(file)]
    resources: Array<GString>,
}

#[godot_api]
impl INode for Foo {}
```

It leads to this:
![image](https://github.com/godot-rust/gdext/assets/1572963/a9172443-b756-4d4a-a7a7-d37734624582)
![image](https://github.com/godot-rust/gdext/assets/1572963/2db4c31a-6431-4b46-afbf-09945905f3cd)

For user it's unexpected and it would be rather to notify about incorrect annotation.

### Steps to reproduce

- Add extenstion
- Describe incorrect export


### Minimal reproduction project (MRP)

[godot-rust-repro.zip](https://github.com/user-attachments/files/15904998/godot-rust-repro.zip)
Repository: kubernetes
Issue: Support HTTP2 probes over cleartext (h2c)
Labels: sig/node,needs-triage

I'd like to request that this use case becomes supported. At work, we are running a cluster behind a massive HTTP load balancer, so we have no real reason to support TLS in our microservices and ingresses. The load balancer takes care of that.

I can't really say that I like what happened in the original issue https://github.com/kubernetes/kubernetes/issues/97330...

@lol768 is another user that has this specific use case in mind.

Now, because this use case was not accommodated in the past, I now have to introduce a really frankensteinian network setup into my namespace.

----- BEGIN EDIT 1 -----
The reason why I've even introduced HTTP/2 support into my microservices is because there are clear advantages of HTTP/2 over HTTP/1.1 in the use case of the project I work for, that have to do with efficiency and performance.

----- END EDIT 1 -----

I now have to make sure that every web service has a second listening port where it only emits HTTP/1.1 so that Kubernetes will be able to issue probes into it. And to make this port a probe-only port that doesn't get exposed outside, I need to make sure that my ingresses will never expose it, or anyone from the team never dares to expose it. And to make sure that the probe-only port doesn't leak any sensitive data, I have to make sure that it returns only some kind of generic HTTP response to the probes.

At this point you're probably thinking why won't I just get a TCP probe to knock on the port where we serve HTTP/2. This will work of course, but it's naive. It misses the point. If this was a TCP service that doesn't serve HTTP, it would make perfect sense, but it isn't. HTTP is not just TCP 80 or 8080 or what have you, but it's a probe with extra context - the return is expected to be a HTTP response, so that we know the microservice isn't just merely accepting connections, it's also sending coherent responses.

I hope this is explanation enough and that its merits are reasonable.
Repository: rust
Issue: Dead code pass no longer considers enum used in `pub extern "C" fn` as used
Labels: A-lints,T-lang,T-compiler,C-bug,S-has-mcve,L-dead_code

A repository that I maintain recently received a bug report about our proc macro generating a warning after they upgraded to `1.79.0`.

I haven't bisected for the exact commit that introduces the warning, but I have been able to reproduce it in `1.79.0`.

## Minimal Reproduction

```rust
fn main() {}

mod private_mod {
    #[repr(C)]
    pub enum MyEnum {
        Variant(u32)
    }
    
    #[no_mangle]
    pub extern "C" fn some_function() -> MyEnum {
        MyEnum::Variant(5)
    }
}
```

```
   Compiling playground v0.0.1 (/playground)
warning: field `0` is never read
 --> src/main.rs:6:17
  |
6 |         Variant(u32)
  |         ------- ^^^
  |         |
  |         field in this variant
  |
  = note: `#[warn(dead_code)]` on by default
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
  |
6 |         Variant(())
  |                 ~~

warning: `playground` (bin "playground") generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.85s
     Running `target/debug/playground`
```

In the playground -> https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3f5c81c0749130a6e46fbea14cbb055f

## Potential Candidates

This comment links to some `rustc` commits that may have introduced the issue https://github.com/chinedufn/swift-bridge/pull/278#issuecomment-2179226690

As mentioned, I haven't taken the time to bisect since I know that it's possible that a core maintainer already has a good sense of when/how this regression could have been introduced.
Repository: pytorch
Issue: Adding betainc
Labels: triaged,module: numpy,module: special

### 🚀 The feature, motivation and pitch

`betainc` function is needed to calculate the cumulative density function of Student's t-distribution etc, which will be useful for the maximum liklihood estimation of probability density functions.

Ref.
https://github.com/pytorch/pytorch/pull/58700
scipy doc
https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.betainc.html

### Alternatives

_No response_

### Additional context

The PR https://github.com/pytorch/pytorch/pull/58700 is for an old code base, which cannot be merged as is and seems to be modified.
However, there are many useful components and we would like to implement betainc based on this.
Also, implementation of ohter special functions like `zeta` is of as a reference.
I would like to implement it with these as a starting point, but would appreciate any advice.
While tensorflow and jax have it, I want to use pytorch, and so would like to try this implementation.


cc @mruberry @rgommers @kshitij12345
Repository: material-ui
Issue: [dialog] Support click away rejection animation for confirmation dialog 
Labels: new feature,waiting for 👍,component: dialog,design

### Summary

Give visual feedback when an end-user clicks away a dialog. It's not clear on https://mui.com/material-ui/react-dialog/#confirmation-dialogs what's happening when you click on the backdrop. 

### Examples

- https://vuetifyjs.com/en/components/dialogs/#persistent makes it clear

https://github.com/mui/material-ui/assets/3165635/61448d1d-3668-485c-af8c-cfb1f8b9a273

### Motivation

Improve UX

**Search keywords**: -
Repository: neovim
Issue: terminal :enew buffer should set buftype=terminal before BufWinEnter autocmd
Labels: enhancement,terminal

### Problem

I have some code I'd like to run when most buffers enter a window, so I create an `autocmd` for `BufWinEnter`.  But there are some buffers on which I do not want to run this code.  I can exclude most of these cases by checking the `filetype` or `buftype`.  One case that I'd like to exclude is terminal buffers.  However when a terminal buffer is created via `:terminal` and my BufWinEnter autocmd is executed the first time, the `buftype` is still empty.  I've also checked other terminal buffer related variables: `b:term_title`, the `channel` local option and `getwininfo(buf).[1].terminal`, but these are also empty during the initial BufWinEnter.  Note: they are present in subsequent BufWinEnters.

This might be fine if I wanted to avoid this code running for any buffer that has empty buftype, filetype, event.file, event.match (as terminal buffers do during initial BufWinEnter), but I do want this code to run on normal new buffers like with `:enew` (which have the same state).

My current hack is to run the code with `vim.defer_fn()` after x ms, after which buftype has usually then been set to 'terminal'.

Steps to reproduce:
1. Write the below code to a file 'test.lua'
2. nvim --clean test.lua
3. :source %
4. check the messages to see if buftype et al. have values initially and after the delay.

```lua
vim.api.nvim_create_autocmd({ 'BufWinEnter' }, {
  group = vim.api.nvim_create_augroup('DetectTerminalBufWin', { clear = true }),
  desc = 'Find a way to detect if this bufer is (or is going to be) a terminal buffer',
  pattern = '*',
  callback = function(evt)
    vim.print(
      evt.event,
      ('filetype:%s'):format(vim.bo[evt.buf].filetype),
      ('buftype:%s'):format(vim.bo[evt.buf].buftype),
      ('b:term_title:%s'):format(vim.b.term_title),
      ('channel:%s'):format(vim.bo.channel),
      ('getwininfo.terminal:%s'):format(vim.fn.getwininfo(vim.api.nvim_get_current_win())[1].terminal)
    )

    if evt.file == '' and evt.match == '' and vim.bo[evt.buf].filetype == '' and vim.bo[evt.buf].buftype == '' then
      vim.defer_fn(
        function()
          vim.print(
            ' ',
            'defered',
            ('filetype:%s'):format(vim.bo[evt.buf].filetype),
            ('buftype:%s'):format(vim.bo[evt.buf].buftype),
            ('b:term_title:%s'):format(vim.b.term_title),
            ('channel:%s'):format(vim.bo.channel),
            ('getwininfo.terminal:%s'):format(vim.fn.getwininfo(vim.api.nvim_get_current_win())[1].terminal)
          )
        end,
        200
      )
    end
  end,
})
vim.cmd.terminal()
```

System: Windows 11
nvim: v0.11.0

### Expected behavior

Either `buftype` is set to 'terminal' prior to initial BufWinEnter autocmds or there is some other variable/mechanism to detect a terminal buffer at this time.
Repository: go
Issue: x/tools/gopls/internal/cmd: `gopls check` doesn't wait for didOpen finish before it makes diagnostics request
Labels: gopls,Tools

### gopls version

0.15.3
```
gopls -v version
Build info
----------
gopls, built in GOPATH mode (unknown)
    @
go: go1.22.3 X:nocoverageredesign
```

### go env

```shell
go env                                                                                        х INT
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/michaelpo/.cache/go-build'
GOENV='/home/michaelpo/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/michaelpo/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/michaelpo/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/golang'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/lib/golang/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.2 (Red Hat 1.22.2-1.el9)'
GCCGO='gccgo'
GOAMD64='v2'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2398423546=/tmp/go-build -gno-record-gcc-switches'
```
```


### What did you do?

I work on integration of a third-party build system (Buck2) and gopls.
I want to write e2e tests with my `GOPACKAGESDRIVER`.

The command `gopls check` would work good for a simple smoke test.

However, when I run it on a broken file, it reposts no issues.
This is happening because of lack of the synchronisation between [`conn.openFile`](https://github.com/golang/tools/blob/f2d2ebe43e72e46b6ae6140c48f124b74309ecdd/gopls/internal/cmd/check.go#L68C3-L68C39) and [`conn.diagnoseFiles`](https://github.com/golang/tools/blob/f2d2ebe43e72e46b6ae6140c48f124b74309ecdd/gopls/internal/cmd/check.go#L74) calls. 

The issue is that `conn.openFile` calls `Server.DidOpen` internally and `Server.DidOpen` processes files asynchronously.

When I put `time.Sleep(...)` before `conn.diagnoseFiles` the command reports all the errors correctly.

When I test this command without custom `GOPACKAGESDRIVER` it works with no extra `time.Sleep` because `go list` returns results faster than my driver and by the time `conn.diagnoseFiles` is called all the data is ready.

I'm happy to make a PR, but I'm not familiar with gopls codebase. 
Could you give some hints how to approach this issue nicer than `time.Sleep`? 
Is there a way to query another method of the server to check if the file has been processed before querying `conn.diagnoseFiles`?

### What did you see happen?

~

### What did you expect to see?

~

### Editor and settings

_No response_

### Logs

_No response_
Repository: flutter
Issue: [iOS] Textfield loses focus after 'Shake to undo' system dialog, despite keyboard reappears.
Labels: a: text input,platform-ios,has reproducible steps,P2,team-text-input,triaged-text-input,found in release: 3.22,found in release: 3.23

### Steps to reproduce

1. There is a textfield on the screen.
2. Type some text into it
3. Shake iOS device
4. System 'Shake to undo' dialog appears, keyboard disappears
5. Make any choice in the dialog


### Expected results

Expected result: Keyboard is reopened, TextField regains focus, user able to type.

### Actual results

Actual result: Keyboard is reopened, TextField does not have focus, user is unable to type or to hide keyboard.

### Code sample

<details open><summary>Code sample</summary>

```dart
TextField(

)
```

</details>


### Screenshots or Video

<details open>
<summary>Screenshots / Video demonstration</summary>


https://github.com/flutter/flutter/assets/151284328/fe50ab1e-0d9e-43cc-a42a-acecfaebb92b


</details>


### 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: Can only run projects using the Compatibility rendering method, even though the hardware supports Vulkan
Labels: bug,platform:windows,topic:rendering,topic:thirdparty,needs testing

### Tested versions

- 4.2.2 stable console and regular
- 4.2.1 stable console and regular

### System information

Godot v4.2.2.stable - Windows 10.0.22631 - GLES3 (Compatibility) - AMD Radeon(TM) Graphics (Advanced Micro Devices, Inc.; 31.0.21912.14) - AMD Ryzen 7 5800H with Radeon Graphics (16 Threads)

### Issue description

Only Compatibility mode projects can be created without crash. Pre-existing projects crash when switched from Compatibility mode. Crashes do not report an error in console

### Steps to reproduce

1. Open Godot
2. Create a new project or access a pre-existing project
3. Switch mode from Compatibility to either Forward+ or Mobile
4. Crash without error in console :(

### Minimal reproduction project (MRP)

[test1.zip](https://github.com/user-attachments/files/15906116/test1.zip)