Yes but the math (which happens in the receiver, so can be replicated by a user with an open source receiver) would be very different. You actually wind up with a 3D position relative to the Earth's center, which then needs to be mathematically mapped to lat/lon - that's what the WGS84 datum is for.
More annoying is when you use something like SoundSource (a paid app which adds per-app volume control and input/output redirection to macOS... a feature that by all rights should be built in in any reasonable OS) you get a permanent purple dot indicating a third party tool is intercepting audio.
Again, I get it, but as a power user this kind of stuff is just infuriating.
Not really. It's certainly intended for the basic "fan out m tasks to n workers, and the fanout producer wants to know when they're all done" and can be abused for some more, but I don't think it does anything to help with the "consumer died, I want the producers to be able to know this rather than just continuing to push messages into a queue forever" case.
I've written wrappers to handle things the way I want, but it always feels like a bit of a hack. (Usually I use a stop sentinal internally and reach inside to unbound the queue before I send it to avoid blocking). Just wish it were built in.
For one thing, static vs dynamic RAM. Static RAM (which is what's used for your typical CPU cache) is implemented with flip-flops and doesn't need to be refreshed, reads aren't destructive like DRAM, etc.
The one thing I wish stock python queues had an option for (async or otherwise) was some kind of explicit termination. e.g. be split into producers and consumers, and have consumers indicate iteration complete when all producers have finished (and vice versa - signal producers that all consumers have gone away). You can kind of kludge around it in one direction with stop sentinals but it's a lot more awkward to deal with - especially if your queues are bounded as then you can get into the situation where you block trying to push the stop sentinal onto the queue as it's full.
I highly doubt (and some quick checks seem to verify that) any of the tiny CC implementations will support the cleanup extension that most of this post's magic hinges upon.
Does anyone know of a Wayland WM/compositor that does multi-screen like XMonad? Preferably out of the box but I'll take configurable.
For those unaware, though I doubt you're reading this thread if so, I want n desktops that are shared between all screens, not desktops _assigned_ to particular screens. If I summon a desktop on screen 1 and it's currently displayed on screen 2, they should swap.
Ideally also does layouts kind of like xmonad too, not "here's a tiling tree structure and a bunch of commands to manually manage it".
They (digital calipers) are also a lot more convenient in mixed-unit environments (e.g. PCB layout, which is why I purchased mine) than analog ones. Granted since I live in the US everything is mixed unit whether I like it or not. :)
Well yes, in theory, but it's generally considered in somewhat bad taste to replace fundamental basics of the language. At that point you're not really writing Clojure anymore, it's hard to read other people's code, it's hard for other people to read your code, etc. See the somewhat controversial Allegro CL IF* macro for an example of this (I think that's what it was called; turns out that's really hard to search for).
It's a little different if you're either creating a domain-specific language (at that point you've already made the decision to have a new language, so go nuts) or if you're adding new control structures that you can't have in the base language without excessive boilerplate (see for example the somewhat common AIF macro, which binds its conditional result to a variable). But I'd consider making a new MY-LET macro because I don't like what the built-in LET looked like to be a bit gauche.
Regardless, I just decided to stick with the Lisp dialect that already worked the way I wanted.
Oddly, as someone who was reasonably into Common Lisp, what really viscerally turned me off to Clojure was the use of square brackets.
This sounds petty but I actually have some rationalization for it. Once you learn to read Lisp (mostly looking at the indentation and ignoring the parens) it's really nice that there's only one kind of delimiter in the language. It allows a lot of easy structure editing with a decent editor. I had emacs set up to use the unshifted square bracket keys to create and exit balanced parenthesis pairs. Once you got used to this, this was really pleasant to write and mutate code.
As soon as I saw Clojure, I knew that my setup would unavoidably get twice as complicated because they added another delimiter that's used in random places in the code. (Why are function arguments a vector instead of a list? Just because the designer thinks it looks better? Why are let bindings a vector? Why are ordinary function calls and function bodies a list? It just feels arbitrary.) That in and of itself really turned me off. (The fact that it's the JVM really didn't help either, but that was actually secondary to the above.)
Other issues for me were the lack of two layers in the LET statement (i.e. it's (let [a 1 b 2] ...) rather than (let ((a 1) (b 2)) ...). To some that probably "looks better" but it kills the ability to use emacs's transpose-sexps to swap the order of your let bindings around.
All in all the syntax just didn't seem well thought out to me. OTOH to non-lispers it probably looked better, so maybe that was the goal.
Not quite what you're looking for I think but it was a Wine-style reimplementation of MacOS.