IPython and IPython notebook (or Jupyter as it is now called) are great tools that make interactive Python work incredibly easy. If you want to do large-scale computations, like nested cross-validation I mentioned in a previous post, you want to automatically distribute your work across multiple compute nodes instead of interactively looking at results. Thankfully, the folks behind IPython provide IPython.parallel, which is a library for parallel computing. It is versatile in the sense that you can choose whether you want to distribute your work locally, via SSH or MPI by simply adjusting config files.

If you are working with machine learning, at some point you have to choose hyper-parameters for your model of choice and do cross-validation to estimate how well the model generalizes to unseen data. Usually, you want to avoid over-fitting on your data when selecting hyper-parameters to get a less biased estimate of the model's true performance. Therefore, the data you do hyper-parameter search on has to be independent from data you use to assess a model's performance.

I've successfully been running an instance of GitLab for almost a year now. The same server is running Redmine, hence both GitLab and Redmine are running in their respective sub-directories. Phusion Passenger is my application server of choice. Unfortunately, it became increasingly difficult to keep this setup running with newer versions of GitLab. First, GitLab officially is not supporting running it out of a sub-directory, second, by default it uses Unicorn. Here, I want to detail my setup how you still can achieve the GitLab + Apache + Phusion Passenger combo, because I could only find slightly outdated guides online.

I am pleased to announce version 3.2.1 of the Python bindings for
GObject. This is a maintenance release for the stable branch bringing
you a couple of bug fixes.

Download

http://download.gnome.org/sources/pygobject/3.2/pygobject-3.2.1.tar.xz

sha256sum:
0f07401289fa33e8caee7a9342f5c838bb44cd0a386cb99093505edb5e42817a

I am pleased to announce version 3.1.1 of the Python bindings for GObject. This is a bug fix release of the unstable branch, which will eventually result in the stable 3.2.x series.

Download

http://download.gnome.org/sources/pygobject/3.1/pygobject-3.1.1.tar.xz

sha256sum: ae6da0f95c0d6b93694191133a3b046f7811ba047e3bd5e9c13c9e6907f71515

I am pleased to announce version 3.1.0 of the Python bindings for GObject. This is the first release of the unstable branch, which will eventually result in the stable 3.2.x series.

It is important to point out that this release reverts the change "Convert all strings to utf-8 encoding when retrieving from TreeModel" to restore backwards compatibility. If you are using Python 2 it is recommended to always use the byte-representation of UTF-8 encoded strings (str class) instead of the unicode objects. I'm going to add a section to the Python GTK+ 3 tutorial that will explain this issue and how to deal with it in more detail.

Download

http://download.gnome.org/sources/pygobject/3.1/pygobject-3.1.0.tar.xz

sha256sum: a5b36eff7c4b14f161bc9ba2ae09a03ddb47d9f2c769589b8f389ae3a92cc92e

One of the big advantages of PyGTK is that it is documented very well. Unfortunately, despite the efforts to make PyGObject as compatible to PyGTK as possible, the differences are still huge. A big portion is due to the changes between GTK+ version 2 and 3, of course. To date, you basically have to look into the GIR file or C reference manual to try to figure out how things work. Once you are familiar with the way C functions are converted to Python, you can guess most methods.