J S

TL;DR The world makes sense again! Arrow.jl is the fastest reader now (except for one case). It took leveraging threads, skipping unnecessary resizing of buffers, some initialization, and adding support...

I've changed the condition for automatic partitioning to be `Tables.rowaccess()=true` as well, to prevent accepting some columntables without row iterators. In addition, I've changed `Iterators.partition(Tables.rows(tbl),chunksize)` to `Iterators.partition(tbl,chunksize)` to avoid missingness...

> In addition, I've changed Iterators.partition(Tables.rows(tbl),chunksize) to Iterators.partition(tbl,chunksize) to avoid missingness type getting lost (eg, for DataFrames) Okay, I was wrong. I misunderstood what `rowaccess` requirements are -- `Iterators.partition()` still...

Added compat for DataFrames via Extras

I did a quick benchmark on a simple linear regression model and I don't see much difference in how quickly it adapts (perhaps it's too easy to see any difference)...

Quick update: - added dispatch for `sample()` to handle types that require gradient information (dispatches over a new abstract type `AbstractHMCAdaptorWithGradients`) - added variations of NutpieHMCAdaptor to benchmark various aspects...

> I don't know for sure, bad step size adaptation might explain what you are seeing. If the mass matrix itself is good, but the final step size doesn't match...

I can confirm the same issue with HTTP 1.10.8 with Julia 1.11 beta2 for any GET calls.

Linking a great writeup by @domluna here: https://github.com/domluna/tinyrag In particular, [this function](https://github.com/domluna/tinyrag/blob/861944eed4964092aed0081a57a7ed956fd02bc5/rag.jl#L3) looks the same as the inner function [here](https://github.com/svilupp/PromptingTools.jl/blob/15982fe6068421c2cc304d0f69e90ceee8073894/src/Experimental/RAGTools/retrieval.jl#L213). It needs some benchmarking and potentially mini PR if someone...

Closed by https://github.com/svilupp/PromptingTools.jl/pull/152