AFL maegul • 4 days ago • 83%

Instead we’ve the lions, power, swans and cats. Who were premiers in 2003, 2004, 2005 and 2007 respectively (with a cheeky eagles flag in 2006). edit: Or, to include repeats and losing the grand final: The 01, 02, 03, 04, 05, 07 & 09 premiers, and, the 04, 06, 07 & 08 runners up are in the prelims this year. Not one GF in 9 years that didn’t have one of these four and only two that were win by another team.

Shows and TV maegul • 2 weeks ago • 88%

How are people feeling about it? I was disappointed by season 1, but happy to keep watching as I'm a die hard fan from childhood. Season 2 had me excited *at first* ... ::: spoiler spoilers (and ranting) The first two-three episodes at least had me even a little pumped. The dark wizard in the east very much signals to me that the stranger could be a blue wizard, along with the dark wizard, which is honestly very cool and a nice way to split the difference around Tolkien's "speculation" on what happened to them. Getting more complex Sauron manipulation and moving the plot along too seemed nice. But after episode 4, I don't know. I came away from it thinking it might have been the worst tv episode I've watched since Picard S2, which was very strange given how much interesting shit they did. Ents, Bombadil, Wizards, Hobbit origins (actually I don't care for the amount of hobbit stuff in the show at all). But there was something just boring about it all for me. The only way I can explain what I think I'm seeing, *and why it's fundamentally flawed*, is that the writers/directors want to take Tolkien seriously and even feel rather pressured to do so ... and so in many ways they're actually writing/filming that sense of seriousness rather than a well thought out adaptation style. The clue for me is how the whole show is at once strangely grounded *and* somehow "elevated" at the same time. The elves, such as Galadriel and Elrond, are kinda normal people doing normal things a lot of the time (compare LoTR trilogy Galadriel basically being mind-crushing and haunting most of the time) ... but talk as though they're reading directly from the bible or Silmarillion. Same for Halbrand/Annatar/Sauron. The construction of the rings is a clue into this I think, where they've attempted to portray it as powerful and important, but there's absolutely no sense of how in the world they're magical, no indication that there's some special elven craft behind them. Just "add mithril and get powerful rings". Bombadil's dialogue seemed the same to me. Talking about being the eldest as though he's talking about what happened last week. Now in that character this sort of approach makes the most sense. But even so, there didn't seem to be any joy, jolly or aloofness about the character to signal how old he must be to be casual about witnessing the beginning of time. And there's always the concern the show should have for making us the viewer *feel* what's happening on screen ... and I don't think we felt Bombadil's mysteriousness much at all. Compare with, in the LoTR books, Tolkien using a wonderful way of showing that ... the one ring had no affect no him whatsoever to the point that he could see Frodo while he was wearing it. The only breath of fresh air so far has been the dark wizard, which clearly takes cues from Saruman. It's probably been the only sense stylistically I've gotten that we're in a lost age of a fantasy world. One take I had from season 1 was that RoP's biggest problem might be that it's being made after Game of Thrones not before it. That GoTs is absolutely the wrong influence for a show like this and yet is likely to have one due to its pervasive success. And I feel like I may have been right about that. The Tolkien world and GoT "politics and intrigue" are not compatible. Moreover, I suspect the GoT style may have run its course somewhat. A show like RoP was a chance to try something interestingly mystical and I don't think the creators were up to the challenge, perhaps not at all. :::

Today I Learned maegul • 2 weeks ago • 97%

www.newsweek.com

While territorial claims are and will likely be heated, what struck me is that the area is right near the Drake Passage, in the [Weddell Sea](https://en.wikipedia.org/wiki/Weddell_Sea) (which is fundamental to the world's ocean currents AFAIU). I don't know how oil drilling in the antarctic could affect the passage, but still, I'm not sure I would trust human oil hunger with a 10ft pole on that one. Also interestingly, the discovery was made by Russia, which is a somewhat ominous clue about where the current "multi-polar" world and climate change are heading. Antarctica, being an actual continent that thrived with life up until only about 10-30 M yrs ago, is almost certainly full of resources.

movies maegul • 3 weeks ago • 98%

It's funny, at time of posting, many of the YT comments are *very* nostalgic about how much has happened in this 8 year period ... and I can't lie, I feel it too god damn it.

Casual Conversation maegul • 3 weeks ago • 89%

Seems like fertile ground for coming up with something fun and interesting ... a whole shadow universe that barely touches ours ... but I don't think I've ever seen it.

movies maegul • 3 weeks ago • 96%

Rant … ::: spoiler spoiler I’m talking about Ash/Rook, obviously. Just saw the film recently, and while it’s a bit of a love it or hate it film I think, the Rook character is I think objectively egregious. The idea is good, IMO, in a number of ways, and I can understand that the film makers felt like it was all done with love and affection for Holm and the character. As a viewer, not necessarily onboard with how many cues the film was taking from the franchise, I noticed the silhouette of Rook pretty quickly and was quite happy/hyped to see where it would go. **But OMG the execution is unforgivable!** And I feel like this is just so much of what’s wrong with Hollywood and VFX, and also indicates that some execs were definitely intervening in this film. Somewhat fortunately for the film, it had a low budget (AFAICT, by Wikipedia) and is making a profit. But it’s no excuse to slap some bad CGI onto shots that were not designed for bad CGI. Close ups on the uncanny valley! Come on! AFAICT, bad CGI is often the result of a complete disconnect between the director and the VFX crew, in part because the VFX industry is kept at arms length from the film industry, despite (it because of) its massive importance. That CGI is not something you do a close up on. No remotely decent director would have done that knowing the CGI looked like that. This is likely bad studio management creating an unworkable situation. What could have worked much better IMO is don’t have the synth functioning well. Have its facial expressions and movements completely artificial and mechanical. Rely on the likeness of Holm and the AI voice (which did and generally do work well). Could have been done just with a well directed animatronic coupled with some basic CGI to enrich some textures and details. Instead we got a dumb “we’ll do it in post” and tortured some poor editor into cutting those shots together. For many the film was a mixed bag. For me too. But this somehow prevents me from embracing it because I just don’t trust the people who made it. ::: … End rant.

movies maegul • 1 month ago • 75%

A nice and fair comparison I thought. The main difference, it seems, was the styles of the two films, where a bunch of stylistic choices rather disparate from whether CGI was used or not separate the two. My take after seeing furiosa was that it's biggest flaw was that its makers struggled with the expectations of Fury Road and I think these stylistic differences kinda support that, where I'd guess they felt like they had to go with a different look and not simply repeat Fury Road's aesthetic when in the end there may not have been much of a coherent artistic purpose behind those changes.

Videos maegul • 1 month ago • 85%

New genre just dropped! I've liked some of the other things this guy has done, but didn't get into this track at first. As I kept watching though, I got more and more into it and am certain I'd be down for an album of this stuff.

movies maegul • 1 month ago • 84%

*Yes, I'm slow, sorry!* Now this may very well be excessive expectations. I had heard a few people say it's this year's Andor. IE, you should just watch it even if it's not the sort of thing you think you'd be into. Also, I've never played the games **I've just finished the first 2 episodes**, and, for me, it's not bad, it's a kinda interesting world ... but there's a distinctly empty feeling and awkwardness to the show for me. Sometimes scenes feel like they're either filling time or still trying to find their rhythm. I'm not sure any of the dialogue has caught my ear (at all). I'm not sure I've picked up on any interesting stakes or mysteries. And I've often wondered about the directing (where I can't help but wonder if Jonathan Nolan's directing is more about trying to compete with his brother). The soft tipping point for me was the Knight's fight with the Ghoul (episode 2) ... it just felt pointless and childish. The whole scene seemed to strangely lack any gravity or impetus. And I find myself ~2.5 hrs in and not caring about anything that's happening. It's a post nuclear apocalypse world, with some mutants, a naive bunker person, and a manipulative corporation or two doing sneaky shit ... ... dunno ... what am I missing? Should I just keep watching?

movies maegul • 1 month ago • 92%

Watching this, and seeing more of these types of interviews from Corridor Crew, it struck me that it's filling the void left by death of DVDs/BluRays and their special features.

Learning Rust and Lemmy maegul • 1 month ago • 100%

# Intro Having read through the macros section of "The Book" (Chapter 19.6), I thought I would try to hack together a simple idea using macros as a way to get a proper feel for them. The chapter was a little light, and declarative macros (using `macro_rules!`), *which is what I'll be using below*, seemed like a potentially very nice feature of the language ... the sort of thing that really makes the language malleable. *Indeed, in poking around I've realised, perhaps naively, that macros are a pretty common tool for rust devs (or at least more common than I knew).* I'll rant for a bit first, which those new to rust macros may find interesting or informative (it's kinda a little tutorial) ... *to see the implementation, go to "Implementation (without using a macro)" heading and what follows below*. # Using a macro Well, "declarative macros" (with `macro_rules!`) were pretty useful I found and easy to get going with (such that it makes perfect sense that they're used more frequently than I thought). * It's basically pattern matching on arbitrary code and then emitting new code through a templating-like mechanism (pretty intuitive). * The type system and `rust-analyzer` `LSP` understand what you're emitting perfectly well in my experience. It really felt properly native to rust. ## The Elements of writing patterns with "Declarative macros" **Use `macro_rules!` to declare a new macro** Yep, it's also a macro! **Create a structure just like a `match expression`** * Except the pattern will match on the code provided to the new macro * ... And uses special syntax for matching on generic parts or fragments of the code * ... And it returns new code (not an expression or value). **Write a pattern as just rust code with "generic code fragment" elements** * You write the code you're going to match on, *but for the parts that you want to capture as they will vary from call to call*, you specify variables (or more technically, "metavariables"). * You can think of these as the "arguments" of the macro. As they're the parts that are operated on while the rest is literally just static text/code. * These variables *will have a name and a type*. * The name as prefixed with a dollar sign `$` like so: `$GENERIC_CODE`. * And it's type follows a colon as in ordinary rust: `$GENERIC_CODE:expr` * These types are actually syntax specifiers. They specify what part of rust syntax will appear in the fragment. * *Presumably,* they link right back into the rust parser and are part of how these macros integrate pretty seamlessly with the type system and borrow checker or compiler. * Here's a decent list from rust-by-example (you can get a full list in the [rust reference on macro "metavariables"](https://doc.rust-lang.org/reference/macros-by-example.html#metavariables)): * `block` * `expr` is used for expressions * `ident` is used for variable/function names * `item` * `literal` is used for literal constants * `pat` (pattern) * `path` * `stmt` (statement) * `tt` (token tree) * `ty` (type) * `vis` (visibility qualifier) *So a basic pattern* that matches on any `struct` while capturing the `struct`'s name, its only field's name, and its type would be: ```rust macro_rules! my_new_macro { ( struct $name:ident { $field:ident: $field_type:ty } ) } ``` Now, `$name`, `$field` and `$field_type` will be captured for any single-field `struct` (and, *presumably*, the validity of the syntax enforced by the "fragment specifiers"). **Capture any repeated patterns with `+` or `*`** * Yea, just like `regex` * Wrap the repeated pattern in `$( ... )` * Place whatever separating code that will occur between the repeats *after* the wrapping parentheses: * EG, a separating comma: `$( ... ),` * Place the repetition counter/operator after the separator: `$( ... ),+` ### Example *So, to capture multiple fields in a `struct`* (expanding from the example above): ```rust macro_rules! my_new_macro { ( struct $name:ident { $field:ident: $field_type:ty, $( $ff:ident : $ff_type: ty),* } ) } ``` * This will capture the first field and then any additional fields. * The way you use these repeats mirrors the way they're captured: they all get used in the same way and rust will simply repeat the new code for each repeated captured. ## Writing the emitted or new code **Use `=>` as with match expressions** * Actually, it's `=> { ... }`, IE with braces (not sure why) **Write the new emitted code** * All the new code is simply written between the braces * Captured "variables" or "metavariables" can be used just as they were captured: `$GENERIC_CODE`. * *Except types aren't needed here* * Captured repeats are expressed within wrapped parentheses just as they were captured: `$( ... ),*`, including the separator (which can be different from the one used in the capture). * The code inside the parentheses can differ from that captured (*that's the point after all*), but at least one of the variables from the captured fragment has to appear in the emitted fragment so that rust knows which set of repeats to use. * A useful feature here is that the repeats can be used multiple times, in different ways in different parts of the emitted code (the example at the end will demonstrate this). ### Example *For example*, we could convert the `struct` to an `enum` where each field became a variant with an enclosed value of the same type as the `struct`: ```rust macro_rules! my_new_macro { ( struct $name:ident { $field:ident: $field_type:ty, $( $ff:ident : $ff_type: ty),* } ) => { enum $name { $field($field_type), $( $ff($ff_type) ),* } } } ``` With the above macro defined ... this code ... ```rust my_new_macro! { struct Test { a: i32, b: String, c: Vec<String> } } ``` ... will emit this code ... ```rust enum Test { a(i32), b(String), c(Vec<String>) } ``` # Application: "The code" before making it more efficient with a macro *Basically ... a simple system for custom types to represent physical units.* ## The Concept (and a rant) A basic pattern I've sometimes implemented on my own (without bothering with dependencies that is) is creating some basic representation of physical units in the type system. Things like meters or centimetres and degrees or radians etc. If your code relies on such and performs conversions at any point, *it is way too easy to fuck up*, and therefore worth, IMO, creating some safety around. NASA provides an obvious warning. As does, IMO, common sense and experience: most scientists and physical engineers learn the importance of "dimensional analysis" of their calculations. In fact, it's the sort of thing that should arguably be built into any language that takes types seriously (like eg rust). I feel like there could be an argument that it'd be as reasonable as the numeric abstractions we've worked into programming?? At the bottom I'll link whatever crates I found for doing a better job of this in rust (one of which seemed particularly interesting). ## Implementation (without using a macro) The essential design is (again, this is basic): * A single type for a particular dimension (eg time or length) * Method(s) for converting between units of that dimension * *Ideally*, flags or constants of some sort for the units (thinking of enum variants here) * These could be methods too ```rust #[derive(Debug)] pub enum TimeUnits {s, ms, us, } #[derive(Debug)] pub struct Time { pub value: f64, pub unit: TimeUnits, } impl Time { pub fn new<T: Into<f64>>(value: T, unit: TimeUnits) -> Self { Self {value: value.into(), unit} } fn unit_conv_val(unit: &TimeUnits) -> f64 { match unit { TimeUnits::s => 1.0, TimeUnits::ms => 0.001, TimeUnits::us => 0.000001, } } fn conversion_factor(&self, unit_b: &TimeUnits) -> f64 { Self::unit_conv_val(&self.unit) / Self::unit_conv_val(unit_b) } pub fn convert(&self, unit: TimeUnits) -> Self { Self { value: (self.value * self.conversion_factor(&unit)), unit } } } ``` So, we've got: * An `enum` `TimeUnits` representing the various units of time we'll be using * A `struct` `Time` that will be any given `value` of "time" expressed in any given `unit` * With methods for converting from any units to any other unit, the heart of which being a `match expression` on the new unit that hardcodes the conversions (relative to base unit of seconds ... see the `conversion_factor()` method which generalises the conversion values). *Note:* I'm using `T: Into<f64>` for the `new()` method and `f64` for `Time.value` as that is the easiest way I know to accept either integers or floats as values. It works because `i32` (and most other numerics) can be converted lossless-ly to `f64`. *Obviously you can go further than this. But the essential point is that each unit needs to be a new type with all the desired functionality implemented manually or through some handy use of blanket trait implementations* # Defining a macro instead *For something pretty basic, the above is an annoying amount of boilerplate!!* May as well rely on a dependency!? Well, we can write the boilerplate once in a macro and then only provide the informative parts! In the case of the above, the only parts that matter are: * The name of the type/`struct` * The name of the units `enum` type we'll use (as they'll flag units throughout the codebase) * The names of the units we'll use and their value relative to the base unit. IE, for the above, we only need to write something like: ```rust struct Time { value: f64, unit: TimeUnits, s: 1.0, ms: 0.001, us: 0.000001 } ``` *Note: this isn't valid rust!* But that doesn't matter, so long as we can write a pattern that matches it and *emit* valid rust from the macro, it's all good! (Which means we can write our own little DSLs with native macros!!) To capture this, all we need are what we've already done above: capture the first two fields and their types, then capture the remaining "field names" and their values in a repeating pattern. ## Implementation of the macro **The pattern** ```rust macro_rules! unit_gen { ( struct $name:ident { $v:ident: f64, $u:ident: $u_enum:ident, $( $un:ident : $value:expr ),+ } ) } ``` * Note the repeating fragment doesn't provide a type for the field, but instead captures and expression `expr` after it, *despite being invalid rust*. **The Full Macro** ```rust macro_rules! unit_gen { ( struct $name:ident { $v:ident: f64, $u:ident: $u_enum:ident, $( $un:ident : $value:expr ),+ } ) => { #[derive(Debug)] pub struct $name { pub $v: f64, pub $u: $u_enum, } impl $name { fn unit_conv_val(unit: &$u_enum) -> f64 { match unit { $( $u_enum::$un => $value ),+ } } fn conversion_factor(&self, unit_b: &$u_enum) -> f64 { Self::unit_conv_val(&self.$u) / Self::unit_conv_val(unit_b) } pub fn convert(&self, unit: $u_enum) -> Self { Self { value: (self.value * self.conversion_factor(&unit)), unit } } } #[derive(Debug)] pub enum $u_enum { $( $un ),+ } } } ``` Note the repeating capture is used twice here in different ways. * The capture is: `$( $un:ident : $value:expr ),+` And in the emitted code: * It is used in the `unit_conv_val` method as: `$( $u_enum::$un => $value ),+` * Here the `ident` `$un` is being used as the variant of the `enum` that is defined later in the emitted code * Where `$u_enum` is also used without issue, as the name/type of the `enum`, despite not being part of the repeated capture but another variable captured outside of the repeated fragments. * It is then used in the definition of the variants of the enum: `$( $un ),+` * Here, only one of the captured variables is used, which is perfectly fine. ## Usage Now all of the boilerplate above is unnecessary, and we can just write: ```rust unit_gen!{ struct Time { value: f64, unit: TimeUnits, s: 1.0, ms: 0.001, us: 0.000001 } } ``` *Usage from `main.rs`:* ```rust use units::Time; use units::TimeUnits::{s, ms, us}; fn main() { let x = Time{value: 1.0, unit: s}; let y = x.convert(us); println!("{:?}", x); println!("{:?}", x); } ``` *Output:* ```rust Time { value: 1.0, unit: s } Time { value: 1000000.0, unit: us } ``` * Note how the `struct` and `enum` created by the emitted code is properly available from the module as though it were written manually or directly. * In fact, my LSP (`rust-analyzer`) was able to autocomplete these immediately once the macro was written and called. # Crates for unit systems I did a brief search for actual units systems and found the following ## `dimnesioned` **[`dimensioned` documentation](https://docs.rs/dimensioned/latest/dimensioned/index.html)** * Easily the most interesting to me (from my quick glance), as it seems to have created the most native and complete representation of physical units in the type system * It creates, through types, a 7-dimensional space, one for each SI base unit * This allows all possible units to be represented as a reduction to a point in this space. * EG, if the dimensions are `[seconds, meters, kgs, amperes, kelvins, moles, candelas]`, then the `Newton`, `m.kg / s^2` would be `[-2, 1, 1, 0, 0, 0, 0]`. * This allows all units to be mapped directly to this consistent representation (*interesting!!*), and all operations to then be done easily and systematically. Unfortunately, I'm not sure if the [repository](https://github.com/paholg/dimensioned) is still maintained. ## uom **[uom documentation](https://docs.rs/uom/latest/uom/)** * This might actually be good too, I just haven't looked into it much * It also seems to be currently maintained ## F# Interestingly, `F#` actually has a system built in! * See [learning documentation on `F#` here](https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/units-of-measure) * Also this older (2008) [series of blogs on the feature here](https://learn.microsoft.com/en-us/archive/blogs/andrewkennedy/units-of-measure-in-f-part-one-introducing-units)

Lemmy maegul • 1 month ago • 100%

I looked around and struggled to find out what it does? My guess would be that it notifies you of when new posts are made to communities you subscribe to. But that sounds like a lot, so I'm really not sure. Otherwise, is it me or does the wording here not speak for itself?

Fuck AI maegul • 1 month ago • 90%

www.bain.com

Report showing the shift in AI sentiment in the industry. Relatively in depth and probably coming from a pro-AI bias (I haven’t read the whole thing). Last graph at the bottom was what I was linked to. Clearly shows a corner turning where those closer to the actual “product” are now sceptical while management (the last category in the chart) are more committed.

Lemmy maegul • 2 months ago • 88%

Generally, the lens I've come to criticise any/all fediverse projects is how well they foster community building. One reason why I like and "advocate" for the lemmy/threadiverse side of things is precisely because of this and how the centrality of the community/sub/group is a good way of organising social media (IMO). Also, because of that, I recently came to be skeptical of the effects that the "All" feed can have. I didn't even realise that people relied mostly on the All feed until recently. I think I've reached the point now of being against it (at least tentatively). I know, it's a staple and there's no way it's going away. And I know it's useful. But thinking about the feature set, through the community building lens, I think it'd be fair to say that things are out of balance: they don't promote community building enough while also providing the All feed which dissolves community building. Not really a criticism of the developers ... AFAIU, the All feed is easier to implement than any other community building feature ... and it's expected from reddit (though it isn't normal on forums AFAICT, which is maybe worth considering for anyone happy to reassess what about reddit is retained and what isn't). But still, I can imagine a platform that is more focused on communities: * Community explorer tool built in. * Could even be a substitute for an All feed ... where you can browse through various communities you don't know about and see what they've posted recently * Multi-communities (long time coming by now for many I'd say) * Could even be part of the community explorer tool where you can create on-the-fly multi-communities to see their posts in a temporary feed * Private and local only communities (already here on lemmy and coming for private communities) * Post visibility options for Public communities (IE, posts that opt-in private) * More flexible notifications for various things/events that happen within a community * Wikis * Chat interface * I'm thinking this is pretty viable given that Lemmy used to use a web-socket auto-updating design ... add that to the flat chat view and you've got a chat room. There are resource issues, so limiting them to one per community or 6hrs per week per community or something would probably be necessary. A possibly interesting and frustrating aspect of all of these suggestions/ideas above is I can see their federation being problematic or difficult ... which raises the issue of whether there's serious tension between platform design and protocol capabilities.

movies maegul • 2 months ago • 88%

There are also some gems in there about how old and constant underplaying the amount of VFX in a film is. From the video, Stand By Me had a VFX shot (the train bridge scene, of course) but no one was allowed to talk about that. And of course The Fugitive train crash scene had to have "real trains" even though it's all mostly miniatures.

Learning Rust and Lemmy maegul • 2 months ago • 91%

The post mentions data or research on how rust usage in is resulting in fewer errors in comparison to C. Anyone aware of good sources for that?

movies maegul • 2 months ago • 86%

*Lets try this experiment* Start watching **Big Trouble in Little China** at **7pm**, **Central Time, USA** (as precisely as you can) ... and come here for live posts as you watch! *This is ~24 hours from the time of this post* Here's a [timeanddate.com link to the timezone(s) involved](https://www.timeanddate.com/worldclock/converter.html?iso=20240727T235800&p1=tz_aet&p2=tz_cest&p3=tz_ct). --- [@AVincentInSpace@pawb.social](https://pawb.social/u/AVincentInSpace) jas volunteered to run a live watch on cytube the day afterward (approx 7pm Monday). Posts and links should be coming (and see comments below on the idea).

movies maegul • 2 months ago • 83%

*Lets try this experiment* Start watching **Big Trouble in Little China** at **7pm**, **Central European Summer Time** (as precisely as you can) ... and come here for live posts as you watch! *This is ~17 hours from the time of this post* Here's a [timeanddate.com link to the timezone(s) involved](https://www.timeanddate.com/worldclock/converter.html?iso=20240727T235800&p1=tz_aet&p2=tz_cest&p3=tz_ct).

movies maegul • 2 months ago • 80%

*Lets try this experiment* Start watching **Big Trouble in Little China** at **7pm**, **Australian Eastern Standard Time** (as precisely as you can) ... and come here for live posts as you watch! *This is ~9 hours from the time of this post* Here's a [timeanddate.com link to the timezone(s) involved](https://www.timeanddate.com/worldclock/converter.html?iso=20240727T235800&p1=tz_aet&p2=tz_cest&p3=tz_ct). --- A little short notice, it's more of an experiment this time. I've got my DVD and will most likely pop in.

Learning Rust and Lemmy maegul • 2 months ago • 100%

A supplement to typical tutorials that caters to C programmers interested in learning how to be unsafe upfront. Seems good from a quick skim. Also seems that the final lesson is that starting on the safe/happy path in rust doesn’t have to cost performance if you know what you’re doing.

Learning Rust and Lemmy maegul • 2 months ago • 100%

Just a quick riff/hack on whether it'd be hard to make a `collect()` method that "collected" into a `Vec` without needing any turbofish (see, if you're interested, my [prior post on the `turbofish`](https://lemmy.ml/post/17715376). *Some grasp of traits and iteration is required to comfortably get this ... though it might be a fun dive even if you're not* ### Background on `collect` The implementation of `collect` is: ```rust fn collect<B: FromIterator<Self::Item>>(self) -> B where Self: Sized, { FromIterator::from_iter(self) } ``` The generic type `B` is bound by `FromIterator` which basically enables a type to be constructed from an `Iterator`. In other words, `collect()` returns *any* type that can be built from an interator. EG, `Vec`. The reason the `turbofish` comes about is that, as I said above, it returns "*any* type" that can be built from an iterator. So when we run something like: ```rust let z = [1i32, 2, 3].into_iter().collect(); ``` ... we have a problem ... rust, or the `collect()` method has no idea what type we're building/constructing. More specifically, looking at the code for `collect`, in the call of `FromIterator::form_iter(self)`, which is calling the method on the trait directly, rust has no way to determine *which implementation* of the trait to use. The one on `Vec` or `HashMap` or `String` etc?? Thus, the `turbofish` syntax specifies the generic type `B` which (somehow through type inference???) then determines which implementation to use. ```rust let z = [1i32, 2, 3].into_iter().collect::<Vec<_>>(); ``` *IE: Use the implementation on `Vec`!* ### Why not just use `Vec`? I figure `Vec` is used so often as the type for collecting an `Iterator` that it could be nice to have a convenient method. The docs even hint at this by suggesting that calling the `FromIterator::from_iter()` method directly from the desired type (eg `Vec`) can be more readable (see [`FromIterator` docs](https://doc.rust-lang.org/core/iter/trait.FromIterator.html)). *EG ... using `collect`*: ```rust let d = [1i32, 2, 3]; let x = d.iter().map(|x| x + 100).collect::<Vec<_>>(); ``` *Using `Vec::from_iter()`* ```rust let y = Vec::from_iter(d.iter().map(|x| x + 100)); ``` As `Vec` is always in the prelude (IE, it's always available), using `from_iter` clearly seems like a nicer option here. *But you lose method chaining!* So ... how about a method on `Iterator`, like `collect` but for `Vec` specifically? How would you make that and is it hard?? ### Making `collect_vec()` *It's not hard actually* * Define a trait, `CollectVec` that defines a method `collect_vec` which returns `Vec<Self::Item>` * Make this a "sub-trait" of `Iterator` (or, make `Iterator` the "supertrait") so that the `Iterator::collect()` method is always available * Implement `CollectVec` for all types that implement `Iterator` by just calling `self.collect()` ... *the type inference will take care of the rest, because it's clear that a `Vec` will be used*. ```rust trait CollectVec: Iterator { fn collect_vec(self) -> Vec<Self::Item>; } impl<I: Iterator> CollectVec for I { fn collect_vec(self) -> Vec<Self::Item> { self.collect() } } ``` With this you can then do the following: ```rust let d = [1i32, 2, 3]; let d2 = d.iter().map(|x| x + 1).collect_vec(); ``` Don't know about you, but implementing such methods for the common collection types would suit me just fine ... that turbofish is a pain to write ... and AFAICT this isn't inconsistent with rust's style/design. And it's super easy to implement ... the type system handles this issue very well.

NeoDB maegul • 2 months ago • 100%

wedistribute.org

cross-posted from: https://lemmy.ml/post/18372054 > Today, we sat down and reviewed NeoDB, a Fediverse review system that lets you track books, movies, music, tv shows, games, podcasts, and more. There's some really incredible ideas beneath the surface.

Learning Rust and Lemmy maegul • 2 months ago • 100%

I hadn't thought about this until now. Handy. Of course there's the [`f64` equivalent](https://doc.rust-lang.org/stable/std/f64/consts/index.html): `std::f64::consts`

Fuck AI maegul • 2 months ago • 71%

cross-posted from: https://lemmy.ml/post/18310802 > Fun to see him (kmac2021) making shit again

Videos maegul • 2 months ago • 71%

Fun to see him (kmac2021) making shit again

Learning Rust and Lemmy maegul • 2 months ago • 100%

*This pertains to Ch 16.03 of The Book, specifically `Arc` in multithreaded programs* I was just looking at the signature for `thread::spawn` (documentation linked to by post URL) wondering if and how the requirement for a thread-safe smart pointer is enforced by the type system. In short, how is the use of `Arc` necessitated by the type system?? For the signature, you get this: ```rust pub fn spawn<F, T>(f: F) -> JoinHandle<T> where F: FnOnce() -> T + Send + 'static, T: Send + 'static, ``` Where the parameter `f` is bound by ` F: FnOnce() -> T + Send + 'static`. And ... I'm not entirely sure how I should think about this. Obviously, `Send` and `'static` here are related to my question, where *in some way* the closure must be thread-safe (through the `Send` trait) and also have a whole-life-of-the-program lifetime (through the `'static` lifetime). Therefore, *in some way*, something like `Rc` would be invalid but `Arc` would be. **But how exactly?** 1. Are the bounds on the return type of the function/closure, which then sort of back propagate onto the input parameters or captured values of the function/closure? 1. Or are these somehow properties of the function itself? 1. And why is `T` separately bound by `Send + 'static` when they are already present in the bounds on `F`? My best guess is that the bounds on `F` are best parsed as ... ```rust F: ( FnOnce() -> T ) + Send + 'static T: Send + 'static ``` IE, Everything separated by a `+` is unitary, and, therefore, `FnOnce() -> T` is a single bound and `Send` another separate bound. But I'm unsure about that, haven't read that anywhere, and am not really sure how to understand how exactly a function *can have* `Send` or `'static` without some logic linking that directly to its input parameters? Thoughts?

movies maegul • 2 months ago • 97%

The votes are in ... **Big Trouble in Little China** beat out Dungeons and Dragons: Honour Among Thieves by a hair (1 vote it seems) (see [voting post here]([https://lemm.ee/post/36642778](https://lemm.ee/post/36642778?sort=Top))). [IMDb](https://www.imdb.com/title/tt0090728/) | [Wikipedia](https://en.wikipedia.org/wiki/Big_Trouble_in_Little_China) Please treat this as **Discussion Thread** for the film over the next week or two ... or if you like, write up your own posts about it! If you have any tips on where to get it, please feel free to share (I'll probably add them to the top post) I've certainly never seen it and look forward to watching it! --- EDIT: A live watch event *might happen* if it can get organised. Feel free to comment about that below or put your hand up to organise it if you're interested. We could watch it live together, or schedule a time and run a megathread here. Share your thoughts below. --- ### Honourable Mentions **Terminator 2: Judgment Day** * For being rather popular (came a close third in the voting). * It was my nomination as a nostalgia visit back to popcorn 90s AI action sci-fi, which my partner hasn't seen. * I'll probably watch it some time soon **Soylent Green** * Also popular in the voting, and keeping up what might be a classic dystopian trend here **The Apartment (1960)** * Easily the oldest film suggested this round! I've never seen it but it seems to be a classic and I really appreciate that someone nominated it (and it was popular in the voting too!) *And there were other films in the nominations too you might be interested in* (see the voting post linked above) ... for me personally *Underwater (2020)* stood out as one I'd not heard of (despite being recent), and, as an Alien fan, I'll be more than happy to give it a watch.

NeoDB maegul • 2 months ago • 100%

In particular: https://eggplant.place/discover/ Which is running a dev version of neoDB, and so may be unstable, but has English as its main language.

It just struck me recently and I'm sharing. As a millennial who enjoyed these shows as a young(er) adult ... I cherished them both, and at the time probably like 30 Rock more, and probably would have said that it's "the better comedy". Over time though I've noticed I basically don't really think about 30 Rock ... frankly I almost certainly think about Seinfeld more ... but Community has "seeped in" to my TV subconscious fabric. If I were to re-watch either right now, it'd be Community hands down. It'd be heart warming and comfortable and, *I suspect*, more relevant or still meaningful. By comparison, I wouldn't be surprised if 30 Rock would feel more dated, "noisy", and kinda culturally narrow and specific in a not-coincidentally SNL-like way. 30 Rock may still be "the better" TV Comedy (whatever that means). But it was written by a TV writer about making TV in New York, while Community was written *about* TV and its fans, IE "us", living in any random city.

Lemmy maegul • 2 months ago • 100%

EDIT: Looked a little deeper/better on GitHub and found [this issue, #4865](https://github.com/LemmyNet/lemmy/issues/4865) which is likely the most related issue, and it seems the devs are aware. *It also seems to be a recent v19.5 -ish issue too from some of the comments there* --- I seem to be encountering what may be a bug with pinning/featuring posts ... interested if anyone's got similar/counter experiences The issue is that the pinning of a post doesn't get federated correctly. The conditions, AFAICT are: * Post originates from a "federated instance" (IE, an instance other than the community's home instance) * The mod action of pinning is also done by a moderator on a "federated instance" * Lemmy versions 19.4 or greater (*much more tentative, but from a brief perusal, it seems true*) The effect seems to be: * The pinning works fine on the "home instance" of the community * But federation breaks in two slightly different ways: * No pinning occurs * If a mod on a "federated instance" tries to pin, after an initially failed federation of "pinning", it will succeed on the federated instance only temporarily The last dynamic is hopefully a clue to what could be happening (sounds like some queued tasks colliding in an incorrect way)

movies maegul • 2 months ago • 95%

**Upvote the film you'd like to watch the most in the comments below!** Nominations are in for July's Fedi Film Club (see [nominations post here](https://lemmy.ml/post/17500783)). Each one in is a separate comment below, which you can upvote. And, for clarity, they're also in the list below, in alphabetical order. *If you have any handy tips on the best way to get a hold of any of these, please share! Note though that the high seas in general are likely are well known option.* * Big Trouble in Little China * Dungeons and Dragons: Honour Among Thieves (2023) * I’m Thinking of Ending Things (2020) * Soylent Green * Terminator 2: Judgment Day * The Andromeda Strain (1971) * The Apartment (1960) * The Peanut Butter Falcon (2019) * Underwater (2020) * Wacko (1982) --- *And of course, the point of all this is to crowd-source human curated film recommendations. This is definitely a diverse bunch of films, some of which I didn't know about and others I'd never seen. I'll definitely want to watch more than one of these!*

Learning Rust and Lemmy maegul • 2 months ago • 100%

The [`about` section](https://turbo.fish/about) of the linked page has links and a brief explanation of the story. In my own words ... ### Description of the Turbo-fish syntax * Whenever a generic type (see ch 10 of The Book) is involved in calling a function/method or constructing/handling a struct/enum, you may need to specify that concrete type for that generic. * See [this handy blog post on the turbofish that lists when it's necessary](https://matematikaadit.github.io/posts/rust-turbofish.html) * This type is provided with the `turbo fish` syntax: `::<>` ... where the type goes between the angle brackets. * EG: ```rust let v = Vec::new(); let v2 = Vec::<i32>::new() ``` * The elements of `v` have an undefined type, which rust will infer once an element is pushed into it. But `v2` has a defined element type, `i32`, defined using the `turbo fish`. --- ### The Story * This syntax wasn't always liked, and the double colons (`::`) thought redundant. * But it stuck * And was given the name "turbo-fish" by Anna Harren (u/deadstone, Reddit) ... who sadly passed away in 2021. * It turns out that the double colons are pretty vital to preventing ambiguity. * This is enshrined in the [**Bastion of the Turbofish**](https://github.com/rust-lang/rust/blob/43192ca3d72ed0ca42ba913137585219ba0a691f/src/test/ui/parser/bastion-of-the-turbofish.rs) which stands as a memorial to Anna Harren ... * a test in the language's test suite that ensures that the double-colons syntax isn't removed by directly using the ambiguous syntax that'd arise without it. * See if you can understand the test (it took me a while! ... [this HN post might help](https://news.ycombinator.com/item?id=27155091)): ```rust let (the, guardian, stands, resolute) = ("the", "Turbofish", "remains", "undefeated"); let _: (bool, bool) = (the<guardian, stands>(resolute)); ``` *hint: what are angle brackets normally used for and how are `bool` types related to that?*

Learning Rust and Lemmy maegul • 3 months ago • 100%

github.com

Nice and handy reference with explanations and examples.

Learning Rust and Lemmy maegul • 3 months ago • 100%

You've gotta be familiar with `Traits` to try to work this out. ::: spoiler Just in case you want to try to work it out your self first Gotta say, after hearing that rust is not an OOP/Class-inheritance language, and is strongly and explicitly typed, the `Deref` trait feels like a helluva drug! Obviously it's not the same thing, but working this out definitely had me making a couple of double takes. Somewhat awkwardly, I worked it out through the standard lib docs before reading ch 15 of the book (it's more fun this way!). And for those who want a quick answer: * Read the [`Deref` docs, especially the `deref coercion` part](https://dev-doc.rust-lang.org/stable/std/ops/trait.Deref.html#deref-coercion) * This allows a variable of a particular type to be *implicitly* substituted with another variable of a different type. * It happens any time a reference is passed in/out of a function, including `self` in method calls. * And obviously requires that `Deref` be implemented. * So `sort()` isn't implemented on `Vec`, it's implemented on the `slice` type (`[T]`). * But `Vec` implements `Deref`, substituting `[T]` for `Vec<T>` in all function/method calls. * Which means `Vec` gets all of the methods implemented on `[T]` ... *almost like `Vec` is a subclass of `[T]`*! * And yea, OOP people want to abuse this ([see, eg, rust-unofficial on anti-patterns](https://rust-unofficial.github.io/patterns/anti_patterns/deref.html)) :::

movies maegul • 3 months ago • 96%

**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"](https://lemmy.ml/post/17317598). * We'll take a vote on the suggestions in about a week's time after this. Then we can watch and discuss.

movies maegul • 3 months ago • 97%

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?

movies maegul • 3 months ago • 91%

www.youtube.com

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.

Learning Rust and Lemmy maegul • 3 months ago • 100%

Continuing on from Chs 5 & 6 of "The Book" (see "Reading Club" post [here](https://lemmy.ml/post/17112524)), 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](https://rust-book.cs.brown.edu/appendix-03-derivable-traits.html#debug-for-programmer-output). 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](https://doc.rust-lang.org/reference/attributes.html)): `#[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](https://github.com/rust-lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md#controlling-copy-vs-move-with-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](https://doc.rust-lang.org/src/core/marker.rs.html#403)). #### 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](https://doc.rust-lang.org/std/clone/trait.Clone.html#implementors)), 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](https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#2834)), 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.

Learning Rust and Lemmy maegul • 3 months ago • 100%

Relevant for [@sorrybookbroke@sh.itjust.works](https://sh.itjust.works/u/sorrybookbroke) '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.