gwicke

I agree the FreeCAD UX could use some improvements, but I think even more important would be improving reliability and feature coverage in the OpenCascade CAD geometry library it uses. Slightly more complex things like fillets, lofts, nurbs surfaces are very limited and unreliable today. Mixing any of these with booleans tends to create more trouble.

Blender on the other hand is very solid in the modeling department, in my experience. The mesh based approach certainly helps, but not depending on an external organization for the core geometry functionality does not hurt either.

I wrote a fairly similar library that additionally uses data from last.fm and pandora, and supports compiling by track similarity as well: https://github.com/gwicke/compilation

I'm using it to power the auto-playlist feature in my fork of https://github.com/andrewrk/groovebasin, a node music player.

I wonder if Amazon is also deduplicating. It seems likely that a share of users would store large media files or software packages without encryption.

At Wikimedia, we are using firejail to lock down services. We encountered some bugs in older versions, but those have since been fixed. Overall, it has been working fairly well for us.

We are actually working on a storage service called RESTBase (https://www.mediawiki.org/wiki/RESTBase). RESTBase has pluggable table storage backends, starting with Cassandra. Other backends will scale this down for small installations.

The medium-term goal is to store all revisions as HTML, so that views and HTML-based saves can become storage-bound operations with low double-digit ms latencies. This will mostly eliminate the remaining 2-4% of cache misses, and should get us closer to actual DC fail-over without completely cold caches.

There is still a large amount of work to be done until all the puzzle pieces for this are in place, but we are hard at work to make it a reality. A major one, the bidirectional conversion between wikitext and HTML in Parsoid (https://www.mediawiki.org/wiki/Parsoid), is already powering VisualEditor and a bunch of other projects (https://www.mediawiki.org/wiki/Parsoid/Users). Watch this space ;)

This depends on the definition of compliant. By the paper's feature-based approach, Parsoid would be 'compliant' with the PHP parser.

There is more to compliance than a simple feature comparison though, most of which can only be identified by large-scale testing. Each night, we have been running tests on a sample of 160k articles from 16 languages to check our progress. In this test setup, 99.99995% of articles round-trip perfectly from wikitext to HTML and back. Currently the focus is on visual diffing to identify remaining rendering differences.

There is still a good amount of work left until Parsoid is ready to replace the PHP parser, but most of this is actually not relevant to you if all you'd like to do is extract semantic information.

Regarding the paper: The authors correctly describe some of the issues inherent in wikitext parsing. Its conclusions are however based on strong assumptions about the implementation strategy. For example, they do not consider the option of flattening a PEG parse tree back to tokens in order to implement context-sensitive and generally unbalanced parts of the syntax. Similarly, the analysis of the parsing complexity seems to assume a lack of transclusion limits.

Nothing beats being told that what you just did is in fact not feasible ;) Check out this page:

https://www.mediawiki.org/wiki/Parsoid

This is the bidirectional conversion engine between wikitext and HTML+RDFa that powers VisualEditor and several other tools. It tracks source range to DOM structure correspondence as proposed in the post. At this point, the IDE is basically a user interface and performance problem. The conversion is readily available through a REST interface, but on the largest articles parsing from modified wikitext to HTML can take around 10 seconds. Most of that time is spent in the expansion of the myriad of citation templates that we like people to add. It is possible to speed this up to something more usable for an IDE, but it's not trivial.

You might also be interested in this blog post about some of the challenges we encountered while building Parsoid: http://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-c...