Quickly setup powerline for bash in ubuntu

Powerline can do many things and it is very configurable.

I wrote a small script in case you just want to power-up your bash prompt and do it without a lot of manual steps.

This is what you will get:

Get it done!

Read the README file first, then:

(you may need to install git first, or just copy and paste the script somewhere from the repo… it will anyway install git)

git clone git@github.com:vincepii/ubuntu-powerline-bash.git
cd ubuntu-powerline-bash
./install.sh

Feel free to improve the script.

Repository on GitHub: https://github.com/vincepii/ubuntu-powerline-bash

Advertisements

Adding a new split functionality to konsole (multi-terminals)

The existing “Split-View” functionality in Konsole certainly has its rationale (http://dot.kde.org/2007/05/23/road-kde-4-konsole-gets-overhaul), but it is not the one I expect to use.

I am trying to implement a different split, which works similarly to the one found in Terminator.

A picture can explain it better than words:

Multi-Terminals in Konsole
Multi-Terminals in Konsole

The work-in-progress is at this “personal” konsole repository on gitHub, which I will keep aligned with the master, hoping that, once finished, it will be possible to integrate this implementation into the KDE repos.

Remember The Lens – Revamped

I want to start this post by thanking Pavel Shabardin as he created some new tickets on the GitHub page of Remember The Lens that caused new nice features to be brought to the project.

What’s new

  • Icons. I was willing to replace those ugly icons I made a while ago since a long time. I found some really nice ones on openclipart.org that gave the lens a new fresh look.
  • Preview. It is now possible to right-click on a task to get extra information.
  • Complete/Uncomplete tasks. On the preview screen, a button will appear to complete/uncomplete a task (depending on its current status). Very handy.
  • Show completed tasks. Because of that button above, it’s also good to show already completed tasks, so a “Complete” can be easily undone. A new “Show/Hide” section on the lens filters has a button for this.
  • Internationalization. The lens is now open to translations. I lost the Russian translation because I introduced new messages and changed existing ones. The Italian translation is of course there :).

Under the lens

Screenshots are more immediate than a video showing the lens at work (also, last time I wasn’t able to speak loud enough). Here are some.

Search and replace from command line

I usually do my find and replaces from within VIM or Eclipse (refactoring).

It may be useful to do it from the command line in case you don’t want to (or cannot) open your editor or if you need to work on a larger set of files (e.g.: scripts, meta-languages that Eclipse won’t refactor, etc).

The following command will recursively find all the *.cpp, *.h and *.c files starting from the current directory and change every occurrence of the pattern (in this case just a string) “createAndSet” with “init” (IMPORTANT: read the WARNING notice below before using the command):

find . -name *.c -o -name *.cpp -o -name *.h | xargs sed -i.bak 's/createAndSet/init/g'

The -i option tells sed to edit files in place and the optional parameter “.bak” tells sed to create backup files with a “.bak” suffix. By removing the “-i” option, sed will just output the result to stdout.

Warning

Use the command above judiciously, it may be disruptive and change your code in ways you do not expect.

Sed will replace every occurrence of a regular expression. If you want to change every occurrence of the string “int” to “long int” and you try to use the substitution “s/int/long int/g“, then every occurrence of a “printf” call will become “prlong intf”.

Test the regular expressions and observe their effect by calling sed in “dry run” mode, without the “-i” option (no in-place editing).

I cannot be responsible for any damage caused by the usage of the above command or a similar one :)!

Setting up a personal git repository: end-to-end tutorial

Recently I was in France with a colleague at an event organized by ETSI. In that occasion we needed to work on some code, but for some reasons we couldn’t use the company remote repositories.

Manually merging changes to a local copy we had was a time consuming and inefficient task, so I quickly set up a git repository on my machine that my colleague could access through the local network. Having a reference to do that operation in a short time may be very useful in situations similar to that one, but version tracking may be essential as well when working on personal projects or sketching code for new ideas. Setting up a git server is also a good idea to recycle some old hardware (I used to have an old notebook which worked as a printing server and git repository on my home network).

The following tutorial summarizes the steps required to setup a SSH server, use RSA keys, authorize users, and create a new git repository. This reference is first of all useful for me, but I hope that someone else will take advantage of this yet-another-git-setup-tutorial :).

Disclaimer

There are many different ways of setting up a git repository. This tutorial shows a possible way for doing this quickly. Do not use this tutorial to set up a git repository in a production environment, where every configuration parameter (e.g.: for the SSH server) must be finely tuned and well understood.

Intended audience and assumptions

If you need to setup a git repository for personal use or for some reasons you don’t want to use a cloud service such as github, then this guide may help you. The steps here described will allow for the quick setup and use of a git repository on top of a fresh installation of an Ubuntu GNU/Linux distribution (I am using Ubuntu 12.10).

I assume that a git repository is created on the local machine inside the home folder of a new “git” user. In a more general configuration, where the git client and server are remote machines, you will just need to replace the loopback 127.0.0.1 address with the one of the server.

Some basic knowledge of the Unix command line interface is required.

SSH Server configuration

The machine that will host the git repository needs to be accessed by clients. A possible way to access a machine remotely is through SSH.
SSH supports both password and public/private keys authentication. In this tutorial I will use RSA keys.

Install and configure an SSH server on the machine that will host the git repository:

sudo apt-get install openssh-server

Edit the /etc/ssh/sshd_config file to tweak the SSH server settings at your preference. I generally disable Password Authentication (you may need to uncomment the line) and Challenge Response Authentication:

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Start or restart the ssh daemon to accept the new configuration:

sudo /etc/init.d/ssh restart

Authorized Keys configuration

The public keys of the authorized entities who can login through ssh must be collected in the authorized_keys file under the ~/.ssh folder.

Create a git user on the machine that will host the repository (handle this as you prefer, it is not required to create a new user, but much cleaner):

sudo adduser git

Login as the git user, if you are on the same machine, just use

su git

to change to git user, then cd to the home directory

cd

Create a .ssh folder and set its permissions (see the ssh man (1) page for explanations on permissions of the .ssh folder and its content):

mkdir .ssh
chmod 700 .ssh

Create an authorized_keys file under the ~/.ssh folder and append to it the public keys of the authorized git users:

touch .ssh/authorized_keys

A possible way to populate the authorized_keys file, from a user on the same machine as the “git” user would be (appends the public key of the current user at the end of the authorized_keys file of the “git” user, command issued from the home directory):

sudo bash -c "cat .ssh/id_rsa.pub >> ../git/.ssh/authorized_keys"

Set the proper permissions for the authorized_keys file:

chmod 600 .ssh/authorized_keys

Create a new git repository

Install git (if needed):

sudo apt-get install git

Initialize an empty git repository (I assume repositories are created in the home folder of the git user):

mkdir test_repo.git
cd test_repo.git
git init --bare

The server configuration is done.

Setup RSA keys on the client

The remaining part of the tutorial refers to operations to be done on the client who wants to access the git repository that we have prepared. In order to use the Secure SHell connection, the client needs a pair of public/private keys.

If you already have RSA keys, put them in ~/.ssh, otherwise you can create a new pair with:

ssh-keygen -t rsa -C "Comment Here (usually your email)"

Move the pair of generated keys (id_rsa and id_rsa.pub) into ~/.ssh
See the FILES section of the SSH man (1) page to set the proper permission to the ~/.ssh folder and its content. In a typical configuration, you may want to use:

chmod 700 .ssh/
chmod 400 .ssh/id_rsa
chmod 400 .ssh/id_rsa.pub

Clone the git repository

Set the git user global configuration:

git config --global user.name "Your Name"
git config --global user.email you@example.com

Create a new folder where you want to clone the repository, cd into that folder and initialize git:

mkdir foo
cd foo
git init

Configure the git client to access the test_repo.git repository (add the pointer to a remote called origin):

git remote add origin ssh://git@127.0.0.1/~/test_repo.git

Clone the repository (if someone has already committed some changes):

git clone ssh://git@127.0.0.1/~/test_repo.git

Create a new file and upload to the repository:

echo "Hello" > readme.txt
git add readme.txt
git commit -m "First commit"

Push the committed changes to the master branch:

git push origin master

Done.

Great vim quick reference card

There are some Vim commands or keystrokes which I don’t use often and also some useful ones which I tend to ignore or forget.

For example I never do movements with combinations of (), [] and {}, even if some of them would allow me to move through source code in a real hurry!

I have my own text file with some “must-remember” commands, mostly related to my own bindings and plugins, but I just found an impressively complete Vim reference card, which is going to be stuck up over my desk at the office.

The card has been made by Laurent Grégoire, with some community contributions and can be found on Laurent website here: http://tnerual.eriogerg.free.fr/vim.html.

This is the direct link for the English PDF.

Other formats and languages are available on the website.

C++ Simulator for the Monthy Hall Game

Suppose you’re on a game show, and you’re given the choice of three doors: Behind one door is a car; behind the others, goats. You pick a door, say No. 1 [but the door is not opened], and the host, who knows what’s behind the doors, opens another door, say No. 3, which has a goat. He then says to you, “Do you want to pick door No. 2?” Is it to your advantage to switch your choice?

[From Wikipedia]

Introduction

The game is simple: first the player chooses a door, than the host opens one of the remaining doors which has a goat behind it, then the player is offered the chance to change door. At the end, the last door the player chose is opened and the hidden object is the player’s prize. The player’s objective is to open the door that hides the car.

To understand the gist of the game, whether it should be better to change the door or to keep the previously selected one, consider this simple explanation.

If you want to change door, then you will win if your first choice was a goat-door.
If you don’t want to change door, then you will win if your first choice was the car-door.

At the beginning, you can pick a goat-door with a probability of 2/3 (66%).
At the beginning, you can pick a car-door with a probability of 1/3 (33%).

If you decide to change door, you will win with a probability of 2/3.
If you decide not to change door, you will win with a probability of 1/3.

Well, this is the game, then it comes the simulator.

The Simulator

Code here: https://github.com/vincepii/MontyHallSimulator

I was watching the football match between Portugal and Czech Republic and getting bored.
My brother proposed me to implement a model to simulate the Monty Hall problem, and that was a great idea.

While I was at coding, I decided that it was more interesting to develop a full emulator of the game, rather than a tiny mathematical simulation model, and this is what I did. Nevertheless, the emulator performs well also for simulations (10,000,000 runs of the game in less than 7 seconds on my notebook).

If you want to try it, or take a look at the code, you can find it on GitHub.

If you are only interested in some results, this is what happens when running 10,000,000 cycles:

vince@vince-VPCSB1C5E:~$ montyhallsimulator --cycles 10000000

Number of games (total): 10000000
Number of times the player changed doors: 5002849
Games result (WON/TOTAL): 5003182/10000000 (50.0318%)
Winning rate when changing door: 3336568/5002849 (66.6934%)
Winning rate when NOT changing door: 1666614/4997151 (33.3513%)

It is funnier to see what happens every game, using the verbose mode:

vince@vince-VPCSB1C5E:~$ montyhallsimulator --cycles 1 --verbose

The player Chose door number 2
The host Chose door number 1
The Player Changed its door and picked door number 0
The Player Won the game, car behind door number 0

The simulator also works with more than three doors, applying the same rules. This could be interesting for statistical analysis.

For the complete list of options, just type – -help:

vince@vince-VPCSB1C5E:~$ montyhallsimulator --help
Program options:
  --help                Help message
  --doors arg (=3)      Number of doors (default: 3)
  --cycles arg (=1)     Number of runs of the game (default: 1)
  --verbose             Verbose mode, prints player and host actions (default: 
                        false)

Technicalities

The Pseudo-Random-Number-Generator that the simulator uses is the boost::mt19937, initialized with a time-dependent seed.

In order to test different PRNGs easily, the generator has been encapsulated inside an Adapter class and instantiated with a Singleton to ensure that always the same generator with the same seed is used across a simulation.

I have used the boost::program_options library for options parsing. If downloading the run-time libraries (e.g.: libboost-program-options-dev package under Ubuntu) is a problem for you, the main.cpp file can be easily edited to manually assign values to the doors, cycles, and verbose variables. Then the code for options handling can be removed.

I’ve used the CMake build system to create Makefiles for the code. That’s another requirement.