• 2 Posts
  • 380 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle


  • The bingo one actually uses crossbeam channels instead of mutexes, so that’s nice. I haven’t looked too closely at it though.

    I don’t think you can do too much about the Spectrum one if you want to keep the two threads, but here’s what I would change related to thread synchronization. Lemmy doesn’t seem to allow me to attach patch files for whatever reason so have an archive instead… https://dblsaiko.net/pub/tmp/patches.tar.bz2 (I wrote a few notes in the commit messages)

    Just to give the reason for Rc<RefCell> in the current project. I’m reading in a M3U file and I’m going to be referencing it against an Excel file. So in the structure for the m3u file, I have two BtreeMaps, one for order by channel number and one by name. Each containing references to the same Channel object.

    So basically it’s channels indexed by channel number and name? That one is actually one of the easy cases. Store indices instead:

    struct Channels {
      data: Vec<Channel>,
      by_number: BTreeMap<u32 /* or whatever */, usize>,
      by_name: BTreeMap<String, usize>,
    }
    
    // untested but I think it should compile
    fn get_channel_by_name(ch: &Channels, name: &str) -> Option<&Channel> {
      Some(&self.data[*ch.by_name.get(name)?])
    }
    





  • Yep. Lack of format support is usually to blame on the one who doesn’t support the format. You can absolutely blame Apple for this too though, their apps can’t open e.g. Matroska video or FLAC.

    And perplexingly, they don’t support uploading HEIC, their own image format of choice, on the web iCloud Photos. So there’s that too.

    (At this point my music library is stored as ALAC because it’s well supported in both Linux and Apple’s OSes. Really wish it wouldn’t have to be that way though. Someone needs to tell them about ffmpeg.)

    For example they used to have their own video container .mov

    It’s always very very funny every time someone mentions MOV, because while it’s very similar to MP4, it’s actually an open format while MP4 isn’t (!). You actually have to pay for the MP4 standard document while Apple just gives you the MOV documentation.

    Also at least taking a screen capture on macOS still gives you a MOV container, actually.










  • What do you mean by “more powerful” wrt CMake?

    CMake is a turing-complete language with some APIs that Meson either doesn’t have an equivalent yet because it’s comparatively new (for example, until 2023, there was no built in way to get a relative path from two paths, and if you wanted that you had to shell out to an external program), or they aren’t going to add because it doesn’t fit their design.

    Meson is (intentionally) limited in terms of extensibility, instead it tries to come with everything built in that you need, even down to specific library support like Qt, from what it seems like to me. For example, you cannot define your own functions, it ships builtin modules but does not allow other packages to provide their own (for example like KDE’s Extra CMake Modules), to name a few that I’m familiar with and why I was put off using it so far.

    I have yet to see how actually limiting that is, going to try to move the project I’ve been working on for years that relies on some of these CMake features to Meson soon and see how it fares. But considering that big projects like GNOME use it all over the place it’s probably workable in practice, I’ll just have to rethink the existing approach a bit.

    Is that considered bait?

    Wasn’t it? Go’s build system is very much not what I would call an example of good design (exhibit A: load-bearing comments and file names).