Recent submissions

Comment · 1 month ago
You are in luck, Fearless SIMD published 1.0 just a few days ago: https://crates.io/crates/fearless_simd

It's the closest thing to Google's Highway.

(I am not connected to Fearless SIMD in any way other than as a user.)

Comment · 1 month ago
Thanks, Frank. :)

NGL, SIMD in Rust has not been a great experience. Philbin uses the "CPU Feature Tokens" pattern that the Fearless SIMD team (which the root article's author is a part of) came up with: https://shnatsel.medium.com/safe-simd-in-rust-even-on-the-in...

The pattern provides a safe abstraction for runtime CPU detection and SIMD dispatch. It's gnarly AF, but Fearless SIMD 1.0 came out a few days ago so people won't have to implement it themselves anymore.

I'd recommend grabbing that lib and giving SIMD-in-Rust another shot.

Comment · 12 years ago
Comment · 12 years ago
Author of YCM/ycmd here; I'd be happy to answer any questions you might have!
Comment · 12 years ago
Author of YCM here; supporting emacs is one of the big reasons why ycmd is now vim-agnostic and targeting other editors. I don't use emacs and never have, but plenty of people I respect do and they all say they'd love to see something like YCM for their editor of choice.

Problem is, I know nothing of emacs scripting and have even less time to maintain Yet Another open-source project. So if I end up being the person who writes such a client, it will be shitty.

I'm really hoping someone from the emacs community takes the lead on building a ycmd client. I'd provide any and all support they'd need.

Comment · 13 years ago
That's perfectly fine. To each his own! :)
Comment · 13 years ago
> So I cloned the repo, ran install.sh and got prompted to run the git submodule checkout for jedi the first time I opened a python file.

Yep, I added that check to better support the use case of people checking out the repo themselves instead of using Vundle (which will checkout the git submodules for you automatically).

I'm happy you enjoy the plugin!

Comment · 13 years ago
"Super-quick" was intended to be a bit tongue-in-cheek, although compared to the Full Installation Guide (it's in the docs), trust me, the "super-quick" installation really is super-quick.
Comment · 13 years ago
I'm the main YCM developer.

Most complaints here are about the installation procedure. I tried to make it as easy as possible, but the root of the problem is that you _have to_ compile the ycm_core module so that completion is fast. There's no going around it. The compiled module is the main reason why YCM is so fast when you get it configured.

Other than complicated/rare configurations, installing YCM is IMO not that difficult. The _only_ difference between installing any "average" plugin with Vundle/Pathogen and YCM is running ./install.sh from the YCM directory after you pull it in. That's it. The script will download dependencies for you (libclang), run cmake, make and all the other tools so that everything is installed correctly. It will clean up after itself too. It's pretty hand-holdy so it will tell you if you need to install something (like CMake).

The docs are pretty extensive so you should not get stuck anywhere even if you encounter problems.

I'm happy to hear suggestions on how to further improve the installation procedure. As always, pull requests are welcome too.

YCM too goes out of its way to inform you if you missed something you needed to do, like create a ycm_extra_conf.py file with your build flags (if you want the C-family semantic completion to work) because YCM can't conjure out of the air all the include paths and such needed to compile your project. There's no going around this, a real compiler is used to build the AST so we need the compiler flags.

All in all, if the installation procedure is the main complaint, I'm happy (not really, but you get the point) because that means that actually _using_ the plugin is a good experience (I hope). The installation you go through once and forget about; you use the plugin every day.

Here are excerpts from the FAQ about some of the other things people have brought up:

# Why isn't YCM just written in plain VimScript, FFS?

Because of the identifier completion engine and subsequence-based filtering. Let's say you have many dozens of files open in a single Vim instance (I often do); the identifier-based engine then needs to store thousands (if not tens of thousands) of identifiers in its internal data-structures. When the user types, YCM needs to perform subsequence-based filtering on all of those identifiers (every single one!) in less than 10 milliseconds.

I'm sorry, but that level of performance is just plain impossible to achieve with VimScript. I've tried, and the language is just too slow. No, you can't get acceptable performance even if you limit yourself to just the identifiers in the current file and simple prefix-based fitering.

# Why does YCM demand such a recent version of Vim?

During YCM's development several show-stopper bugs were encountered in Vim. Those needed to be fixed upstream (and were). A few months after those bugs were fixed, Vim trunk landed the pyeval() function which improved YCM performance even more since less time was spent serializing and deserializing data between Vim and the embedded Python interpreter. A few critical bugfixes for pyeval() landed in Vim 7.3.584 (and a few commits before that).

Comment · 13 years ago
Better Objective-C triggering support (the issue you linked to) is coming soon.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton