Stuff in my vimrc: 04 Spelling and Natural Language

I use vim for almost everything I write, regardless of that being a program, data file, email, blog post, research paper, etc. To write such things I need to use natural languages such as English. A blog post or documentation, for example, will be almost entirely in English. A program, while being a very different form of text, will still have variable names, comments, and so on, in English.

The thing is… Natural language is hard to spell, and I tend to make a few more typos then I would like. (I’m sure you will find some example in my blog posts).

Luckily, Vim comes with a built in spell check feature that works very well! In particular, it can do spell check in certain sections of code files. For example, while editing a Python file, it will do spell check in comments and identifier names. It will even spell check the individual words in an underscored identifier such_as_this.

Vim will also give the user correction options by pressing z=.

Like this, while using Vim, I can have a very high degree of certainty that what I’m writing is correctly spelled.

Basics In Vim

To get the basics working is pretty easy. To enable spell check we use the following command:

:set spell

We can set a language by using the command:

:set spelllang=en

Or, just join both:

:set spell spelllang=en

If all you want if to have English spell check enabled at startup, them simple place that last command in your vimrc, and your done. You might want to, at some point, change the language or turn off spell check, and when that happens, simple run these commands:

:set spelllang=pt
:set nospell

Off course, we can go a bit further then that. But first, I must speak about my usage of language in Vim.

My Natural Languages

The vast majority of time that I use Vim, I use it to write in English. But sometimes I want to write a text in another language, those languages being my native Portuguese or the language which I’m currently learning, German.

Because I use these three languages, it is very common that I open a new vim instance and want to quickly change the current spell checked languages from the default English to either Portuguese or German. So I’ve implemented a state machine that lets me alternate from English, to Portuguese, to German, back to English. The alternation happens when I press <leader>a.

It is also common for me to want to turn off spell check. This may happen because I might open some plain text file that may not contain an actual natural language text, or a language which I don’t use. It also may be that a given file type doesn’t have proper spell check like a Python file, so it happens that Vim identifies every ASCII character as a spelling mistake. To turn spell check off, and back on, I press <leader>s.

On The vimrc

This is the language section in the vimrc:

fu! InitLanguage()
    set spell spelllang=en
    let b:language = 0

fu! ToggleSpell()
    set spell!

" Function to toggle between the used languages
fu! ToggleLanguage()
    if b:language == 0
        set spelllang=pt
        let b:language = 1
    elseif b:language == 1
        set spelllang=de
        let b:language = 2
        set spelllang=en
        let b:language = 0

" Initialize language variables for every new buffer
autocmd BufWinEnter,FileType * :call InitLanguage()

" Toggle between the languages, or just toggle the spell functionality
nnoremap <silent> <leader>a :call ToggleLanguage()<CR>
nnoremap <silent> <leader>s :call ToggleSpell()<CR>

" Underline spelling mistakes
hi clear SpellBad
hi SpellBad cterm=underline

" Remove spell check from some files
autocmd BufEnter *.sql :set nospell
autocmd BufEnter *.erl :set nospell
autocmd BufEnter *.asm :set nospell
autocmd BufEnter *.s :set nospell
autocmd BufEnter *.go :set nospell

Functions and State Machine

To begin with, we define the functions InitLanguage, ToggleSpell, and ToggleLanguage. The first function simply sets spell check using the single liner like stated before and initializes the state machine. The second function toggles the value of the spell setting. So every time this is called, spell check either turns off or on. The third function alternated the three states of the state machine, making spell check go from EN, to PT, to DE, back to EN.

The state is kept by the variable b:language. It is a buffer variable (the leading b: indicates that). This because spell checking is kept at a buffer level, meaning that, different files in vim might be set to different spell checking languages.

Initialize Language

Continuing in the vimrc, we have the auto command:

" Initialize language variables for every new buffer
autocmd BufWinEnter,FileType * :call InitLanguage()

This makes Vim set our default spell check and initialize our state machine by running the init function. The function executes when a buffer is displayed in a window or when the file type for that buffer changes.

Key Binds

Next, we set the already mention key binds. They are <leader>a and <leader>s. Both are key binds for normal mode only:

" Toggle between the languages, or just toggle the spell functionality
nnoremap <silent> <leader>a :call ToggleLanguage()<CR>
nnoremap <silent> <leader>s :call ToggleSpell()<CR>


To display the actual errors, we need to tell vim to underline them using the following lines:

" Underline spelling mistakes
hi clear SpellBad
hi SpellBad cterm=underline

I only need this because there is a plugin that interferes with spelling underlining. Without these lines in my file, I don’t see spelling errors underlined.

Remove Spell Check For Certain File Types

With some file types, I prefer to simply have spell check off by default. This might happen because the spell checking in those files might not be good enough, or not exist at all.

To do this, I have the following auto commands

" Remove spell check from some files
autocmd BufEnter *.sql :set nospell
autocmd BufEnter *.erl :set nospell
autocmd BufEnter *.asm :set nospell
autocmd BufEnter *.s :set nospell
autocmd BufEnter *.go :set nospell

In order, we have files of types: SQL, Erlang, Assembly, Assembly* again, and Go. With Erlang and Assembly, the native syntax support does not distinguish what should be spell checked and what should not, so opening a file with spell check on will lead to having everything marked as an error.

With SQL and Go, spell checking works, but it happens that I see far to much code written in camel case, or having identifier names that are not regular words and are instead abbreviations. Because of this, a file in SQL or Go will be marked with many spelling errors, even if they are not technically an error.

Beside, I can simply do <leader>s to turn on spell checking to see if a comment, for example, is correctly written, and turn the thing off again to continue working.

(* By Assembly files with extensions .asm and .s, I mean programs written for the x86 instruction set using the AT&T syntax, since that was what I used when writing Assembly)


This is how I use spell checking in Vim. There are other native shortcuts that allow a user to jump to the next/previous error. I actually never use these, so I don’t even remember them.

<- Prev – 03 Folds and why I don’t use them

Stuff in my vimrc: 03 Folds and why I don’t use them

Part three is going to be a bit different. Initially, this part was suppose to be about Vim Folds and about what I have in my vimrc to handle them. But there isn’t much related with folds in my file, and I don’t usually use them in my workflow. Because of this I though about skipping this part entirely.

But then it hit me, rather then skipping, why don’t I simply talk about why I don’t use them and what I do instead to orientate myself in a big file of code?

What Folds Are

In any project, you’ll find files which have a few dozens of functions, classes, structures, etc. It is not easy to get a mental overview of such files, since you have to scroll though several lines of code, sometimes passing by functions or classes which have over 100 lines of code, 7 levels of indentation, and obscure names.

Off course, one can always argue that if a file as such structures, then the code might need to be refactored. Be that as it may, such files are out there, and we have to maintain them.

A very common way to get such an overview is to fold the code, like in this image:

This is folds.c file in the Vim code that implements this feature. In it, all of the code of the functions is folded away and we only see their names and order within the file. We quickly get an overview of the content with little to no scrolling.

Such folding features are present in most (if not all) IDEs and in many editors. Vim has folding out of the box. It comes with a variety of key binds based on using the z key to open and close folds, and like in anything else, you need to specify a few settings before being able to use it.

To enable folding, I have the following:

let c_no_comment_fold = 1

" Function to start using folds, but only when I want
fu! StartFolds()
    set foldnestmax=1     " Only fold one level
    set foldmethod=indent " Use syntax to determine where to fold

nnoremap <silent> <leader>z :call StartFolds()<CR>

There is a constant declarations, a function, and a custom key bind.

The constant c_no_comment_fold is there to make Vim not fold C-like comment blocks. These are blocks like so:

 * This is a C comment block

Such syntax is present in languages such as C, C++, C#, Go, Java, CSS, and so many many others. It just so happens that when I have folded code, I simply like to have the comments still present. This is because if I’m folding, then that is because I’m trying to understand the code in a file, and having any comments helping me with that task is important.

So having a bulk of code away of view is important until I decide to open it explicitly. But having a comment block is always important.

Next, the function StartFolds. This function only executes when I press the custom key bind defined right bellow <leader>z. This function simply sets the two variables:

set foldnestmax=1     " Only fold one level
set foldmethod=indent " Use syntax to determine where to fold

About foldnestmax. Vim can fold in many levels of indentation. Think for example that you can fold a whole function, an if block inside a function, an if block inside another if block, and so on. I decided that it is enough to fold only one level, so I set that option.

About foldmethod. Vim can fold according to many rules. For example, it is possible to set manual markers between two lines, and have Vim fold in those lines. It is also possible to let Vim fold according to the current syntax. I have it set to indent. Like this, Vim picks indentation blocks to fold.

My current setup could be improved by having a function to disable folding. And now that I’m writing this post I’m starting to think that I would like to try having manual markers…

Tag Bar as Alternative

The key issue is getting orientated in a big file and knowing what is declared in it. I like to use a tags bar:

A bar such as this gives me the necessary overview. I can sort the bar according to different rules, scroll it, and select one item to have my view jump directly to the element in the file. Because this is jumping, I can also use the Go Back feature builtin in Vim. Basically, every time you jump within a file or to another file in Vim, it creates an internal stack of locations. You can then traverse that stack backwards to get back to a previous location.

I have a simple key bind to show or hide the bar which is <leader>t. I usually only bring the bar up when I have a single file in view, or at most a vertical split. Anything else and the screen becomes to cluttered.

The content of the tags bar is filled according to the tag information of Vim. I use the plugin You Complete Me that fills that tag information. Off course, any tag information will always depend on how the support for tagging that a language as. So when working with a common programming language, you will most probably have tag information.

In future posts, I’ll talk about semantic completion and the usage of these plugins in more detail.

<- Prev – 02 File ExtentionsNext – 04 Spelling and Natural Language ->

Stuff in my vimrc: 02 File Extensions

In my previous post I wrote about the general settings in my vimrc. I continue to explore my file, hosted here. In this post, I’ll be talking about File Extensions.

File Extensions

When editing a file in Vim, you can choose which is its file type. Knowing the file type, Vim can load the correct syntax highlighting, and in some cases certain functionalities of plugins may be activated and used.

To have syntax highlighting, you need this setting:

syntax enable

After this, Vim will set the file type for any opened file automatically. So if you open a Python file, Vim will set the type to python, a JavaScript file will be javascript, and so on.

The user can always change the current file type to anything else. A common case is setting the file type to plaintext, which causes language specific syntax highlighting to go away but doesn’t shutdown the highlighting for other opened files:

set ft=plaintext

File Extension Conflicts

Sometimes, a file may be opened in Vim, but the file type is interpreted incorrectly. In this case we have to set the correct type by hand.

Take the example of opening a Prolog file. The file extension of Prolog is .pl. However, the extension for a Perl file is also .pl. So when a .pl file is open, regardless of it being a Prolog or Perl program, Vim assumes the Perl file type.

Vim assumes Perl simply because it is much more famous and highly used then Prolog. But for me personally, Prolog is more important. This is because I’ve made some development in Prolog in the passed, and have never actually used Perl for anything.

So every time I want to edit a Prolog file I would have to write:

set ft=prolog

But this would be extremely cumbersome to do. So I add an automatic command that executes every time a buffer which name ends in .pl is created or read. That line looks like this:

autocmd BufNewFile,BufRead *.pl :set ft=prolog

The command is autocmd, which is executed on the events BufNewFile or BufRead, for buffers which end in .pl. The automatic command which is executed is exactly what we saw before:

set ft=prolog

Like this, Vim assumes file type Prolog for any .pl file which I open.

File Extensions in my

At the time of writing, this section of my vimrc looks like this:

" Make .pl files load like Prolog and not like Perl
autocmd BufNewFile,BufRead *.pl :set ft=prolog

" Make .tex files load like tex files.
autocmd BufNewFile,BufRead *.tex :set ft=tex

" Make .md files load like Markdown files.
autocmd BufNewFile,BufRead *.md :set ft=markdown

" Make .rl file load as Go
autocmd BufNewFile,BufRead *.rl :set ft=go

" Make Emakefile files load like Erlang files.
autocmd BufNewFile,BufRead Emakefile :set ft=erlang

" Make ejs file load as HTML
autocmd BufNewFile,BufRead *.ejs :set ft=html

" Make .docker files load as Dockefile
autocmd BufNewFile,BufRead Dockerfile.* :set ft=dockerfile
autocmd BufNewFile,BufRead *.docker :set ft=dockerfile

Without these rules, .tex files would open as plaintext instead of LaTeX, and .md would also open as plain text instead of Markdown, although in recent versions of vim, they already open as Markdown out of the box.

The other rules I have are for specific library file types. We have the .rl files which are from a Go library called Ragel. This library is used to make Flex typed Lexers (to build parsers or compilers). I never actually used this library in a big project, but I’ve made experiments with it. Despite having a specific file name, the code contained in a Ragel file is Go, so my Vim will open these files as Go files.

I’ve made some experiments with Erlang, and I like the language quite a lot. The Emakefile is a specific type of Makefile to compile an Erlang program to the Beam Virtual Machine. Like Ragel, the code in these files is simply Erlang, hence the rule.

In a personal project I’ve made two years ago, I’ve used ejs, Embedded JavaScript Templating. This is a Node.js templating library which I used to generate static HTML pages for a simple web application. The library is very similar to other templating libraries, such as Django Templates, Go Temples, Java Spring Templates, and others.

I want to see the ejs files as HTML, despite the fact that some of its code (the actual template code) is JavaScript. When I worked with this, there was no way of having syntax highlighting for HTML and JavaScript at the same time in an ejs files, but since the templating part was so simple, it was also not needed.

Finally, the last part of this section is about Docker files. I’ve seen and worked on many projects that used files with names starting with Dockerfile. and others ending with .docker. I naturally have rules to make these files open with the file type Dockerfile.

<- Prev – 01 General Options | Next – 03 Folds and why I don’t use them ->

Stuff in my vimrc: 01 General Options

Vim has been one of the most important tools in my toolbox. Since 2013, it has been the editor I’ve used for everything. From developing projects in Python, Node, Go, C, to writing my Master’s Degree Thesis, and this Blog Post.

Customization is quite common when using Vim. We want different key binds and features, and it is through these key binds and features that we adapt and develop our own Workflow.

Vim Customization comes mostly by writing a vimrc file. In this series of blog post, I will talk about stuff I have in my vimrc file.

My vimrc file is hosted in here.


A vimrc file is usually developed overtime by the person who uses it. People sometimes take ideas from other people’s vimrc, but one should never copy a whole file.

My file is not particularly big. I have the following structure to it:

  • Plugins
  • General Options
  • File Extensions
  • Folds
  • Language
  • Highlight Unwanted Spaces
  • Maps and Keybinds
  • Plugin Specific Options

I’ll make a post for each of these points or for specific details within the points. I’ll start by the General Options section of the file. I’ll talk about the Plugins later.

General Options

The General Options have the most basic kind of settings. When I’m using an instance of Vim which doesn’t have any configuration, for example in a server, I usually some of this setting directly on the command line.

I’ll be talking about my choice of options in no particular order.


I like to have a background highlight in the line where the cursor is located. This line is present in every windows which is showing in a particular tab, so if I have the screen split to display multiple files, of many locations in the same file, the cursor line will still be highlighted, even if the cursor is not currently on that window.

Off course the lines are also numbered. I use the regular numbering as opposed to the relative numbering, since I could never get used to the regular numbering.

For these things, I use the following options:

set cursorline
set number

Tab Completion

Not to be confused with semantic completion, this is about how the tab completion for the vim command line works. I have a lot to say about semantic completion, but that is not in the scope of this particular blog post.

Out of the box, the completion of the vim command line works like this. Suppose you want to open a file called So you write :e log and now you would press tab to autocomplete to :e But instead, you get :e

This is because vim will pick the first alphabetical option from a pool of options and present it for autocompletion. If you press tab again, you would get the next option, and tab again, you get the next, and so on.

I prefer to see the list of options first, and then start tabbing over the options until the one I want. Inside the editor, be that to pick files or commands, this just seems to make more sense to me. So I use these options:

set wildmode=longest,list,full
set wildmenu


When you split the current window either horizontally or vertically to see different sections of a file, or another file, that is called… well, a split.

You can issue a command to split the current window and open a file in the split at the same time. The thing is, by default, vim splits the window and the new file will be on top or on the left, depending if the split if horizontal or vertical respectfully.

I prefer the opposite behavior. So, I can issue the command split newfile, and the new file will open in the split on the bottom. Same with vsplit newfile which opens the file in the split to the right.

I have these settings for this:

set splitbelow
set splitright

Backup Copy

In many projects, you have a workflow which works like this: The project is running, you change a file, something auto compiles your changed files, the project restarts or reloads, and you see the results of your changes right away. You see this, for example in Django projects, where the runserver reloads and restarts the server upon a file change, or in an Angular project, where the files are compiled, and the browser refreshes.

Sometimes, Vim doesn’t write the changes to disk right away, or only the .swp is written. When this happens, the autoload features simply don’t work, because no file change could be detected.

To avoid this, I have this option which guaranties that the files are always written to disk when I issue the save command:

set backupcopy=yes


I use spaces. Specifically, an indent block for me is four spaces. Unless a project requires tabs or a different indent block, I keep these settings.

I change the tab key to write an indent block instead of a tab character. Some file types, like Makefile, will ignore this behaviour since Makefiles actually need a tab character.

I also make it so a backspace over indent sections of the line deletes the whole block and not the individual spaces that make that block up. Lastly, in many languages, when I press return after an opened braked or after a colon, a new indent block is placed.

set shiftwidth=4 softtabstop=4
set tabstop=4
set expandtab
set backspace=indent,eol,start

Colors and Themes

I like light themes as opposed to dark themes. I also like the Solarized theme. I’ve been using Solarized Light for many years now, and don’t plan on changing it.

I use a Vim plugin to have the Solarized theme available and I set it as my theme with these commands:

set background=light
colorscheme solarized

So the theme is solarized, and the variant is light, as opposed to dark.

Next – 01 File Extensions ->

Compiling Vim

I’ve been using Vim since 2013. It is my main development tool for everything I do, both professionally and personally. I use it along a few plugins and I also add some costume commands, functions, and key binds to my vimrc file.

When I started using Vim I would simply install the vim-gnome package from the Debian repositories. But I like to keep up with the latest features, bug fixes, and improvements of the project. The easiest way to do so is to pull the latest version from the git repository, compile, and use it like that.

Here is what I do.

Get the Source

Vim is nowadays hosted at GitHub. The GitHub issues tracker is also used by the development team there, so if you are interested in contributing for Vim, this would be the place to go.

Since this is a Git repository, to begin we start by cloning the repository:

git clone

At this point you might want to checkout a specific tag for a specific version of Vim. According to the Ubuntu 18.04 Bionic Beaver package page, the distributed Vim version for that Ubuntu is v8.0.1453, so you can checkout that tag since we are sure it is stable.

I keep up with the latest version, which would be ahead of version v8.0.1453.


Once we have the source we need to install a few packages in our system in order to compile Vim.

sudo apt-get install \
    build-essential \
    libncurses5-dev \
    libgnome2-dev \
    libgnomeui-dev \
    libgtk2.0-dev \
    libatk1.0-dev \
    libbonoboui2-dev \
    libcairo2-dev \
    libx11-dev \
    libxpm-dev \
    libxt-dev \
    python-dev \
    python3-dev \
    ruby-dev \
    lua5.1 \
    lua5.1-dev \
    libperl-dev \

In the list of packages we have things like build-essential which contains gcc and related tools, the libncurses5-def package which is the library that Vim uses to use ncurses, a few interpreter for python, ruby, etc, and few other things.

All this is necessary for the Vim I used. The Vim installed by the Debian package, gnome-vim, has similar dependencies.


To build Vim and make it ready for usage, we run the three usual steps, which are configure, make, and make install. First, here is the configuration I use for my build:

./configure --with-features=huge \
            --enable-multibyte \
            --enable-rubyinterp=yes \
            --enable-python3interp=yes \
            --with-python3-config-dir=/usr/lib/python3.4/config-3.4m-x86_64-linux-gnu \
            --enable-perlinterp=yes \
            --enable-luainterp=yes \
            --with-x=yes \
            --enable-cscope \

First, we have the flag for features. This flag defaults to huge, but we still set it explicitly:


There is a very big number of features which can be set or unset with the different values this flag takes. A listing of them is in here. Personally, I just leave the huge to enable everything, since that is what the Debian packages also do.

The next flag is used to compile Vim with multibyte support. This means that Vim will be able to use (natural) languages that need more then one byte per character, like Japanese, Chinese, and so on. Read more about it here.

Even if you only write English, you should still set this flag:


Next we have the interpreter:


I enable the interpreters for Python, Ruby, Perl, and Lua. I also set a specific path for the python interpreter. Without it, Vim could not find it.

We compile Vim with the X Windows System. This enables Vim to use the X’s Clipboard. Without this feature, copy and pasting to and from Vim becomes cumbersome. So we add:


Vim comes with support for cscope built in. If you don’t know what cscope is read here. I don’t do much C development nowadays, but still, I like to have this around.


Vim installs a few files which it needs at runtime for various purposes. These include, for example, the Syntax files, which set the specific syntax highlighting for each language. They also include the (natural) language files, the files which specify the color themes, and many other things.

The directory where these files is installed is specify by the following flag:


The default value of this flag is actually /usr/local. I believe that the Debian package for vim-gnome sets this prefix to /usr/share/vim/vim{VERSION}, since that is where these files show up in my system.

Build and Install

After the configuration is done, we simply run make and make install:

make install

You should be able to run vim now.

If you have any issues, such as missing features like the system clipboard, or Vim not being able to use the Python interpreter, check if the configuration flags are correct and if that step succeeds without issues.

Any change to that requires a new execution of make and make install. Just in case, you should also run make clean before.

Experience at HackerX

On December 14th, I attended a HackerX event which was held at Beta-i, in Lisbon Portugal. This post details my experience.

What is HackerX

HackerX is a recruiting/networking event that works sort of like speed dating. The idea is to join companies and developers in one place for companies to spot potential recruiting candidates, and for developers to get to know and make contacts and get acquainted with the new trends.

For the actual event, each company sets up a table with interviewers while the candidates line up. Each candidate then sits with one company for a five minute interview. After those five minutes, the candidate needs to switch to the next company.

A candidate therefore get to talk with people from a company for five minutes, and that’s pretty much it.

The event is invite only, although I believe you can request an invitation or pay for one. The companies which will attend the event are only revealed hours before it, so you have little time to do any research on them.

The Event I Attended

An event like this will usually have a small number of companies and a big number of candidates. The event I attended had 7 companies and around 40 candidates. I didn’t know any of the companies from before the event.

That particular event was aimed for people who are into Full Stack Web Development and at least one year of experience in the area.

Going Through the Interviews

I was in a lucky position when people started lining up, so I was actually one of the first people to go through the interviews without having to wait. The interviews, despite being so short, were actually quite varied.

Some companies had only one person, while others had two or three. Some companies started the interview by presenting themselves and asking specific questions while others simple gave a small presentation and let the candidate talk about themselves.

In particular, one company had two interviewers. One was holding a phone with a timer while the other made a few questions. I got to answer a lot of questions, but didn’t ask any of them myself and didn’t get to know what they did.

Another company had one interviewer which clearly rather be anywhere else but there. He gave a quick introduction of his company. Asked me one question (which I actually don’t remember what it was), and that was it. We sat awkwardly for a few minutes while I failed to start any conversation.

In all other interviews the five minutes always felt to short, so it is important think about what you want to say about yourself and what questions do you want to ask. Most of the interviews end up with either you rushing a few last sentences or the interviewers quickly taking a few last notes about yourself.


I went to this event not actively looking for a job, but on the following day two companies contacted me to schedule interviews. A attended both and ended up getting a great offer from one of those companies. So I got my next job which, start April, from this event.

Aside from that, this event was a great way to get to know companies in the area. I got some cards and flyers and got to know the current trends in terms of used technologies. I strongly recommend anyone attending this event, even if you are not looking for a job.

January to March

This is a blog post about what I am up to, and what I’ve been doing since January and will do until the end of March. For some context:

Late 2016

In the last few months I quitted my job for three reasons:

  1. I wanted to finally finish my Masters Degree Thesis
  2. I wanted to get back into web development instead of what I was doing at the time
  3. I was dissatisfied with my overall professional situation

In late 2015 I had almost everything done needed to earn a Masters Degree except for the Thesis. At the time a seemly great job opportunity came along. Personally, I found this to be a perfect opportunity to develop myself in my chosen professional field, move to Lisbon (I had only worked “physically” at Évora at this point), and earn some money. For those reasons, and other necessities, I set my thesis aside and pursued a new job.

Fast forward to late 2016. I started becoming dissatisfied with my professional situation which prompted me to look for alternative paths to take. Naturally, I decided that I should finally complete my Degree and work on a Thesis. I contacted Professors at the University of Évora (where I study), and a theme was proposed. Still in late 2016 I started working on that theme during my free time.

January to April

With this project, I resigned my job where I still worked until the end of December and imposed a deadline of no later then April 2017 to finish the thesis. I imposed this deadline on myself mostly for financial reasons as this thesis has no grant.

The period from January to March was necessary to complete the thesis’ project, but also to learn a few new technologies to get back into Web Development.

I’ll write two dedicated posts about the thesis and about web development, but basically, the thesis is a project about Data Mining done to the University of Évora’s Moodle data. If falls under the Educational Data Mining, or EDM, field.

To get back into web development I intent on exploring Node.js, libraries and packages used in Node.js, and also explore the newer trends in design, architecture, workflow, etc, among other things.

HackerX and New Job

Still in late December I had already resigned my job and started my new thesis. I intended on starting to look for another job only at the end of March.

But I received an invitation for the HackerX event. I will write a dedicated post about that, but basically, I attended one such event and schedule interviews with two companies. At the beginning of January I ended up getting a new job as a result of this event. The new job only starts on April 3.

Right Now

First of all, I am extremely grateful for having gotten a job on the beginning of January that only starts on April because this gives me time and space to focus on my thesis and other projects without the stress of looking for work when March comes. It also gives me an extra incentive not to slack and finish things on time.

It’s February 10th as of the time of writing, and I have indeed been following what I set out to do on this period. I intent on writing more blog posts about the thesis and other personal projects that I have made.

Flex and Bison

What follows is the basic of the basics of flex and bison. This is intended to be a simple first approach to both tools, so don’t forget to RTFM.

Flex and Bison are two very cool tools that are used for two very straight forward tasks. This post gives a brief overview of a example of using the tools to build an interpreter of arithmetic expressions.

The code can be found on GitHub.


Flex is used to generate scanners (or tokenizes). A Scanner is program that reads an input usually in the form of a string and yields a list of tokens. Tokens are just atomic symbols which may then be use for anything.

Flex does this by taking a .l file and generating a few C functions which are then compiled to an object (`.o) file. Any other program can then take these generated functions to parse a stream of bytes (for example a string or the contents of a file) and returning a sequence of tokens.


Bison is used to generate parsers. More precisly, LALR(1) parsers, among other thigns. A LALR(1) parser is a program that decides if a given sequence of tokens conforms to the syntaxt specified by a given LALR(1) grammar.

Bison does this by taking a .y file and generating a few C functions which are then compuled to an object (`.o file. Any other program can then take these generated function to parse a sequence of tokens (for example the results of running a scanner generated by Flex) and retuning something! We’ll get into that later.

Flex and Bison

You’ve probably noticed how the previous two sections are very similar. That’s because both Flex and Bison are used in a pretty similar way. To start with lets look at some of the contents of a Flex file. We have two sections, separated by a line containing %%. First, the Regular Expressions:

INT_LIT [0-9]+

COMMENT “#”.*”\n”
IGNORE [ \t]

You can’t simpler then that. You have a regex which only recognizes natural numbers, a regex which recognizes anything that starts with a “#” symbol and ends with a new line. And a regex that recognizes spaces and tabs. You give them the names INT_LIT, COMMENT, and IGNORE, respectively.

Next, we have the rules. The rules have a left and right part. The left states what is the pattern (regex) to be recognized. The right is some C code which will execute when say pattern is recognized. For example:

yylval.literal = atoi(yytext);
return T_INT_LIT;

The variable yytext contains the string which was recognized. So, if the scanner sees an number 10, yytext will have the string “10”.

The Bison file will also have two sections separated by a line containing %%. First, we declare tokens, among other things, using lines like the following:


Then we declare the grammar, like the following:o

expr: expr T_PLUS expr { $$ = ExprBinary(plus_op, $1, $3); }
| expr T_SUB expr { $$ = ExprBinary(sub_op, $1, $3); }
| expr T_MULT expr { $$ = ExprBinary(mult_op, $1, $3); }
| expr T_DIV expr { $$ = ExprBinary(div_op, $1, $3); }
| expr T_INT_DIV expr { $$ = ExprBinary(int_div_op, $1, $3); }

| T_SUB expr %prec UMINUS { $$ = ExprUnary(uminus_op, $2); }

| T_PAR_O expr T_PAR_C { $$ = ExprUnary(par_op, $2); }
| T_INT_LIT { $$ = ExprLiteral($1); }

That code specifies that the non-terminal symbol expands to an expression plus an expression, or an expression minus an expression, and so on. Notice that as each rule is recognized, the C code inside the brackets is executed. In that code $$ means the value of the non-terminal head symbol of the rule (in this case the, left-most expr). The $1, $2, etc, symbols represent the various symbols in the right side of the rule.

Abstract Syntax Tree

The result of executing this example will be an Abstract Syntax Tree which represents the original program. The AST will have every information we’ve original inserted in our program with the difference that it will be easy for the machine to process, as opposed to being easy for the human to process.

The AST is, as the name implies, a tree. The tree is made up of different kinds of nodes, some are expressions, others are a whole program, etc. That tree can then be evaluated, meaning that if we gave a program like 10 + 20, the tree will evaluate to 30.

In this example, the tree is specified in ast.h/c. The evaluation is done in eval.h/c


The main function should give an overview of how this interpreter works. You can compile and use it with the following:

./test < input

And don’t forget. This is a very very easy example of Flex and Bison. Much can be said about these tools. RTFM.

Final Notes.

The return of the various malloc calls in this example are not verify DON’T DO THIS NEVER.

The example could be way simpler if the expressions were evaluated directly in the parser specification. Therefore we wouldn’t need an AST and we wouldn’t need to evaluate it.

Compiler From Simple Language to x86 in Erlang

GitHub Link for Project.

Recently I decided to learn both Erlang and x86 assembly. I needed both technologies for a thing unrelated to the project in this post.

I decided that a cool thing to do was to make a compiler from a toy programming language to x86. I like compilers, and writing a compiler in Erlang proved to be a simple task. Simpler then other projects I’ve made in C and C++.

The Compiled Language

I didn’t really put much effort into coming up with any original language. I just needed a simple language that allowed me to make some calculations. Because this project wasn’t focus on compiler design but rather in learning Erlang and x86, I decided that the language would only have one data type, integers, and very few other features. The final result is a language that looks like this:

# Initialize the numbers to calculate the sequence
n1 = 1;
n2 = 1;
i = 0;

while i < 10 [
    # Display the value of n2

    # Get next number
    t = n1;
    n1 = n2;
    n2 = n2 + t;

    i = i + 1;

That is the implementation for the Fibonacci sequence. The first few lines initialize the two variables to calculate the numbers in the sequence and a index i.

Inside the cycle, the value of n2 will be displayed, the next number is calculated, and i is incremented.

In this language functions look like this:

# A function is identified by its name and arguments number
def f(x): x*2;
def f(x, y): x*y;

f(10, 20);

def f(x): x*5; # Redefines f with 1 argument


They are identified by their name and the number of arguments, so f(x) and f(x, y) are different. Functions can also be redefined, like in the example, f(x) is redefined.

The language is simple, and I changed it a lot as I developed this compiler. But like I said, the objective was simply to have something to develop a compiler for.


I have a lot of experience with the lesser known Prolog. Prolog is an amazing language for many things, but not really used in many places. On the other hand, I actually know a lot a Haskell, but I don’t really like it for many reasons (which I won’t discuss now).

For me, Erlang is like taking the best of Prolog and the best of Haskell and joining those things into one language. Because of that, learning Erlang was not only easy but also enjoyable.

A great things about Erlang is its parallel computing capabilities. Sadly, this project doesn’t take advantage of any of that, so I won’t discuss it further.


While in college I learned the MIPS instruction set. I’ve developed a few considerable projects in MIPS that run in the Mars simulator. I’ve also studied the pipeline implementation for some MIPS processors, and developed a compiler that compiled to MIPS (from a language that was more complex then the one in this project).

Learning x86 didn’t take long because of my previous knowledge of MIPS. The instructions change, the registers also change, but many conventions are the same, or they follow similar ideas.

The Compiler

This project is just a small personal project. As such I didn’t really was much time in testing, documenting, distribution, etc. But I got it working fine.

The implementation uses two Erlang tools to build the scanner and parser. They are leex and yeec, respectively. They are similar to Flex and Bison for C. The rest is just Erlang.

not_so_blue v2.0

My Linux theme, not_so_blue, which I’ve talk about in this post, as worked out great! I like the solarized color scheme and the concky windows are really great and useful. Since the post I have naturally changed things a bit. Over the course of a few months, the changes I made were:

Dropped the hexadecimal text

The text itself just had some randomly typed message. I thought it looked cool, but after a while it just looks horrible. Plus, it gave the impression that it had some real time output, which it didn’t. I though about implementing something like that, but it would not be useful and it would just be another process running.

By dropping that I was able to add more concky windows.

Dropped the sine waves

The sine waves look cool, but I got tired of them. Plus, everyone thought they had animations when they saw the screens.

Again, I thought it would be cool to animate them somehow. Just have their frequency change with the processor usage or something like that. It would look great, but it would also be a bit ridiculous to have something requiring so much processing power for some eye candy thing.

More concky windows

The new concky windows are very useful and they look nice. The first one shows the processes currently running, which is a bit useful. I can quickly see what are the processes taking up most of the processor’s time without doing the top command.

The second window just displayed some information regarding the CPU, RAM, and SWAP. Again, very useful and nice looking.

The center window might look a bit redundant when considering that the same information already appears on the top bar. But it shows up differently and looks very cool. I know it is redundant, but I like it. Plus, it displayed temperature.

The fourth window is for networking information. The top bar only says if Wi-Fi is up or down. In here I have some more information which is both cool and useful. The same goes for wired connections.

The fifth window… Well I needed something. It’s funny like that.

New Wallpaper

The new wallpaper is just a maze. I a maze generator online. Generated some maze. Placed it on top of a singled colored wallpaper, rotated it, gave it a few colors.

So simple and so cool.


The rest is similar. The distro is still Ubuntu, now with version 14.04 LTS. The window manager is i3.

A few screens are here at the bottom of this post.

Check my GitHub containing the concky configurations.

clean dirty1 dirty2