Author Archive

apt-get: install software/packages in specific version

February 5, 2018 Leave a comment

Sometimes there is a need to install a specific version of software for it to be compatible to other software, already have certain bug fixed, or because we need specific features. And sometimes there are multiple versions of the software available in the repos of your Linux machine, which allows for selecting the version that you want to have instead of just installing the default version. With apt this is possible – however, be careful to not install incompatible versions of software that causes conflicts with other things on your machine.

We are now going to demonstrate installing a specific version of fish, the user friendly interactive shell. At the time of writing there is only version available in the Ubuntu 16.04.3 repositories, but we need at least version 2.3.x, as this is where fish became compatible to fzf, the fuzzy command-line finder (which is a very helpful tool btw). At the time of writing the latest version of fish in the Ubuntu PPA of fish 2.x is 2.7.x. We therefore at first need to add its PPA to make the version we need available to apt:

sudo apt-add-repository ppa:fish-shell/release-2
sudo apt-get update
sudo apt-get install fish

Now, to see all versions of the desired package available for installation on your machine with apt execute:

apt-cache madison fish

In our example we see:

fish | 2.7.0-1~xenial | xenial/main amd64 Packages
fish |    2.2.0-3 | xenial/universe amd64 Packages

We can also look at some more details with:

apt-cache policy fish

In our example we see:

  Installed: (none)
  Candidate: 2.7.0-1~xenial
  Version table:
     2.7.0-1~xenial 500
        500 xenial/main amd64 Packages
     2.2.0-3 500
        500 xenial/universe amd64 Packages
        100 /var/lib/dpkg/status

where 2.7.0-1~xenial is the exact identifier of the version we want to install for our scenario. We can now install this version using apt by setting the additional SW parameter:

sudo apt-get install SW=version

which in case of our example is:

sudo apt-get install fish=2.7.0-1~xenial


Redshift: protect your eyes during long nights in front of your PC

January 20, 2018 Leave a comment

For the night owls amongst us: looking at our screens during long night sessions – thereby at the whole spectrum of visible light from blue to red – means accepting a bunch of unhealthy drawbacks. For example: as the blue part of the spectrum of visible light is usually only visible during daytime our bodies have adapted to using it as a “clock” mechanism: while we see blue light we i.e. release hormones that keep us awake. That can e.g. make falling asleep more difficult/can cause insomnia when we have worked in front of a monitor for a couple of hours until late in the night. Therefore, besides dimming monitors (reduces the contrast to the dark surroundings), reducing the amount of blue light during night sessions and causing a tinge of red on our monitors is a good thing – not only for our eyes, but also for our bodies as a whole.

How to cause a redshift on your screen

Luckily for the night owls amongst us this problem has been recognized and addressed for different platforms already: for example, even many mobile phones provide for the functionality to redshift screen colors nowadays. For Linux, applications that do this job for us include redshift, openlux, and f.lux (the latter seems to be the original thing but is closed source). My current personal recommendation would be to use redshift, as it’s open source, included in the repositories of all major distributions, easy configurable, and does the job with a single command on your terminal. One word for the curious: from the technical perspective redshift relies on an X server extension to function.

Redshift logo

Redshift project logo

In terms of features redshift automatically adjusts screen colors to better match what the natural light would be – which would be caused by a sun that has probably already set hours ago, meaning there should be no blue light at all. redshift uses your location and time to adjust the screen colors. It provides for deriving the location automatically, but I personally like providing it by hand (see example below). Next to the location the second important setting is what you want your screen colors to be during daytime and nighttime (the color temperature in K to be exact). Both settings can be provided as parameters when calling redshift from the terminal:


For example, I use those color temperatures and coordinates (for the latter providing exact data is not as important as it might seem):

redshift -t 6500:3200 -l 48:14

One more hint: of course you can autostart redshift with i3 by adding this line to your ~/.i3/config/i3.config:

exec --no-startup-id redshift -t 6500:3200 -l 48:14


git-latexdiff errors? Workaround: using latexdiff manually allows fixing broken things

December 4, 2017 Leave a comment

In a previous post we have highlighted git-latexdiff, which visually highlights the changes between two versions of the same latex file managed with git – without you being required to checkout any versions of that file yourself. In certain cases git-latexdiff might terminate with errors instead of producing a visual diff file. For example, it might struggle with broken latex code, broken figures, certain usage of subfiles, etc. In such cases, it might help to manually do what git-latexdiff would do fully automatically for you. Here’s a simple step-by-step explanation of how you could achieve visual highlighting even with broken Latex files:

  • Have the repository R2 available, which contains the file F in the newer version you want compared. Copy the repository R2 to a different folder R1 (you could do this on other ways too, but with copying you can hardly mess things up). In the copied folder checkout the version of the repository which contains F in the older version you want compared. Therefore, R2 contains F in the new version and R1 contains F in the old version now.
  • You can now fix both versions of F  should they contain broken latex code. F essentially needs to compile in both R2 and R1.
  • If you run into troubles with figures (also in subsequent steps) it might be helpfull to add the “draft” parameter to the documentclass. This can be done in both F files or in the diff.tex generated later. It disables figures in the documents, which causes less problems later in case figures are part of what prevents latexdiff, pdflatex, or one of the other tex tools from doing their jobs. This might also the case if figures have both been added and removed, or if figure paths have changed between those versions.

After those preparations, in your terminal run the following command from somewhere outside both repositories:

latexdiff --append-safecmd=subfile R1/path/to/F R2/path/to/F --flatten > diff.tex

The option


makes the subfile command safe to use within the scope of the “\DIFadd” or “\DIFdel” commands, which latexdiff uses to mark differences between versions. The option


replaces “\input” and “\include” commands within body by the content of the files in their argument. This makes all content of the document appear in your highlighted diff in the end. If the latexdiff-command succesfully generated a diff.tex file, copy this file into R2 or R1, right next to where F is located. You should now be able to compile and show the pdf file:

pdflatex diff.tex && biber diff && pdflatex diff.tex && evince diff.pdf

Fixing even more problems

In case you run into errors during compilation using the method above you might be able to manipulate the diff.tex file. If this does not help and if you are just interested in differences in the plain text there is an even stronger workaround you can try: you can copy the important parts of the content of your main .tex files in both R1 and R2 into newly created – and therefore clean – dummy.tex files. The important part of the text will usually be textual paragraphs, and more importantly for big documents, includes of subfiles. The dummy.tex files need to be of the same document class (e.g. a book class document will need a clean book again to work).  Remember to do this in an identical way in both R1 and R2. Afterwards you can compare the dummy.tex files using latexdiff (instead of the original main files). Doing so can circumvent many different types of problems that might be introduced due to code in custom Latex .cls or .sty files that is either unsupported by latexdiff and/or is broken in some way.

git latexdiff usage: visually highlight changes in version controlled Latex files

October 2, 2017 1 comment

This is a follow-up post to latexdiff-git, which is outdated by now.

latexdiff is a powerful tool that uses two Latex files to generate a third Latex file in which differences between the first two files are visually highlighted. latexdiff is especially useful when comparing an old with a new version of the same Latex file. However, latexdiff does not account for any version control on its own. This means that if you want to visually highlight the differences between two versions of a version controlled Latex file, you are required to manually checkout the two different versions ahead of comparing them with latexdiff. In case you are using git as your version control system, this is where git-latexdiff comes into play. It accounts for checking out the different version of a Latex file as well as comparing them with latexdiff in a single command: you only need to specify which latex file and versions should be used for the comparison.


Ensure you have git, a latex distribution (e.g. texlive-full), and latexdiff installed and available in the path of your CLI.

git-latexdiff installation

Clone git-latexdiff:

git clone

Follow instructions in the README. This will involve a:

sudo make install

in most cases on an Ubuntu system. If all went well “git latexdiff” should be available in your CLI (it should print the help message):

user@machine:~$ git latexdiff

fatal: Please, provide at least one revision to diff with.
Usage: git latexdiff [options] OLD [NEW]
 git latexdiff [options] OLD --
 git latexdiff [options] -- OLD
Call latexdiff on two Git revisions of a file.

OLD and NEW are Git revision identifiers. NEW defaults to HEAD.
If "--" is used for NEW, then diff against the working directory.

 --help this help message
 --help-examples show examples of usage
 --main <file> name of the main LaTeX, R Sweave,
 or Emacs Org mode file.
 The search for the only file containing 'documentclass'
 will be attempted, if not specified.
 For non-LaTeX files, a reasonable `prepare` command
 will be used unless explicitly provided
 --no-view don't display the resulting PDF file
 --latex run latex instead of pdflatex
 --bibtex, -b run bibtex as well as latex
 --biber run BibLaTex-Biber as well as latex
 --view view the resulting PDF file
 (default if -o is not used)
 --pdf-viewer <cmd> use <cmd> to view the PDF file (default: $PDFVIEWER)
 --no-cleanup don't cleanup temp dir after running
 --no-flatten don't call latexpand to flatten the document
 --cleanup MODE Cleanup temporary files according to MODE:

- keeppdf (default): keep only the
 generated PDF file

- none: keep all temporary files
 (may eat your diskspace)

- all: erase all generated files.
 Problematic with --view when the
 viewer is e.g. evince, and doesn't
 like when the file being viewed is

--latexmk use latexmk
 --latexopt pass additional options to latex (e.g. -shell-escape)
 -o <file>, --output <file>
 copy resulting PDF into <file> (usually ending with .pdf)
 Implies "--cleanup all"
 --tmpdirprefix where temporary directory will be created (default: /tmp).
 Relative path will use repository root as a base
 --verbose, -v give more verbose output
 --quiet redirect output from subprocesses to log files
 --prepare <cmd> run <cmd> before latexdiff (e.g. run make to generate
 included files)
 --ln-untracked symlink uncommited files from the working directory
 --version show git-latexdiff version.
 --subtree checkout the tree at and below the main file
 (enabled by default, disable with --whole-tree)
 --whole-tree checkout the whole tree (contrast with --subtree)
 --ignore-latex-errors keep on going even if latex gives errors, so long as
 a PDF file is produced
 --ignore-makefile ignore the Makefile, build as though it doesn't exist
 -* other options are passed directly to latexdiff
 --bbl shortcut to flatten a bbl file of the same name as the project
 --latexpand OPT pass option OPT to latexpand. Use multiple times like
 --latexpand OPT1 --latexpand OPT2 to pass multiple options.
 --latexdiff-flatten use --flatten from latexdiff instead of latexpand

Unrecognized options are passed unmodified to latexdiff.

git-latexdiff usage

The main CLI usage of git-latexdiff is:

git latexdiff --main YOURFILE OLD_HASH [NEW_HASH]

A bunch of useful options are available for git-latexdiff. For example:

-v # good in case you run into any errors
--cleanup keeppdf # delete the checked-out 'old' and 'new' folders but keep the pdf
--cleanup all # delete all generated files afterwards
--output FILE # copy pdf before deleting it to FILE (disables automatically viewing the pdf). good in combination with --cleanup all
--tmpdirprefix ./FOLDERNAME/ # alternative to the above: specify where temporary stuff is stored, makes it easier to access diff files. good in combination with --cleanup keeppdf
--bibtex # also run bibtex
--biber # also run biber

Therefore, the command you might want to run therefore might be similar to this:

git latexdiff --main MYFILE.tex --bibtex --output git-latexdiff.pdf --cleanup all OLD_HASH NEW_HASH

…where you can specify


as NEW_HASH, if you want to run git latexdiff against the current (possibly unstaged/uncommited) version of the file, or where you can leave out NEW_HASH completely, if you want to run it against the last commit. Or your command might look similar to this:

mkdir git-latexdiff; git latexdiff --main MYFILE.tex --tmpdirprefix ./git-latexdiff/ --cleanup keeppdf OLD_HASH


Savitzky-Golay Filters: Approximating Time Series using Polygons with an Example in R

August 6, 2017 Leave a comment

Continuous data streams (“time series data”) are usually smoothed before data processing is applied on them. For this purpose both the running mean filter (also called moving/rolling mean/average) and the related running median filter are frequently used. Both have the disadvantage of “cutting off” peaks. This is a side effect of not trying to approximate a given signal in the best way. That is, they apply a simple function without incorporating the error they introduce on the signal during the approximation.

As alternative to such approaches a Savitzky-Golay filter can be used. It tries to approximate a given signal using a sliding window approach and a low degree polynomial to model data within that window. In contrast to running mean/median it also incorporates the introduced error in the approximation process using linear least squares. This leads to not “simply cutting off peaks” but modeling them in the best way possible, just as the rest of the data.

Here’s a simple example of a Savizky-Golay filter in comparison to running mean/median in R on an excerpt of the beaver data:

matplot(data.frame( beaver1[,3], # original data
runmed(beaver1[,3], k = 11), # with running median filter
filter(filt = sgolay(p = 5, n = 11), x = beaver1[,3]) # with SG filter
), type='l', lwd=2, lty=1, ylab='')
legend('topleft', legend=c('original', 'runmed', 'Savitzky–Golay'), col=1:3, lty=1, lwd=2)


Savitzky-Golay Filter Example

Savitzky-Golay Filter Example

Install R from source: a simple way to compile R from source and use it in RStudio or on servers without X

Sometimes we need to use special versions of R (e.g. the latest version of R is not available in the repositories of the machine we need to use). This post describes a simple way of compiling R from sources and using it in RStudio or on servers without X.

Get latest R source

Get the source of your desired R version from You want to obtain a file named R.x.y.z.tar from there and untar it using tar -xf R-x.y.z.tar.gz. Change into the untar-ed folder then.

More details on this are available at

Build R from source for RStudio

Built R using the following commands. Be aware that there are a number of prerequisites to this compilation, like having gcc and g++ installed.

./configure --enable-R-shlib
make check
make check-all


Passing the checks creates the R and Rscript frontends in ./bin/ — those are what you most likely need. You can call these directly, link to them, or use them in RStudio (see below). If you forgot to add the –enable-R-shlib parameter to configure you need to delete and re-extract the tar before redoing the process — otherwise make will fail.

More details on this are available at

Define the R to use with RStudio

RStudio uses the R defined by which R. Hence we can add the following to the ~/.profile file to define which R is used by RStudio:

# export RSTUDIO_WHICH_R=/path/to/your/R # this is what RStudio usually uses
export RSTUDIO_WHICH_R=/usr/local/bin/R  # this is what we use
. ~/.profile # reloads the profile without requiring us to logout+login again

More details on this are available at

Build R for environments without X/without Java

Do the same steps as above, but use this configure instead:

./configure --with-x=no --disable-java

More details on this are available at

Hint for “package not available for R version x.z.y…” errors

If package installations fail because your repositories don’t contain the required SW, try the Berkeley mirror: from our experience, they host lots of packages in many versions. For example:

install.packages("ggplot2", repos="")

Alternatively, the URL to the source archive can be specified directly:

packageurl <- ""
install.packages(packageurl, contriburl=NULL, type="source")

More details on this are available at

Yet another option is to use devtools to fetch code e.g. directly from GitHub:


More details on this example can be found at


Categories: Data Analysis Tags: , , , , , , ,

Rhythmbox is silent: reset pulseaudio configuration

Rhythmbox is silent?

After playing around with different Linux Shells/UIs/window managers (including i3, Gnome Shell, etc) and some frequent restarts, I noticed that for some reason my music player Rhythmbox had stopped playing any sounds. Though it was still “playing” songs, no sounds were actually made by speakers, headphones, etc. In contrast, all other sounds were OK, including OS sounds like info/error messages, or other players like VLC. Changing sound setting, volumes, as well as changing audio devices did not have any effect on this.

Resetting pulseaudio configuration

Turns out that the pulseaudio configuration was messed up. The solution to this problem is to move/delete the old configuration, then let it be recreated (the original problem description and solution to this is here):

mv ~/.config/pulse/ ~/.config/pulse_old/ # move/delete the old config
pulseaudio -k # restart pulseaudio

After doing this and restarting Rhythmbox its sound should be back to normal, – though you might need to restart the OS if you run into problems with external speakers/headphones.