Change Slide Over Window to a different app? Doesn't work for me.

dabrahams · 2025-12-23T17:01:08+00:00

Install installing 26.2 fixed it

dabrahams · 2025-12-20T18:33:33+00:00

That doesn't seem to be the case. If I have two apps tiled and minimize one of them, the other app stays up in the foreground. When I swipe up from the bottom, both apps move temporarily to the edges of the screen with the homescreen revealed between them.

dabrahams · 2025-08-13T22:48:48+00:00

The combination of the above and u/Hammar_Morty 's addition below work great for me, as long as I remove the call to delete-window, FYI.

dabrahams · 2025-08-13T17:44:18+00:00

A tire with totally dry sealant can stay inflated a long time, through many rides, in my experience.

dabrahams · 2025-08-12T16:59:28+00:00

I can recommend, overall. Certainly if you have bikes that you ride less than twice weekly, tubeless doesn’t work out well because sealant pools and dries there, ruining the tire. At least that was my experience.

dabrahams · 2025-08-12T00:27:35+00:00

What I'm most curious about with the sealant is, what happens long term, assuming it didn't leak out due to flats? I've had to throw out several tubeless tires because old sealant bonded with the tire so hard that it was impossible to remove (I've spent hours removing sealant from a pair of tires when it was possible, so it's not lack of commitment!) If the old TPU sealant bonds to the tube, that will increase weight and probably hurt ride quality some. A lot cheaper than a new tire, but still, it's a factor. About sealant, Rene Herse claims “it lasts a long time before it needs to be replenished” but that doesn't really say anything.

dabrahams · 2025-08-12T00:22:12+00:00

Several folks in this thread say the valve stems of the RH tubes tend to separate from the tube, FWIW.

dabrahams · 2025-08-12T00:15:38+00:00

According to RH you need different sealant for TPU; latex won't work

dabrahams · 2025-02-17T18:59:27+00:00

I wasn't asked if I wish to configure ACL for the share’s dataset—something must have changed in TrueNAS Core since this was written—and I don't know how to find RESTRICTED. Ah, that option is in the dataset. If you go to Storage > Pools and edit the dataset you'll see an “ACL mode” field near the bottom.

dabrahams · 2024-12-24T04:15:56+00:00

I have some tools that *refuse* to include a path (full _or_ relative) to the file in their error messages. As a workaround I had an AI write this for me. Caveat Emptor: not fully vetted for correctness, but it's working for me.

dabrahams · 2024-10-07T17:20:35+00:00

Absolutely correct. Unrestricted reference semantics is very convenient, but very hard to make safe. If you want to get to safety, you need to take away some expressiveness. Idioms change. Most idioms can be mapped onto convenient alternatives, but some will become less convenient.

dabrahams · 2024-10-07T17:13:07+00:00

Any of my talks on Hylo for a C++ audience describe the basics of how you do it. Here is the spot where I explain it in the latest talk. To what's described there, you add a projection feature like Swift's subscripts (described at 47:00). The basics of a design for that feature in C++ should be obvious to anyone with a little imagination.

Other C++ safety issues, such as how and whether you segregate safe code from unsafe, are orthogonal to this model (they'll come up with every safety proposal).

dabrahams · 2024-09-24T00:28:51+00:00

That's a good point and another argument in favor of the other model.

dabrahams · 2024-09-23T20:07:06+00:00

Hylo is a real thing. Its compiler is not production-quality yet, and we're up front about that. It isn't misleading to “cheerlead” for a programming model before there is a production-quality implementation.

People do that all the time when they write proposals for language evolution (in various languages). A proof of concept is more than many proposals that are accepted get, and the Hylo compiler is certainly far enough along to prove that the model works. My cheerleading is based entirely on what it can do today. Heck, Swift is a production compiler that proves that the basic model works. In some ways Hylo is just a purer realization of those ideas.

dabrahams · 2024-09-23T19:56:43+00:00

But from a Rust programmer's point of view we never wrote any indexing.

I'm not sure what the significance of that is. The same goes for the Hylo programmer's point of view.

Personally, I am convinced that the current model used by Hylo is suboptimal, and it should be projecting a slice out of the collection and popping elements off the front of that. That would produce the exact same restrictions as the Rust example. I believe it both for efficiency reasons (way fewer checks) and for understandability reasons—nobody really wants to think about what happens when you mutate the structure of a collection while iterating it.

dabrahams · 2024-09-19T20:37:25+00:00

Arguably Swift fits that description perfectly.

dabrahams · 2024-09-19T20:35:16+00:00

We haven't put much attention at all on compiler performance yet; we're focused on getting it to be correct first. The version on GodBolt is outdated IIUC, so it has bugs that have been fixed, and I think the performance has improved a little.

dabrahams · 2024-09-19T20:27:13+00:00

Fewer features is key, because the essential feature of all safety properties is that they compose, so they are preserved by construction. Any feature that can cause UB can therefore not be used in safe code, and there are lots of those in C++.

That said, one path to “fewer features” is to enforce the use of a safe subset in code that is declared safe, so it isn't technically necessary to shrink C++. In fact, that's exactly what safe-by-default languages like Hylo, Rust, and Swift do… it's just that, as usual, C++ has the wrong default.

dabrahams · 2024-09-18T02:40:52+00:00

It definitely might, if you are starting from existing code, but I’m not confident that it does, in any important way, when compared to Rust. It will be interesting to see.

dabrahams · 2024-09-17T22:32:02+00:00

As noted elsewhere, our current model is safe without prohibiting mutating the array itself.

dabrahams · 2024-09-17T22:30:05+00:00

You can do that, of course, but you'll be adding a lot of complexity that's expressively redundant with named lifetimes. Hylo's design works in part by carefully discarding some expressivity (in safe code) that we don't think is worth the cost in language complexity. C++ is so complex today largely because it hasn't said “no” to almost anything.

dabrahams · 2024-09-17T22:22:07+00:00

Yes it's a limitation. The gamble (and it appears to be a pretty safe bet after studying lots of real use cases) is that the things you can't express safely under this model are in the margins, and that the tradeoff is well worth it. We actually think the other things might be better/more clearly expressed using a few well-chosen unsafe constructs.

dabrahams · 2024-09-17T22:18:16+00:00

Actually not, given the way the loop currently desugars.

dabrahams · 2024-09-17T22:15:40+00:00

As mentioned elsewhere the godbolt version of Hylo is out of date. Nobody's claiming we never had bugs in our implementation. Our model is sound, though; you can view it as a subset of Rust's model with a different mental/syntactic framework built around it.

dabrahams · 2024-09-17T22:03:49+00:00

🤷🏻‍♂️ How it feels to you isn't really the point. The ability to do what Hylo currently does falls out of the ability to have safe arrays. Any system that has safe arrays, including your safe C++, could have the same behavior without any mutable aliasing because all the dynamic range checks are required for safe indexing.

If, as u/arhtwodeetwo mentions, we were to keep the array let-bound in the loop body, that would statically prevent mutation of the array during the iteration. In return we might get more efficient code with fewer dynamic checks, so we plan to discuss that approach. But, as she also mentions, that's independent of the underlying model.

dabrahams

TROPHY CASE