toml-rs VS hashbrown

I updated the toml<->json online converter after the ValueAfterTable error has been fixed with toml 0.6. Very nice to see progress on the toml and toml_edit crates.

use std::fs::File; use std::io::Write; use std::collections::BTreeMap as Map; use serde_derive::{Serialize, Deserialize}; #[derive(Debug)] #[derive(Serialize, Deserialize)] #[serde(tag = "type0")] enum FooBarTwo<'a> { FooBarOne { string1: &'a str }, } #[derive(Debug)] #[derive(Serialize, Deserialize)] #[serde(tag = "type1")] enum FooBarThree<'a> { FooBarFour { string2: &'a str }, } #[derive(Debug)] #[derive(Serialize, Deserialize)] struct FooBarFour<'a> { black: &'a str, #[serde(borrow)] green: FooBarTwo<'a>, #[serde(borrow)] blue: FooBarThree<'a>, } #[derive(Debug)] #[derive(Serialize, Deserialize)] struct FooBarFourList<'a> { // Uasing a Map to workaround a known bug (#303) when using top level Vec // see https://github.com/alexcrichton/toml-rs/issues/303 #[serde(borrow)] foo_bar_six: Map<&'a str, FooBarFour<'a>> } fn main() { let red = FooBarFour { black: "aaa", green: FooBarTwo::FooBarOne { string1: "aaaabbbb" }, blue: FooBarThree::FooBarFour { string2: "ccccccc" }, }; let pink = FooBarFour { black: "aaa", green: FooBarTwo::FooBarOne { string1: "aaaabbbb" }, blue: FooBarThree::FooBarFour { string2: "ccccccc" }, }; let mut white = Map::new(); white.insert("pink", pink); white.insert("red", red); let fbfl = FooBarFourList { foo_bar_six: white }; println!("\nTL: {:?}\n", fbfl); let filename = "./data/test.toml"; let data = toml::to_string(&fbfl).expect("Error serialising fbfl"); println!("\nTL as TOML: {:?}\n", data); let mut f = File::create(filename).expect("Unable to create file"); f.write_all(data.as_bytes()).expect("Error writing data to file"); let toml_in: FooBarFour = toml::from_str(&data).expect("Error deserialising fbfl"); println!("\n{:?}\n", toml_in); }

This is especially useful for data deserialization: Just by implementing the Serialize and Deserialize traits from the serde crate, the (almost) universally used serialization library in the Rust world, we can then serialize and deserialize our types to a lot of data formats: JSON, YAML, TOML, BSON and so on...

It looks like the fields are public now (https://github.com/alexcrichton/toml-rs/pull/455, https://docs.rs/toml/latest/toml/value/struct.Date.html), so just upgrading the crate should do it :-)

Pair that with Serde for serialization/deserialization (JSON, TOML, YAML, CSV/TSV, XML, URL query strings, etc.), Figment for configuration, and ignore for filesystem traversal with blacklist support, and Rust is a real joy for writing CLI utilities.

Added toml-rs-compatible API via the toml_edit::easy module for when developers want to ensure consistency between format-preserving and general TOML work, with one caveat.

A quick example off the top of the head of my head is some tests in the toml package. It has a few different approaches. One is to use macros as in parser.rs. In valid.rs and invalid.rs it uses macros to generate a separate test for each input file. This allows you to run just one individual test from the list. These examples aren't perfect, and there are more sophisticated test utilities (like insta) that can abstract the process of "here are a bunch of inputs, test them all".

I want to read a toml file with default value. I tried toml-rs but it doesn't allow for default values.

That's because you're looking at a wrapper around the actual implementation (which lives in an external package). Notice "use hashbrown::hash_map as base;" at the top.

There's far more unsafe there: https://github.com/rust-lang/hashbrown/blob/f2e62124cd947b5e...

You might want to check out how popular ecosystem crates do some of these things. Particularly relevant to you are probably crates providing collections, such as smallvec, hashbrown, or indexmap.

https://github.com/topics/swisstable

rust-lang/hashbrown: https://github.com/rust-lang/hashbrown

CuPy has array but not yet hashmaps, or (GPU) SIMD FWICS?

NumPy does SIMD:

Thanks, great point indeed. I am looking into this https://github.com/rust-lang/hashbrown

The way I think about it -- rather naively, I suppose -- is that I care more about the references cells make to each other than the actual grid of cells displayed on a table. The latter feels more like a "view" of the data than an actual data structure?

This also seems to align with the relative priority of (sorted from highest to lowest): figuring out the order of evaluation, calculating those evaluations, and finally displaying the results of the evaluation

updated std's hashbrown dependency to 0.14 which contains some optimizations

The std hashmap is actually very fast and uses state of the art hashmap design, namely because it's implemented by hashbrown

I believe Rust uses hashbrown as the underlying implementation now. This just calculates the number of buckets based on the number of items requested:

https://github.com/rust-lang/hashbrown/blob/009969a860290849...

Is it really the case that rehashing can guarantee that the number of buckets allocated will be sufficient for any given set of keys? In principle you could fail to rehash in a way that reduces collisions after k attempted rehashings.

For example, since the hashbrown crate is marked with #![no_std], it can be used as a dependency for the standard library.

To implement something that cannot be expressed in safe Rust, or at least cannot be expressed succinctly in safe Rust, like fundamental datastructures. The hashbrown crate contains a lot of unsafe code, but it's such high quality that it's now the backing implementation for std::collections::HashMap.