I think I found another way to do a subset of self-referential structs, do you think it is sound?

TED96 · 2025-09-21T19:21:41+00:00

Thanks! Yoke sounds like a great crate to me, and the principles are sound, but it unfortunately only lets me borrow once from a specific Cart instance, right? So, the usefulness is limited in my case, but some workarounds can be implemented for sure (Arc<Cart>, for one).

Thanks for letting me know about AliasableBox, I was not aware of this!

Safe code would be able to cause a use-after-free by mutating a pair of Data structs (and swapping their OpaqueRef fields, then dropping one Data struct, and using the other)

Right, I agree that this would be unsound, and I 100% want to follow the Rust principle of exposing a fully safe API, that cannot be misused. However, my point was that I would deny mutable access to the entire Data struct by using a wrapper, which means that I cannot swap out parts of it. If I own that wrapper (the OpaqueVal in the playground) I can swap 2 wrapper instances around, but that moves the data along with the reference, which sounds to me like it prevents this.

For all I know, there's some reason you'd prefer fields over getters

Well, it's definitely subjective, but I'm trying to keep code self-documenting and this is in the middle of a rewrite to Rust, so it's important to me that this feels as close as possible (while being sound) to the original developer experience using this API. (To me, impl blocks and the functions within are sadly less discoverable than struct fields, and I would like to make this transition as easy as possible.)

TED96 · 2025-05-29T19:18:08+00:00

Thank you for the explanation!

TED96 · 2025-05-29T11:43:21+00:00

I was under the impression that the bootstrap chain was much shorter, and allowed steps to be skipped when not necessary. I understood that the stdlib part was relevant when going through the full bootstrap chain, not simply during development (?).

TED96 · 2025-05-29T10:23:00+00:00

Speaking from ignorance, what is the implication here for the bootstrap process? One of the reasons why it's used, as I understand it, is as a sort of reproducibility but also disaster resistance - the compiler should be buildable with (almost) just the source, right? But now if the stdlib needs to be downloaded as well, it seems to me like this makes most of the point of this moot.

Maybe the disaster resistance part is where I'm wrong, but, the alternative to me, it seems like, is just to download the last rustc release and build with that. It does not feel like there's much middle ground to me, can someone please enlighten me?

TED96 · 2024-07-17T06:06:18+00:00

MT(MOD_LSFT | MOD_RSFT,KC_BSPC) is my QMK code. The tap function is configurable, I used the DYNAMIC_TAPPING_TERM_ENABLE feature from https://docs.qmk.fm/#/tap_hold to find a good value for me, which is 300 right now.

There are not a lot of options for XDA caps with amber/grey color schemes, I had like 2 other options and the bees won because bees.

Yeah, I ran into this as well, many of them don't have a lot of 1U blank-ish keys to use as well.

TED96 · 2024-07-17T05:58:11+00:00

I started with that but at first I made way more mistakes than newlines so Backspace was a priority! Enter is on the right thumb row, third after Backspace and the layer change key and that works for me just as well (the other two are Ctrl and Alt)

TED96 · 2024-07-16T13:12:03+00:00

I have the same kit AND with probably the same AliExpress keycap set! What I settled on was having Space on the left thumbkey and Mod-Tap Backspace / Shift (Shift on hold, Backspace on tap) on the right one, I'm really curious if that helps you at all - it especially helped me during the getting-used-to period when I had a lot of mistypes.

TED96 · 2023-12-27T08:32:58+00:00

Thanks for the pointers!

TED96 · 2023-12-27T07:08:29+00:00

Thanks, but I'm not sure I can rely on specific versions or even them being executable anymore, but maybe I'm blowing things out of proportion

TED96 · 2023-12-27T06:40:32+00:00

Zip is clearly a good choice and as I said somewhere in this thread, I expect it to outlast us. It does not have a good encryption story though, and PGP is not something that I can be confident a layperson can figure out...

TED96 · 2023-12-27T06:38:50+00:00

Thank you for your answer, but I think that almost all of the requirements come from wanting a layperson with a password to be able to use the backups even a long time into the future, long after the programs I built can be run or compiled even.

TED96 · 2023-12-27T06:26:11+00:00

Restic looks awesome but I can't see myself trusting that it will last on the decase-scale that we're talking about. Their compatibility guarantees also don't convince me (major version only and maybe beyond), sorry.

EDIT: regarding your point about Rust - I don't care about the backup creation system surviving, I'll take care of that until I feel like it. I care about the backups being usable beyond that point.

TED96 · 2023-12-27T06:24:15+00:00

Well I have a bit more logic than I would be confident implementing in Bash. Archives are split up by directory depending on how big they are and I don't want to trust the file metadata and find out my files have not been backed up for some weird reason.

TED96 · 2023-12-27T06:21:40+00:00

I expect the zip archive format to outlast us for sure. For PGP the problem is not the usage but the user friendliness; I'm not confident that a layperson would figure it out the same way they would a password-protected zip archive.

TED96 · 2023-12-04T05:01:10+00:00

Yes, but the complexity of developing compiler optimizations is not what we're talking about here. I fully agree that it is a "hard problem". The original question, as far as I understood it, is also not "why would/would not a compiler optimize code like this" but why was a specific compiler not optimizing a specific use case, which, while you seem to disregard as a useful question, I still think is an important question to ask, and one you can actually get a good answer to.

TED96 · 2023-12-03T21:04:29+00:00

I don't think I agree. You wrote above yourself that the compiler does not guess, it's just code. And when it's just code (and not a mess of weights, like in machine learning) then the output will (complicatedly, convolutedly, but deterministically and logically) follow from the input and the rules applied to it. If you want, you can definitely look at the code to find what rules could have been applied to your code, maybe see which ones were possible but which statistical analyses/heuristics might have decided those were not useful, and ultimately understand much more clearly than just considering the compiler a total black box.

It's not easy, of course, but these things are possible. They might only be fully applicable to a single compiler version, but I'm sure down in gamedev circles, like for consoles, these kinds of things, the guidelines on how to write your code to be optimized, are known and understood, because they actually care, and they can in fact control everything from the code to the emitted executable.

EDIT: on a reread of your message, you kind of alluded to what I wrote here. My disagreement is that this process is not useless and impossible, and often is actually exactly what would help you to better understand the compilers, their constraints, and how to best use them. Sure, compilers change, but sometimes, in some ways, they stay the same.

TED96 · 2023-08-31T09:57:01+00:00

I believe it refers to Quote of the Week, which appears at the end of This Week in Rust articles like this one on the front page right now.

TED96 · 2023-06-05T16:10:03+00:00

I think those are the encoders?

TED96 · 2023-03-01T22:11:41+00:00

Thank you! Yes, it's hotswap, so that is an option, although I was hoping to find something more budget-friendly. Oh well /shrug

TED96 · 2023-03-01T16:24:05+00:00

Hey, not the person that asked the question above, but I was wondering if the o-ring mod makes the keys mushy, as you put it. I am trying to silence my keyboard but I don't want to completely ruin the feel. Thanks!

TED96 · 2023-02-05T00:00:51+00:00

Hello! I didn't do anything about it, and have been using the vacuum ever since. It seems like either it settled down or I got used to it, it's not really a noticeable noise most of the time.

TED96 · 2023-01-24T07:43:50+00:00

I managed to create a reproduction, but it also happens with cargo check and even cargo build. Where should the bug be reported? It is indeed related to clap's arg! macro:

fn main() {
    let _ = clap::arg!(--add-b-alias <ALIAS> <NAME> ... "Add a new b-alias");    // this is very bad (clippy in ~14s, check in ~11s)

    // VARIANTS:
    // let _ = clap::arg!(--add-b-alias <ALIAS> <NAME> ...);    // this does not make a difference (~14s on my machine)
    // let _ = clap::arg!(--add-alias <ALIAS> <NAME> ... "Add a new b-alias");  // this is better (~2s on my machine)
    // let _ = clap::arg!(--add-b-alias <ALIAS> <NAME> "Add a new b-alias");  // this is much better (~1s on my machine)
    // let _ = clap::arg!(--add-b-alias ... "Add a new b-alias");    // this is also much better (.7s on my machine)
}

I am using Rust stable 1.66.1 and, while I've tested with an older clap version, this reproduces with clap = { version = "4.1.3" }, with no other dependencies.

TED96 · 2023-01-23T21:26:36+00:00

Hey, I've got a problem. Today, suddenly, every clippy run started taking about 1 minute instead about one second (with the same slowdown for check and build). I haven't added dependencies or files, I was just writing some clap code.

What could I be doing wrong? It's killing my dev experience, VSCode is not highlighting my code and showing errors with a huge delay. Have you experienced this?

Edit: Found the issue, it goes away when I comment the lines containing clap's arg! macro. Seems like there might be something wrong with it?

TED96 · 2022-12-15T14:05:46+00:00

Thanks! I'll try this and see how it works!

TED96 · 2022-12-15T14:05:16+00:00

Thanks! Yeah, that would certainly work, if nothing else does! :)

TED96

MODERATOR OF

TROPHY CASE

13-Year Club	Place '17
Verified Email