LiteLLM - Best as a proxy/router
Unified interface across providers Supports tool_choice parameter Can route to local models (vLLM, Ollama) or cloud APIs Automatic format translation
Run Ollama as the backend, then put LiteLLM in front of it to add proper tool_choice support:
| // from https://renenyffenegger.ch/notes/tools/Graphviz/examples/organization-chart | |
| // Inspired by | |
| // https://stackoverflow.com/a/7374543/180275 | |
| digraph ORG { | |
| ranksep=0.2; | |
| node[shape=box3d width=2.3 height=0.6 fontname="Arial"]; |
🚀 Simplifying your Rust Results! Technically Result is an enum, so you can match on it:
// Instead of this:
match some_function(&input) {
Ok(value) => process_value(value),
Err(err) => {
log_error(err);
}
}
When parking_lot is used in a wasm context, sometimes we run into an error with the unknwon target
failed to resolve import `env::now`The solution is here: Amanieu/parking_lot#269 (comment)
While you can lock parking_lot_core to anything below 0.8.1 (uses the InstantDummy) I would not recommend this. Instead I'd recommend to enable the necessary features transitively when using wasm-bindgen. That means for instant to work on wasm32 you have to enable the wasm-bindgen feature and depending on the platform and whether performance.now() is available, you also need to enable inaccurate.
... is the best. But you need to set it up right.
~/.config/lazygit/config.yml~/Library/Application Support/lazygit/config.yml%LOCALAPPDATA%\lazygit\config.ymlInstead of getting git diffs, you can get colorful side by sides with git-delta:
Use trait objects (&dyn Fn()) when you need runtime polymorphism and don't mind the small performance cost of dynamic dispatch.
Use generics (F: Fn()) for better performance through static dispatch, but at the cost of potential code bloat due to monomorphization.
| # It's not documented, but you can use `package.metadata.component.bindings` to | |
| # set additional derive attributes for the generated bindings: | |
| [package.metadata.component.bindings] | |
| derives = ["serde::Serialize", "serde::Deserialize", "Hash"] |
Beetswap uses libp2p-core v0.42.0
Which means that any time you want to use Beetswap, you'll need core v0.42.0.
Oh, you want to use WebRTC though? That's fine.
Well, you'll need libp2p-webrtc-websys version 0.4.0 because anything before that breaks because __Nonexhaustive
was switched to __Invalid in wasm-bindgen.
So there's the web browser which everyone has, but JavaScript is slow and insecure.
But there's a bunch of tech out there that doesn't really need JavaScript; Rust => WebAssembly. So why are we bending over backwards to fit things into the browser?
What if we had a modular way to share "sites" that were really wasm apps. We could use 1 "wasm browser" and just run these apps.
If these wasm apps output a display to egui, we could load these wasm apps as plugins and just run the thing. Can we load a WIT component into egui and have it output the right display? If so, it's so on.
| // ensures you get compiler warnings if your type suddenly (unexpectantly) break autotraits | |
| // from Rust for Rustaceans Book | |
| mod tests { | |
| use ipns_entry::entry::IpnsEntry; | |
| fn is_normal<T: Sized + Send + Sync + Unpin>() {} | |
| #[test] |