Yes, essentially. However, the 'pinky-promisers' are large, well-funded, geographically distributed organizations that have strong incentives, both in terms of reputation and operations, to keep their promise
Where are you based? I have it tested annually, but only after moving to USA (from Poland). I don't remember if I had such a test done earlier - I think I might have had it done as a part of screening for whether I'd be allowed to go scuba-diving or something else sports-related.
How is it a pain to stop in a car? Does your foot hurt from pressing the brake pedal and then the accelerator? I don't get it - it takes actual, not-insignificant effort to start riding a bike after a full stop, unlike a car, even when it has a manual transmission. I'm guessing that is why there are jurisdictions that introduce laws allowing cyclists to skip the full stop.
And yet the register magically knows how much tax to add for each and every item you buy. I could maybe agree with your argument if taxes changed often, but they don't, and it's very much possible to calculate them beforehand and display full price.
Do you agree with this statement?
"If you paid for a product with a known platform restriction, don't expect it to Just Work, & don't leave a negative review if it doesn't."
I'm asking because IMO you initially claimed something more broad than your second comment indicates.
It starts to become annoying when you have a home office for 2 people though. 2 PCs + 4 monitors and some random things in a room can start approaching the wattage limit. Especially given that I think it's not too common to have one circuit per room (anecdata: my house has one circuit for all outlets per story; not counting bathroom and kitchen which I believe are mandated by building code to be separate).
Lots of smaller (kw) circuits is safer than a few very large circuits. The NEC in the US actually stipulates that you must use different receptacle styles for higher ampacities specifically because it is less dangerous. If you run a small appliance on a 30-40amp circuit, you run the risk of that seemingly safe appliance pulling the full 40+ amps required to trip the breaker
Not sure if I understand - can you clarify? Did you mean that a normally safe 1.5kW appliance runs the risk of cooking itself if it's connected to a 40amp circuit? If yes, then sure, that makes sense.
> Lots of smaller (kw) circuits is safer than a few very large circuits.
Not fully convinced about the safety aspect but it definitely feels more convenient (can selectively turn rooms off if you need to work on something) - if I'm ever opening the walls, I'm going to switch to that approach. At the very least, I want to have a dedicated 20amp circuit in the home office...
Largely yes a 1.5 kW device (a 12.5 amp space heater for example) is less safe on a 40 amp circuit. Since if it fail pulling more load than designed but not truly shorted the breaker may not trip. But if you put that space heater on a 15 amp circuit it would most likely trip the breaker. As other commenters have said the UK addresses that risk with fuses in the plug.
Also I recently redid my kitchen and I added an additional 20 amp circuit just for the kitchen island outlets and it has been super nice.
Are safety concerns alleviated here by GFCI breakers? In what cases could this appliance pull more amps than it was designed for? I know it's not required for circuits outside kitchen and bathroom, but I was thinking about just replacing all the breakers with combined GFCI/AFCI ones (especially given that my circuits are so old that there's no ground on them, in which case code I believe mandates that the outlets are GFCI-protected and labeled as "no ground").
So the risk would be reduced. Since if the failure causes a electricity to travel anywhere other than the neutral it will cause the gfci to trip. A scenario where a device would pull more power would be a short developing in a heating element reducing its resistance. So it would just pull more power but all of the power is still going to the neutral and wouldn't trip the GFCI.
Also with replacing all your breakers it can increase safety. But first the breakers are not cheap. Second it can lead to a lot of nuisance trips, albeit that is better than it used to be with modern breakers.
Yeah your AFCI in theory is supposed to help reduce fire risk. Since failures like that cause arcing. But yeah it will be around $60-$80 per breaker, but there is definitely cheaper than ripping open walls to re-run wires.
GFCI is not a magic “make everything perfectly safe” - you could electrocute yourself to very dead without tripping a GFCI if all the power went down the main wires and none went to ground.
Britain solves this with fuses inside appliance plugs.
The continental European system doesn't really solve it, as far as I know, so you have thicker wires on low power appliances than you would in the USA.
The US also has fused plugs but their are not widely used for some reason. I see them mostly on Christmas lights, but I have also seen it on some small home electronics like a window fan and air purifier.
Yeah sadly having separate circuits for each room is not required by the NEC to the best of my knowledge (and might be overkill depending on the situation). Usually though best practice is to have a separate circuit though for each bedroom. Depending on how your outlets are wired it might be possible to split them off onto separate breakers relatively easily though.
Rust noob here so please be gentle - can someone explain why in `Vm<'a>` the lifetime is needed? I see that in tests, `Vm<'static>` gets created, presumably because there's nowhere to grab a better lifetime from? But if that's the case, would it be possible to express this in a different way? ISTM that Vm owns everything it needs, so is there a way to avoid bubbling the lifetime up?
Similar question applies to ClassManager - it already owns all the classes (they are in an arena), so it looks like a lifetime is needed because there's no way to say "things live as long as ClassManager lives" w/o introducing the lifetime at `ClassManager<'a>` level...
Given that classes are managed by the arena, I know the reference will not be dangling thanks to the 'a lifetime.
Initially I had implemented this with raw pointers, without lifetimes, but then I switched to the reference because it felt more "idiomatic" and I had to put the lifetimes just about everywhere to make the compiler happy.
If there are better ways to do this, I would be really happy to learn, though!
For things like classes that aren't going to be created and destroyed quickly it likely is best to just use a Rc. Then you know it will be available and don't need to bother with lifetimes.
Of course there is a good chance that you will eventually want a VM-scoped lifetime for something else so maybe it is best to just start now.
Yeah, I think I understand why you had to write it this way, but the fact that this lifetime needs to be bubbled up so far up is really non-intuitive to me.
> If there are better ways to do this, I would be really happy to learn, though!
Me, too. :) I find myself limited by my way of thinking here, coming from C++ ("I _know_ it lives long enough, why don't you let me express this?").
Agreed, it _is_ annoying. It bubbles up everywhere and it feels like "something to silence the compiler" more than "something to express the safety of the code", as other people have pointed out.
The better way to do this is to use an indexing arena such as `slotmap` or `generational-arena`, so `ClassRef` is not actually a memory pointer to anything but can still be looked up in the context of the class collection. Or, if you never need to remove any values, you can use Vec as your arena and usize as your key.
IMHO, using an vector index as a pointer should be a last resort (as an alternative to unsafe). Although it's memory safe, you still have many of the traditional issues like stale pointers / use-after-free, plus you also have the cost of a bounds-check on every access and making sure you use your stored indexes with the correct container instance. If you can solve your problem by using safe code with lifetimes, that should be preferred.
What is presented here is a self-referential type, and Rust does not allow you to declare self-referential types, and an indexed arena is a solution to that. You are correct that you still have all the issues you described - that doesn't mean it should be a 'last resort' to stop using an incorrect system of lifetimes, because there is no 'safe code with lifetimes' that encodes a self-referential type. The type safety issue is solved by using slotmap or typed-generational-arena, which use unique key types.
Same way to write self referential structs - use index types into the whatever arena you are using. Indexes are usually 32 bit so they are a bit faster than pointers.
If you are building one off trees such as for parsing and ast transforms, bumpalo is your friend.
In your case, you can look into generational arenas and slabs which are useful for graphs.
You're right there – It looks like the author is trying to express "this lifetime lasts as long as the VM exists", which isn't possible to express in Rust. For VM::new, the callsite just picks a lifetime that lasts long enough – even if that outlasts the VM, making the lifetime useless. This is a bug and unsound.
My understanding is that if Rust let you compile it, then there is no bug with a lifetime (the code doesn't use `unsafe`). There may be something magical happening under the hood that I do not fully understand, but in Rust I trust. ;)
IIUC this should be fine - MemoryChunk doesn't seem to deallocate the memory (so we leak), unless there's a dealloc somewhere (sorry, not logged in to GH so cannot search). Which is not the worst outcome here, because as you said, we don't want to deallocate this memory since there may be places that still refer to it...
VM creation is using unsafe (the line I pointed out above). You're right, I can't find any deallocation either – but weirdly it /does/ segfault (or sometimes have other memory related errors) if I drop the VM while it's heap is still referenced.
The thing with a tighter bound on the lifetime is that VM carrying a lifetime for itself is fundamentally flawed. A solution would be to remove said lifetime, and have all methods on VM that return lifetimed objects take said lifetime from the reference to the VM.
That sounds reasonable (and way better than what I have implemented).
I am not sure I am going to try it though - it probably is a bit too much code to change for something that I consider "done" and I am not working on. :)
