There isn't, by design. You write _some_ black-box implementation locally which outputs a textual solution you drop into the browser (at least, this is how it was in 2015 when AoC started).
I can't recommend this enough. I had to miss out on last year's challenges, but planning on participating this year; it's a great way to keep your brain nimble if you feel like you're in a rut.
On windows, if you have a logitech gaming mouse, you can set the polling rate. The default USB is 125Hz IIRC, on my mouse you can up it up to 1000Hz. For gaming it helps reduce input lag as much as possible since 125Hz is 8ms of input lag. For desktop usage, about 125Hz works fine.
For what it's worth, on my 120Hz screen, I can tell a difference between 125Hz and 250Hz polling rates, from 500Hz upwards I think I can tell but it might be placebo.
Yes there is. Humans are normally not very responsive to the time between when an action is started and when it is carried out on the screen, but this changes for actions like drawing and dragging. This is the reason for the new Pro Motion behavior on the recently released iPad Pro models. For more information, this video [1] is a good place to start.
"not very responsive"? I'm responsive. I mutter things like, "Shit, why does it seem that the amount of lag in my computer's response to my inputs get worse and worse as its physical components get faster and faster."
I think you misunderstood what I meant by non-responsive. 10ms latency from click to action is nowhere near as noticeable as 10ms latency when dragging, because the mouse visibly lags behind.
I think there might be. If your polling is not frequent enough, then if you observed a finger touch disappear from one spot and appear at another spot, you have no way to know whether the finger moved there in the span of one polling period or if the finger was lifted and a second finger placed at the new location during that polling period. So a high polling rate might be essential to disambiguate cases like this, especially for many-finger multi-touch situations.
Can you clarify which part you think could be handled by the touchpad's microcontroller? In order to implement modern gestures and interactions you need full access to all input events, otherwise you'd lose the ability to customize or adequately handle changes to context.
A finger touching and leaving would be a high-priority event for the controller to output, and it should probably internally monitor events at a high resolution.
For position, as reported to the OS: what use would actually need a report every 2 milliseconds? Intuitively, I'd think that motions that matter wouldn't need that many datapoints to reliably differentiate.
Remember that 500 interrupts per second isn't the same as a report every 2 milliseconds - reading status from a device may involve more than one interrupt.
It's often used to compensate for the fact that you want an up-to-date reading at arbitrary points within a frame. If you only update once per frame, and some code reads the position just before that every frame, that's going to give a full extra frame of lag, rather than just an extra 2ms.
Indeed; in fact, that microcontroller could conceivably do the same thing programs like Synergy do with the input events: namely, converting them into a stream of bezier-curve-based gesture-motion events and reporting those to the OS. I can't imagine you'd need to report those at more than 5Hz or so (Synergy manages to have smooth multitouch movement across a LAN just fine with an even-lower update rate.)
You can lift one finger and place another finger quickly enough to fool some older touchpads. I was able to do it fairly consistently with my old Dell laptop.
That's not necessarily because you could do it in a single frame; a lot of the old touch controllers would maintain high levels of hysteresis as a really crude technique to mitigate low SNR. Couple that with a fairly dumb implementation of pointer tracking and you end up easily fooling touchpad into thinking the two pointers are the same. Note also that this is a much rarer and more user-friendly failure scenario than choosing to have the software err in the other direction (erroneously splitting a moving finger into two separate pointers, one of which may look like a tap gesture).
Source: I occasionally work with touchscreens, many of which experienced the same issue in early devices.
It's a cheap/easy way to minimise the input lag. It's otherwise complicated to know exactly when updates should arrive, as different programs might fetch it at different times in each frame, giving you up to a full frame of extra lag if you're only doing it once per frame.
Yes. Suppose you poll at 120Hz. That is a maximum of 8ms between you moving your mouse and the input being registered. Suppose now you poll at 1000Hz. Input lag is now 1ms.
That's not a hobby -- that's a job that requires you to shill out to brands while being as loud and obnoxious as possible...
A hobby isn't usually about being popular, it's just something you like doing on your spare time. I'm fairly sure nobody on here who codes in their spare time does it to get laid, but because it's just an interesting way to fill out spare time to them.
While I don't want to downplay his role in mobilizing the community, it's hardly single-handed. Implementing ext/sodium was a group effort by dozens of developers, reviewers, and testers.
Libsodium was Frank Denis's project, which was spawned by NaCl by cryptographers Dan Bernstein, Tanja Lange, and Peter Schwabe.
The participants who voted on the RFC, for the most part, were involved in the technical discussions over the past two years since I first mentioned the notion of doing so (before the PHP 7.0 release).
Similarly, there were 13 people who contributed to the libsodium-php repository (ext/libsodium in PECL). Every single one of them had to consent to relicensing the extension to easily get merged into PHP, and we all did.
I often joke that I'm the worst C developer in all of infosec, but there's some truth to that when it comes to modifying the PHP core.
My main role in the ext/sodium project was saying, "We should do this," and somehow getting people to listen.
Very fair. I don't mean to minimize the efforts of others and the community. I should say as an outsider with a long-held aversion to anything PHP-related, Scott has single-handedly changed my view of the language to a more neutral position.
While I've found that Haskell's laziness can often be worked around with appropriately-implemented memoization, it's an absolute PITA for anything that requires frequent hops into the IO monad (unsurprisingly). Historically, this has been a bottleneck for me that's prevented me from using Haskell in any major projects.
A Haskell port of a logging library I'd originally written in Python ended up being almost 2 orders of magnitude slower than CPython 3, and almost 3 orders of magnitude slower than PyPy3.
PyPy3 resulted in performance similar to a barely-optimized C port.
You might have better luck with the fast-logger library, for one. I'd also suggest using ansi-wl-pprint, which would work on Windows and also probably be faster than string concatenation (which is just plain bad in Haskell).
As was pointed out, GHC is calling getCurrentTime too often. If you take advantage of GHC's laziness, the value will stay valid longer. I assume that is what fast-logger does.
As interesting as SIGINT against terrorist networks sounds, I assume most of this is classified -- since the cells are already known to operate smaller, and likely more difficult-to-intercept networks than nations, they'd probably adapt fairly quickly if it were revealed how they're being eavesdropped on.
I would imagine that since groups like ISIS aren't running their own cell networks, it would be very easy for government groups to locate anyone using those networks. Satellite phones can be just as easy to find too. The only way to really hide is just blend in with the normal cell noise of a city, use encrypted messaging, and hope no one is connecting the metadata dots to find you.
Mexican drug cartels have been found to be running their own cell networks, so the idea that ISIS or any other well-funded group could do the same is not outside the realm of possibility. Of course, from a SIGINT perspective, cell towers are pretty hard to hide.
Speaking as a non-American, this is partially-valid point, and a very frustrating one.
While the only people who can affect the decision are Americans (members of congress won't, and fundamentally shouldn't listen to calls and emails sent by foreign nationals), this is an issue that affects much of the internet-using world by virtue of such a large volume of international internet traffic going through lines on US soil.
In this case, it would make sense for there to be a framework whereby international citizens can provide input, but I doubt there's a way to do this without setting a precedent which could seriously compromise the integrity of their federal decision-making bodies (any further).
To to my understanding they can not legally sell information about me as I have local laws protecting me from that. Sure I doubt they really care but this seems to be a us thing to me
