NIH = Not Invented Here

This is follow-up to this story from a week ago.

Way to miss the point. I (and other readers) would happily fix the problem for them if they provided any means to do so, but they don't. Instead, they provide an illusion of wanting feedback when they won't bother to actually read it, which is worse than simply not accepting feedback at all since it wastes the submitter's time for nothing. Other sites, like the PHP documentation site, manage to handle user feedback, but Microsoft can't?

Also, whenever function arguments are of some #define'd type (e.g. DWORD, LPSTR, SQLHDBC), those type names should all link to some explanation of what they are and how to appropriately generate and use them (e.g. how to do conversions between all of the different string types) so developers don't have to go on a long expedition to find out how to set up the inputs for a function.

Minor rant, but look at the "InConnectionString Argument" section (which I can expand/collapse [useless] but can't link directly to, which is annoying) of this page. Try to read their grammar for a connection string. Confused yet? There are line breaks that have completely disappeared, causing words to merge together (e.g. "connection-stringattribute" should be "connection-string" with "attribute" being on a new line). I filled out the little "did you find this helpful" thing at the bottom of the page explaining the problem a year ago, and it hasn't been fixed. Dumping half-assed documentation on the web and not fixing (reported!) errors wastes the time of each individual developer that has to read/decipher it. The PHP online documentation is one of the most useful ones I've found, largely because it allows users to add comments/examples that make things clearer. Microsoft does the opposite -- not only can users not add to it, but the improvements that users suggest (through the "did you find this helpful" thing) are ignored. Perhaps all of the useful information is on StackOverflow because Microsoft doesn't allow it to be added to their own documentation.

More generally, it should be easy to bookmark pages (URLs should NOT break, even when new versions are released!) and sections within pages so it is easy to refer back to important things, as you could with paper documentation. Documentation for each function/object should link back to an overview that explains how it fits into things, and it should link to examples that show how all of the arguments (not just one special use case) works. Documentation should explain any differences between new/old behavior of any function/object because not everyone is developing for the latest version of the OS or development platform. And, just to beat a dead horse, users should be able to submit improvements/clarifications that actually get used.

On the other hand, if someone says "the price increased tenfold" would they mean the price is now 10p or 11p? Taking the words literally, as you have for reducing tenfold, it would be 11p, but I would guess that most people intend 10p -- not that it's right, but people tend to use such language in a very sloppy manner.

Except that the exchange rate for Bitcoin may not be as well established as other currencies (I don't know that for sure, but it seems a reasonable guess), making it harder for your employer to defend the amount they paid during an audit.

I don't think you understand how a futures contract works (or you're just wildly speculating). The futures price is not the price of the underlying asset -- it takes into account the appreciation of the underlying asset that is expected to occur over the life of the contract (and some adjustment for interest rates). So, the expected payout (ignoring interest rate effects) of the contract is $0.

Also (this is more a reply to the parent), futures contracts are "marked to market." You pay nothing to enter into one (although you'll need to have cash in your account). Each day money is added/removed to your account based on changes to the future price, so the value of the contract itself is zero. Hence, if someone pays you in futures, they've paid you nothing -- you may gain/lose money in the future due to fluctuations, but the expected value of those fluctuations is 0.

If anything, I would expect visible="hidden" to be worse since: "With ‘visibility’ set to hidden, however, processing occurs as if the element were part of the rendering tree and still taking up space, but not actually rendered onto the canvas." I don't have time to verify that at the moment, but maybe I'll test it later and post an update.

Since none of the other browsers are exhibiting the same slowness, are you saying that Chrome is exceptionally slow at building the DOM?

I've noticed that for large SVG files where much of the content has display='none' (so it is only displayed when something is clicked to trigger a change in the display property) Chrome seems to take several seconds to become responsive after the SVG page load is initiated, while other browsers seem to handle it almost instantly. Since a display value of none "indicates that the given element and its children shall not be rendered directly (i.e., those elements are not present in the rendering tree)" it seems Chrome shouldn't be spending so much time processing such stuff. Version 24 doesn't seem to fix that issue.

Yeah, I badly misread the post I was replying to to imply static linking when he/she said nothing of the sort. My bad.

Ignore the above -- I'm not sure how I read "ship all necessary DLLs" as statically linking the libraries. I think I need more sleep...

Is close-source software likely to have problems with the LGPL if they link statically instead of dynamically? That's a question, not an accusation -- I don't know which libraries game makers are likely to use, and whether they are LGPL or something else.

I think the Nexus 7 will generate a hover event (instead of a click event) if you hold your finger down on the same spot for a long enough period of time. I don't know if that you works on the Galaxy Tab, but I thought it was worth mentioning. I was just reading about similar problems with hover events on the iPad yesterday.