If it were a magic lang item, you could treat the resulting value in a special way. Then, you could create an optimization pass for this situation: if a variable is assigned random in a loop and the loop can only be exited with a certain value, the compiler can coerce the magic rand value to it.

You could do a lot worse. If the type of i was an object, you could overload the negation operation to have side-effects for the third snippet, for example.

I don’t know what I was thinking.

But, if you borrow C’s semantics, you are allowed to “optimize” away side-effect-less loops, even if they would never terminate. But that would require the random method to be pure.

I feel like an idiot. Also, in the “Good” example, no underflow occurs. i goes from 0 to -10, and x is assigned to -i every loop.

It might still be possible to optimize away the random number example, if the random function were made a magic language item, but it would not be even remotely close to being worth the effort.

The compiler should be able to optimize all of them to the same machine code.

1. This is already good.
2. Easily optimized by constant folding.
3. This one depends on the semantics of signed underflow, so it may not do what you want.
4. The loop can only exit if x==10, so as long as the nextInt() method doesn’t have side effects, the loop should be eliminated. But, again, language semantics can affect this.

Edit: Very wrong for 3 & 4, see replies.

1. do not use ANY company resources. This could put you at risk of theft.
2. do not do it on company time or make it look like it’s on company time. See point 2.

Did you mean “See point 1.”?

I mostly agree with you, but this is not quite true:

XDG implementation (which is also only used as a fallback when the three DE-specific implementations fail, even though all of them actually support XDG so having separate implementations is pointless)

Yes, the DE-specific implementations is pointless (as far as I know, I use a WM), but the XDG implementation is actually used first, and the function returns true if any impl returns true, like xdg() || gnome() || gnome_old() || kde().

rework the code so that there is a difference between “this DE wants light mode” and “couldn’t figure out of this DE is in light or dark mode” - both of these are now represented by the “false” return value.

This isn’t that bad? Yes, having an enum with three variants would be better and more readable, but the code just defaults to light mode if nothing wants dark mode, and prefers dark mode even if separate impls want both light and dark mode.

With multiple impls, you have to resolve conflicts somehow. You could, for example, match on current DE/WM name, only using the current DE’s impl, defaulting to XDG, avoiding the problem entirely or just use first impl that doesn’t return “default” or “error”.

I don’t like AI generated code, having reviewed some disgusting slop before. But it’s better to criticize the code’s actual faults, like the incorrect impls (which you listed) or failing the Linux CI.

That’s quite fast, do they cause many accidents?

You can blame the EU for that:

pedal cycles with pedal assistance which are equipped with an auxiliary electric motor having a maximum continuous rated power of less than or equal to 250 W, where the output of the motor is cut off when the cyclist stops pedalling and is otherwise progressively reduced and finally cut off before the vehicle speed reaches 25 km/h;

Bikes that do not comply with that are classified differently, and at least here, have to be registered as motorcycles/mopeds. Which won’t go through, as, for example, the brakes are typically not motorcycle-grade.

source

Where I live, they’re only allowed to assist to up to 25km/h (about 15.5mi/h), so I can ride a lot faster with a normal bike.

What kinds of limits are there for (e)bikes where you are?

Here, for electric bikes, they have an age limit of 15 years and a BAC limit of 0.5‰.

I’ll see your ebike and raise you a non-electric bike.

It’s JS, so about 5, I think.

Edit: Looks like TypeScript, but the same applies.

And Beta.

Lemmy is written in Rust.

And multiple times, up to once per instance. Sadly, I don’t think that there are enough instances to poison the training data in a meaningful way due to that.

After a quick look, looks like it tries to split the (unencrypted) hostname into multiple packets, or at least scramble it slightly. I’m not sure how much it helps in practice, but it might help against naïve filtering/scanning, as the hostname is either sent in different packets, or split and sent unordered in the same packet. It probably only helps if encrypted client hello isn’t supported.

TL;DR: If I’ve understood everything correctly, it just moves chunks of the plaintext hostname around & tries to split it into multiple packets.

Note: Mostly based on comments, as it’s late & I’m too tired to parse too much cryptography code.

Full source of the limit_chunks function, formatted with Rustfmt:

const fn limit_chunks<'a>(
    left: (u64, &'a [u8]),
    right: (u64, &'a [u8]),
    limit: usize,
) -> ((u64, &'a [u8]), (u64, &'a [u8])) {
    let (left_offset, mut left) = left;
    let (mut right_offset, mut right) = right;
    if left.len() + right.len() <= limit {
        // Nothing to do. Both chunks will fit into one packet, meaning the SNI isn't spread
        // over multiple packets. But at least it's in two unordered CRYPTO frames.
    } else if left.len() <= limit {
        // `left` is short enough to fit into this packet. So send from the *end*
        // of `right`, so that the second half of the SNI is in another packet.
        let right_len = right.len() + left.len() - limit;
        right_offset += right_len as u64;
        (_, right) = right.split_at(right_len);
    } else if right.len() <= limit {
        // `right` is short enough to fit into this packet. So only send a part of `left`.
        // The SNI begins at the end of `left`, so send the beginnig of it in this packet.
        (left, _) = left.split_at(limit - right.len());
    } else {
        // Both chunks are too long to fit into one packet. Just send a part of each.
        (left, _) = left.split_at(limit / 2);
        (right, _) = right.split_at(limit / 2);
    }
    ((left_offset, left), (right_offset, right))
}

Same, but for write_chunk:

fn write_chunk<B: Buffer>(
    offset: u64,
    data: &[u8],
    builder: &mut packet::Builder<B>,
) -> Option<(u64, usize)> {
    let mut header_len = 1 + Encoder::varint_len(offset) + 1;

    // Don't bother if there isn't room for the header and some data.
    if builder.remaining() < header_len + 1 {
        return None;
    }
    // Calculate length of data based on the minimum of:
    // - available data
    // - remaining space, less the header, which counts only one byte for the length at
    //   first to avoid underestimating length
    let length = min(data.len(), builder.remaining() - header_len);
    header_len += Encoder::varint_len(u64::try_from(length).expect("usize fits in u64")) - 1;
    let length = min(data.len(), builder.remaining() - header_len);

    builder.encode_varint(FrameType::Crypto);
    builder.encode_varint(offset);
    builder.encode_vvec(&data[..length]);
    Some((offset, length))
}

Link to the MIT license file

Is silicone rigid enough? Adult toys have slightly different requirements from many other 3D printed things.

How do you usually do that?

Do you create a negative of the model digitally or take a mold of the printed parts?

What kinds of human-friendly materials do you use? And do you need any special equipment for it?

With the new Swap™ technology, you are no longer* limited** by your RAM. Our*** brand-new**** Swap™ technology turns your unused disk space into usable***** memory at almost****** no******* perceivable performance impact. When combined with our ZSwap™ compression technology, you can now achieve an up to 5000% or better******** unused-disk-to-memory conversion ratio********* than many RAM-downloading services.**********

I hope that the language’s ints are at most 32 bits. For 8 bits it could even be written by hand & the source code for a 32 bit version would only take up avg_line_len * 4GiB space for the source code of the function. But it might take a bit of time to compile a version that supports the full range of 64 or 128 bit ints.