maegul

Please suggest a film for July's "Fedi Film Club"!

Anything that either you'd like to watch or would recommend to the community.

Please make sure it's more than a year or two old so that it will (hopefully) be available somewhere.

And if possible, provide a quick description for why you'd like to watch or why you suggest it.

---

• See the introduction post for "Fedi Film Club".
• We'll take a vote on the suggestions in about a week's time after this. Then we can watch and discuss.

I watched them roughly once every night or two. And I'd previously seen them all.

And I was rather surprised at how I felt about the films afterwards. It seemed really clear that the quality of the films went continuously down after Casino Royal.

I thought Skyfall would stand out as the best followed by Casino Royal. But, in sequence, nah. Despite having clearly positive qualities, it seemed bloated and empty by comparison.

I also thought Quantum of Solace would rank pretty low as I recall thinking little of it at the time it came out. Instead, I thought it paired really well with Casino as a great follow up.

In fact, it felt like the Craig-era was basically Casino + Quantum and "other things". And yea, the "post-Skyfall" films just didn't feel like they were worth the effort. I thought they'd be more passable than they were, but after Casino + Quantum, which, for me, had a real punch and through-line, Spectre + No-Time-to-Die just felt like they were going through the motions and taking up space. At times, they really seemed to be badly flawed. And that's where my impression of Skyfall really hit ... it seemed that was the "what do we do now with this character?" moment and that Skyfall belonged with Spectre etc not the other way round.

Is this common among Bond fans or am I off base here?

About 10 mins. Focuses on some of the shooting and camera choices in Alien.

Specifically how "dirty shots" were used ("dirty" meaning some unfocused object "dirties" up the shot) and how the 2 camera setup were used.

I think the video was trying to make a point about how Alien was kinda "modern" in this regard. I don't know cinema theory well enough to know ... definitely interesting though!

Either way ... it's some Alien appreciation and this little snippets are definitely good reminders of how awesome the film is.

Continuing on from Chs 5 & 6 of "The Book" (see "Reading Club" post here), I don't think the Copy and Clone traits were quite given sufficient coverage.

So I thought I'd post my understanding here.

Tl;Dr

Copy	Clone
Implicit	Explicit (v.clone())
Simple (memcpy)	Arbitrary
"cheap"/quick	Potentially expensive
Simple types	Any type

Derivable Traits

• These are traits which have a standard implementation that can be freely and easily applied to structs and enums (IE, custom types).
• The ones available in the standard library are listed in Appendix C of The Book. Other libraries/crates can apparently implement them too (though I don't know of any).
• They are part of and use the Attributes syntax (see Documentation in the Rust Reference here): #[ATTRIBUTE].
• To derive a trait we write #[derive(TRAIT1, TRAIT2, ...)] above our type declaration

#[derive(Copy, Clone)]
struct Copyable {
    field: i32,
}

#[derive(Clone)]
struct OnlyClonable {
    field: i32,
}

The Three Step Ladder

• The two traits, Clone and Copy, are about providing opt-in options for custom types around what "ownership semantics" they obey.
• "move semantics": are what we know for most types and have learnt about in ch 4. There is no copying, only the moving of ownership from one stack to another or the use of references and the "borrow checker" that verifies safety.
• "Copy semantics": are what basic types like i32 enjoy. No ownership movements. Instead, these variables get implicitly copied, because they're simple and copying involves the same work involved in passing a memory address around.

The RFC for these traits puts it nicely ...

From RFC 0019 - Opt in built-in traits document on the Copy Trait

Effectively, there is a three step ladder for types:

• If you do nothing, your type is linear, meaning that it moves from place to place and can never be copied in any way. (We need a better name for that.)
• If you implement Clone, your type is cloneable, meaning that it moves from place to place, but it can be explicitly cloned. This is suitable for cases where copying is expensive.
• If you implement Copy, your type is copyable, meaning that it is just copied by default without the need for an explicit clone. This is suitable for small bits of data like ints or points.

What is nice about this change is that when a type is defined, the user makes an explicit choice between these three options.

IE, "move semantics" are the default, "copy semantics" can be adopted, or clone for the more complicated data types or for where it is desired for duplication to be explicit.

• Note that Clone is a supertrait of Copy, meaning that we have to derive Clone if we want to derive Copy, but can derive Clone on its own.

struct Movable {
	field: i32
}

#[derive(Clone)]
struct OnlyClonable {
    field: i32,
}

#[derive(Copy, Clone)]
struct Copyable {
    field: i32,
}

Example

Demonstrate how a struct with Copy obeys "copy semantics" and gets copied implicitly instead of "moved"

• Declare structs, with derived traits, and define a basic function for taking ownership

fn check_if_copied<T: Clone>(x: T) -> T {
    println!("address: {:p} (from inner owning function)", &x);

    x
}

#[derive(Clone)]
struct OnlyClonable {
    field: i32,
}

#[derive(Copy, Clone)]
struct Copyable {
    field: i32,
}

• Instantiate variables of both structs, cl that has Clone and cp that has Copy.
• cl is moved into check_if_copied and so is no longer live or usable afterward.
• cp is not moved into check_if_copied and lives beyond the call of check_if_copied.

let cl = OnlyClonable{field: 0};
let cp = Copyable{field: 1};


// OnlyClonable type obeys "move semantics"

check_if_copied(cl);  // cl gets moved in as it's not copyable

// COMPILER ERROR.  Can't do this! As moved into `report_if_copied`!
println!("address: {:p}", &cl);

// Copyable obeys "copy semantics"

check_if_copied(cp);  // cp is implicitly copied here!

// Can! as not moved but copied
println!("address: {:p}", &cp);

Demonstrate the same but with mutation

let mut mcp = Copyable{field: 1};

let mcp2 = check_if_copied(mcp);  // as mcp was implicitly copied, mcp2 is a new object
mcp.field += 100;

// values will be different, one was mutated and has kept the data from before the mutation
println!("mcp field: {}", mcp.field);
println!("mcp2 field: {}", mcp2.field);

prints ...

mcp field: 101
mcp2 field: 1

Application and Limitations

Copy

• Copy is available only on types whose elements also have Copy.
• Such elements then need to be the numeric types (i32, f64 etc), bool and char. So custom types that contain only basic data types.

#[derive(Copy, Clone)]
struct Copyable {
    field: i32,
}

• Any field with a non-copyable type such as String or Vec cannot be made Copyable

// Copy cannot be derived as `f2: String` does not implement Copy
#[derive(Copy, Clone)]
struct NotCopyable2 {
    field: i32,
    f2: String
}

• But custom types that have the Copy trait as fields work fine, like Copyable from above as a field:

#[derive(Copy, Clone)]
struct Copyable2 {
    field: i32,
    more: Copyable
}

• Beyond this, Copy is not overloadable and can't be implemented in rust (without using unsafe presumably). It's really just a primitive of the language it seems (see source code for the Copy trait).

Clone

• Like Copy, Clone relies on the struct's fields also implementing Clone.
• A number of standard library types have implemented Clone (see list of implementors in the documentation), including the fundamental collections you'll find in chapter 8 of The Book: String, Vec, HashMaps and also arrays.
• Thus the code below, which involves a more complex Struct with fields that are a String, array and Vec, compiles just fine.
• With the clone() method, Clonable is now able to be duplicated allowing the original to be usable after being passed in to check_if_copied().

#[derive(Clone)]
struct Clonable {
    name: String,
    values: [f64; 3],
    data: Vec<i32>
}

let clonable = Clonable{
    name: "Sam".to_string(),
    values: [1.0, 2.0, 3.0],
    data: vec![111, 222]
};

// clonable is duplicated with the `.clone()` method
check_if_copied(clonable.clone());

// original still usable as it was never moved
println!("Name; {}", clonable.name);

• But, unlike Copy, is overloadable, which means you can implemented Clone for your custom types however you want if necessary.
• This would be jumping ahead a bit to Traits, but we could implement Clone for our struct above ourselves with something like the below:

struct Clonable {
    name: String,
    values: [f64; 3],
    data: Vec<i32>
}

// Just use each field's `.clone()` implementation, much like the default would do
impl Clone for Clonable {
    fn clone(&self) -> Self {
        Self {
            name: self.name.clone(),
            values: self.values.clone(),
            data: self.data.clone()
        }
    }
}

• Or we could see how Clone is implemented for Option:

impl<T> Clone for Option<T>
where
    T: Clone,
{
    fn clone(&self) -> Self {
        match self {
            Some(x) => Some(x.clone()),
            None => None,
        }
    }
}

• Basically relies on the implementation of Clone for the inner value inside Some. Note the where clause that limits this to Option variables that contain values that have the Clone trait.

Deep or Shallow Duplication

• In the case of Copy, duplication should always be "deep".
  • Which isn't saying much due to the simplicity of the types that can implement Copy.
• In the case of Clone ... it depends!
  • As the implementations of Clone on the fields of a custom struct/enum are relied on, whether the duplication is deep or shallow depends entirely on those implementations.
  • As stated in the RFC quoted above, Clone is for complex data structures whose duplication is not trivial such that compromises around performance and duplication depth may need to be made.
  • A clue can be discerned from the signature of the implementation. For Option, above, the inner value was restricted to also having implemented Clone, as the value's .clone() method was relied on. Therefore, Option's is deep.
  • Similarly, the Clone implementation for Vec has the same restriction on its elements: impl<T, A> Clone for Vec<T, A> where T: Clone, (see source code), indicating that its implementation is at least one level deep.

---

Overall, this seemed a fundamental part of the language, and I found it weird that The Book didn't address it more specifically. There's nothing really surprising or difficult here, but the relative roles of Clone and Copy, or the "three step ladder" are important to appreciate I think.

Relevant for @sorrybookbroke@sh.itjust.works 's next stream next week as they're hitting smart pointers.

cross-posted from: https://programming.dev/post/16059115

Found this on Mastodon https://fosstodon.org/@dpom/112681955888465502 , and it is a very nice overview of the containers and their layout.

The Idea

• Watch and discuss movies together (kinda like a book club)
• "Crowd source" recommendations for not-entirely-new films (IE, older than a year or so, let's say)
• Aim for generally bettering or curating our film "diet"

How it will work (at least at first)

• 1 film a month
• First, a post to take nominations/suggestions
  • Post any film you want to watch, or have heard good things about, or recommend to everyone else
• Second, a post to take votes on the nominations
• And then we watch and discuss the winner

---

First round will start next month (July)

Please share any thoughts/feedback, though we'll likely run this at least once first before making any changes, just to feel it out

Not the prettiest graph, but a neat way of putting all this information into one image.

Wiki Commons page: https://commons.m.wikimedia.org/wiki/File:Generation_timeline.svg#mw-jump-to-license

Wikipedia page on Generations: https://en.wikipedia.org/wiki/Generation

Edit: Here's the exact same clip on the standard YouTube Watch page.

courtesy of zagorath

---

Brandon Sanderson the fantasy author

For those uninterested in watching a youtube short (sorry), the theory is pretty simple:

COVID and the death of theatres broke the film industry's controlled, simple and effective marketing pipeline (watch movie in theatres -> watch trailer before hand -> watch that tailer's movie in theatres ...) and so now films have the same problems books have always had which is that of finding a way to break through in a saturated market, grab people's attention and find an audience. Not being experienced with this, the film industry is floundering.

In just this clip he doesn't mention streaming and TV (perhaps he does in the full podcast), but that basically contributes to the same dynamic of saturation and noise.

Do note that Sanderson openly admits its a mostly unfounded theory.

For me personally, I'm not sure how effective the theatrical trailers have been in governing my movie watching choices for a long time. Certainly there was a time that they did. But since trailers went online (anyone remember Apple Trailers!?) it's been through YouTube and online spaces like this.

Perhaps that's relatively uncommon? Or perhaps COVID was just the straw that broke the camel's back? Or maybe there's a generational factor where now, compared to 10 years ago, the post X-Gen and "more online" demographic is relatively decisive of TV/Film sales?

After Chs 5 and 6 (see the reading club post here), we get a capstone quiz that covers ownership along with struts and enums.

So, lets do the quiz together! If you've done it already, revisiting might still be very instructive! I certainly thought these questions were useful "revision".

---

I'll post a comment for each question with the answer, along with my own personal notes (and quotes from The Book if helpful), behind spoiler tags.

Feel free to try to answer in a comment before checking (if you dare). But the main point is to understand the point the question is making, so share any confusions/difficulties too, and of course any corrections of my comments/notes!.

Finally, we can make our own types (or data structures)!!

---

This is supplementary/separate from the Twitch Streams (see sidebar for links), intended for discussion here on lemmy.

The idea being, now that both twitch streams have read Chapters 5 and 6, we can have a discussion here and those from the twitch streams can have a retrospective or re-cap on the topic.

This will be a regular occurrence for each discrete set of topics coming out of The Book as the twitch streams cover them

---

With Ch 4 on the borrow checker out of the way, chapters 5 & 6 feel like the "inflection point" ... the point where we're ready to actually start programming in rust.

Custom types, data structures, objects with methods, pattern matching, and even dipping into rust's traits system and it's quasi answer to class inheritance.

If you're comfortable enough with the borrow checker, you can really start to program with rust now!

---

I personally didn't think this content was difficult, though it prompts some interesting points and topics (which I'll mention in my own comment below).

• Any thoughts, difficulties or confusions?
• Any quizzes stump you?
• Any major tips or rules of thumb you've taken away or generally have about using structs and enums?

This seems to be the case from what I've seen and from a quick check just now.

Is this intentionally so? Is it likely to remain so?

Not that I have any problems with it. I'm just thinking about trying to run a poll through lemmy's current features (where native polls are in the roadmap anyway). And I figure, for simple polls, a bunch of comments for each option in a locked thread where people can only up vote would roughly do the trick (except that a voter would know the results ahead of time).