hallettj @ hallettj @beehaw.org

Programmer in NYC

---

Read more

Posts

3

Comments

163

Joined

2 yr. ago

I also have mixed feelings about Discovery, but for different reasons. I love the characters and character writing. I disagree that the rest of the crew doesn't get any development - but a lot of that does come in later seasons. My complaints are about the plots. I think season 1 was the most problematic in that respect with progressive improvements over the next two seasons. (I haven't seen season 4 yet.)

• Overly ambitious arcs, and over-the-top stakes make the story feel unbelievable
• Discovery being the only crew able to address several civilization-threatening crises makes the universe feel small
• Leaning on action and artificial tension (like, the ship will explode in 3 minutes) is a cheap way to seek engagement that deprives us of time seeing the characters drive the story

We don't need constant threats of annihilation in the story to be engaged! The most compelling Trek writing has had much lower stakes. When we have had high stakes, like in The Best of Both Worlds and The Dominion War, the writers managed to make us feel like we were seeing a pivotal part of a much larger conflict. They took the time to build up to the big tension, and took the time to play out satisfying resolutions. And they didn't make it the entire show.

But things got gradually better,

I love Michael, and I enjoy watching her be great at everything. But she can be part of a larger society of amazing people, and still be amazing herself.

In season 3 things slowed down enough, and they spent enough time letting more of the cast develop and drive the story that I felt like I could enjoy the story without gritting my teeth.

I don't disagree with you about mirror-Georgiou's participation being unbelievable. The thing where everybody loves Michael to the degree where it becomes their primary motivation is too Mary Sue-like. Again I think that's at its worst in season 1. OTOH having Michelle Yeoh on the show is a lot of fun so I'm inclined to forgive the stretch in that character arc.

And there is also Nushell and similar projects. Nushell has a concept with the same purpose as jc where you can install Nushell frontend functions for familiar commands such that the frontends parse output into a structured format, and you also get Nushell auto-completions as part of the package. Some of those frontends are included by default.

As an example if you run ps you get output as a Nushell table where you can select columns, filter rows, etc. Or you can run ^ps to bypass the Nushell frontend and get the old output format.

Of course the trade-off is that Nushell wants to be your whole shell while jc drops into an existing shell.

I'm a fan! I don't necessarily learn more than I would watching and reading at home. The main value for me is socializing and networking. Also I usually learn about some things I wouldn't have sought out myself, but which are often interesting.

I thought the changeling that shared Odo's look chose it to make Odo feel like he belonged. And her disdain for solids might have made her not want to look too much like them.

The only other changelings I remember from DS9 were,

Good to hear!

Well if you want to try another avenue, I've read about implementing self-referential structs using Pin.

There's a discussion here, https://blog.cloudflare.com/pin-and-unpin-in-rust/

There's a deep dive on pins here, but I don't remember if it addresses self-referential types: https://fasterthanli.me/articles/pin-and-suffering

Somehow I'm very familiar with the first line, but none of the other lyrics. TIL!

This is exactly why we have Reversed Polish Notation. When will people learn?

Oh goddammit! Why doesn't PEMDAS prepare us for unary negation??

The problem is that the way PEMDAS is usually taught multiplication and division are supposed to have equal precedence. The acronym makes it look like multiplication comes before division, but you're supposed to read MD and as one step. (The same goes for addition and subtraction so AS is also supposed to be one step.) It this example the division is left of the multiplication so because they have equal precedence (according to PEMDAS) the division applies first.

IMO it's bad acronym design. It would be easier if multiplication did come before division because that is how everyone intuitively reads the acronym.

Maybe it should be PE(M/D)(A/S). But that version is tricky to pronounce. Or maybe there shouldn't be an acronym at all.

The parentheses step only covers expressions inside parentheses. That's 2 + 2 in this case. The times-2 part is outside the parentheses so it's evaluated in a different step.

Oh I'm sorry! I messed up my test case so it only looked like the block fixed things.

The comment from subignition explains that the phone's answer, 16, is what you get by strictly following PEMDAS: the rule is that multiplication and division have the same precedence, and you evaluate them from left-to-right.

The calculator uses a different convention where either multiplication has higher priority than division, or where "implicit" multiplication has higher priority (where there is no multiply sign between adjacent expressions).

Did you try adding the block like I suggested? I reproduced the same error that you are seeing, and verified in my playground snippet that the block fixes the problem.

It's ok that query_map references pstmt. Isolating pstmt in a block causes it to be dropped at the end of the block while rec_iter continues to live. I think that might be thanks to temporary lifetime extension or something.

I want to make a small correction - this is not true:

iirc I had to reboot every time for it to be applied while with Arch you can just install something and run it immediately.

nixos-rebuild behaves like most package managers: it makes new packages available immediately, and restarts relevant systemd services. Like other distros you have to reboot to run a new kernel.

And cleaning up Steam games is as issue with most distros too. But I kinda see your point.

Btw Nix (both NixOS and the Nix package manager running in other distros) has this feature where you can run packages without "installing" them if you just want to run them once:

        $ nix shell nixpkgs#package-name


  

That puts you in a shell with one or more packages temporarily installed. The packages are downloaded to /nix/store/ as usual, but will get garbage-collected sometime after you close the shell.

Ok I have a simple solution for you. What you need to do is to produce rec_iter in such a way that pstmt is dropped at the same time. You can do that by creating and calling pstmt in a block like this:

    
let rec_iter = {
    let mut pstmt = conn.prepare(sql.as_str())?;
    pstmt.query_map(/* ... */)?
};

  

Here is a Rust Playground example

I'm glad you found a workaround. I didn't want to be defeated by the callback idea that I had yesterday so I worked on it some more and came up with a similar-but-different solution where ZnsMaker stores pstmt paired with a closure that borrows it. This is again a simplified version of your code that is self-contained:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=5bd6fb7c1cbf1c9c44c8f4bdbb1e8074

The closure solution avoids the need to pass conn to make_stream. I don't know if it would fix the new borrowing error that you got since I did not reproduce that error. But I think it might.

Does znsstream need to outlive znsm? If so I think my solution solves the problem. Does znsstream need to outlive conn? That would be more complicated.

Edit: Oh! You don't need to put both the pstmt and a closure in ZnsMaker. Instead you can just store a closure if you move ownership of pstmt into the closure. That ensures that pstmt lives as long as the function that produces the iterator that you want:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=491258a7dc9bcad9dab08632d68c026b

Edit: Lol you don't need ZnsMaker after all. See my other top-level comment. I learned some things working on this, so time well spent IMO.

Well I'm curious to know what solutions there are to this. But I did reduce your problem to a smaller, self-contained example:

    
struct ZKNoteStream<'a, T> {
    rec_iter: Box + 'a>,
}

struct BorrowedThing(Vec);

impl BorrowedThing {
    fn prepare(&self) -> IterProducer<'_> {
        IterProducer(&self.0)
    }
}

struct IterProducer<'a>(&'a Vec);

impl<'a> IterProducer<'a> {
    fn query_map(&self) -> impl Iterator {
        self.0.into_iter()
    }
}

fn test(conn: &BorrowedThing) -> ZKNoteStream<'_, &String> {
    let pstmt = conn.prepare();
    let rec_iter = pstmt.query_map();

    ZKNoteStream { // cannot return value referencing local variable `pstmt`
        rec_iter: Box::new(rec_iter),
    }
}

  

Edit: Wow, that code block came out mangled. Here is a Rust Playground link

I ran into a similar problem yesterday, but it was a case where I had control over all the code. What I did was the equivalent of changing query_map so that instead of taking a reference to its receiver, it takes ownership.

My thinking at the moment is that you may need to modify ZKNoteStream so that instead of containing the resulting iterator it contains pstmt, maybe paired with a function takes pstmt as an argument and returns the iterator. It seems like you should be able to create an FnOnce closure with a move keyword that moves ownership of pstmt into that closure, which you could then store in ZKNoteStream. But I'm not able to make that happen right now.

Thank you for including a workaround with this terrible news!

As a Nix fanboy I would write a Nix expression that downloads the AppImage, and also writes the desktop file with the appropriate path written into it via string interpolation. That can be done either through a NixOS configuration, or in any Linux distro using Home Manager.