[mini] Setting up Spark on Arch Linux

First things first: install openjdk (version 8 is the better one at the time of this post) and scala. This should be pretty standard. But if you really need some orientation, then check out our Wiki.

sudo pacman -S scala scala-docs scala-sources

I’m not listing any jdks here because there are several variants of it to choose from. I personally use jdk8-openjdk-infinality to benefit from the infinality font patchset.

Now, check out if you’re good to go:

$ scala
Welcome to Scala version 2.11.6 (OpenJDK 64-Bit Server VM, Java 1.8.0_40).
Type in expressions to have them evaluated.
Type :help for more information.

scala> println("hello world")
hello world

Now, let’s grab the apache-spark package from the AUR. Un-tar it and do a

Edit: actually, I recommend this PKGBUILD that I improved, based on the one from the AUR: (note: this will be deprecated one day…)

# Maintainer: Franois Garillot ("huitseeker") 
# Contributor: Christian Krause ("wookietreiber") <kizkizzbangbang@gmail.com>
# Contributor: Thiago Perrotta ("thiagowfx") 
 
pkgname=apache-spark
pkgver=1.3.1
pkgrel=2
pkgdesc="fast and general engine for large-scale data processing"
arch=('i686' 'x86_64')
url="http://spark.apache.org/"
license=('Apache')
depends=('maven' 'java-environment>=6' 'scala' 'python2>=2.7')
install=$pkgname.install
source=("http://d3kbcqa49mib13.cloudfront.net/spark-$pkgver.tgz"
        "$pkgname-standalone.service"
        'spark-env.sh')
md5sums=('5ae47bffe0e88c3ccf26e70a72791070'
         'bb7d8b85366e6f9cc0b2777eaea161a8'
         '0913001583e607849270090555dbd309')
backup=("etc/$pkgname/spark-env.sh")
 
prepare() {
  cd "$srcdir/spark-$pkgver"
  sed -i "s|pid=$SPARK_PID_DIR/spark-$SPARK_IDENT_STRING-$command-$instance.pid|pid=/var/lib/$pkgname/spark-daemon.pid|" sbin/spark-daemon.sh
}
 
build() {
  cd "$srcdir/spark-$pkgver"
 
  export MAVEN_OPTS="-Xmx2g -XX:MaxPermSize=512M -XX:ReservedCodeCacheSize=512m"
  dev/change-version-to-2.11.sh
  mvn -Dscala-2.11 -DskipTests -Dmaven.repo.local=/tmp clean package
}
 
package() {
  cd "$srcdir/spark-$pkgver"
 
  install -d "$pkgdir/usr/bin" "$pkgdir/usr/share"
 
  cp -r "$srcdir/spark-$pkgver" "$pkgdir/usr/share/$pkgname/"
 
  for f in spark-{class,sql,shell,submit}; do
      echo -e "#!/bin/sh\ncd /usr/share/$pkgname/bin/\n./$f" > "$pkgdir/usr/bin/$f"
      chmod +x "$pkgdir/usr/bin/$f"
  done
 
  install -Dm644 "$srcdir/$pkgname-standalone.service" "$pkgdir/usr/lib/systemd/system/$pkgname-standalone.service"
  install -Dm644 "$srcdir/spark-env.sh" "$pkgdir/etc/$pkgname/spark-env.sh"
 
  cd "$pkgdir/usr/share/$pkgname/conf"
  ln -sf "/etc/$pkgname/spark-env.sh" .
}
$ makepkg -si

And now wait. Spark is built with maven, so it will pull several dependencies then compile them; maven is the equivalent of cmake in the Java world.

Why is this here? To show people from other distros how it is easy to install “uncommon” software on Arch. And hey, if the software is not packaged, then it is (usually) easy to do that too; just request this on the appropriate subforum. Or, better yet, learn to do that yourself.

Advertisements
[mini] Setting up Spark on Arch Linux

[OCaml #01]: OCaml starters

You should read this post first.

Last week or so I thought I would start to learn Perl or Lua, but I discovered OCaml…and then my focus instantly shifted into it. I’m not really sure what I’ll do about the language, but for now I’m studying it a little bit, so I’ll post here a few notes about it.

Note: this post is likely to be updated as I progress through the language; alternatively, a new post might be created, or I can abandon this thing altogether (yeah, this happens).

So…

  • To get an interpreter: ocaml
    • Now enter valid OCaml expressions, and finish them with ;;
    • You can enter more than one expression at a time, e.g.
    let x = 1
    let y = 2
    ;;
    • Equivalently, you can write a script.ml file and enter these same commands, then enter into the interpreter and type:
      #use "script.ml";;
  • Alternatively, you can compile this script with ocamlc. This will create three files: an executable (a.out by default), a.cmi (interface) and a.cmo (object file).
  • To run an OCaml executable, use ocamlrun.
  • Up to here, this is very similar to haskell: ghc, ghci, and runhaskell.
  • Pattern matching is very easy overall (as with haskell)
  • let isvowel c = 
        match c with
            'a' | 'e' | 'i' | 'o' | 'u' -> true
            | _ -> false;;
  • However, I find P.M. more explicit with OCaml. Haskell uses function overloading to implement pattern matching (at least in the syntax level), while OCaml uses a switch-like statement to do that. Well, actually haskell desugars function overloading to a ‘case’ expression behind the scenes, which is very similar to OCaml’s match, but hey…it is just slightly easier to read the OCaml syntax.
  • You can use _ to match anything.
  • You can also use _ to ignore what is not relevant to you in a match, e.g. when matching tuples:
  • let fst (x, _) = x;;
    let snd (_, y) = y;;
  • You can match character ranges, e.g. ‘A’..’Z’.
  • Two bindings are available: let and let rec. The last one is used to define recursive functions, and they are fundamentally the same; the difference lies in scoping rules (e.g., when using let … in). Example of let rec:
  • let rec factorial n = 
        if (n < 0) then failwith "negative factorial!"
        else if (n = 0) then 1
        else n * factorial (n-1);;
  • OCaml from the very beginning is a super nice intro book to the language. I gave it a 5/5 on Goodreads.
  • Examples from the book: in this user repository.
  • Logical operators are not exactly what you expect regarding equality: = and <>. Yeah, not ==. Annoying, huh?
  • true and false are written in lowercase. Different from python, equal to ruby. Why are programming languages so different? At least, if you write it wrong, you are prompted with a nice message:
  • Error: Unbound constructor True
    Hint: Did you mean true?
  • Speaking of messages, error messages from OCaml are veeeeeery good. It looks like its creators know how to actually communicate with other humans (gcc, this is a subtle sarcasm directed to you!). Want to see an example? I’ll give you one about a warning:
  • let f l = 
        match l with
        [] -> True;;
    
    (* Response: (yeah, this is a comment!)
    
    Warning 8: this pattern-matching is not exhaustive.
    Here is an example of a value that is not matched:
    _::_
    val f : 'a list -> bool = <fun>
    
    *)
  • Naming convention when deconstructing lists: h::t. This means head and tail. In haskell, we usually use x:xs.
  • Oh yeah, haskell is : while OCaml is :: while in the lisp family of languages this is cons.
  • And the append/concatenate operator is @. In haskell it is ++, in python it is +.
  • Yeah, I keep comparing OCaml with other languages because I find it easier to understand it this way.
  • A list in OCaml is a single linked list behind the scenes. So the :: operator only acts on one side of the list…you’re screwed if you want the other one — alternatively, revert the list or use a better data structure.
  • Speaking about lists….[1;2;3;4] not [1,2,3,4]. The last style is from Python / Haskell / Ruby.
  • Package manager? Yeah! opam. This should be analogous to RubyGems and Haskell’s Cabal or node’s npm. opam install, opam remove, opam search…I keep writing it opan, for some reason.
  • love this feature: every function in OCaml has only one parameter. Native currying (aka partial application) FTW! Like haskell.
  • The compiler is pretty smart about inferring types, but annotations can be made too:
  • let sum10 (x:int):int = x + 10;;
  • Anonymous functions:
  • fun x -> 2 * x
    
    (* example of use with map: *)
    map (fun x -> 2 * x) [1; 2; 3] (* yields [2; 4; 6] *)
  • Just comparing with haskell, which is slightly smaller:
  • map (\x -> 2 * x) [1..3]
    
    -- or, better yet
    map (* 2) [1..3]
  • Actually, it is possible to use something such as (+) or (<=) in OCaml. But…not (*). This is confused with a comment. Maybe there is a way of escaping this. Edit: yeah, we just have to insert spaces: ( * ).

I guess I’m stopping here for now. This includes up to chapter 6 of the aforementioned book, plus a few random sources on the web.

[OCaml #01]: OCaml starters

Getting started with Ogre3d

I struggled a little[1] to get started with Ogre3d graphics, so here are a few notes. In this post we will be able to run some basic examples from the framework.

1. Get a distribution with a nice packaging system[2] and install ogre from it. I can cite two of them: Arch Linux family (pacman-based) or Gentoo family (portage-based). The point is: DON’T install the ogre package from deb-based distros (those include Debian and Ubuntu). They have a few problems:

1.1 Packages are usually outdated[3]. In the case of ogre, this is not a super problem. Its current version is 1.9, and the available one in Ubuntu is 1.8. Even if you can live with that, don’t install Ogre3d on Ubuntu. Keep reading.

1.2 Some files are missing from the packages. Yeah, and I’m pretty sure of that. I compared the upstream ogree tree (from mercurial/BitBucket) with the files that are installed on Ubuntu (dpkg-query -L libogre-1.8-dev), and some files were missing, period. One example I recall? SdkTrays.

1.3 Some files are installed in non-standard locations. I can’t list them because I’m not using an Ubuntu distro right now, but I remember, for example, ‘x86_64-linux-gnu’ (or something along these lines) being used as a directory. Really? This is non-standard. And what about /usr/lib/ogre? This folder doesn’t even exist on Ubuntu. And it should!

Worse yet? Ogre documentation assumes the default installation directory is /usr/local. In other words, it assumes you don’t use a package manager at all, plus you used make install after compiling it, which implies you must have sudo rights on the system. This is simply too restrictive. Also, we all know everything that ends up on /usr/local (=programs installed manually by the user, without a package manager) sooner or later turns into a mess.

Okay, that said, please notice I’m not trying to convince yourself not to use Ubuntu for ogre3d development. I’m just stating I had an awful experience with it. You do whatever you want, okay? Also, if you can handle ogre3d on Ubuntu, please leave a comment telling me how you did that.

I’m using Arch to do ogre3d development from now on; and, if I’m ever forced to use Ubuntu (for example, at work or at my lab at college), I’ll have to struggle to install ogre locally on the system. More on that later.

pacman -Syu ogre

Now, see if you can run the most basic pre-example from Ogre. It is here. This link will probably be broken in the future, so I’ll say those are the files from this example:

  • ogreapp
    • CMakeLists.txt (see below)
    • BaseApplication.h
    • BaseApplication.cpp
    • TutorialApplication.h
    • TutorialApplication.cpp

There is also a dist folder.

You see, it contains a CMakeLists.txt, so the build is (should be!) pretty straightforward. Well, not on Ubuntu…but I’m assuming we’re not using Ubuntu from this point, so, just create your build directory, cd into it, cmake .. and make.

Now, you’ll have to copy (manually) the OgreApp executable into the dist folder. This build system could be better, but…okay. Just do it. And it should work. Unless you’re using a virtual machine: this can cause problems if you forget to enable 3d acceleration. You have been warned.

Oh, just a little warning. See the plugins.cfg config file. You should probably change /usr/local/lib/OGRE to /usr/lib/OGRE.

Basic Example 1

You should get it from here. Now what? Manual work: uncompress it, move its files to a ‘basic1’ directory, and copy CMakeLists.txt and dist/ from the previous example to ‘basic1’.

Then you will have do copy and paste the code from the wiki to TutorialApplication::CreateScene on TutorialApplication.cpp. Done? Now build as usual, and copy the OgreApp executable to the dist/bin directory. And we’re done.

PS. It is likely I’ll write another post about Ogre.

Footnotes

[1]: Not really…a little? This must be a joke. Note: cmake wasn’t the problem, since I had experience with it. I think the problem is the documentation. Ogre’s wiki is way too scattered. There should be a single entry point on “getting started with ogre”, but there are several ones. A typical beginner (=me) will struggle to decide which one to begin with. Worse yet: documentation outside the ogre3d website is way too poor. Discussion forums, reddit, blog posts…no, all the ones that I’ve found are either inactive, old or poor. But now you know that: please don’t make the same mistakes I did.

[2]: Bias: I like (correction, love) both Arch and Gentoo.

[3]: PPAs? Please just don’t use them.

Getting started with Ogre3d

C++ man pages

Today I stumbled upon across a project called cppman 1, which I believe has a very suggestive name indeed.

Manual pages for the C programming language are almost always available on Unix systems. Don’t you remember the signature of the qsort function? No problem, a man 3 qsort will refresh your memory. What about printf? What about stdlib.h? Man won’t disappoint you.

However, what about C++ man pages? I first discovered that they weren’t available by default about three years ago. Okay, so what do I do? A simple google search will probably lead you to Stack Overflow2.

At the aforementioned time, there weren’t really useful answers in there. Okay, some of them pointed out to libstd++ docs, but using them wasn’t much convenient. The best documentation sources you could find were cplusplus.com and cppreference wiki3.

You can live with these on-line references, but you will quickly get bored with them. Now, back to cppman, the boredom killer and time saver.

cppman – quick reference

Installing it

  • If you’re an user of Arch Linux, it is available in the AUR at the time I’m writing this post.
  • Otherwise, you can install it using python’s pip – ya know, pip install cppman.

It doesn’t really matter the method you choose, just make sure to add it to your PATH.

Using it

cppman sort
cppman map

Don’t cry, it is real. You can optionally cache all of its man pages, but I don’t find this strictly necessary for me. The default option (no cache) downloads manual pages on-demand.

Oh, it uses vim as its default pager, so you can search for keywords with /.

Also, hyperlinks are everywhere, so you can use K or C-] to follow them. To go back, use C-t.

By the way, it is compatible with man, so if you decide to cache its man pages, you can view them later with man (instead of cppman).

Happy hacking reading!4

Footnotes:

1

cppman – you don’t need to read the whole article; if you’re in a hurry, just open the project page and forget me!

2

As always, huh? Link.

3

The last one is by far much better maintained.

4

Wait, since when reading manual pages is a source of happiness?

C++ man pages

Tmux: a gentle introduction

Proposal: there are plenty of tutorials and insights about tmux out there on the web, so a simple web search will spawn many and many links. This post isn’t another tutorial. Instead, I’m listing four purposes of why you should use tmux.

Sensasionalist and alternative title: “Tmux: 4 reasons you’ll love it”. But…c’mon. I’m not here to convince you to use any tool; just read and create your own judgement about it.

Okay, tmux

Observation: You should probably install and open tmux to follow this mini tutorial. After executing tmux, you’ll probably notice nothing fancy happens: it just feels like opening a new terminal.

Purpose #1. Tmux is a terminal multiplexer. If you are used to open several windows of your favorite terminal emulator on X (my currently one is terminator; common examples also include gnome-terminal, xfce4-terminal and konsole; you probably have one of those installed on your system), you should probably stop that. Now.

Observation: <prefix> denotes your tmux prefix key. The default one is C-b, however it can be changed for your convenience – for example, vim users tend to dislike this setting, because C-b is a frequent used key on it (it scrolls one page up, like PageUp). C-a is a common alternative. My personal preference is C-b – even though this is annoying when using emacs, because I have to press it two times in a row to go back with the cursor (like <LEFT ARROWKEY>).

Here is how you open a new tab (which would be the equivalent of a new window on terminal emulators) on tmux: <prefix> c. No need to touch the mouse; no need to play with two windows.

Okay, and how do you switch between windows? <prefix> n to go to the next one and <prefix> p for the previous one. Fair? It looks like emacs in this sense.

Okay, what’s next? Multiplexing, of course! To create a new horizontal split, use <prefix> ". Is this intuitive? Probably not. However, I’m already used to it. Buuuut, if this bothers you, this can be changed – almost everything on tmux can be changed in its .tmux.conf config file. To create a new vertical split, use <prefix> %. I spend most of my time using vsplits rather than hsplits.

How do you switch between splits? <prefix> o.

Just this subset of keystrokes is sufficient boost your terminal productivity a little more.

Purpose #2. Tmux is an excellent pair programming tool. Suppose you want to share a terminal session with a friend. For starters, what is a terminal session? Think of it as an analogous to desktop sharing in the GUI world. However, it is more than a simple sharing: the observer user has full control over the terminal, just like you. It is like the observer (guest, as you wish) were in the same room as you, with access to the same keyboard as you (or, for that matter, access to another keyboard, attached to the same machine as yours).

Therefore, a terminal session is very suitable for:

(a) pair programming (b) remote support (from a technical person, for example)

So what? The first thing you should do is open tmux. Now, tell your friend to ssh into your machine (you should already know how ssh works…). Then, he just has to run tmux attach-session. This supposes you only have one session of tmux active at any moment. And that’s it. Notice that you can have several sessions of tmux; however, you’ll have to name them to keep them organized. This is topic for another day.

To quit from tmux, just execute exit or type Ctrl+D.

Purpose #3. tmux is very configurable and can be scripted to do almost anything concerning shell organization.

If you want to get started, here is my .tmux.conf file

I constructed it in the same way as my .emacs and .vimrc files: looking up documentation and inspecting several files from other people. The result is quite reasonable and with saner defaults. I encourage you to do the same, and create a .tmux.conf file for you by merging several other ones.

Purpose #4. tmux can be used as an “IDE” / programming workspace, and this becomes really easy (for example) with the use of tmuxinator.

The idea is to center all your workflow into one place: tmux. No need to swap windows. This is left as an exercise for the reader (readers don’t like that, huh?). You can begin by installing tmuxinator. Hint: it is available in the AUR.

Conclusion

Stop hitting alt-tab and using the mouse. Use tmux. But only if it would boost your productivity. Otherwise, stick to your own habits. That’s it.

Observation: what about GNU screen? I don’t know. You tell me. I haven’t tried it, because most sources I read and most people I know seem to prefer tmux over it, finding it more modern and powerful. I’m pretty satisfied with it, so no need for testing GNU screen right now. Maybe in the future; however, there are more interesting tools to try out at the moment. See you.

[Bonus purpose: detaching from a terminal, then re-attaching to it later. I’m not listing this one as a fifth purpose because I never found it really necessary. Maybe just for monitoring servers. However, there are better solutions for that]

Tmux: a gentle introduction

MatLab debootstrapping #1

Alternative title: ‘Matlab, second impressions’.

Those days I am trying to learn MatLab super fast for prototyping purposes. Now, a ‘super fast’ learning isn’t really my preferred style for approaching a new programming language (technology, for that matter). However, this is necessary at the moment, so let’s cut the chatter.

The sole reason for the existence of this post is: I would be creating some annotations anyway, so I thought: why not share them? Better than creating throwaway org files. So, disclaimer: this is not a tutorial. Really. Just a couple of notes. Information is not necessarily correct, so consume it at your own risk. So, let’s go.

MatLab Paradise

  • everything seems optimized for matrices and vectors. MatLab itself means ‘matrix laboratory’.
  • a number is treated as a 1×1 matrix. This is really interesting and has some nice implications and overall syntatic sugar.
  • a good PDF
  • matrix manupulation: A = [1,2,3] is a row vector; B = [1;2;3] is a column vector; C = [1,2;3,4] mix them together.
  • slicing: python style, but with another syntax. 1:10 means range(1,10) and 1:2:5 means range(1,5,2) – but matlab is inclusive (5 is present).
  • indexing vectors: A(1,2); A(2,1); pretty much what you’d expect. Beware: indexes begin from 1, not zero.
  • slow, slow, slow. See some benchmarks on the homepage of Julia language. I don’t know Julia at the moment, but I would be probably happier with Golang or Python.
  • you don’t really need Wolfram Alpha (or Mathematica, for that matter) if you know what to do with MatLab.
  • matlab -nodesktop for a command-line prompt. It is self contained, and you can still browse help pages with, for example, doc lu or help lu.
  • Introspection #1: whos. Know everything about your variables.
  • oh yes, talking about variables, the workspace view is really nice. In particular, I can save my variables later for dinner with save out.mat. And load them again with… load out.mat. Ouch!
  • some unix goodness is available. ls, cd, pwd, ls -l.
  • However, mkdir and rmdir.
  • Hello, world!: fprintf('string here') or display('hello, world!').
  • strings are enclosed with single, not double, quotes. Why, why??
  • functions: C/C++/Java style. f(a,b,c,d,e).
  • however, some functions have more than one return value. So what? Style: ret1,ret2 = f(a,b,c).
  • Too much junk on your screen? C-l or clc.
  • Beware! clear will delete your variables. clear var is more specific. clear all is even more destructive.
  • auto-completion with TAB. No C-Space.
  • Do you want more help? lu( then F1. Hints? C-F1.
  • C- is an emacs thing, yes.
  • Speaking about emacs, MatLab hotkeys seem optimized for emacs users. Don’t see it? C-y for yank (paste), C-k for kill (copy), C-a and C-e for navigation…even C-s for searching (not saving!) and C-_ for undo. I want my .emacs keybindings here!
  • open file.m. You don’t really need the fancy GUI.
  • delete file.m. Not rm.
  • comments with the percent sign (%). Why not hashes?
  • Do you have a matlab script (file.m) in a directory? Want to execute it? Then cd into it then write ‘file<CR>’ in your prompt.
  • version! R2014a == 8.3.0.x
  • C-c for long computations.
  • rand(2,2) if you ran out of creativity for numbers.
  • v = [1 2] equals v = [1,2]. Who needs commas?
  • element-wise operators are preceded with a dot. Example: .*.
  • I love intelligent prompts. C-p, M-p, C-n, M-n, <UP>, <DOWN>.
  • Do you miss your shell? system('echo Hello world!').
  • I hate files. What about you? fid = fopen('file.txt','w'); fprintf(fid,'...'); fclose(fid);

Introspection

  • which lu.m, which lu
  • edit lu.m, edit lu
  • Try with a non-built-in: edit ccode
  • help <so-what> –> spits output
  • doc <so-what> –> help browser
  • whos –> about your variables and symbols and functions
  • type <so-what>. For example, type ccode. More related to Windows than for discovering the type of your variable. In the last case, you better with whos. tl;dr Unix’s cat.
  • try double-clicking on a variable in your workspace
  • path

Internals. Functions, variables, types, control flow.

  • sum(a), min(a), max(a), median(a), var(a), prod(a), mean(a), size(a), mode(a), std(a)
  • false is an alias for 0. true is an alias for 1. Case sensitive!
  • isvector(a), isempty(a)
  • not is a tilde, not ! (C-style)
  • Matrix indexing: I want column 2: a(:,2); I want line 2: a(2,:).
  • inv(a)
  • find (a < 3) – hey John, it’s a filter!
  • 2^3 == 8
  • quick matrix generation: zeros, ones, eye, magic, rand.
  • Some math: cos(pi), sin(pi), tan(pi), tanh(pi).
  • More math: rad2deg(pi) == 180, deg2rad
  • det(m), rank(m), trace(m), a,b = lu(m)
  • if, elseif (together!), else, end. No parenthesis required.
  • for k=1:10; display('hey'); end
  • while
  • switch b; case 1; display('one'); end. No : after cases.

Symbolic math library/toolbox

  • syms x y z
  • a shorthand for x = sym('x')
  • x = sym('x', [2 1]) for a symbolic column vector
  • f = x + y^2 –> symbolic function
  • subs(f, [x y], [1 2]) –> eval
  • gradient(f), hessian(f), ccode(f) –> I love some magic!

Fancy stuff

  • diary on, diary off, help diary

This document has been created with Emacs 24 (orgmode, in particular). Yeah, although I’m migrating to vim those days, I’m still passionated about some aspects and features of Emacs.

A possible next post might include plots and/or some toolboxes.

MatLab debootstrapping #1

From Emacs to Vim – Chapter #1 – Vim plug-ins

This is the continuation of the first post.

As you get the feeling and overview of vim, the first thing you’ll probably miss [as an probable-soon-to-be-emacs-orphan (actually, not really, I’ve already told you I’m not going to abandon emacs – for example, this post is being written within it, with org2blog – (too many level of parenthesis, please help me!!))] are your customizations and custom plug-ins and extensions.

A couple of google searches would bring me to projects like janus and vim bootstrap. Those look nice and I would probably appreciate them if I were a beginner. However, as a super user – if you read this statement as bragging, then you are probably not understanding the purpose of this mini series –, I like to be in control of the personalization and settings of my text editor. Right? So, I’ve chosen to control my own plug-ins. In other words: bottom-up instead of top-down.

Now, the two state-of-the-art plug-in managers you’ll find out there to manage your vimscripts are vundle and pathogen. I began using Vundle, but after a few hours I realized that pathogen was KISS and superior. Period.

Not that Vundle is bad. It looks (works) okay too; in this case it was simply a matter of personal choice. The way Vundle works is as follows: your .vimrc will be populated with several lines such as:

Plugin 'tpope/vim-surround'
Plugin 'username-from-github/repository-name'
Plugin 'matchit'
Plugin 'vimscript-name-from-vim-dot-org'
Plugin 'git://www.absolute-path-to-my-site-here.com/repository-name.git'

Then, you just have to install those plug-ins with a simple command:

:PluginInstall

Done. It is simple, yes, but I liked more the approach of pathogen: you maintain a git repository with your plug-ins. Each new plug-in is a git submodule within your repository. Yay, this means it is super-easy to set up and share your plug-ins with other people. This is exactly what I’ve done: you can peek out my vim repository here.

Now, there is one super good advantage here over emacs. The cost of adding a new plug-in is practically zero. This has two meanings, actually:

  1. vim start-up time is ridiculously fast. Even with a dozen plug-ins, I still don’t notice it. With emacs, if I don’t run it as a daemon, it is a nightmare: a couple of seconds (yeah, a couple of seconds is really a nightmare, not kidding) of start-up time.
  2. I don’t even have to touch my .vimrc to add a new plug-in. I just have to clone a new repository into my $HOME/.vim/bundle folder. Period. With emacs, I have to continuously poke my .emacs file to add, remove and constantly tweak my extensions. Yeah, I’ve been doing that for a while, and it does provoke a lot of stress and anxiety. You already have to tolerate a little bit of RSI with emacs, so you don’t need more problems.

Now, don’t undermine my (our) dear Emacs! Emacs Lisp will (and will always be) superior to vimscript. I have no doubt of this fact and therefore I won’t even discuss it here. Emacs is much more extensible than vim.

Okay, then what? You have to find a few plug-ins, right? In Emacs, most plug-ins with decent quality you might find will be available either on MELPA or Marmalade and, of course, on GitHub too. In vim, it looks like the home of scripts is the vim website itself ((1) and (2)) and GitHub. I couldn’t find a central repo or website hosting the majority of its plug-ins, as with emacs. However, there is vim-awesome, which indexes existing ones (this concept is like the ruby toolbox, godoc.org and Emacs paradox extension by Bruce Connor.

I won’t discuss the plug-ins I’m using right now, however here is a snapshot of my $HOME/.vim/bundle directory at the time of this post (19 plug-ins, yay):

- YouCompleteMe
- ack.vim
- ag.vim
- ctrlp.vim
- delimitMate
- nerdtree
- syntastic
- tagbar
- vim-airline
- vim-bufferline
- vim-commentary
- vim-easytags
- vim-fugitive
- vim-gitgutter
- vim-markdown
- vim-misc
- vim-repeat
- vim-sensible
- vim-surround

Most of those have an emacs equivalent. Okay, I’m stopping here for now, until the next post 🙂

Update: next post.

From Emacs to Vim – Chapter #1 – Vim plug-ins