430 karma · joined June 17, 2015
https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
Wasm was effectively an extension of asm.js. It makes the experience of compile-to-web better, but it isn't much more opaque than other projects.
And by all accounts the situation in Xinjiang is much worse than Guantanamo Bay. To start, Guantanamo Bay at its peak had under 800 people imprisoned. Xinjiang re-education camps are estimated to hold 1-3 million people. So the scale is massively different. It's hard to know exactly what happens in the camps, but the reports of torture and organ harvesting don't paint a rosy picture.
A couple months ago a friend of a friend was killed because a boy from school brought a gun from home to their house to show off and was playing with it. He thought it was empty. It wasn't. Now a girl is dead, a boy's life is ruined, and their families are devastated.
This happens all the time.
I work on a web platform team, and I've seen many vulnerability reports over the years (well over 100). I've never seen a report from the NSA or US government. Actually, the only government I've seen reports from are the UK, so credit to them for actually doing something to keep people secure. But most reports I see are from project zero or Chinese companies.
Either the US government doesn't care at all about browser security or they are keeping vulnerabilities for themselves.
From what I've read, they work by comparing the player's moves against chess engines, and if the player is picking engine's choice too often in positions where there are multiple roughly equal moves, they get flagged.
I think it's mostly that there's a lot of newsworthy events going on in China right now.
But it looks like the CONTRIBUTING.md file wasn't updated to reflect this change.
Sure you can do everything with ROP, but it is less convenient (and Intel CET might eventually make ROP attacks actually hard).
I believe people in the community also have a ChakraCore fork specifically made for using Node on iOS.
Google only released a patch early because the finder blogged about it.
https://blog.edgespot.io/2019/02/edgespot-detects-pdf-zero-d...
No ticket, nothing.
So you can always use the size of your bytecode as an inlining heuristic (which is what Chakra does).
Of course that wouldn't work before v8 had an interpreter, but they could have used other heuristics. For example, they could have used the size of the AST as a heuristic and saved that even after the AST gets thrown away.
What I do now is run a script that averages results from the preceding 10 runs and compares that to the average of the following 5 runs to see if the regression is consistent or anomalous. If the regression is consistent, then the script automatically files a bug in our tracker.
There is still some noise in the results, but it cuts down on those one-off issues.
But a much more common case is that properties added after object creating will be added in an inconsistent order, for example:
o = {}; o.x = 1; o.y = 2; o.z = 3;
p = {}; p.y = 4; p.x = 5; p.z = 6;
When executing p.y = 4 you don't know that the object will eventually evolve to have the same properties as o.
There will always be some cost here, because at runtime you need to check if your assumptions still hold. Some of the time you can pull these checks out of loops, but sometimes you can't, and they can be costly.
There are a few things a JIT can theoretically do better. Inlining is the biggest one. For example, a JIT knows not to inline a function that never gets called, and it can also do inlining for indirect calls based on profile data. A JIT could also theoretically move unexecuted blocks out of line for better instruction cache locality. It could also check for aliasing at run time (with a bailout) and then optimize a loop assuming no aliasing.
Unfortunately for JITs, AOT compilers can do a pretty good simulation of most of these things with PGO, that is running a scenario with an instrumented binary and re-optimizing using profile data.
Still can't bailout if an assumption is wrong, so it doesn't work for dynamic languages, but you don't really need bailout for much in static languages.
I think this is a pretty good middle ground, where we still get compile errors to help against code rot, but also keeps code needed for special configs disabled/isolated.
That seems like pretty unreasonable tinfoil. There is no reason for Microsoft to want to give information to governments. I assume they don't pay, and the cost is consumer trust. Makes a lot of sense to rearchitect such that you can't give in to government demands.
Why do you think inline caches would be an issue?