maegul

Oooff ... I don't think it's like MKBHD to come down so hard on a product. But this thing seemed weird (and probably dumb) when it was launched and so I guess this lines up.

Not that a wearable assistant doesn't make some sense, but some former Apple higher ups who think they're good enough to disrupt the smartphone market by ... checks notes ... relying entirely on other companys' new/untested/problematic/maybe-just-shit AI services and pretending that all of the other "smart" devices we have just don't exist in some sort of volley in the ongoing platform wars ... really does kinda epitomise all of shittiness of the current tech world.

cross-posted from: https://lemmy.ml/post/13485452

I linked to this in a previous post along with my hot take about general things (https://hachyderm.io/@maegul/112132220413742000)

But really, if you're into films, into VFX/SFX/behind-the-scenes stuff, and find the state of VFX in the film industry interesting (I'm constantly amazed at the size of the VFX credits in films) ...

... then this is really worth a watch.

I found part 3 particularly enjoyable as it looks at the history of using matte paintings for what CGI is often used now ... and also looks at oppenheimer to, in the end, illustrate that the term "CGI" and the CGI v practical divide are not really useful.

General page for challenges for learning rust

Writing a Diff

• First posed here
• Check in for solutions/statuses here

Intro

Not long ago I posed a challenge for those of us learning rust: https://lemmy.ml/post/12478167.

Basically write an equivalent of git diff --no-index A B ... a file differ.

While it's never too late to attempt it, I figured it'd be a good time to check in to see what anyone thought of it, in part because some people may have forgotten about it and would still like to have a shot, and also because I had a shot and am happy with what I wrote.

Check In

I'll post where I got up to below (probably as a comment), but before that, does anyone have anything to share on where they got up to ... any general thoughts on the challenge and the general idea of these?

My experience

My personal experience was that I'd not kept up with my rust "studies" for a bit and used this as a good "warm up" or "restart" exercise and it worked really well. Obviously learning through doing is a good idea, and the Rust Book is a bit too light, IMO, on good exercises or similar activities. But I found this challenge just difficult enough to make me feel more comfortable with the language.

Future Challenges

Any ideas for future challenges??

My quick thoughts

• A simple web app like a todo app using axtix_web and diesel and some templating crate.
• Extend my diffing program to output JSON/HTML and then to diff by characters in a string
• A markdown parser??

cross-posted from: https://lemmy.ml/post/13353225

Quick little confusion or even foot-gun I ran into (while working on the challenge I posed earlier).

TLDR

My understanding of what I ran into here:

• Matching on multiple variables simultaneously requires assigning them to a tuple (?),
• which happens more or less implicitly (?),
• and which takes ownership of said variables.
• This ownership doesn't occur when matching against a single variable (?)
• Depending on the variables and what's happening in the match arms this difference can be the difference between compiling and not.

Anyone got insights they're willing to share??

Intro

I had some logic that entailed matching on two variables. Instead of having two match statements, one nested in the other, I figured it'd be more elegant to match on both simultaneously.

An inline tuple seemed the obvious way to do so and it works, but it seems that the tuple creates some ownership problems I didn't anticipate, mostly because I was thinking of it as essentially syntax and not an actual tuple variable.

As you'll see below, the same logic with nested match statements each on a single variable doesn't suffer from the same issues.

Demo Code

fn main() {

    // # Data structures
    enum Kind {
        A,
        B
    }
    struct Data {
        kind: Kind
    }

    // # Implementation
    let data = vec![Data{kind: Kind::A}];

    // ## Basic idea: process two adjacent data points
    let prev_data = data.last().unwrap();
    let new_data = Data{kind: Kind::B};

    //

MATCH STATEMENTS

// ## This works: match on one then the other
let next_data = match prev_data.kind {
    Kind::A => match new_data.kind {
        Kind::A => 1,
        Kind::B => 2,
    },
    Kind::B => match new_data.kind {
        Kind::A => 3,
        Kind::B => 4,
    },
};

// ## This does NOT work: match on both
let next_data2 = match (prev_data.kind, new_data.kind) {
    (Kind::A, Kind::A) => 1,
    (Kind::A, Kind::B) => 2,
    (Kind::B, Kind::A) => 3,
    (Kind::B, Kind::B) => 4,
};

}

### The Error

The error is on the line `let next_data = match (prev_data.kind, new_data.kind)`, specifically the tuple and its first element `prev_data.kind`, with the error:

error[E0507]: cannot move out of prev_data.kind which is behind a shared reference

move occurs because prev_data.kind has type Kind, which does not implement the Copy trait

### The Confusion

So `prev_data.kind` needs to be moved.  That's ok.  Borrowing it with `(&prev_data.kind, ...)` fixes the problem just fine, though that can cause issues if I then want to move the variable within the match statement, which was generally the idea of the logic I was trying to write.

What got me was that the same logic but with nested match statements works just fine.

I'm still not clear on this, but it seems that the inline tuple in the second tuple-based approach is a variable that takes ownership of the variables assigned to it.  Which makes perfect sense ... my simple mind just thought of it as syntax for interleaving multiple match statements I suppose. In the case of nested match statements however, I'm guessing that each match statement is its own scope.

**The main thing I haven't been able to clarify is what are the ownership dynamics/behaviours of match statements??**  It seems that there's maybe a bit happening implicitly here??  I haven't looked super hard but it does seem like something that's readily glossed over in the materials I've seen thus far??

### General Implications

AFAICT:
* if you want to match on two or more variables simultaneously, you'll probably need borrow them in the match statement if they're anything but directly owned variables.
* If you want to then use or move them in the match arms you may have to wrangle with ownership or just use nested match statements instead (or refactor your logic/implementation).
* **So probably don't do multi-variable matching unless the tuple of variables is a variable native to the logic**?

Quick little confusion or even foot-gun I ran into (while working on the challenge I posed earlier).

TLDR

My understanding of what I ran into here:

• Matching on multiple variables simultaneously requires assigning them to a tuple (?),
• which happens more or less implicitly (?),
• and which takes ownership of said variables.
• This ownership doesn't occur when matching against a single variable (?)
• Depending on the variables and what's happening in the match arms this difference can be the difference between compiling and not.

Anyone got insights they're willing to share??

Intro

I had some logic that entailed matching on two variables. Instead of having two match statements, one nested in the other, I figured it'd be more elegant to match on both simultaneously.

An inline tuple seemed the obvious way to do so and it works, but it seems that the tuple creates some ownership problems I didn't anticipate, mostly because I was thinking of it as essentially syntax and not an actual tuple variable.

As you'll see below, the same logic with nested match statements each on a single variable doesn't suffer from the same issues.

Demo Code

fn main() {

    // # Data structures
    enum Kind {
        A,
        B
    }
    struct Data {
        kind: Kind
    }

    // # Implementation
    let data = vec![Data{kind: Kind::A}];

    // ## Basic idea: process two adjacent data points
    let prev_data = data.last().unwrap();
    let new_data = Data{kind: Kind::B};

    //
***
MATCH STATEMENTS
***

    // ## This works: match on one then the other
    let next_data = match prev_data.kind {
        Kind::A => match new_data.kind {
            Kind::A => 1,
            Kind::B => 2,
        },
        Kind::B => match new_data.kind {
            Kind::A => 3,
            Kind::B => 4,
        },
    };

    // ## This does NOT work: match on both
    let next_data2 = match (prev_data.kind, new_data.kind) {
        (Kind::A, Kind::A) => 1,
        (Kind::A, Kind::B) => 2,
        (Kind::B, Kind::A) => 3,
        (Kind::B, Kind::B) => 4,
    };
}

The Error

The error is on the line let next_data = match (prev_data.kind, new_data.kind), specifically the tuple and its first element prev_data.kind, with the error:

error[E0507]: cannot move out of `prev_data.kind` which is behind a shared reference

move occurs because `prev_data.kind` has type `Kind`, which does not implement the `Copy` trait

The Confusion

So prev_data.kind needs to be moved. That's ok. Borrowing it with (&prev_data.kind, ...) fixes the problem just fine, though that can cause issues if I then want to move the variable within the match statement, which was generally the idea of the logic I was trying to write.

What got me was that the same logic but with nested match statements works just fine.

I'm still not clear on this, but it seems that the inline tuple in the second tuple-based approach is a variable that takes ownership of the variables assigned to it. Which makes perfect sense ... my simple mind just thought of it as syntax for interleaving multiple match statements I suppose. In the case of nested match statements however, I'm guessing that each match statement is its own scope.

The main thing I haven't been able to clarify is what are the ownership dynamics/behaviours of match statements?? It seems that there's maybe a bit happening implicitly here?? I haven't looked super hard but it does seem like something that's readily glossed over in the materials I've seen thus far??

General Implications

AFAICT:

• if you want to match on two or more variables simultaneously, you'll probably need borrow them in the match statement if they're anything but directly owned variables.
• If you want to then use or move them in the match arms you may have to wrangle with ownership or just use nested match statements instead (or refactor your logic/implementation).
• So probably don't do multi-variable matching unless the tuple of variables is a variable native to the logic?

cross-posted from: https://lemmy.ml/post/13060811

It doesn't disprove the "unadaptable" claim about the book.

I liked the film, am a fan of the book, and this isn't a "book was better, they should have just stuck to the book" opinion.

It's more that watching it (and I'd be curious to see if this feeling changes on re-watch or seeing it back-to-back with pt 1) I felt Denis struggle to achieve everything he was aiming for while controlling rhythm and momentum in a compelling way that captures the spirit of the story and its world.

General spoilers for the story if you haven't read the book and some minor ones about the film

Watching it, I thought the middle section up to Paul drinking the water of life was struggling to not be slow but also convey a sense of gravity and alien spookiness. IMO, it failed at both. The final fight with Routha, without out any sense of Paul's special KH perspective, feels like an anti-climax. Ditto with the ploy of threatening to destroy the spice not actually working as the houses don't accept his ascension. The lack of any substantial passage of time undermines the feeling of growth and settling into fremen culture that was sitting right there for Dennis. While the whole messianic issue is given a good amount of attention, no doubt in preparation for pt 3, Paul as KH and the particular struggle he goes through is not.

And to be a tad more superficial, the whole IR sequence on the Geidi Prime (Harkonnen home planet) felt rather distracting and unnecessary ... the alien/HR Giger -esque aesthetic of the Harkonnens was plenty of creepiness while jumping from visual to IR and back to visual spectra felt disjointed and distracting. I would have preferred a clear look at some Giger-ish art design than the IR look.

Like I said, I liked it. But I could see cracks in the adaptation and with the film being as good as it is I can't help but wonder what could have been.

I wasn't going to post this until I watched this interview with Denis on what his influences were for pt 2. Good interview. You'll find Lawrence of Arabia in his list, which makes a lot of sense. What prompted me here though was that he cited the Road Runner cartoon, where he admitted to wanting to improve on Dune pt 1, specifically to do better at rhythm and momentum, and that he felt like taking notes from Chuck Jones set off a grenade for him. I feel like that's what I'm picking up on ... he clearly was after some sort of forceful pacing ... while what I felt was that the film/story wasn't given the time to breath it needed.

I'd even go so far as to suggest that his statement in the interview kinda confirms my thought, that he really wasn't quite sure how to manage rhythm and momentum for pt 2, which of the two parts does a lot of the heavy lifting in terms of plot (with pt 1 doing world building and succeeding wonderfully IMO) ... and was searching for some inspiration which, IMO, didn't quite land.

For me, I keep coming back to LotR and its film adaptation, an importance reference/standard for this IMO, where I think everyone would agree that the third film, RotK, really captured the spirit and feeling of the book/story (yes even the multiple endings) and nailed the rhythm and momentum for that story.

With Dune pt 2, I've come away not feeling like I watched the story of Paul Atreides. It's something close, frustratingly so for me ATM, to the point where I'm inclined to re-read the book to kinda look for this sense I have in my mind. By contrast, the LotR films never made me want to re-read the books straight after, as I was happy with them as their own experience of the story.

cross-posted from: https://lemmy.ml/post/12904730

It seems they’re not far from finishing and have the first few chapters up for early access and feedback. It could be the go to text for learning the protocol.

It seems they’re not far from finishing and have the first few chapters up for early access and feedback. It could be the go to text for learning the protocol.

For those who don't know, rust-analyzer is the main rust LSP (Language Server Protocol). So super handy! Here's their homepage: https://rust-analyzer.github.io/

I wanted to have it running for little all the programs and tests I'd write and run while going through "The Book" and have settled on a setup I thought I'd share.

The main problem I encountered is that having R-A run on a single file isn't really a thing. It seems it kinda is but I couldn't get it working and it seemed to be a pain anyway. Plus I wanted to be able to use both cargo projects/crates and little test programs/functions simultaneously from a single workspace in my text editor dedicated to working through The Book.

My solution

at the moment

What I settled on was:

• Running multiple cargo projects under a single instance of rust-analyzer running in a single workspace in my editor
• Organising simple test programs as specific functions in a single cargo project.
  • So far, I'm thinking of organising these thematically specifical cargo projects. So I've got one called "borrow_checker" for all borrow checker and ownership toy examples.
  • These specific functions can get called from a single main() if helpful/necessary.

EG directory structure:

the_book/
 ├──  Cargo.lock
 ├──  Cargo.toml
 ├──  guessing_game/
 │  ├──  .gitignore
 │  ├──  Cargo.lock
 │  ├──  Cargo.toml
 │  ├──  src/
 │  └──  target/
 ├──  hello_cargo/
 │  ├──  .gitignore
 │  ├──  Cargo.lock
 │  ├──  Cargo.toml
 │  ├──  src/
 │  └──  target/
 ├──  misc_play/
 │  └──  borrow_checker/
 │     ├──  .gitignore
 │     ├──  Cargo.lock
 │     ├──  Cargo.toml
 │     ├──  src/
 │     └──  target/
 └──  target/
    ├──  .rustc_info.json
    ├──  CACHEDIR.TAG
    └──  debug/

Basically everything inside the_book/ is its own cargo project.

And inside misc_play/borrow_checker/src/ is a typical main.rs with multiple functions testing or toying with something I was trying to understand ... and hopefully use the LSP to help me with.

Getting this to work

So that's the structure. But getting it to work requires a little trick. It requires using a Cargo Workspace.

In this case, it's a matter of adding a Cargo.toml file at the top level (ie, the_book/Cargo.toml) with the following:

[workspace]

resolver = "2"
edition = "2021"

members = [
	"guessing_game",
	"hello_cargo",
	"misc_play/borrow_checker"
]

Here, members is clearly listing each of the projects or libraries. And I added the resolver and edition keys to silence a cargo warning about incompatible resolvers (which I don't know anything about).

With this file, when at the top level, one can run cargo build to build all of the projects/packages. Or, cargo build -p SPECIFIC_MEMBER to build only a specific project/package. Meanwhile, rust-analyzer seems happy to work on any file from any of these projects in a single editor workspace.

There's a section in The Book on cargo workspaces: https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html (where this feature is about much more than just getting rust-analyzer to work with my preferred directory structure!)

Anyone else have thoughts on how best to structure your code and setup for working through something like The Book or any other materials for that matter?

For those on matrix but not aware of any rust spaces on there, here are some links to active rooms/spaces (courtesy of @ericjmorey@programming.dev ):

https://matrix.to/#/#rust:mozilla.org

https://matrix.to/#/#rust:matrix.org

They're both part of this Space for Rust Matrix Rooms:

https://matrix.to/#/#rust-space:matrix.org (also the main link/url of the post)

In the rust-space you'll find a number of rooms specific to crates/libraries such as diesel and actix-web, and they seem active and open to helping people out with problems.