• 0 Posts
  • 2.34K Comments
Joined 3 years ago
cake
Cake day: June 21st, 2023

help-circle
  • From an article linked in this one:

    Via WSVN, Bermudez claims he’s “not against video games, but to go out and get a video game where – which glorifies not only our first responders getting shot, but also pedestrians and residents – it’s nonsensical.”

    Republican sheriff Cordero-Stutz similarly points to GTA’s crime-centric themes, adding: “At a time when law enforcement is working every day to reduce violent crime, prevent robberies and car thefts, combat drug trafficking, and build stronger relationships between our deputies and the communities we serve, I believe we need to seriously consider the message we send when our own government promotes a fictional identity centered around many of those same crimes.”

    Remember, kids. Guns don’t kill people. Games about guns kill people.



  • fearless_simd takes unsafe out of SIMD.

    No matter what level of abstraction you’re after, be it autovectorization and multiversioning, or portable SIMD, or safe access to raw intrinsics and nothing more, fearless_simd has you covered!

    Just adding some context. Seems like the v1 announcement, which is cool. It looks like a really useful crate, and I’m sure I’ve used it transitively at least once (based on the download count), though not directly yet.


  • You took out a loan for $300? Honestly, I didn’t even know they wrote loans for that much. Wouldn’t the origination fee completely overshadow the loan amount? Or is this on a credit card or something?

    Anyway, mirroring the other commenter, but if you are in no position to accept additional debt, then doing it on behalf of someone else accomplishes nothing. You’ve helped her make the payment once and now you have this additional debt to worry about until you can eventually pay it off.

    Without knowing the interest rate, all I can say is that it’s a good thing it’s only $300. I’ve seen people do this for far larger amounts and end up in debt spirals.


  • Steve doesn’t really elaborate on the drawbacks to the features he listed, just kinda says he doesn’t like them. I’ll do some of that here:

    • Function overloading: overload resolution adds a ton of complexity to the language for a feature with API-friendly workarounds (use different names, builders, etc).
    • Default/optional arguments: can be confusing when the default value is initialized. For example, in Python, default values are static and reused across calls, meaning you can technically have def foo(a=[]), append to a on each call, and use that data on future calls to foo since the same list is provided as a default each time. In C#, default values are compiled into the caller’s code, meaning if the caller’s code was developed for an older version of a library and you use it with an updated version that has a new default, the caller will still use the old default. And so on, languages all handle defaults differently.
    • Named parameters: the article covers some of the biggest issues. There’s also the issue that API designers may not want their parameter names to be part of the API (consider the function is generated by a macro or build script, for example). Also, named parameters imply to new Rust devs that the parameters can be reordered, and it’s odd to have them without optional arguments as well. Then there’s the issue of code inspection (via macro or tool) if you can reorder parameters since you can only inspect source tokens, not query semantic information, so if parameters are reordered then it can become difficult to know which value goes to which parameter from the macro/tool.
    • Varargs: to be honest, I don’t really have a drawback for this in mind beyond them just being a fair bit complicated to implement. The C# params Foo[] args equivalent wouldn’t be very useful, but varargs with variadic types would be powerful, just I assume very difficult to implement (for example fn foo<...Ts>(blahs: Ts...) or something, where Ts is a variadic tuple). In any case, that’s a feature many libraries would take advantage of (axum, bevy, etc).




  • When an Aura enters without being cast, if the effect that puts it onto the battlefield doesn’t specify what it will enchant, you can attach it to any object or player that fits the requirements of its enchant ability. There are a few exceptions. You couldn’t attach Pacifism to a creature with protection from white, for example. Attaching an Aura this way doesn’t target the object you’re attaching it to.

    This is a trick I used in Brawl once to gain control of an opponent’s Niv-Mizzet, Guildpact with some Mind Control enchantment (I forgot which). It rarely comes up, but it’s one of those tools you can use to give you an edge in niche scenarios.


  • But how should any process know the variable of my script?

    Processes can touch any directory they have access to. There can be any number of reasons that a process might do this, from antivirus software (which somehow exists on Linux) to search software leaving index files everywhere to something that just for some reason modifies random directories. My point was that Bash can’t guarantee that none of this ever happens, though rm -rf "$TEMPDIR" would get around that and delete the directory anyway (and any lingering contents).

    Since you only seem to be worried about accidentally deleting the wrong directory due to mistakes while presumably debugging, this isn’t really as relevant as I was suspecting it was. For something more robust though, I’d normally recommend a recursive delete without following any links (in case something links to files you don’t want to delete, like ~ or something).


  • So I don’t see how a subprocess should be able to do that.

    I’m referring to any process being able to do that, subprocess or not. If you know that no process on the system can interfere with your directory in any way, then you can be confident that nothing else will touch it.

    Because what if I make mistakes in my own script and reassign $TEMPDIR by accident in a loop, instead reading from it. So at the time of execution of rm -rf, there is a chance that $TEMPDIR could potentially point to a different directory in example.

    Create another variable for use in the script, and only use $TEMPDIR for creating and deleting the directory then. As long as you are certain you don’t reassign it, then you know the value won’t change, and you can use a second variable to ensure you don’t do that by accident.


  • With Bash, you’ll only ever get “good enough” solutions. Even with your current setup, it’s susceptible to a race condition where another process adds to the TEMPDIR directory some other way during the script, and potentially even recreates tests after you delete it and before you remove the parent directory.

    Usually with Bash, the most readable solution is the best. I’d recommend a simple test for $TEMPDIR existing before a simple rm -rf "$TEMPDIR".

    However, I am very, very afraid of doing rm -rf in context of variables, in case the variable happens to become empty due to user error (or later changes in script).

    In this case, just test for this? Test that the variable is not empty and that the directory exists, then rm -rf the directory. No need to overcomplicate it.



  • Tailwind class soup is something I see often in LLM-generated code. For some reason, every starter template in existence decided to include Tailwind, and then the coworker generating this code (who doesn’t have frontend experience at all) just rolls with whatever the LLM shits out.

    I believe there’s a proper way to use Tailwind, but I can’t be bothered to read the docs for it. It makes far more sense to me to either use plain CSS or, if I’m using a component library, then whatever that library comes with for its theming system.

    Also, this whole article basically boils down to “use a proper theming system”, which it even admits can be as simple as some CSS classes with standardized names.




  • Sol is pretty fast from my experience, but still does the same thing that everything before it did: generate plausible code that I need to correct (and often rewrite) afterwards.

    I haven’t used Astra yet, but I don’t really expect it to change that. Once it becomes available at work, I’ll give it a shot of course, but my expectations aren’t very high.

    Edit: turns out I have Astra at work. It meets my expectations. I’ve had to rewrite a bunch of test code it generated and point it to the docs for a library to show it that some methods were deprecated and soon to be removed.



  • If you have a repo cloned locally and hosted on the remote, then you have the repo saved to two different places (although possibly without all the refs locally but you likely have your main/dev/etc branch at least).

    What I’ve been wanting to do once I get my NAS working again is host the repos on that instead. You can make a mirror of a repository very easily, so if you want to mirror a GitHub repo onto another service or a NAS or something (or the other way around, NAS -> GH for example), it’s really only a couple commands to fully back it up, and you could just put that in a cron job or hook.