@maegul
@lemmy.mlhttps://www.newsweek.com/russia-ukraine-oil-antarctica-putin-1900233
The reserves uncovered contain around 511 billion barrels worth of oil.
https://www.youtube.com/watch?v=mn2Dcy-NDTw
Aproveite vídeos e músicas que você ama, envie e compartilhe conteúdo original com amigos, parentes e o mundo no YouTube.
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.
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.
https://www.youtube.com/watch?v=IToAClt_utU
Aproveite vídeos e músicas que você ama, envie e compartilhe conteúdo original com amigos, parentes e o mundo no YouTube.
https://www.youtube.com/watch?v=jQs7jb25WNY
Aproveite vídeos e músicas que você ama, envie e compartilhe conteúdo original com amigos, parentes e o mundo no YouTube.
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?
https://www.youtube.com/watch?v=mpHlhNpc_ko
Aproveite vídeos e músicas que você ama, envie e compartilhe conteúdo original com amigos, parentes e o mundo no YouTube.
https://blog.sylver.dev/build-your-own-sqlite-part-1-listing-tables
As developers, we use databases all the time. But how do they work? In this series, we'll try to answer that question by building our own SQLite-compatible database from scratch. Source code examples will be provided in Rust, but you are encouraged t...
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.
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).
rust-analyzer
LSP
understand what you're emitting perfectly well in my experience. It really felt properly native to rust.Use macro_rules!
to declare a new macro
Yep, it's also a macro!
Create a structure just like a match expression
Write a pattern as just rust code with "generic code fragment" elements
$
like so: $GENERIC_CODE
.$GENERIC_CODE:expr
block
expr
is used for expressionsident
is used for variable/function namesitem
literal
is used for literal constantspat
(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:
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 *
regex
$( ... )
$( ... ),
$( ... ),+
So, to capture multiple fields in a struct
(expanding from the example above):
macro_rules! my_new_macro {
(
struct $name:ident {
$field:ident: $field_type:ty,
$( $ff:ident : $ff_type: ty),*
}
)
}
Use =>
as with match expressions
=> { ... }
, IE with braces (not sure why)Write the new emitted code
$GENERIC_CODE
.$( ... ),*
, including the separator (which can be different from the one used in the capture).
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
:
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 ...
my_new_macro! {
struct Test {
a: i32,
b: String,
c: Vec<String>
}
}
... will emit this code ...
enum Test {
a(i32),
b(String),
c(Vec<String>)
}
Basically ... a simple system for custom types to represent physical units.
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).
The essential design is (again, this is basic):
#[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:
enum
TimeUnits
representing the various units of time we'll be usingstruct
Time
that will be any given value
of "time" expressed in any given unit
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
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:
struct
enum
type we'll use (as they'll flag units throughout the codebase)IE, for the above, we only need to write something like:
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.
The pattern
macro_rules! unit_gen {
(
struct $name:ident {
$v:ident: f64,
$u:ident: $u_enum:ident,
$( $un:ident : $value:expr ),+
}
)
}
expr
after it, despite being invalid rust.The Full Macro
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.
$( $un:ident : $value:expr ),+
And in the emitted code:
unit_conv_val
method as: $( $u_enum::$un => $value ),+
ident
$un
is being used as the variant of the enum
that is defined later in the emitted code$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.$( $un ),+
Now all of the boilerplate above is unnecessary, and we can just write:
unit_gen!{
struct Time {
value: f64,
unit: TimeUnits,
s: 1.0,
ms: 0.001,
us: 0.000001
}
}
Usage from main.rs
:
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:
Time { value: 1.0, unit: s }
Time { value: 1000000.0, unit: us }
struct
and enum
created by the emitted code is properly available from the module as though it were written manually or directly.rust-analyzer
) was able to autocomplete these immediately once the macro was written and called.I did a brief search for actual units systems and found the following
dimnesioned
[seconds, meters, kgs, amperes, kelvins, moles, candelas]
, then the Newton
, m.kg / s^2
would be [-2, 1, 1, 0, 0, 0, 0]
.Unfortunately, I'm not sure if the repository is still maintained.
Interestingly, F#
actually has a system built in!
F#
here