CapacitorSet

Saved you a click: the internal state of some slot machines' PRNG can be predicted after observing a few of its outputs.

The Closure Compiler with ADVANCED_OPTIMIZATION is a great tool, and I wish more projects used it. However, when I tried it on my own projects I found that it is a relative pain in the arse to export absolutely everything that you don't want the compiler to remove or rename: this might be why it didn't gain a lot of traction.

Monitoring hardware, then.

Reread the list with your assumptions in mind (one nonzero-length field, with a maximum field, Unicode).

Getting names right is very hard: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

[OpenTokRTC](https://opentokrtc.com/) relies on WebRTC, a vendor-independent HTML5 technology.

Is there a technical, non-commercial introduction that isn't filled with too much marketing hype?

That's an extremely rose-tinted narrative.

It was much more difficult to understand. For whatever reason, it appears that I couldn't `splice` arrays (https://github.com/CapacitorSet/rebridge/issues/2), and I honestly couldn't figure out what was wrong.

There was also the issue of error handling, which is much easier with promises.

Previous thread here, about v1.0: https://news.ycombinator.com/item?id=12723474

v2.0 addresses some of the feedback in the previous thread, and uses Promises rather than synchronous non-blocking access.

That seems like a nice use case for ipfs: https://ipfs.io/

As of now there is no automatic mirroring, because nodes only store the data they request, but in the future one will use filecoin (http://filecoin.io/) to incentivize mirroring.

To first thought, there may be licenses in place preventing you from self-hosting the content.

Spam filters could do very little, because it's almost impossible to tell whether a conversation was run by a bot - and it's outright impossible to do so for a single response.

However, you raise an interesting point: blacklists could reasonably be put into place. I'll make a merge request to use Spintax.

I think there's a better chance for a static_assert proposal in C, especially since Torvalds isn't particularly fond of C++.

Edit: whoops, apparently static_assert is in C11 as well as in C++11. Ignore this comment.

The thing is, modern antiviruses rely on context to classify data as malware or not. It is fine if antivirus.exe is trying to remove itself; not so much if it is being removed by calc.exe.

I wouldn't mind working with your coding style either: though I don't have the same standards for braces and array initialization, you apply your style consistently across the whole code.

>None of these choices are particularly important. Being CONSISTENT does.

The thing is - there isn't much consistency in his syntax. The most obvious example is the indentation, that appears to be 8 spaces except for one line which is indented with 4; there isn't consistency in whether to have a space or not before semicolons, before and after parentheses, or before and after binary operators.

To me, having consistent indentation does make a substantial difference - it is fundamental to understand at a glance what structures are present in the code, rather than "parsing" it in detail every time I'm looking for something.

I really dislike his choice of coding style. Compare:

  int CountBits (unsigned int x )
  {
      static unsigned int mask[] = { 0x55555555,
          0x33333333,
          0x0F0F0F0F,
          0x00FF00FF,
          0x0000FFFF
          } ;

          int i ;
          int shift ; /* Number of positions to shift to right*/
          for ( i =0, shift =1; i < 5; i ++, shift *= 2)
                  x = (x & mask[i ])+ ( ( x >> shift) & mask[i]);
          return x;
  }

as opposed to:

  int countBits (unsigned int x) {
    static unsigned int mask[] = {
      0x55555555,
      0x33333333,
      0x0F0F0F0F,
      0x00FF00FF,
      0x0000FFFF
    };

    int i;
    int shift; // Number of positions to shift to the right
    for (i = 0, shift = 1; i < 5; i++, shift *= 2)
      x = (x & mask[i]) + ((x >> shift) & mask[i]);
    return x;
  }

Are bit fields slower (at least in C)? It's a matter of load-constant mask-compare, as opposed to load-compare; I imagine it's a matter of one additional instruction per load statement, and this instruction also happens to be very fast.

If anyone is interested, this is known as p-hacking in statistics (https://en.wikipedia.org/wiki/Data_dredging), and works in a similar way.

For instance, you have a statistical population of one hundred men and one hundred women: you collect as much data as possible about them - as many features as possible, actually - until you find something which happens to be statistically significant for your group (eg. salt consumption). Then, you publish your results, pretending that the feature you found was the original hypothesis for the study ("Our study confirms that salt consumption is higher in males.")

I wonder if such a "low-level" coding style, based on bitfields and state machines, generally leads to better performance than more abstract patterns. While the former is close to how a human would design hardware for that task, the latter can be better optimised by the compiler.

>I don't neccessarily think vscode needed to reach out to NPM to let them know they were going to be consuming their public API.

VSCode is used by a non-negligible number of users, and seems to rely on npm to operate at its best. It would have been good etiquette to let npm know, even though they couldn't forecast this exact situation.

Why not both? It is trivial to make a circuit such that the LED is on if either there is power to the camera, or the software tells you to.

Still, I don't think you can use it to avoid (physical) crashes due to an incorrect algorithm, simply because theorem provers work on a cognitive basis but control systems operate on continuous fields (i.e. transfer functions defined over the complex numbers).

Thank you for your feedback.

* I don't think the asynchronous flow can be further simplified. If you do find a sleek solution, do submit a PR, or even an issue with some sample code.

* Stack overflow is not an issue at this time (and even less in the future, with tail call optimization in V8), except for pathological objects. As such, I didn't use lodash, to keep the library as small as possible.

* JSON.parse errors are not an issue, under the assumption that the Redis database is only written to by Rebridge itself. If you find otherwise, do submit an issue. Circular references are indeed a known limitation, documented in the README.

* Thanks, I removed it in beda881. It was probably a debug line.

For the sentinel, I haven't yet had to use it (I used it in a small Telegram bot with a single Redis server on a cheap VPS). I'll open an issue for that.

What do you mean by micros?

Anyway, yeah, it's just meant to be some sort of synchronous syntactic sugar on Redis.

Edit: I think you meant macros. In that case, consider that it's not as simple as that, because a) the redis library is only asynchronous, and b) such an approach requires to implement wrappers for every function that writes to the object, eg. Array.proto.splice.