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

```rust #[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.

```rust 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

```rust 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.

```rust 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

```rust 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.

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

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

rust // 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:

rust #[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().

```rust #[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:

```rust 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:

rust 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 @[email protected] '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).

I only discovered the River Songs audio piece for the last few nights (it played just after sunset around the Yarra every day, bouncing sounds and singing around all the buildings around the Yarra) ... and I honestly really loved it, easily one of my favourite urban art pieces ever.

Otherwise, I felt like this round was somewhat underwhelming and underfunded from what I saw, which feels like a trend with these White Night / Rising things ... seems like they have a ~3 year lifetime before they just dwindle to being underwhelming? But I didn't really dig into this one or see much of it. I'd guess the works along the river put a constraint on this year? But still ...

Any thoughts? Is it something only central/inner dwellers tend to notice?

I never got around to watching it when it came out, and I think I'd completely missed the critical reception and box-office failure it received. Which saddened me to read after the watch, I have to say, as I was really happy to have watched it.

For those who don't know the film, I personally liked Roger Ebert's review (with whom I generally vibed). It was polarising, and genuinely confusing if you want to "understand" a film, while also potentially being vacuous and overwrought. I'm not going to say it was a good film or recommend it to people. If it's for you, you'll know. All I'll say is that it was, for me, a very good kind of film and generally well executed. Some ambitious film ideas and high level or broad concepts put to screen pretty full-throttle.

I haven't seen a film in this general category of viewing experience for a while (probably entirely on me). Last probably would have been 3000 Years of Longing and maybe Twin Peaks S3 (I count that as an 18 hr film), and then Aronofsky's The Fountain (to which Cloud Atlas is probably the closest sibling I can think of).

Without getting nostalgic about films or critical of the current era (I'm not on top of film enough to do that) ... I was certainly reminded that I need to revise my film/TV diet. It re-affirmed for me a sense that films are more powerful than TV and that this era of TV has been productionised in a way that seems to suck the art of it.

As for what the film was actually about, I think it's much like 2001 A Space Odyssey, it's both obvious and confused/inexplicable. I'm sure there's a whole technical breakdown one could read or endeavour to create oneself, but I'm happy to have watched it once and perhaps revisit it again later to try to pick up on all of the connections I'm guessing they wove through the film, in large part because I think that's in line with the spirit of the film which I'm happy to embrace.

---

Beyond all of that, but kinda connected I think, was to reminisce about the Wachowskis' career, where whatever their flaws, I think I prefer them making things to not ... there's a certain essence of good-hearted and ambitious geek-dom to their stuff that I'm just happy to watch (including Jupiter Ascending and Matrix 4).

For those who know Rick Beato, you may already have opinions one way or another. Generally I welcome his channel to YouTube.

He has been beating this AI and "computerised music" drum for a while though. I was grateful to see him join the dots between computerised music and AI just taking over: "a computer makes better computer music than a human".

It's a pattern I think I see in technological development. While for us or socially it may look like inflection points change everything, there is likely to be a continuous arc of technology that just happens to mean different things to us as it goes. Electrical technology for music -> electrical technological music ... was always a clear trajectory ... and that people are already accustomed to the hyper-polished "digital" sound of AI music because of the past 20 years just confirms that.

Nicely executed VFX experiment (they have a companion video on how they did this and what their motivation was, which is interesting if you're into VFX stuff).

Sounds like I'm trying to be controversial, but I'm really not. Nor a Luka hater (I'm a fan). I'm just thinking out loud here ...

It's just that watching the first two games of the finals, I can't shake the feeling that the Celtics make him look small. Not physically, but in terms of the power he has over the game, even though he's probably the best or top 2 of the players on the court.

It just feels like being 1 way and ball heavy is too often just too much of a weakness, especially while watching Brown, Jrue and Porzingis (and even Tatum managing his slump) be impactful all over the court in ways that connect together as a team.

Meanwhile Luka is too often getting frustrated with his shot not going down or not getting the call he wanted and clearly wanting to wait for the next offensive possession to have another go at his favourite moves (though being frustrated with his team makes sense, but TBF he's had some frustrating turn overs too).

Like, it feels like this finals could be the beginning of a story about Luka being this mercurial and prodigious offensive player that never wanted to (or could) take care of his weaknesses enough to get a ring.

I'm not calling it or anything ... it's just what I'm coming away from the first two games with ... in part because while the Celtics (especially with Porzingis in) are the better team I don't think they've played well and have still made it look clearly one-sided while it doesn't feel like Luka is a miraculous hero who just needs some help.

I feel like Hot Fuzz and Edgar Wright appreciation in youtube cinema critic or analysis videos are basically a meme by now (eg Every Frame a Painting did one 10 years ago ... shit I'm getting old) ...

but I'm a fan, so give me another serving any day.

Also this had things I didn't know about.

Some of the visual/directing references they dig out (and simply demonstrate through video comparison) are had no idea about (however accurate/intentional they are).

And I had no idea that Hot Fuzz is in many ways basically a remake/perfection of an indy short film Wright made as a late teen ("Dead Right" (1993), which has no wikipedia page, but seems to be up on youtube)

and yea ... I hate the guy's voice too ... still they're the only one I've seen keeping up the "serious video essay" format well and I appreciate that a lot TBH

I'm sure this will get clarified in the release notes for 19.4, and I'm probably annoyingly jumping the gun ... I'm just curious.

Otherwise, I find it cool to see this feature come out!

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

> I'd certainly seen this exoplanet somewhere in my mainstream news world somewhere ... so nice to see a breakdown here from "Dr Becky" about how the science isn't so clear cut. > > Anyone else able to provide insight on what the possible outcomes of the newly acquired data will be?

EDIT: what's with the downvotes? Genuinely confused ... is there some rule/culture against youtube videos or something?

I'd certainly seen this exoplanet somewhere in my mainstream news world somewhere ... so nice to see a breakdown here from "Dr Becky" about how the science isn't so clear cut.

Anyone else able to provide insight on what the possible outcomes of the newly acquired data will be?