• 0 Posts
  • 320 Comments
Joined 2 years ago
cake
Cake day: July 30th, 2023

help-circle



  • I have 4 characters (past and present) that all occupy the same “party role” for this reason. They each have their own back stories sure, but their decision-making process is essentially the same because it’s how I would solve that given problem. The same set of equations, just with different source data.

    I hadn’t thought about over-exaggeeating a trait before to differentiate them, I may have to use that trick going forward.



  • Building electronics can be a long process. The FW16 itself experienced many months of delays before it was finally released to preorder. Also, the 13" board that runs the same generation as the FW16 came out before the FW16.

    As a FW16 owner, I’d love some news myself, but they did just add two whole new SKUs which is going to take up some component of R&D time. They may be working at a tick/tock cadence for updating small devices then coming back to the large device.





  • From memory I can only answer one of those: The way I understand it (and I could be wrong), your programs theoretically should only need modifications if they have a concurrency related bug. The global interlock is designed to take a sledgehammer at “fixing” a concurrency data race. If you have a bug that the GIL fixed, you’ll need to solve that data race using a different control structure once free threading is enabled.

    I know it’s kind of a vague answer, but every program that supports true concurrency will do it slightly differently. Your average script with just a few libraries may not benefit, unless a library itself uses threads. Some libraries that use native compiled components may already be able to utilize the full power of you computer even on standard Python builds because threads spawned directly in the native code are less beholden to the GIL (depending on how often they’d need to communicate with native python code)