Skip Navigation

Posts
3
Comments
44
Joined
2 yr. ago

  • I knew that shell files, especially in build systems can get hard to read, but this was absolutely painful to look at from start to finish, even with the very helpful explanations in between. Of course the obfuscation is mostly done by design in this case.

  • OpenSuse Slowroll does pretty much that, a slightly delayed rolling release.

  • I don't think there is a good way of having references within the same struct, but you could store reference counted matches:

     rust
        
    matches: Vec<Rc<Match>>,
    players: HashMap<String, Rc<Match>>,
    
    
      

    You would still have to make sure that the players map is updated, maybe weak references are useful there.

    Maybe you could also consider storing the players of a match in the match itself, not outside.

  • If there won't be too many different plugins, maybe having a feature for each plugin would work. Then you could use --features=... when compiling to select the plugins you need.

  • Cat by C418 is literally the only piece in the list I recognize.

  • I like to look at Issues and Pull Requests on Github if a crate wasn't updated for multiple years. If there are already problems like unsoundness, deprecation, or breaking bugs mentioned with no reaction shown by the maintainer, that is a good sign to look elsewhere instead. If everything seems fine and the crate isn't very complex or security-critical, it is probably not an issue.

  • Why does it say "Texas" on it 6 times?

  • That's GDPR coming through.

  • I am also very interested in seeing what the next generation of Rust-inspired languages will look like, and not because I am dissatisfied with Rust today. Rust has significantly raised the bar of how a good programming needs to work and any new language in the systems programming area (and beyond) will inevitably be compared to it.

  • I really like kitty. It is fast and simple but gives me all the features I would want.

  • ...but big gaps remain across the board.

    Good progress, but let's keep going, especially in those states that still have a long way to catch up.

  • This is not cool of Twitter.

  • Being active is probably most important.

    Maybe it would be possible to get a link into a "This Week in Rust"?

  • Where are these circles coming from!?

  • Rust @programming.dev

    Seeking beta testers for Rustup 1.27.0

    internals.rust-lang.org /t/seeking-beta-testers-for-rustup-1-27-0/20352
  • lemmy.made.me.look.at.this.each.time.i.open.a.terminal

    Hostnames can be up to 64 characters long in Linux.

  • Deleted

    deleted by creator

    Jump
  • That's sad that Mozilla has to take it into their own hands to provide a proper alternative to Snap Firefox.

  • Yeah, not gonna do that.

  • Linux @lemmy.ml

    Booting into Linux 6.6.6

    imgur.com /t4ghX5w
  • Rust:

    Cannot move princess out of castle which is behind a shared reference

  • Governments trying to ban end-to-end encryption be like:

  • You're trying to iterate over a Vec while mutating its contents in other places, which is something the borrow checker doesn't like. Altough the later cards that get their copies count increased aren't the same as the iterating reference card, Rust forbids two mutable references into the same Vec, even if they reference different elements of the Vec.

    You could try to iterate over indices into the array instead of directly over array elements, then you get rid of the reference in the outer loop. This would probably require the least change to your code.

    Another option would be to split apart the data structures between what needs to be mutated and what doesn't. I've solved this puzzle in Rust and had a separate mutable Vec for the number of copies of each card. Then you can iterate over and mutate both Vecs separately without having conflicting references.

  • Linux @lemmy.ml

    I Compiled the Linux Kernel myself for the first time