• 0 Posts
  • 32 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle
  • For a while I just couldn’t play souls-likes. The enemy attacks were blatantly undodgeable. Like, even if you move at the maximum possible speed, in any direction, at the very start of an animation, you can’t get out of the way. Then I realized you’re not really supposed to get out of the way, you’re supposed to abuse the immunity frames from the roll to “dodge” straight through the attacks. Basically the opposite of what I had been doing.









  • When you hit the windows key (aka meta-key or super-key) it brings up the app launcher. You get a dock at the bottom with pinned or running apps (like a taskbar), and all of your open windows are presented in a sort of mini-version that lets you switch between them or move them between workspaces. There is a search bar that you can immediately type into to open any app with a .desktop file. There is also a button to bring up the app grid which shows your apps kind of like a mobile device’s home screen.






  • I find that much harder to read than a for loop. You are making a helper function to only use it once, which is kind of confusing when it is totally unnecessary. Also, distinguishing between two groups only inside the setter line is weird. Applying the modification to one group, then the other, is more obvious. Considering the alternative isn’t really longer, and only using basic loop syntax, I would just use the loop. If you really want to add the “set dots visibility” explanation into it, just use a comment, that’s what they’re for.

    I literally just now misunderstood your code and had to change my comment to correct for it.


  • Use:

    items=[...]
    for o in items:
        ...
    

    This is the most direct way of doing what you want. The first option might allocate a new array each iteration, which is unnecessary. The match statement is both a pain in the ass to write and less direct, which at best compiles to the same thing and at worst has you doing a bunch of totally unneeded comparisons.

    If this ‘i’ variable you used isn’t just an incrementing counter, use the last option. If it is though, it’s an extra counter you don’t actually need.

    The performance difference here would be so small I doubt you could even observe it. So, you really shouldn’t worry about this particular pattern. Compiler optimizations are more likely to trigger on simple, direct code, so writing it as directly as possible is probably the fastest option anyway.






  • Well you’re right that it’s not practical now. By “soon” I was thinking of like 10+ years from now. And as I said, it would likely start in systems that aren’t used for those applications anyway (aside from web browsers, which use way more ram than necessary anyway). By the time it takes over the applications you listed, we’ll have caches as big as our current ram anyway. And I’m using a loose definition of cache, I really just mean on-package memory of some kind. And we probably will see that GPU style memory before it’s fully integrated.