Notes on programming

To set up a static blog in Github Pages using the Racket package Frog, you need to do the following:

• download and install Racket (duh!)
• install Frog with raco:

$ raco install frog

• create a folder and initialize a Frog project there:

$ mkdir new-blog
$ cd new-blog
$ raco frog --init

• customize the .frogrc file. Set at least scheme/host to https://your-username.github.io, and title & author to whatever you want.

• add some content of your own:

$ raco frog -n "New post"
# ... output says something like:
~/new-blog/_src/posts/2016-10-03-new-post.md
# ... edit that file with your preferred editor ...
when you are finished editing, preview your glorious site with

$ raco frog -bp

• initialize an empty Git repository on the project folder, and tell git to ignore the Frog machinery and your source directory

$ git init .
$ cat << EOF > .gitignore
/.frog/
/.frogrc
/_src/
EOF

• commit everything, except for what we just ignored

$ git add .
$ git commit

• on github.com, create a new repository with the name your-username.github.io. Once created, add it as a remote to your local repo, and push your local master to it.

$ git remote add origin <your new repo>
$ git push -u origin master

• after some seconds, your new blog should be available as http://your-username.github.io

Now, each time that you want to add a new post, it’s just a matter of

$ raco frog -n "Another post"
# ... edit that post ...
$ raco frog -b
$ git add .
$ git commit -a
$ git push

The current Syntastic checker for Racket syntax in Vim is the racket executable itself. This means that the current buffer is executed by Racket whenever it is checked for syntax, and this can have unintended consequences, e.g. entering an infinite loop, if you happen to open the wrong file.

In order to just get the syntax errors, add this to your .vimrc:

let g:syntastic_racket_racket_args="--load"

It is always a nuisance to remember which files were you working on when you last exited your editing session. I have tried different approaches, including:

• leaving a test that does not succeed in order to get an errortrace that points to the next task I should tackle
• opening the editor inside a tmux or screen session, and therefore never ending the editing session

The last idea I had was to create a unfinished Git commit (called “Unfinished: The commit title”), and use Git to retrieve the name of the files that were touched in that commit. You can do it like this:

$ git log --pretty=format: --name-only -n 1

If you alias that command in your .gitconfig, e.g. to lastedited, you can then open the files in your editor by command subtitution:

$ vim $(git lastedited)

There are quite some posts out there that compare programming languages to something else, like religions, rock bands, types of women … There is a compilation of these over at Lambda the Ultimate.

One comparison that I find missing is that of programming languages to music genres (maybe the “Subcultures” post was simmilar, but it seems to be a dead link now). This is the more surprising since it looks like developers tend to argue about their favourite languages just like most people about music: everyone knows it is a highly subjective preference, but no-one escapes trying to convince others that they are not listening to the “right” music!

So, here is my (completely subjective) view on programming languages as music genres:

SVN

Python’s setuptools provide a simple mechanism to tag your built distributions with the SVN revision they belong to, by creating a setup.cfg file along the normal setup.py, and there write

[egg_info]
# Add svn revision to the file name
tag_svn_revision = 1

Git

How to do the same for Git? Or in general, with other information? (Date tagging is also supported by default).

Answer: modify directly the options dictionary in the call to setup, in setup.py. There, you can put anything you can compute with Python or system calls. E.g. for git:

import shlex
from subprocess import check_output

GIT_HEAD_REV = check_output(shlex.split('git rev-parse --short HEAD')).strip()


setup(
    # ... other keys like project name, version, etc ...
    options = dict(egg_info = dict(tag_build = "dev_" + GIT_HEAD_REV)),
)

With that setup, distributions (sdist or bdist) would be tagged with the string “dev” and the git hash of the latest commit:

$ bin/python setup.py sdist bdist_egg
$ ls dist
pyhello-0.1dev-92ffa06.tar.gz    pyhello-0.1dev_92ffa06-py2.7.egg

Whenever you want to build a stable release (without any “dev” tags), just set the key to empty in your setup.cfg, like this:

[egg_info]
tag_build =