Jason_Gibson

A changelist is most generally a Perforce term (and as may the case for Google, a similar concept). In the Perforce Helix Core (what the "Perforce Server" is currently called), changelists are increasing integers that mark units of atomic change. Changelists can contain committed work, pending work, or shelved work (a shelf is un-committed work that resides server-side). Shelves are often how code review is done since the file content and metadata is available outside of the author's computer.

ASAN on its own doesn't detect uninitialized memory. MSAN can, though. Valgrind is also more than just the memcheck sub-tool - there are others, like Cachegrind, which is a cache and branch-prediction profiler.

https://github.com/google/sanitizers/wiki/AddressSanitizerCo... https://github.com/google/sanitizers/wiki/MemorySanitizer https://valgrind.org/docs/manual/manual.html

Do you mean 'BEGIN CONCURRENT'?

https://sqlite.org/cgi/src/doc/begin-concurrent-pnu-wal2/doc...

Where did you see that the plan is to bring those into the mainline distribution?

A company called Violin Memory used to make one for servers:

http://www.storagesearch.com/ssd-23.html

Could you give an example of where Perforce is not OSS-friendly? Sure, the product core is not OSS, but parts of the periphery are, and there's at least one section of the company whose entire business model is supporting OSS:

https://www.openlogic.com/ https://www.openlogic.com/about-openlogic-perforce

Could you give an example of where it has Embraced->Extinguished?

While the Helix Core Server itself is not Open Source, much of the surrounding tooling is. E.g., see the code here: https://swarm.workshop.perforce.com/user/perforce_software I don't think it'd be fair to say it's "fully" closed-source.

This forum post has some info on benchmarking SQLite with two different backends:

https://sqlite.org/forum/forumpost/9aa5e1dcffde1336

See the "preliminary results" link.

And to expand on this, it's easier to add features to a language than to remove them. If one's design requires certain runtime constraints (ability to hook into interpreter execution and memory allocation, no per-process global restrictions), packaging (e.g. static linking), and ease of portability, then starting off on the minimal side (Lua) is better than trying to strip things off of a larger (Python) runtime.

You can also get to a middle-ground state between "no batteries" and "just enough batteries" to get a large portion of the expected work done if the problem space is understood and has some bounds. E.g. including a library to make HTTP requests, parse JSON and work with an embedded SQL database will be enough for a lot of use-cases in the "user-defined glue logic on an existing application" space.

Indeed, and not only did they develop the Perceus technique for the Koka language, but the immediately practical mimalloc allocator came out of that work as well.

https://github.com/koka-lang/koka https://github.com/microsoft/mimalloc

Microsoft's 'mimalloc' MIT-licensed allocator is lock-free. Perhaps there's something in there that'd be interesting to read.

  https://github.com/microsoft/mimalloc
  https://github.com/microsoft/mimalloc/blob/master/include/mimalloc-atomic.h

  https://plv.mpi-sws.org/genmc/