scholium::mark annotation replaces all kinds of TODOs with Rust-native way, allowing developers to categorize them with better precision, write better reasoning and make them easy to extract, report and maintain in the long run. Thanks to Rust literal string boundaries, it's possible to write long multiline reasons, for example allowing to attach even code snippets if needed.

Annotation is made to be attached to an exact place and it provides only documentation value without altering an item attached in any way. This means if the annotation when be attached to a function, module, crate (or a statement), it documents this particular item and nothing else.

#[scholium::mark(
    info,
    implementation::extend,
    doc::possible_extensions,
    reason = "Extend functionality to use any type implementing `+` operation"
)]
fn add(a: u32, b: u32) -> u32 {
    a + b
}
[–] 1 point 5 months ago

I already have mine written quite a while ago. Why not obsidian? AsciiDoc and few other things Obs will miss. Works with SQLite and PostgreSQL. For pure native UI (not WebUI) miss only AsciiDoc grammar I’m working on.

For you… sql knowledge requirement depends on your likings: you can build very small or unoptimised app and be fine, you can make very nice, and complex one and have very complex SQL queries.

I discourage to use MySQL (and clones) due some… peculiarities.

  • source
  • [–] 1 point 5 months ago

    The usual handling in Rust afterwards is in most cases log one error or return to upstream “there was an error”. In some rare cases all errors returned as a single case.

    Both of these first are bad for i18n and finding what’s really happened in the middle.

  • source
  • parent
  • context
  • [–] 1 point 9 months ago

    I don’t think cargo-deny alone is enough. And many from Rust ecosystem thinks that if I specified version “1”, it will be enough forever. Many tools nowadays are installed by binstall, so binary will be older and older and won’t receive any updates.

  • source
  •  

    This is a small release to support Deku 0.20.0 release. The only incompatibility was an introduced descriptive-errors feature which is explicitly propagated at the moment.

    The crate started as support decoding and encoding fixed and variable length unicode strings, but quite soon become more than this.

    While there’s some ideas to implement, new ideas and improvements are always welcome.

     

    New version of deku_string v 0.4.0. Notable changes:

    • Support for Vec<T> will all benefits of the library.
    • Full support for no_std (thanks for contribution).
    • Support for defmt library used in embedded environments.
    • New more readable documentation (including tests).

    deku_string is a utility crate for deku, binary bit-aware parser with ability create serde-like models. Crate provides thin wrappers around String and Vec to support various common layouts such as fixed-length, prefix length (Pascal-like and .Net-like) and zero-ended strings.

    Stay tuned for for more awesome news!

    PS: Looking for contributors to provide 16-bit compile target support.

    view more: next ›