no I think barely awake is the optimal mode to consume this

interesting, so Python encourages thread reuse in ThreadPoolExecutor because threads are more expensive because of the GIL [Python interpreter state], Rust threads are thin wrappers around OS threads

Rust thread size is 2 MiB doc.rust-lang.org/std/thread/#...
Python’s is 8 MiB (i.e. the OS default)

You can really just make your code 7x faster without rayon huh github.com/lmmx/syncdoc...

A scope is a lifetime guarantee not a pool… doc.rust-lang.org/stable/std/t...

> All threads spawned within the scope that haven’t been manually joined will be automatically joined before this function returns

ohoho

rusqlite ! It has a query parsing/metadata exposing Statement type docs.rs/rusqlite/lat...

Makes things possible you can’t do in other dialects collected in the connectorx lib, seemed “ahead” when I reviewed it

I used it this year in a Polars bridge library called polite github.com/lmmx/polite/...

💫🌎 v0.5 crates.io/crates/syncdoc

`syncdoc --migrate; syncdoc --restore` now ‘round trips’ code through omnidoc macro rewrites & back perfectly

No net effect except docstring ‘fixes’ (moving above attrib macros, trimming) like a linter in effect. Long tail no doubt but I see it work on my codebases

HuggingFace xet-core using ctor to initialise constants 👀 github.com/huggingface/... setting the env var like coreutils nooo

don’t suppose you have any favourite examples? would love to see more code using this to get ideas

The role of syncdoc here would be to allow one to pop such annotations in & out of the code at will, to another format [a doc rather than serialisation format]. The doc could be inspected directly [an externalisation of control flow rationale] or “deployed against” the code e.g. as debugging harness

Obviously I’m suggesting repurposing syncdoc as such a framework. You could annotate things like exit points (which might have some algorithmic interpretation like “found __” rather than merely “a call exitted”), identify particular variables for debug display, with some labelling, …anti-subtext-ify

CI is (for various reasons) a particularly strong motivating use case for something like this

The TypeScript “echo “::group::” syntax in maturin-action (github.com/PyO3/maturin...) is v curious, you can see it as giving multiple levels of self-documentation but perhaps points to an actual framework

I wonder what you’d get if you extracted a form of docs from code comments? I don’t see docstrings as for ‘business logic’

Pseudocode/literate program adjacent. I suspect intensifying that form of document could maximise a sense of trust in what’s executing as well as ability to resume work/remodel