A little bit of neuroscience and a little bit of computing

  • 179 Posts
  • 2.47K Comments
Joined 1 year ago
cake
Cake day: January 19th, 2023

help-circle
  • Q1

    /// Makes a string to separate lines of text, 
    /// returning a default if the provided string is blank
    fn make_separator(user_str: &str) -> &str {
        if user_str == "" {
            let default = "=".repeat(10);
            &default
        } else {
            user_str
        }
    }
    

    When compiling, what’s the best description of the compiler error?

    1. user_str does not live long enough
    2. function make_separator cannot return two different references
    3. function make_separator cannot return a reference of type &str
    4. cannot return reference to local variable default
    Answer

    Cannot return reference to a local variable

    • &default isn’t allowed as default is local to the function.
      • What’s the fix? Copy? Just return "=".repeat(10) directly?
      • How about just return an owned String (requires converting user_str to a String with to_string())

    Context: Because default lives on the stack within make_separator, it will be deallocated once a call to make_separator ends. This leaves &default pointing to deallocated memory. Rust therefore complains that you cannot return a reference to a local variable.


  • Q2

    /// Makes a string to separate lines of text, 
    /// returning a default if the provided string is blank
    fn make_separator(user_str: &str) -> &str {
        if user_str == "" {
            let default = "=".repeat(10);
            &default
        } else {
            user_str
        }
    }
    

    Normally if you try to compile this function, the compiler returns the following error:

    error[E0515]: cannot return reference to local variable `default`
    
     --> test.rs:6:9
    
      |
    
    6 |         &default
    
      |         ^^^^^^^^ returns a reference to data owned by the current function
    

    Assume that the compiler did NOT reject this function. Which (if any) of the following programs would (1) pass the compiler, and (2) possibly cause undefined behavior if executed? Check each program that satisfies both criteria, OR check “None of these programs” if none are satisfying.

    • None of these programs
    // 1
    let s = make_separator("");
    
    // 2
    let s = make_separator("");
    println!("{s}");
    
    // 3
    println!("{}", make_separator("Hello world!"));
    
    Answer
    • Slightly dodgy question, as the undefined behaviour first requires an empty string to be passed in to trigger the return of &default, which results in a dangling pointer being returned. Then, it’s any program that uses the returned reference (so printing will do the trick)

    Context: First, the caller must pass an empty string to trigger the problematic if-condition. This returns a dangling pointer. Second, the caller must use the result of make_separator, e.g. via println.


  • Q3: How fix

    Of the following fixes (highlighted in yellow), which fix best satisfies these three criteria:

    • The fixed function passes the Rust compiler,
    • The fixed function preserves the intention of the original code, and
    • The fixed function does not introduce unnecessary inefficiencies

    1:

    fn make_separator(user_str: &str) -> &str {
        if user_str == "" {
            let default = "=".repeat(10);
            &default
        } else {
            &user_str
        }
    }
    

    2:

    fn make_separator(user_str: String) -> String {
        if user_str == "" {
            let default = "=".repeat(10);
            default
        } else {
            user_str
        }
    }
    

    3:

    fn make_separator(user_str: &str) -> String {
        if user_str == "" {
            let default = "=".repeat(10);
            default
        } else {
            user_str.to_string()        
        }
    }
    
    Answer

    3

    • Return owned default
    • Convert user_str to a String to keep a consistent return type
    • Change return type to String
    • 2 is too restrictive in requiring use_str to be a String
    • 1 doesn’t solve the problem
    fn make_separator(user_str: &str) -> String {
        if user_str == "" {
            let default = "=".repeat(10);
            default
        } else {
            user_str.to_string()        
        }
    }
    

    Context: There is no valid way to return a pointer to a stack-allocated variable. The simple solution is therefore to change the return type to String and copy the input user_str into an owned string. However, requiring user_str to be a String would reduce the flexibility of the API, e.g. a caller could not call make_separator on a substring of a bigger string. It would also require callers to heap-allocate strings, e.g. they could not use a string literal like make_separator(“Rust”).

    The most idiomatic solution to this problem uses a construct you haven’t seen yet: Cow - Clone-on-write. The clone-on-write smart pointer would enable this function to return either an owned string or a string reference without a type error.

    • Interesting!!

  • Q4: Method and Ownership

    • What best describes the compiler error
    /// Gets the string out of an option if it exists,
    /// returning a default otherwise
    fn get_or_default(arg: &Option<String>) -> String {
        if arg.is_none() {
            return String::new();
        }
        let s = arg.unwrap();
        s.clone()
    }
    
    1. arg does not live long enough
    2. cannot move out of arg in arg.unwrap()
    3. cannot call arg.is_none() without dereferencing arg
    4. cannot return s.clone() which does not live long enough
    Answer

    2

    • cannot move arg in arg.unwrap()
      • arg is a reference.
      • but unwrap() has signature unwrap(self) -> T: it takes ownership!
      • Therefore unwrap cannot take ownership (arg doesn’t have ownership to move/give).

    Context: The function Option::unwrap expects self, meaning it expects ownership of arg. However arg is an immutable reference to an option, so it cannot provide ownership of the option. Therefore the compiler complains that we cannot move out of arg via unwrap.


  • Q5

    • Which programs would pass the compiler (presuming this function, from above, passes too) and possibly cause undefined behaviour?
    /// Gets the string out of an option if it exists,
    /// returning a default otherwise
    fn get_or_default(arg: &Option<String>) -> String {
        if arg.is_none() {
            return String::new();
        }
        let s = arg.unwrap();
        s.clone()
    }
    

    Options:

    • None of these programs
    // 1
    let opt = Some(String::from("Rust"));
    let s = get_or_default(&opt);
    println!("{}", s);
    
    // 2
    let opt = Some(String::from("Rust"));
    get_or_default(&opt);
    
    // 3
    let opt = Some(String::from("Rust"));
    get_or_default(&opt);
    println!("{:?}", opt);
    
    Answer
    • All programs (1, 2 and 3).

    • Once arg.unwrap() occurs, s takes ownership of the underlying String.

    • Once s “dies”, the String is deallocated.

    • But, opt, from before the call to get_or_default also owns the same String, and so once it “dies” and its memory is deallocated, a double-free will occur.

    • This actually threw me at first

    • My answer was program 3, as I figured that opt had to be used in some way for “undefined behaviour” to occur, as only then, did I figure, would the inappropriate memory be used resulting in an incorrect result

    • This is kinda wrong, though, because deallocation occurs once opt’s lifetime ends, which will cause a double-free. println prolongs the lifetime while in program 2 the lifetime of opt clearly ends, I suppose, causing the double-free.

      • I personally think this is completely ambiguous, and unless I’m missing something, these undefined behaviour questions easily suffer from these problems.

  • Q6: Fixing

    Of the following fixes (highlighted in yellow), which fix best satisfies these three criteria:

    • The fixed function passes the Rust compiler,
    • The fixed function preserves the intention of the original code, and
    • The fixed function does not introduce unnecessary inefficiencies
    /// Gets the string out of an option if it exists,
    /// returning a default otherwise
    fn get_or_default(arg: &Option<String>) -> String {
        if arg.is_none() {
            return String::new();
        }
        let s = arg.unwrap();
        s.clone()
    }
    

    1:

    fn get_or_default(arg: &Option<&str>) -> String {
        if arg.is_none() {
            return String::new();
        }
        let s = arg.unwrap();
        s.to_string()
    }
    

    2:

    fn get_or_default(arg: &mut Option<String>) -> String {
        if arg.is_none() {
            return String::new();
        }
        let s = arg.as_mut().unwrap();
        s.clone()
    }
    

    3:

    fn get_or_default(arg: Option<String>) -> String {
        if arg.is_none() {
            return String::new();
        }
        let s = arg.unwrap();
        s.clone()
    }
    

    4:

    fn get_or_default(arg: &Option<String>) -> String {
        match arg {
            None => String::new(),
            Some(s) => s.clone()
        }
    }
    
    Answer

    4

    • Really about best-practices here
    • 4 is a better, more idiomatic version of 3, especially because it requires ownership of arg which is restrictive and may not even be available
      • But I think 3 does fix the problem
    • 1 doesn’t fix the problem
    • 2 … I’m not sure about … but I don’t think having a mutable s helps with the problem either (?)

    Context: The combination of is_none and unwrap here is a Rust anti-pattern, since a match combines the two functionalities and automatically deals with pushing the reference &Option into the interior to produce &String. Therefore the match solution is the most idiomatic, and passes the compiler without changing the intended type signature of the function.

    The solution of changing &Option to Option is not desirable because it requires the caller to provide ownership of their option, which is a far more restrictive API.







  • So, to be fair, the line after the quote refers specifically to those that produce “low quality” output.

    So a charitable but not unreasonable read might be that she’s saying any creative role that’s easily replaced with AI isn’t really a loss. In some cases, when we’re talking about artists just trying to make a living, this is really some vile shit. But in the case of email monkeys in corporations and shitty designers and marketeers, maybe she’s got a point along the same lines as “bullshit jobs” logic.

    On the other hand, the tech industry’s overriding presumption that disruption by tech is a natural good and that they’re correctly placed as the actuators of that “good” really needs a lot more mainstream push back. It’s why she felt comfortable declaring some people in industries she likely knows nothing about “shouldn’t exist” and why there weren’t snickers, laughter and immediate rebukes, especially given the lack (from the snippet I saw) of any concern for what the fuck happens when some shitty tech takes away people’s livelihoods.

    If big tech’s track record were laid out, in terms of efficiency, cost, quality etc, in relation to the totality of the economy, not just the profits of its CEOs … I’m just not sure any of the hype cloud around it would look reasonable anymore. With that out of the way, then something so arrogant as this can be more easily ridiculed for the fart-sniffing hype that it so easily can be.


  • Every browser released since 2020 supports this

    It’s a little paranoid of me, but I like the idea that a basic web app I make can be thrown onto any old out of date machine, where ~2015 or younger seems about right for me ATM.

    You mean the Html template Element? I’ve never really got that to work, but I also never seriously tried.

    Yea. From memory, it’s just an unrendered chunk of HTML that you can select and clone with a bit of JS. I always figured there’d be a pattern that isn’t too much of a cludge and gets you some useful amount of the way to components for basic “vanilla-js” pages, just never gave it a shot either.


  • Am I imagining it or has there been a noticeable uptick on the amount media/Hollywood attention on the space race? I suppose it’s always been a point of focus, but with things like this, “For all Man Kind”, “First Man” (film), “Hidden Figures” … I’m wondering if there’s a sort of “Golden Age” preoccupation that’s settled in with the space race?


  • Yea, I’m unclear on how you can take web components and still have widespread browser support (not knowing enough about their ins and outs).

    Plain template elements are widely supported and have been for ~10 years (which ideologically matters to me along the same lines as the top post’s article) … perhaps a little bit of hacking together can get you close with just that?





  • maegul@lemmy.mltoScience Memes@mander.xyzElsevier
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 days ago

    The problems are wider than that. Besides, relying “individuals just doing the right thing and going a little further to do so” is, IMO, a trap. Fix the system instead. The little thing everyone can do is think about the system and realise it needs fixing.


  • maegul@lemmy.mltoScience Memes@mander.xyzElsevier
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    2 days ago

    I’m sympathetic, but to a limit.

    There are a lot of academics out there with a good amount of clout and who are relatively safe. I don’t think I’ve heard of anything remotely worthy on these topics from any researcher with clout, publicly at least. Even privately (I used to be in academia), my feeling was most don’t even know how to think and talk about it, in large part because I don’t think they do think and talk about it all.

    And that’s because most academics are frankly shit at thinking and engaging on collective and systematic issues. Many just do not want to, and instead want to embrace the whole “I live and work in an ideal white tower disconnected from society because what I do is bigger than society”. Many get their dopamine kicks from the publication system and don’t think about how that’s not a good thing. Seriously, they don’t deserve as much sympathy as you might think … academia can be a surprisingly childish place. That the publication system came to be at all is proof of that frankly, where they were all duped by someone feeding them ego-dopamine hits. It’s honestly kinda sad.


  • maegul@lemmy.mltoScience Memes@mander.xyzElsevier
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 days ago

    Yep. But that is all a part of the problem. If academics can’t organise themselves enough to have some influence over something which is basically owned and run them already (they write the papers and then review the papers and then are the ones reading and citing the papers and caring the most about the quality and popularity of the papers) … then they can’t be trusted to ensure the quality of their practice and institutions going forward, especially under the ever increasing encroachment of capitalistic forces.

    Modern day academics are damn well lucky that they inherited a system and culture that developed some old aristocratic ideals into a set of conventions and practices!