What if one's name is represented by a non-printable character or logo? Perhaps your form provides a way to upload a glyph, or you need to enable name submittal via floppy disk.
You're aware that there's a registry per country, no? And that that each country can choose to set aside a subdomain for all government services?
Yes, it's unfair that the US gets naked .gov - but that doesn't preclude the rest of the world from doing the right thing, and it certainly doesn't excuse the US government doing the stupid thing.
There is an annoying bug in Chrome DevTools that people who want to impede debugging of their JS files exploit. I think it's probably related to making the regex engine use excess memory and crashing the tab.
Anyway, just mentioning it to see if someone here knows if it's a well known and difficult to fix bug, or if it's just a bit obscure to have had any fixes for.
I haven't seen that one. I'd start by searching crbug.com. Then, the first step to a fix is always to find a reproducible example of the bug. In this case that would probably be finding an example in the wild and trying to save it locally in a way that still reproduces the bug. If you can get those files attached to the bug report there's a good chance it can be fixed. When I was fixing Chromium bugs, repro cases were worth their weight in gold.
I thought so, too. I'm not interested enough to benchmark it, but for all practical purposes it's instantaneous on my machine. As fast to open a new terminal as it is to switch to the existing one.
Mine takes 50ms, assuming wsl is hot (recorded screen and compared mouse click frame to window pop up frame). I think op should try a different wsl distro or a blank machine and compare differences. I have on access scanning off, performance on, Ubuntu wsl distro, and windows 10.
interesting side note, our brain is compensating for delay, it can do it to around 250ms
so if anything lags up to that amount our brain will compensate and make it feel imstantenious
there was interesting experiment that I reproduced at university, create app that slowly build up delay to clicks to allow brain to adapt, and then remove it completely.
result is that you have feeling that it reacts just before you actually click until brain adapts again to new timing
I don't think it's right to say that the compensation makes things feel instantaneous, but rather that we are able to still feel the association between input and result, allowing for coordinated feedback loops to be maintained. We do grow accustomed to the latency, but I do not think it is right to say that it feels like zero latency.
If the delay is long enough, the output does not just feel delayed, but entirely unrelated to the input.
A latency perception test involving a switch can easily be thrown off by a disconnect between the actual point of actuation vs. the end-users perceived point of actuation. For example, the user might feel - especially if exposed to a high system latency - that the switch actuation is after the button has physically bottomed out and squeezed with an increased force as if they were trying to mechanically induce the action, and later be surprised to realize that the actuation point was after less than half the key travel when the virtual latency is removed.
Without knowing the details of the experiment, I think this is a more likely explanation for a perception of negative latency: Not intuitively understanding the input trigger.
As a long time gamer, I can anecdotally corroborate your theory with my early experiences playing FPS games using a dial-up connection. Average ping was about 200ms which allowed for an enjoyable and accurate experience after some adjustment. >250ms was unpleasant and had a significant impact to ability.
It was for this reason that I, and many others, for a short period, got objectively "worse" at the game when we switched to ISDN/Cable and suddenly found ourselves with 20-30ms pings; Our brains were still including the compensating latency when firing.
This seems more like compensation for projectile velocity, no?
I am assuming that the latency is in enemy location due to the game running hitscan (instantaneous weapons without trajectory simulation) on the server. In this case, your aim is as when you clicked the trigger, but hit is only computed <latency> time later when the server processes the incoming shot request, at which point the enemy position has changed.
This makes the latency behave similar to projectile velocity, where you need to aim not where a target is but where a target will be. Changing to a setup with a lower latency would then be like using a much faster weapon which requires new training to use.
(Input latency would mean that if you move your aim and click the trigger, your aim would continue to change for <latency> time before the bullet fires towards whatever your aim ends up being. This is much worse.)
Open up Chat GPT, paste your functions and ask it to convert them to rust. Go through them 1 by 1, see if you understand and ask questions about anything you don't recognise. Don't expect the output to be perfectly logically correct, you will have to ensure that yourself.
I've found Chat GPT to be really excellent for quickly getting myself up to speed with languages that I'm not familiar with.
Yes, that’s my advice as well. Set up vscode with rust analyzer and paste any errors it shows back into the same ChatGPT conversation and it will debug everything for you.
The syntax isn’t really the hard part, it’s the rules around memory ownership and when you need to clone variables. There are lots of gotchas and the compiler is very unforgiving. If you want to convert your 5 functions into rust in a reasonable time instead of spending weeks grappling with the differences, just use ChatGPT and iterate by pasting in the errors from rust analyzer and the compiler.
If you actually want to learn rust then that’s a different story and you should probably check out Steve Klabnik‘s book or something like that (or just look at the sample code I linked to in my other comment from my own recent rust library for python).
I've never understood that check. Anyone attempting to steal something just wouldn't put an item they didn't scan in the bagging area. It's almost certainly always a false-positive, which is confirmed by most store employees just clearing the error without checking.
And then there's the other check that if you do scan something, it needs to go in the bagging area. So if I go into a store and grab a single item, and just scan it and hold it, the machine will freak out that I didn't put it in the bagging area. If I don't put it there quick enough it'll lock up and need an employee to intervene. Ugh.
In my experience, Target is the only store that has consistently implemented a good self-checkout experience.
Home Depot is the only store that has a great self-checkout experience. They give you fast responsive terminals with wireless barcode scanners, just like the employees have. You can line up your goods in your cart and then checkout faster than with an employee helping.
Afaicr, HD began modernizing their self-checkout terminals ~4 years ago? I remember because it was rolling out and then pandemic happened.
People also underappreciate the internal effort (and cost) required to ship new terminals in a national chain and the drag of running a heterogeneous operation during the transition period.
It feels like 90% of UX issues could be solved with shipping over-engineered (from performance and robustness perspectives) hardware, at additional cost. Which seems like what HD did with the latest terminals.
It is probably quite common for people to put items in the bag after failing to scan them by mistake. But I guess an "a new item check" which is not very weight sensitive would be enough to counter that.
Self-checkout works best in Home Depot type of places in my experience. There are just so many items to keep track of in grocery stores.
The worst ones make it really difficult to use your own bag — no option to tell it, complains when you put your bag in the bagging area, etc. This is one of the main reasons I still go to the checkouts with human operators.
It's not even just the "unexpected item in bagging area" factor, it's that there's often way to little staff around so you spend >5 minutes waiting on any issue, sometimes more than once ("unexpected item" and then later alcohol/age check). They have exactly the same machines in Ireland and New Zealand (just with a different colour scheme, depending on the store) and while they're still crap, they're significantly less frustrating to use than Tesco or Asda in the UK because there's usually enough staff. That's been my experience with it anyway.
reply