• 10 Posts
  • 521 Comments
Joined 6 years ago
cake
Cake day: May 31st, 2020

help-circle

  • Ephera@lemmy.mltoRust@programming.devAnnouncing Rust 1.95.0
    link
    fedilink
    English
    arrow-up
    5
    ·
    23 days ago

    cfg_select! looks good. cfg_if! always added so much boilerplate that it rarely reduced complexity, even though it offered a valid solution for when you had a complex condition in one branch and then not() that in the other. It was also annoying that you had to add a dependency for those rare cases.

    We did also move away from cfg_if!, though, because IDE tooling would mostly just quit working within the cfg_if! macro call. Will have to see, if that’s better with this compiler built-in, or if the IDE tooling gets updated to support that well.









  • I always thought openSUSE’s package manager zypper has quite a few neat ideas:

    • It offers two-letter shorthands for subcommands, so zypper installzypper in, updateup, removerm.
    • When it lists what packages it will install or remove, it will list them with the first letter highlighted in a different color, kind of like so: fish git texlive
      This makes it really easy to visually scan the package list, and since it’s sorted alphabetically, it also makes it easier to find a particular package you might be looking for.
      And while there’s separate lists for packages to be added vs. updated vs. removed, they also color those letters in green vs. yellow vs. red, so you can immediately see what’s what.
    • When it lists items (other than packages), it prints an ID number, too.
      So, zypper repos gives you a list of your repositories, numberered 1, 2, 3 etc., and then if you want to remove a repo, you can run zypper removerepo 3.
    • When you run a zypper search, it prints the results in a nicely formatted table.

    Documentation: https://doc.opensuse.org/documentation/tumbleweed/zypper/







  • I’ve kind of standardized on writing it as “Failed to bar when beebbooping, while fadoodling.”

    Maybe a more concrete example:

    Failed to write file when persisting audio, while recording. Caused by: Permission denied.

    The while-part is optional, in case you’ve got a larger context.
    Well, so is the rest of it, really. I may just write “Error when beebbooping”, if I believe the error from .bar() to describe itself rather well. Error handling is hard. 🫠

    But yeah, you kind of have to describe that an error occurred, rather than purely describing what you want to do, because anyhow doesn’t prefix it or such.






  • Everything I implement at work is open source because I don’t want to wait for a purchase approval.

    Just to say, though, I feel like 99% of the software we deploy is open-source for that exact reason. Projects generally start out small, where you try to evaluate some concept. You’re not gonna spend months to go through the purchase process of some proprietary tool, if you can help it…