mteb/LocBenchRR huggingface dataset:
Removes unnecessary use of markdown-it
The Github API already [offers a markdown version](https://developer.github.com/v3/media/#html) for the requests we're making, so it's not necessary to use markdown-it to process our requests.

However we still need it to format users comments, so we're still using it on  all of the pages where people can write comments. It might be worth it to look for a more specific lib to do this job.
Removes unnecessary use of markdown-it
The Github API already [offers a markdown version](https://developer.github.com/v3/media/#html) for the requests we're making, so it's not necessary to use markdown-it to process our requests.

However we still need it to format users comments, so we're still using it on  all of the pages where people can write comments. It might be worth it to look for a more specific lib to do this job.
Removes unnecessary use of markdown-it
The Github API already [offers a markdown version](https://developer.github.com/v3/media/#html) for the requests we're making, so it's not necessary to use markdown-it to process our requests.

However we still need it to format users comments, so we're still using it on  all of the pages where people can write comments. It might be worth it to look for a more specific lib to do this job.
Removes unnecessary use of markdown-it
The Github API already [offers a markdown version](https://developer.github.com/v3/media/#html) for the requests we're making, so it's not necessary to use markdown-it to process our requests.

However we still need it to format users comments, so we're still using it on  all of the pages where people can write comments. It might be worth it to look for a more specific lib to do this job.
Removes unnecessary use of markdown-it
The Github API already [offers a markdown version](https://developer.github.com/v3/media/#html) for the requests we're making, so it's not necessary to use markdown-it to process our requests.

However we still need it to format users comments, so we're still using it on  all of the pages where people can write comments. It might be worth it to look for a more specific lib to do this job.
Removes unnecessary use of markdown-it
The Github API already [offers a markdown version](https://developer.github.com/v3/media/#html) for the requests we're making, so it's not necessary to use markdown-it to process our requests.

However we still need it to format users comments, so we're still using it on  all of the pages where people can write comments. It might be worth it to look for a more specific lib to do this job.
Removes unnecessary use of markdown-it
The Github API already [offers a markdown version](https://developer.github.com/v3/media/#html) for the requests we're making, so it's not necessary to use markdown-it to process our requests.

However we still need it to format users comments, so we're still using it on  all of the pages where people can write comments. It might be worth it to look for a more specific lib to do this job.
Refactor graphql-ws message types
Both the legacy `graphql-ws` and the newer `graphql-transport-ws` protocols are concerned with the processing of a handful of messages.

Our implementation of the newer protocol uses dataclasses to describe messages and their `type`. They are very pleasant to work with and look like this:

https://github.com/strawberry-graphql/strawberry/blob/b569bf79d5863731aeb7996f073c795616b473e5/strawberry/subscriptions/protocols/graphql_transport_ws/types.py#L17-L24

However, our implementation of the legacy protocol uses `TypedDict` to describe messages and separate constants for message types. In our case they are harder to work with.

We should refactor the legacy protocols message definitions and use dataclasses for them as well.

<!-- POLAR PLEDGE BADGE START -->
## Upvote & Fund

- We're using [Polar.sh](https://polar.sh/strawberry-graphql) so you can upvote and help fund this issue.
- We receive the funding once the issue is completed & confirmed by you.
- Thank you in advance for helping prioritize & fund our backlog.

<a href="https://polar.sh/strawberry-graphql/strawberry/issues/1669">
<picture>
  <source media="(prefers-color-scheme: dark)" srcset="https://polar.sh/api/github/strawberry-graphql/strawberry/issues/1669/pledge.svg?darkmode=1">
  <img alt="Fund with Polar" src="https://polar.sh/api/github/strawberry-graphql/strawberry/issues/1669/pledge.svg">
</picture>
</a>
<!-- POLAR PLEDGE BADGE END -->

Refactor graphql ws message types
Shown in issue #1669 the changes requested was to refactor the use of TypedDict to the use of dataclasses for the graphql_ws component. Three classes were changed in this set: StartPayload, DataPayload, and OperationMessage. 

## Description

The changes done in the PR are as follows:
1. Changed StartPayload to a dataclass and added the asdict method to it via the use of the GraphQLTransportMessage dataclass
2. Changed DataPayload to a dataclass and added the asdict method to it via the use of the GraphQLTransportMessage dataclass
3. Changed OperationMessage to a dataclass and added the asdict method to it via the use of the GraphQLTransportMessage dataclass

## Types of Changes

<!--- What types of changes does your pull request introduce? Put an `x` in all the boxes that apply. -->
- [ ] Core
- [ ] Bugfix
- [ ] New feature
- [x] Enhancement/optimization
- [ ] Documentation

## Issues Fixed or Closed by This PR

* #1669 

## Checklist

<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the CONTRIBUTING document.
- [x] I have added tests to cover my changes.
- [x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).
Difference between numpy and jax.numpy in advanced indexing axes order
### Description

According to #15653, jax should match numpy with respect to advanced indexing.
There is a difference with empty ellipses.


```python
import numpy as np
a=np.ones((3,4,5))
print(a[:,(0,1),...,(0,1)].shape)
# (2, 3) # numpy

import jax.numpy as jnp
a=jnp.ones((3,4,5))
print(a[:,(0,1),...,(0,1)].shape)
# (3, 2) # jax

import torch
a=torch.ones(3,4,5)
print(a[:,(0,1),...,(0,1)].shape)
# torch.Size([3, 2]) # torch

print(np.__version__)
# 1.26.4. same result on 2.1.3

import jax
print(jax.__version__)
# 0.4.33
```



Numpy treats advanced indices separated by an ellipsis that does not consume any axes not as contiguous, whereas jax does  and subsequently does not move the new indices to the front..

### System info (python version, jaxlib version, accelerator, etc.)

```
jax:    0.4.33
jaxlib: 0.4.33
numpy:  1.26.4
python: 3.10.12 (main, Nov  6 2024, 20:22:13) [GCC 11.4.0]
jax.devices (1 total, 1 local): [CpuDevice(id=0)]
process_count: 1
platform: uname_result(system='Linux', node='151e18e640a6', release='6.1.85+', version='#1 SMP PREEMPT_DYNAMIC Thu Jun 27 21:05:47 UTC 2024', machine='x86_64')
```
UnboundLocalError: local variable 'any_on_epoch' referenced before assignment in prediction loop
### Bug description

`UnboundLocalError` raises when using the predict method with `return_predictions=False`.

This is due to `any_on_epoch` [not being defined](https://github.com/Lightning-AI/pytorch-lightning/blob/be608fa355b835b9b0727df2f5476f0a1d90bc59/src/lightning/pytorch/loops/prediction_loop.py#L236) if `data_fetcher` is [an instance](https://github.com/Lightning-AI/pytorch-lightning/blob/be608fa355b835b9b0727df2f5476f0a1d90bc59/src/lightning/pytorch/loops/prediction_loop.py#L229) of `_DataLoaderIterDataFetcher`.

### What version are you seeing the problem on?

v2.4

### How to reproduce the bug

_No response_

### Error messages and logs

```
UnboundLocalError: local variable 'any_on_epoch' referenced before assignment
```


### Environment

<details>
  <summary>Current environment</summary>

```
#- PyTorch Lightning Version (e.g., 2.4.0):
#- PyTorch Version (e.g., 2.4):
#- Python version (e.g., 3.12):
#- OS (e.g., Linux):
#- CUDA/cuDNN version:
#- GPU models and configuration:
#- How you installed Lightning(`conda`, `pip`, source):
```

</details>


### More info

_No response_
PdfWriter().append throwing 'NullObject' object is not subscriptable for a specific PDF file
I am using pypdf to merge PDF files. I haven't had an issue, until I hit a specific PDF file. Every other PDF file (even ones from the same "bundle" [plan set]). I just have no idea why this PDF file is having an issue with the Writer, or if there is any sort of workaround/front end adjustment I can make to the PDF file.


## Environment

```bash
$ python -m platform
Windows-11-10.0.22631-SP0

$ python -c "import pypdf;print(pypdf._debug_versions)"
pypdf==5.1.0, crypt_provider=('local_crypt_fallback', '0.0.0'), PIL=none
```

## Code + PDF

This is a minimal, complete example that shows the issue:

```python
import glob
import pypdf

fromp = '\\\\UNC\\Path\\*.pdf' #actual path exists, other PDF files merge fine

merger = pypdf.PdfWriter()

paths = glob.glob(fromp)
paths.sort()

for pdf in paths:
    merger.append(pdf) #Get error here on the problem PDF file
```

File link below:
[C0.00 - COVER SHEET.pdf](https://github.com/user-attachments/files/17822279/C0.00.-.COVER.SHEET.pdf)

## Traceback

This is the complete traceback I see:

```
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "C:\Users\ethanwade\AppData\Roaming\Python\Python312\site-packages\pypdf\_writer.py", line 2638, in append
    self.merge(
  File "C:\Users\ethanwade\AppData\Roaming\Python\Python312\site-packages\pypdf\_writer.py", line 2796, in merge
    lst = self._insert_filtered_annotations(
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\ethanwade\AppData\Roaming\Python\Python312\site-packages\pypdf\_writer.py", line 2994, in _insert_filtered_annotations
    p = self._get_cloned_page(d[0], pages, reader)
                              ~^^^
TypeError: 'NullObject' object is not subscriptable
```
User defined function recognized as column (Snowflake dialect)
This query:
`select COL1,COL2 from some_table,TABLE(SOME_DB.SOME_SCHEMA.TABLE_FUNC(value1, value2) over (PARTITION BY value1))`
`p = sqlglot.parse_one(query, dialect=sqlglot.Dialects.SNOWFLAKE)`
creates this ast:
`Select(
  expressions=[
    Column(
      this=Identifier(this=COL1, quoted=False)),
    Column(
      this=Identifier(this=COL2, quoted=False))],
  from=From(
    this=Table(
      this=Identifier(this=some_table, quoted=False))),
  joins=[
    Join(
      this=Table(
        this=Anonymous(
          this=TABLE,
          expressions=[
            Column(
              this=Window(
                this=Anonymous(
                  this=TABLE_FUNC,
                  expressions=[
                    Column(
                      this=Identifier(this=value1, quoted=False)),
                    Column(
                      this=Identifier(this=value2, quoted=False))]),
                partition_by=[
                  Column(
                    this=Identifier(this=value1, quoted=False))],
                over=OVER),
              table=Identifier(this=SOME_SCHEMA, quoted=False),
              db=Identifier(this=SOME_DB, quoted=False))])))])`

Inside the anonymous TABLE (which is also a function that returns values as a table you can select on) we can see the expressions contain only one expression which should be another function but is recognized as a Column.

Verified this still happens on 25.31.4.
dialect: Snowflake
Allow for parallelization in `evolven3fit_new`
Currently `evolven3fit_new` evolves the PDFs sequentially both in Q2 and replicas. For many replicas this means that evolution can take up to several hours while even for the usual 100 replica fits it generally will take over 20 minutes for the evolution to complete. 

Whenever resources are available (which they are on any clusters) it would be nice to have the option to parallelize parts of the the evolution to speed up the computation.
Default behaviour in `TextClassificationPipeline` for regression problem type
### Feature request

The `AutoModelForSequenceClassification` class also supports problem_type=regression. I am not sure if it is popularly used but I believe that function_to_apply in `TextClassificationPipeline` should behave as if it is set to "none"  for this case?

### Motivation

Currently, the "sigmoid" function is also applied for regression tasks which, in my opinion, might not be the correct default behaviour.

### Your contribution

I believe this can be handled by adding an additional condition for `self.model.config.problem_type == "regression"` before [this](https://github.com/huggingface/transformers/blob/38f9f10dd9240619ea17fb6c7acb51b3bc592232/src/transformers/pipelines/text_classification.py#L195) line.
[Core] Logs are duplicated if multiple nodes are running on same machine
### What happened + What you expected to happen

I encountered this https://github.com/ray-project/ray/issues/10392 issue when I was experimenting with ray.
This issue was closed due to the inability to provide a reproducible example.


### Versions / Dependencies

ray[all] 2.38.0
MacOS

### Reproduction script


```python
# example.py
import ray

@ray.remote
def foo():
    print('hello')


if __name__ == '__main__':
    ray.init()
    handle = foo.remote()
    ray.get(handle)

```
```shell
RAY_ENABLE_WINDOWS_OR_OSX_CLUSTER=1 ray start --head
RAY_ENABLE_WINDOWS_OR_OSX_CLUSTER=1 ray start --address='192.168.0.196:6379'
python example.py
```

Output:
24-11-08 13:54:19,817 INFO worker.py:1601 -- Connecting to existing Ray cluster at address: 192.168.0.196:6379...
2024-11-08 13:54:19,831 INFO worker.py:1777 -- Connected to Ray cluster. View the dashboard at http://127.0.0.1:8265 
(foo pid=45881) hello
(foo pid=45881) hello


### Issue Severity

Low: It annoys or frustrates me.

A workaround is at: https://github.com/intel-analytics/BigDL-2.x/pull/2799/files

I mitigated this issue by calling this function after starting worker node. Of course, it has many downsides and it's not the way to go in long term.
```python

def kill_redundant_log_monitors():
    """
    Killing redundant log_monitor.py processes.
    If multiple ray nodes are started on the same machine,
    there will be multiple ray log_monitor.py processes
    monitoring the same log dir. As a result, the logs
    will be replicated multiple times and forwarded to driver.
    See issue https://github.com/ray-project/ray/issues/10392
    """

    import psutil
    import subprocess
    log_monitor_processes = []
    for proc in psutil.process_iter(["name", "cmdline"]):
        try:
            cmdline = subprocess.list2cmdline(proc.cmdline())
        except (psutil.AccessDenied, psutil.NoSuchProcess):
            continue
        is_log_monitor = "log_monitor.py" in cmdline
        if is_log_monitor:
            log_monitor_processes.append(proc)

    if len(log_monitor_processes) > 1:
        for proc in log_monitor_processes[1:]:
            proc.kill()


```
In a specific PowerPoint, an issue with missing text occurred during parsing.
### Bug
<!-- In a specific PowerPoint, an issue with missing text occurred during parsing. -->
...

[specific PowerPoint]
[powerpoint_sample.pptx](https://github.com/user-attachments/files/17694015/powerpoint_sample.pptx)

...

### Python version
docling                   2.4.0
Python version: 3.12.7
...
[serve] logging_config specified in `serve.run` is not propagated cluster-wide
### Description

Specifying `logging_config` in `serve.run(..., logging_config={...})` does not configure logging for the cluster, as is expected. This is because we don't propagate `logging_config` to `.serve_start(...)` here:

https://github.com/ray-project/ray/blob/master/python/ray/serve/api.py#L475-L477

A simple workaround for now is,
```Python
logging_config = {"log_level": "..."}
serve.start(logging_config=logging_config)
serve.run(logging_config=logging_config)
```

### Use case

This issue arose when trying to configure Serve logging holistically for tests.
Syntax Bug in Librispeech Whisper Recipe
### Describe the bug

These bugs listed below are related to whisper specifically following this [recipe](recipes/LibriSpeech/ASR/transformer/train_with_whisper.py)
1) line 228 in dataio_prepare, hparams is a dictionary so `hasattr(hparams, "normalized_transcripts")` does not work as intended.

2) line 50. I've gotten some rounding issues for some batches where the .long() rounds down rather than to the nearest int. (i.e. 12.998 gets rounded down to 12, excluding the last token).

### Expected behaviour

1) just change syntax to check keys in dictionary
2) use torch.round() to ensure proper mask computation

### To Reproduce

_No response_

### Environment Details

_No response_

### Relevant Log Output

_No response_

### Additional Context

_No response_
Improve OmegaConfigLoader performance when global/variable interpolations are involved
## Description

Extending on the investigation in #3893 , OmegaConfigLoader lags in resolving catalog configurations when global/variable interpolations are involved.

## Context

**Some previous observations:**
https://github.com/kedro-org/kedro/issues/3893#issuecomment-2460629752
https://github.com/kedro-org/kedro/issues/3893#issuecomment-2465507178

## Steps to Reproduce

Run stress test which creates a single catalog with variable interpolations - https://github.com/kedro-org/kedro/blob/test/ocl-bottleneck/kedro_benchmarks/temp_investigate_ocl/ocl_plot_variables.py

## Expected Result

Reduce the time spent on below methods (when interpolations are involved, the bottleneck seems to be `OmegaConf.to_container`)

- [OmegaConf.load](https://omegaconf.readthedocs.io/en/2.3_branch/_modules/omegaconf/omegaconf.html#OmegaConf)
- [OmegaConf.to_container](https://omegaconf.readthedocs.io/en/2.3_branch/api_reference.html#omegaconf.OmegaConf.to_container)
- [OmegaConf.merge](https://omegaconf.readthedocs.io/en/2.3_branch/api_reference.html#omegaconf.OmegaConf.merge)

## Actual Result

https://github.com/kedro-org/kedro/issues/3893#issuecomment-2465507178

## Your Environment

<img width="245" alt="image" src="https://github.com/user-attachments/assets/07e3d00f-ad2b-41c6-863a-29e7d20d37c1">

* Kedro version used (`pip show kedro` or `kedro -V`): 0.19.9
* Python version used (`python -V`): 3.11
* Operating system and version: macOS and Sonoma 14.7.1
Excessive Recursion in Query Optimization with Multiple OR Clauses
## Context  
We are encountering an issue where a query with a high number of OR operators is causing excessive recursion during the optimization phase. The resulting recursion depth leads to stack overflow errors. As a temporary workaround, we increased the stack size limit.

Despite the number of entries not being particularly high, we suspect that something in the optimization process is causing the recursion depth to increase unexpectedly.
##  Reproducible example code snippet
```python
import sqlglot
import sqlglot.expressions as expressions
from sqlglot.expressions import column

is_equal_list = ['a'] * 500
is_equal = expressions.false()


for value in is_equal_list:
    is_equal = is_equal.or_(column("a_column").eq(value))
```

If you try to access `is_equal`, you'll receive an error:
```python
is_equal
# throws
#sqlglot/expressions.py", line 256, in is_leaf
#    return not any(isinstance(v, (Expression, list)) for v in self.args.values())
#                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#RecursionError: maximum recursion depth exceeded
```
The default recursion depth is 1000.
Missing format string arguments
This assertion error string is not properly formatted as the 2 format arguments `y_pred.shape` and `y.shape` are missing:

https://github.com/scikit-learn/scikit-learn/blob/551d56c254197c4b6ad63974d749824ed2c7bc58/sklearn/utils/estimator_checks.py#L2139

```python
assert y_pred.shape == y.shape, (
    "The shape of the prediction for multioutput data is incorrect."
    " Expected {}, got {}."
)
```

should become

```python
assert y_pred.shape == y.shape, (
    "The shape of the prediction for multioutput data is incorrect."
    " Expected {}, got {}.".format(y_pred.shape, y.shape)
)
```
ToolKit functions with no arguments cause an error when using Gemini models. 
phidata version: 2.7.2

**To reproduce**: Use a Gemini model and provide a toolkit with a registered method that takes no arguments.
**Expected behaviour**: Model can successfully use the tool.
**Actual behaviour**: The gemini library returns this error:

```
400 * GenerateContentRequest.tools[0].function_declarations[11].parameters.properties: should be non-empty for OBJECT type
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.INVALID_ARGUMENT
	details = "* GenerateContentRequest.tools[0].function_declarations[11].parameters.properties: should be non-empty for OBJECT type
```
**A minimal code to reproduce is attached** [reproduce.zip](https://github.com/user-attachments/files/18121422/reproduce.zip).

Workaround: Adding a dummy parameter to the method seems to fix the issue.

Can this be fixed with ToolKit.register(), or where are the model.function_declarations being setup? In the former case, adding a dummy parameter would be easy, but feels messy.
ENH: built-in token refresh
### Feature Type

- [ ] Adding new functionality to stravalib

- [X] Changing existing functionality in stravalib

- [ ] Removing existing functionality in stravalib


### Problem Description

It would be nice if stravalib would automatically refresh access tokens whenever they expire.

### Feature Description

Calling a client method will automatically refresh an access token if it's expired (or about to expire).

### Alternative Solutions

Letting users handle token expiry themselves (which is the current situation)

### Additional Context

_No response_

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct
The pyca/cryptography RSA PKCS#1 v1.5 is unsafe, making the users of it vulnerable to Bleichenbacher attacks
The API provided by pyca/cryptography is not secure, as documented in their docs:
https://github.com/pyca/cryptography/commit/8686d524b7b890bcbe6132b774bd72a3ae37cf0d

As far as I can tell, it's one of the APIs that jwcrypto uses to implement the key management: https://github.com/latchset/jwcrypto/blob/3b7e8322d37a6b07f862d46e6a43b139cbcc89c5/jwcrypto/jwe.py#L36

That would mean that jwcrypto is vulnerable to Bleichenbacher attacks.
To fix it, implementing an API with built-in workarounding of padding oracle attacks is necessary in pyca/cryptography, as briefly described in https://github.com/pyca/cryptography/issues/5510.