yuriks

This feature seems really valuable for commandline tools! However this paragraph gave me pause:

> Currently, disabling lazy imports disabled the syntax keyword, which means that you can’t use it for circular imports, type checking, etc.

Imo this is a good thing, laziness shouldn't be semantically important. The ability to force disable laziness while maintaining semantics is important for linting and testing, and more often than not, circular imports are a sign of bad code structure.

Embassy can (these days, not sure if this is more recent than the article) do preemption, but it works by setting up multiple task pools and executors for each priority level: https://docs.embassy.dev/embassy-executor/git/cortex-m/struc... Non-realtime compute heavy tasks can be processed in the background executor and interrupted by latency sensitive ones.

> it's also the sort of condition that might sometimes has an instant miracle cure

I assume that by this you mean figuring out some kind of dietary restriction?

I also struggle with a lot of those things (also ADHD) plus other inflammation-related issues (ezcema), and noticed a very specific pattern of fatigue during the day that improves at night. It's hard to tell what might be effective or not since keeping stability in my routine is a struggle, but I've mostly came up empty on explanations/solutions so far.

My read of the "side projects and experiments" part of the blog post is that, in the context of LLM projects, if your project does not use resources and isn't looking to attract a community then, if only due to the practicalities of moderation/enforcement, they're unlikely to take any action against it because it won't be visible or causing enough problems.

I think more to the point, if 0 doesn't represent 0.0, and 255 doesn't represent 1.0, congratulations you've just lost your additive and multiplicative identities and most of the math used in colors falls apart.

The argument for 0-256 feels compelling when thinking about the physical display, but it seems like a very poor fit for any digital image processing or rendering.

Both types have the `From` conversion traits implemented between each other, so in most cases interoperating with APIs using the old type should be as simple as doing `(1...4).into()`. And, probably because of the warts of the old types, I haven't seen them used much in APIs, so even that I don't think will happen very often.

That's part of the error enum.

  enum AllocError {
    SizeTooLarge { size: usize },
    // etc.
  }

This enum has a known size and doesn't require any dynamic allocations.

I mean, yeah, that was the point of my original reply: health care, education and housing have been getting less accessible in general, not just that poster's country. (Or wherever they're from. I checked the comment history and it seems to be 90% talking back to people criticizing capitalism/markets. Wouldn't be my preferred hobby of choice, personally.)

I don't have concrete metrics/sources to give right now, but my general perception from reading the news is that there's been staffing issues pushing healthcare systems in the US towards increasing workloads in individual providers, leading to less time/attention given to individual patients, lower availability of appointment slots, and offloading of patients onto alternative app-based telehealth platforms, which have been trending up alongside aquisition/consolidation of independent private practices.

Health care, education and housing have been getting worse and more expensive in the US over the decade also. Must be all that nationalization.

In what ways do version pining/lockfiles not solve this problem?

I love corruption!

No, they're implying that you need a lot of coins to pay for parking.

If you need $6 to pay for parking, and the largest commonly available coin is a quarter, that means you need 24 coins to pay. If the value of currency was such that the parking only costed $3, or if dollar coins were more common, you'd need less coins to pay.

Games are not fungible.

> Is this actually useful in practice?

It's required to do any intialization, particularly for compound futures (e.g. a "join" or "select" type of combinator), since you need to be able to move the future from where it's created to where it's eventually used/polled. I assume some of those cases could be subsumed by &uninit if that existed yeah.

For 1, I think it's hard to make a distinction between swapping an object, vs. swapping/mutating all of its fields such that it becomes equivalent to a different object.

For 3, some objects only need to be pinned under certain circumstances, e.g. futures only need to be pinned after they're polled for the first time, but not before. So it's convenient to separate the pinnability property to allow them to be moved freely beforehand.

I don't quite understand the usecase you have in mind for 4.

People aren't complaining about that. What you do in the privacy of your own computer is only your problem. The issue is people pouring a whole "arduous" 2 hours into vibecoding a project, then advertising it and posting to communities everywhere as a revolutionary bullet-proof high-quality project asking for visibility and contributions.

This post mirrors my sentiment and the reasons I dislike these sorts of "projects" much more closely than the main site does, deserved to be the main submission, in retrospect.

The author of the patch does mention that the better thing to do in the long run is to replace the data structure with one that is possible to better encapsulate: https://lore.kernel.org/all/20251111-binder-fix-list-remove-...

I thought that the implication was that the shader compiler produces a second shader from the same source that went through a dead code elimination pass which maintains only the code necessary to calculate the position, ignoring other attributes.

I was lost when it suddenly jumped from a long retrospective on GPUs to abruptly talking about "my allocator API" on the next paragraph with no segue or justification.

A 'static lifetime does not live for the rest of the program. It rather is guaranteed to live for as long as anyone is able to observe it. Data allocated in an Rc for example, lives as long as there are references to it. The ref count will keep it alive, but it will in fact still be deallocated once all references are gone (and it cannot be observed anymore).

That is not a memory leak though! That's using/exposing an uninitialized buffer, which can happen even if you allocate and free your allocations correctly. Leaking the buffer would prevent the memory region from being allocated by another application, and would in fact prevent that from happening.

This is also something that Rust does protect against in safe code, by requiring initialization of all memory before use, or using MaybeUninit for buffers that aren't, where reading the buffer or asserting that it has been initialized is an unsafe operation.

...yes?

Needs a (2020) in the title. I don't think anything major is outdated, but in particular in section 10, one of the desired syntaxes is now supported as an unstable feature but there wasn't any mention of that:

    #![feature(closure_lifetime_binder)]
    fn main() {
        let identity = for<'a> |x: &'a i32| -> &'a i32 { x };
    }

And after digging through the comments... Yup it's private equity again. PE buyouts should be considered criminal fraud.

The world today is just crooks all the way down (or up, depending on how you look at it).

It relaxes the contract required for an existing type with derive(Clone) to implement Clone, which might allow types in existing code to be cloned where they couldn't before. This might matter if precluding those clones is important for the code, e.g. if there are safety invariants being maintained by Type<T> only being clonable if T is clone.

The rules for what locations/checks can be reached in what situations and with what items are painstakingly encoded in a machine readable format: https://github.com/OoTRandomizer/OoT-Randomizer/tree/Dev/dat...

I don't know the specifics of the OoTR algorithm but in general they work by considering a set of items which are currently "available", and then progressively picking a random item to place only in locations which are reachable with that current set of available items (which is expanded with each placement).

Ironically, testosterone in theory is harder to get. Since it is widely used for sports doping, it's considered an anabolic steroid, and is a scheduled substance in the US, and so has a bit more oversight to prescribe and dispense. (But I imagine there's probably also a larger black market for it for the same reasons.)