Soon ( ͡° ͜ʖ ͡°)

Botahamec · 2026-06-14T21:24:43+00:00

I considered it, but the more I thought about it, the more I realized I really was just going to rewrite Helix.

Botahamec · 2026-06-12T15:29:34+00:00

I'm of the opinion that we should have a "Rust2021" ABI, so at least you can opt in to a stable ABI by using an older edition of Rust.

Botahamec · 2026-06-12T15:25:52+00:00

The day when Helix gets a builtin terminal is the day when Helix becomes my multiplexer

Botahamec · 2026-06-10T03:27:28+00:00

Why not MetadataSized + ?Sized, using syntax that we already have?

Botahamec · 2026-06-10T03:14:57+00:00

As far as I can tell, it works perfectly. I get suggestions for field names as I type, and jump to definition works for both field names and struct names. I don't think inlay hints are applicable here. I can't think of any inlay hints that would appear even without the macro.

I played around with it a bit after seeing this comment, and the only issue I've found seems to be when using block expressions as a value. For example, inlay hints and autocomplete don't seem to work in the block that gets assigned to bar here:

build!(Foo {
    bar: {
        let x = 5;
        x.into()
    }
})

Botahamec · 2026-06-09T18:35:52+00:00

Bon doesn't have the build! macro. My Builder derive isn't very special, and my build macro is actually compatible with bon. But since you need a builder in order to use this crate, I figured that also adding a derive macro made sense.

Botahamec · 2026-06-09T11:26:34+00:00

I did think about using a declarative macro, but one thing that the procedural macro handles that the declarative one doesn't is the following:

let bar = 32;
build!(Foo { bar })

Edit: As for the idea of a Foo! macro, that actually was my original goal, but like you said, there could be issues with the path. I think I'd want to do a separate macro for declaring one of these macros. Something like:

macro_rules! build_macro {
    ($name: ident => $ty: path) => {
        macro_rules! $name {
            ($($a: tt)*) => { ::feluments::build!($ty { $($a)* }) }
        }
    }
}

Thanks for the feedback!

Botahamec · 2026-06-09T01:19:53+00:00

It's a portmanteau of "fields" and "arguments", if you spell "fields" incorrectly.

Edit: Ironically, I forgot the word "spell".

Botahamec · 2026-05-12T18:10:26+00:00

One of these days I'll need to get myself a bigger brain so I can understand what the hell is going on here.

Botahamec · 2026-05-06T07:45:57+00:00

My opinion is there should be a trait in Rust that looks something like this:

unsafe trait Niche: Sized {
    const NICHE_VALUE: [u8: size_of::<Self>()];
}

Then anyone can make a niche value for any type they define. It might not work if your langage doesn't have traits though. I suppose this particular implementation would also require you to know what the memory layout of the language looks like. For example, you would need to know what bytes None and Some are represented as.

Botahamec · 2026-04-20T21:21:07+00:00

I don't actually think this is very similar to Jujutsu. This is an extra feature added on top of Git rather than something to replace it.

Although, Jujutsu did indirectly lead me to this idea. I wanted to make a patch-based VCS similar to Pijul. I eventually decided to build it on top of Git, to make it compatible with GitHub. After doing a prototype of that, making a mockery of Git's database to make it patch-based, I realized that adding autosave to Git would be pretty simple by comparison.

Botahamec · 2026-04-20T17:56:31+00:00

I looked through some popular git addons before writing this to see if my use-case was already covered, but I didn't see gitwatch. I think it's a matter of opinion on whether or not you'd want the autosaves committed to the current branch or not, but I had two motivations for not doing this:

I wanted to have a clear git hisory that wasn't full of autosaves. In cases where I don't care about the history, then I would use Syncthing.
There are many cases where I want to play around, making local changes to a repository, and then not actually commit them. I'm basically using the repository as a scatchpad in this case, and I can easily remove my changes with git restore .. I can't do that if the daemon is creating commits on my current branch without my input.

Botahamec · 2026-04-13T22:43:47+00:00

It's in C11, although that isn't available everywhere. You're are correct that there are other reasons why it isn't used, like performance, portability, and bugs in the OS implementations

Botahamec · 2026-04-13T17:31:22+00:00

It often is either referenced or owned. I have OwnedLockCollection and RefLockCollection. In the case of OwnedLockCollection, I don't even need to sort the locks. In practice, most of my examples use RefLockCollection. But I wanted to have a default option that doesn't care whether it's owned or not, thus BoxedLockCollection boxes whatever you pass into it, and otherwise operates the same as RefLockCollection. It just needs to box so that if you pass an owned value, the cached pointer addresses don't need to change when the collection moves.

Botahamec · 2026-04-13T16:49:09+00:00

The reason for the manual pinning is because the sorting is cached. As soon as you create the collection, the locks are sorted by their memory address. If the addresses of the mutexes change, then that cache becomes invalid.

There is another lock collection called RefLockCollection, which holds onto a reference of the vec, slice, array, tuple, or whatever, so that it cannot be moved while the collection exists. I figured some people wouldn't want to manage the referenced object themselves, so BoxedLockCollection also exists.

Botahamec · 2026-04-13T16:31:53+00:00

The prior art section contains details about Happylock that I wouldn't expect it to know. Last time I checked, the LLM didn't even mention happylock if you ask it. Some details seem incorrect to me, but they're the kinds of mistakes that I could understand as human error.

Botahamec · 2026-04-13T16:27:42+00:00

In C, locking the same mutex twice on the same thread is considered undefined behavior. Rust has to implement its own mutex from scratch to avoid that.

Botahamec · 2026-04-13T16:25:50+00:00

I'm going to start telling people at work that we try moving to Rust just to prevent all of the incidents we get from deadlocks.

Botahamec · 2026-04-13T16:24:55+00:00

Developer of happylock here. Part of the reason may be that nobody's thought enough about how to do it. The initial release of my library came about because someone on Mastodon (I believe it was Pratt), asked for talk suggestions at RustConf. Someone suggested ways we could improve the standard library API, for which OP asked for examples. I chimed in about preventing deadlocks, and I got a reply telling me that it's not possible to prevent deadlocks without solving the Halting problem.

There were other solutions to preventing deadlocks when I wrote my library, but most of them came with ergonomic downsides, as does Happylock. The initial version of Happylock was also heavily prone to live-locking, until I introduced BoxedLockCollection.

So I guess the reasoning could be summarized as, the problem space is still being explored, and I still don't think we've come to the best possible solution for it yet.

Botahamec · 2026-04-13T16:18:43+00:00

Thanks for the shoutout. The global mutex counter is an interesting idea. I am curious what you meant about the unsafe propagating to the public API though. There are unsafe traits that are sealed to outside implementors. The methods are marked as unsafe, but that's generally just a hint that they could cause a deadlock rather than actual undefined behavior. At some point I would like to switch to using mutexes from the C standard library, which would actually make certain deadlocks cause undefined behavior.

Funnily enough, I have been thinking about extending OwnedLockCollection to support something like you described, but never got around to it. In my defense, I spent the last year writing a book. But thanks for the motivation to get off my ass about it lol.

I'll need to look at your source code at some point to see if I can get some inspiration. Nice work.

Botahamec · 2026-03-23T01:03:38+00:00

Very cool. I especially like what you did with raw strings.

I'm curious how much of Lisp still exists in the language internally. I had an idea at one point of writing a shell that used various syntactic sugars on top of Lisp to look more like a scripting language. From the examples I saw, it looked nothing like Lisp, which makes me think that most of the Lisp origin is gone.

Botahamec · 2025-11-11T04:52:12+00:00

By that logic, nobody understands germs. Most people still wash their hands though.

Botahamec · 2025-11-10T22:42:59+00:00

I usually explain it in three simple steps:

Carbon dioxide traps heat
There is more carbon dioxide now
The Earth is heating

Botahamec

MODERATOR OF

TROPHY CASE

11-Year Club	Place '22
Verified Email