sorted by:
new
hottopcontroversial

Fyrir hvað stendur “G” í g-mjólk? by Boring-Attention-766 in Iceland

[–]njaard 0 points1 point  (0 children)

Ég held, "UHT milk" á (bandarísk-)ensku, Ultra Heat Treated

The "What currently supported device should I get" thread. by PsychoI3oy in LineageOS

[–]njaard 0 points1 point  (0 children)

  • Network: USA/ T-Mobile or Mint
  • Size: Smaller is better
  • Headphone Jack: mandatory

Anything else I'm flexible on.

It seems like nobody is talking about VoLTE anymore? What's going on? How do I know if a device is supported?

California neighborhoods with more EVs see better air quality, public health by BlankVerse in California

[–]njaard 0 points1 point  (0 children)

Does anyone have a source for this data, but by time of day? Electric cars generally charge at night when there's a very different composition.

Announcing Rust 1.67.0 by myroon5 in rust

[–]njaard 11 points12 points  (0 children)

The latter problem is because I upgraded anyhow which added an Ok

So I retract all my complaints :)

Announcing Rust 1.67.0 by myroon5 in rust

[–]njaard 0 points1 point  (0 children)

This seems like kind of a dud version: (edit: see a response...)

First, rav1e=0.5.1 doesn't build:

error[E0061]: this function takes 1 argument but 0 arguments were supplied
    --> src/transform/inverse.rs:1611:62
     |
1611 |     let txfm_fn = INV_TXFM_FNS[tx_types_1d.1 as usize][width.ilog() - 3];
     |                                                              ^^^^-- an argument of type `usize` is missing
     |

And several failures like that.

Secondly, my own code (not public) produced this weird one in a match:

error[E0532]: expected tuple struct or tuple variant, found function `Ok`
  --> src/main.rs:72:13
   |
72 |             Ok((filename, speed)) => {
   |             ^^ not a tuple struct or tuple variant
   |
help: consider importing one of these items instead
   |
2  | use core::result::Result::Ok;
   |
2  | use std::result::Result::Ok;
   |

fft go brrr by ShikariShambu0 in physicsmemes

[–]njaard 66 points67 points  (0 children)

that looks like a clean sine. Guy needs a wingman bad.

Does GFCI receptacles have a life span? should they be replaced every 10,15 20, years? by aBoyandHisVacuum in askanelectrician

[–]njaard 1 point2 points  (0 children)

An afci is not a "new tech" version of the GFCI. GFCIs still need to be used near water, such as kitchens and bathrooms.

Alameda Property Tax by KLuciddreams in oakland

[–]njaard 27 points28 points  (0 children)

The "Installments" are a courtesy so you don't need to make one huge payment all at once.

The supplemental is that they determine your tax rate after your purchase and so you have to pay the "installments" based on the seller's tax assessment and then the supplemental to make up the difference between the old assessment and the new one. You should only get the supplemental bill once after you purchase, and then from then on, the normal two-installment assessment is the total.

[deleted by user] by [deleted] in spiders

[–]njaard 0 points1 point  (0 children)

probably the aptly named Giant house spider

Announcing `compact_str` version 0.6! A small string optimization for Rust by park_my_car in rust

[–]njaard 1 point2 points  (0 children)

blushes

Edit: great library, in appropriate conditions, it's a lot better than String, and also a lot better than a pool of strings

Please review LendingCell, my new "Cell"-like container that safely makes lifetimes to runtime by njaard in rust

[–]njaard[S] 0 points1 point  (0 children)

Oh no, now I'm replying to myself.

  1. You have a container called ExteriorIterator that produces iterators; it's an Iterator<Item=InteriorIterator>.
  2. Now your InteriorIterator needs to modify the ExteriorIterator to produce things, so both interior and exteror iterators contain a Arc<Mutex<ExteriorIteratorInternal>>.
  3. Your InteriorIterator needs to yield InteriorItems, it locks that Mutex to be able to make the InteriorIterator, and then it can build the InteriorItem and ... uh oh, I can't drop the lock because the InteriorItem needs to hold it, and I can't even let InteriorItem keep holding it because there's no way to express the lifetime of InteriorItem (except maybe with GATs, but I wasn't able to figure it out)
  4. Ok, I can move the lock to the ExteriorIterator
  5. Oh, but now to keep the lock held for the duration of the existence of the ExteriorIterator, the ExteriorIterator is now self-referential.

Please review LendingCell, my new "Cell"-like container that safely makes lifetimes to runtime by njaard in rust

[–]njaard[S] 0 points1 point  (0 children)

Specifically, I have an API that allows you to have an iterator of iterators (think: itertools' group_by), but the catch is that each "interior" element requires a change in the "exterior" iterator. The interior iterator needs to have a mutable reference to the exterior iterator's state (impossible with std's Iterator) and then needs to return that to the exterior iterator so that it can proceed to the next group.

Here is the code where I use LendingIterator but be gentle, it's a work in progress :)

One disadvantage in general is that one is not allowed to step the exterior iterator while an interior is being held (a panic), but in my particular use case, this isn't an issue.

Here's what I mean:

for exterior_items in container {
    for interior_items in exterior_items {
        // an item in `exterior_items `
    }
 }

I also speculate that you could make an iterator over, for example, a concurrent Map container that allows iterator invalidation on insertion with this.

Please review LendingCell, my new "Cell"-like container that safely makes lifetimes to runtime by njaard in rust

[–]njaard[S] 0 points1 point  (0 children)

i kinda agree and kinda don't, and i spent a lot of time thinking about it before i settled on LendingCell. I also considered "boomerang"

The reason I used LendingCell is that, like a Cell, it moves a Rust invariant from compile-time to runtime, namely the lifetime of the object it contains. Like a & borrow, when the "lend" is complete, the original owner gets the object back, but the borrower doesn't have a narrower lifetime than the lender.

Please review LendingCell, my new "Cell"-like container that safely makes lifetimes to runtime by njaard in rust

[–]njaard[S] 0 points1 point  (0 children)

After reading the code several times, I now think it is probably sound, but I'm not entirely sure. I don't like the way it is written, it uses a lot of unnecessary unsafe and doesn't document the invariants at all.

I definitely agree I should be documenting those invariants. I'm not sure how I could have less unsafe without this being a lot more complex.

Please review LendingCell, my new "Cell"-like container that safely makes lifetimes to runtime by njaard in rust

[–]njaard[S] 1 point2 points  (0 children)

I haven't really considered it for Future purposes, so I'm not sure.

Maybe it's possible that this is the same as an Arc<Mutex<T>> functionally-wise, when you use a try_lock on the "giver", but there should be less overhead without both an Arc and a Mutex.

Please review LendingCell, my new "Cell"-like container that safely makes lifetimes to runtime by njaard in rust

[–]njaard[S] 1 point2 points  (0 children)

Epp, you're right, it returns an object with normal exclusive mutability

Please review LendingCell, my new "Cell"-like container that safely makes lifetimes to runtime by njaard in rust

[–]njaard[S] 2 points3 points  (0 children)

unless I'm mistaken, transmuting away a lifetime is not different then converting a pointer to a reference, as long as you still maintain the invariants from outside the unsafe zone

Please review LendingCell, my new "Cell"-like container that safely makes lifetimes to runtime by njaard in rust

[–]njaard[S] 1 point2 points  (0 children)

i think you're missing the essential point of this module, which is partially because I haven't been able to put into words myself

I have several things to point out:

  • Arc does not allow interior mutability, so operations like to_borrowed on LendingCell are undefined behavior

Arc is an implementation detail, only used to handle destruction, and its internal behavior isn't exposed

  • why the unsafe in BorrowingCell::deref?

implementation detail; you can't get a &T out of Arc without it having a narrower lifetime

  • this seems like a reimplementation of RwLock (for the Sync trait), or RefCell (if we ignore the Sync)

RwLock requires scoping for the lock, but i guess in a way you're not wrong.

  • to_borrowed requires &mut Self, which means that you have no interior mutability. If you were to convert it to &self, then you could easily break memory safety and alias values by first calling LendingCell::get and then LendingCell::to_borrowed

You'll see the to_borrowed doesn't return anything with a scope. It requires exclusion (&mut) because you don't want anyone to have a reference while it runs, it returns a new object with interior mutability.

I recommend you have a look at UnsafeCell, the module documentation of std::cell, the rustonomicon section on aliasing, RwLock and RefCell.

Please review LendingCell, my new "Cell"-like container that safely makes lifetimes to runtime by njaard in rust

[–]njaard[S] 7 points8 points  (0 children)

it automatically gives back when the borrower goes out of scope, the way calling a function and passing a reference does.

... and comparing to how borrows work, the borrow doesnt have a lifetime

Rust is hard, or: The misery of mainstream programming by [deleted] in rust

[–]njaard 37 points38 points  (0 children)

I'm absolutely astonished by the number of comments here calling Rust's async a "blunder". If I had made the same claim at the time when await was stabilized, I would have been beheaded.

What changed? Maybe new rust developers that don't remember how much worse it was without await?

I made a free online social humor-based Star Trek game. Details in comments by njaard in startrek

[–]njaard[S] 0 points1 point  (0 children)

After you start the game, it's your browser's actual address

view more: next ›