_b

Century Link expanded its fiber network in Seattle when it seemed likely Google Fiber would come, but in the last 4 years while it has been clear it wouldn't, it seems like CenturyLink has stopped expanding their network.

Is the source code available for this 2.0 preview? I'd like to look at whatever changes there are in the C++ API.

C++ is getting compile time checks for type, bounds, and lifetime safety, which steals nearly all of Rust's safety thunder.

See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-talk-at-cppcon/

For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.

I've used this for years. It takes a bit of work to get it working well on a codebase, but I find it worthwhile.

Refactoring often involves moving functionality between header files, which can mean fixing up the includes in a large number of other files. IWYU makes this a lot easier. IWYU does require the code to build before it works, but this can usually be easily gotten after a refactor by making one header file temporarily include the other.

I have, a couple times, modified templated code so it wouldn't confuse IWYU, as that is easier than maintaining pragmas correcting IWYU in the files that call the templated code.

Your feedback makes a lot of sense. Much of it we'll be turning fairly directly into work items - so thank you for the guidance.

The two items you call out as possible bugs are, embarrassingly enough, working as intended although I can see how the UX at those points is sufficiently confusing that one might reasonably assume them bugs. For instance, the rating showing up for an article no longer rated - that is the predicted rating for the article. As you start to rate articles in a topic, we show the predicted number of stars for all articles you haven't rated. This can be useful to know (e.g. the ML learns the most from the manual ratings that differ from what it would otherwise predict). The visual distinction between these predicted ratings and your explicit ratings is that the star by the number is filled in for your actual ratings. So the UX problem is that there is no way to know that is what the filled-in / not-filled-in star means. Anyway, will try to improve this.

Amount of UI text is tricky. There is value in both clarity and terseness, and it's a balance I don't always get right.

The ratings are per-article, not per-story, so a rating dropdown guy for the non-primary articles of a story almost certainly should be added. Excellent point.

And sorry about missing the hearts over stars trend. We're hopelessly uncool. Hell, we still love c++.

You should be able to build that topic on idina. If you start with a search for "clinton sanders economy," then communicate the "clinton good, sanders bad" by rating examples of that high, and everything else low.

It is hard for algorithms to understand words like "data-driven political journalism that is slightly left leaning," and, but easier to understand "stuff like this couple of Nate Silver article." So for the short term, I think we'll continue to need positive and negative examples to really get topics good for people, but someday I'd love to figure it all out from NLP parsing a general description.

Thanks!

What do you want regarding font? I'll make it happen for you. Would you like an option to set the font-size for when you are logged in? Or is there someway we could be doing our CSS differently so that zooming-in on our site meets your needs?

For customized categories, the machine learning is optimizing for ordering the articles as closely as possible to how the user rated them. There are other options, like optimizing to clicks, but that can end up with more tabloidy articles than most users like. Our hope is by optimizing to explicit ratings, users will be able to find content that is more deeply interesting.

Agreed, moving towards collaborative filtering is a good idea. We have only a few users right now, so customized categories is mostly content based filtering and figuring out how to recombine the ranking signals for them. That often work fairly well to improve topics (sometimes drastically), but mixing in collaborative filtering seems like an exciting opportunity for improving.

Also hi, I'm Ben, and I worked on this.

The offer isn't generous but it is reasonable.

Sam Altman estimated that employees 10 through 30 combined should get at least 5% of the equity, That implies an average of 0.25%, which is fairly close to 0.2%.

http://blog.samaltman.com/employee-equity

If you want to work for the company, equity is important to you, and you think the offer is below was your contribution to the company will be, then negotiate for the right amount of equity.

Here is a bug report discussing why they don't work together: https://github.com/Valloric/YouCompleteMe/issues/812

Right now, using vim is better than using this new editor (vis), although vis is close to being substantially better than vim.

I use the suckless window manager (dwm) and terminal (st), so gave vis a try for a couple days. Three vim plugins made me return: git-gutters, you-complete-me (ycm), and clang-format.

It is hard to extend vim's functionality. Its plugin interface has issues. Because of that, ycm and git-gutters can not be used at the same time, and something that ought to be straightforward like exposing clang's autocomplete information requires a considerable engineering effort (ycm) spanning three languages and about as much code as vis is total.

Giving vis good extensibility would be easier than fixed vim's plugin interface (sorry neovim). My personal preference for doing this would be a patch to vis that adds vim like gutters and dropdowns, and then patches that require this one and add specific things like ycm and git-gutters. A reasonable programmer could disagree and prefer out-of-process plugins. Either approach being implemented well would be very exciting.

YCM developer - thank you. I spent about 45 hours a week actively coding C++ using YCM. It is wonderful. Your work is appreciated.

I would like to see a benchmark showing if HyperLevelDB's changes made compaction slower or faster. (This is important because LevelDB's bottleneck is commonly compaction.)

Under the compaction section, a chart does show a dramatic improvement on the fillrand benchmark. But since HyperLevelDB removes the LevelDB write delay when compaction falls behind, writes in HyperLevelDB will continue at full speed even as compaction falls extremely far behind. So, yes, the data for the benchmark was technically written into the db, but at the costs of making reads insanely expensive.

Most reads need to touch every level-0 file. If compaction moving data out of level-0 fell 10GB behind, then there would be hundreds of level-0 files, and most reads would need to check all of them.

If the benchmark had mixed in one random read for every random write, I assume HyperLevelDB would have been dramatically slower than LevelDB.

But if the changes in what to pick for compaction made HyperLevelDB non-trivially faster, that would be quite interesting. But I can't tell if they did.