231 karma · joined October 24, 2013
https://github.com/SLaks/Silon#implementation-details
"Silon is implemented using LESS to generate CSS selectors for every combination of inputs that will turn each gate on. In effect, I created a LESS-based DSL that expresses (almost-)arbitrary boolean expressions."
for example, "Google Allo" could have just been released as "Allo", separate website and everything, and if Google feels it's working out and is the future of their messaging platform, eventually officially bring it in to the Google ecosystem. sort of like a buyout
window.location = "data:text/html," + document.documentElement.outerHTML
functioning as a kind of lame save buttonedit: people travel farther distances in cars than on foot, usually. nobody would replace a 20 mile commute by car with 20 miles of walking.
assuming each in-application sound generator is pull-based (like the OS sound APIs typically are) surely each one could write to a single accumulator buffer which is then sent to the OS as-is, eliminating the need for any special mixing
I'd like to know more about the requirements that led to this extra in-application mixing latency
edit: obviously the presence of push-based sound generation in the application would add another layer of mixing and latency, requiring previously prepared buffers to be mixed into a signal for the OS milliseconds after the source buffers were initially filled. however, this would be a self-imposed limitation that I still don't see a reason for
"the integers don't exist, because the percent of real numbers that are integers is effectively 0" is what the parent post is implying, which "works", in the sense that using this proof methodology "works"
The snowman, on the other hand, is a weather symbol for snow, I assume. It appears alongside other symbols for meteorological phenomena, so I imagine was added around the same time and with similar reasoning: http://www.fileformat.info/info/unicode/block/miscellaneous_...