December 5, 2013

Juggling Projects with Projectile

Filed under: blogging,emacs — jonEbird @ 9:56 am

When I’m introducing someone to Emacs, I will often talk about how a typical Emacsen will keep it running for long periods of time and will keep many files (buffers as we call them) open. I personally have over 100 buffers open as I write this. Part of the reason I have so many open is that I’m often jumping between different collections of files as I go about my work throughout the day. When I want to switch over to work on another project, I’ll switch to the desired buffer (C-x b) and while ido makes that easier, I still need to rely a good deal on mental memory to know which files make up which project. Worse yet is that some projects have commonly named files, so you may end up with buffers “Makefile”, “Makefile<2>”, etc. Which one was it?

The Projectile project aims to help solve this problem. It’s about context switching between projects and doing so deliberately. Projectile knows which files are a part of each project. The new workflow for switching to work on another project is: 1. Switch to Project (C-c p s) at which point you’re selecting (with ido again) against a list of projects only, then 2. picking a specific file from that project that you wanted to work on first. Mentally, it is “I want to work on file XX in project YY now. Take me there, Projectile!”. You can also easily switch between other buffers exclusively within the current project you’re working in (C-c p b) or open up a new file within your project (C-c p f). It’s about understanding which files and buffer make up your project and leveraging that to maximize your efficiency.

For example, earlier today I got an email asking for help on a minor issue. I wanted to consult a Python script but it’s been a while and I forgot the full path to the script. “Well, the project has ‘util’ in the name”, I thought to myself, so I switched projects (C-c p s) and typed “util” to narrow the choices of projects to the correct one and hit ENTER. I then typed “.py” to narrow the project files to only Python scripts I’m left with two choices. Nice! I didn’t have to remember the full path to the file and saved about 5-10s of searching which adds up with each project context switch.

The concept of managing the collection of files within a project is the core functionality of Projectile. I didn’t get that when I initially perused the few articles I’ve brought it to my attention. And yet Projectile does not stop there. Some of the other features that I’ve found useful in my 2 days of using it have been:

  • Launching an ack (C-c p a) or grep (C-c p g) to search through the files in your project.
    • This will replace my M-x rgrep habit.
  • Run a multi-occur on open buffers within your project.
    • I rarely used multi-occur because I found it a hassle to select which buffers. Happy addition.
  • Need to replace, ala query-replace (M-%), across all files in your project?
    • It can do that too. (C-c p r)
  • Handful of project testing integration (Listing these here but I honestly haven’t explored these features yet)
    • Support for switching between test file and your current buffer (C-c p t)
    • Find a test file (C-c p T)
    • Run your test suite (C-c p p)
  • And more

Now let’s make your experience with Projectile better:

  • Install guide-key and add “C-c p” (the default Projectile prefix key sequence) to your guide-key/guide-key-sequence. This makes learning a completely new system, like Projectile, nearly trivial since all of the actions use the same prefix. With guide-key, you type the beginning sequence “C-c p” and then be provided with a cheat-sheet.
  • Using IDO? Then install flx-ido and consider ido-vertical-mode
  • Install ack on your machine and then the corresponding Emacs ack-in-a-half module.
  • Make sure you have Exuberant Ctags installed for generating a proper TAGS file.

I will probably look to exploit the hooks available in Projectile. In particular, I think it would be nice to interact with my shell and switch to a different screen session or something. I’m excited to continue to use it.

June 25, 2013

Managing my Emacs Addons with El-Get

Filed under: blogging — jonEbird @ 8:39 am

I like to say that putting my dot-files into a repo was one of the best things I’ve ever done. It was one of those moments that you say to yourself, “Why didn’t I do this years ago?” The process encouraged me to clean up my Emacs configs but there was still one thing that was bugging me. Whenever I perform a fresh checkout of my repository, after a fresh OS install, I would have to keep installing the packages (M-x list-packages) that were referenced in my config that was not yet installed. The process was:

10 Start Emacs with --debug-init
20 Note missing package
30 Install missing packages
40 GOTO 10

It’s annoying and definitely not ideal. Enter El-Get. Before I get too far into this article, there are people that will tell me that I could have probably defined a list of the packages I needed installed and have a small elisp function to ensure they are installed. I know this but I’ve also kept my eye on the El-Get project and have admired the flexibility that it provides. I described it to another Emacs user as putting a layer of abstraction on installing additional packages. Not only does it support installing packages from the normal ELPA / packages.el sources, you can use a handful of other really handy sources for your installs. I specifically like the idea of sharing personal Emacs solutions with other co-workers via a simple git repository. Being able to install solutions directly off of the EmacsWiki is pretty darn cool too.

Let’s get started with the El-Get configuration. From their Basic Setup section, you merely have to add the following to your .emacs file:

(add-to-list 'load-path "~/.emacs.d/el-get/el-get")

(unless (require 'el-get nil 'noerror)
    (goto-char (point-max))

(add-to-list 'el-get-recipe-path "~/.emacs.d/el-get-user/recipes")
(el-get 'sync)

That is technically all you need in order to get things up and running. Of course, the whole point in setting this up is to move our packages to be managed by El-Get. The current list of packages I typically install has been:

  • ace-jump-mode
  • yaml-mode
  • etags-select
  • etags-table
  • lua-mode
  • markdown-mode
  • cups
  • magit

Let’s see what I need to do to get these managed by El-Get. Let’s try adding the “cups” package via El-Get. The El-Get equivalent to “M-x list-packages” is “M-x el-get-list-packages” and then it acts the same way. Page through the list of packages, hit ‘i’ to mark a package for installation and then a final ‘x’ to execute the installation. Ah, but where is the “cups” package? It’s not there.

I need to tell el-get that it can find the “cups” package available via the ELPA sources. The way I’m going to do this is by defining an optional el-get-sources variable. I’ll skip forward a few and also tell you I ended up doing the same for “magit” as well after the recipe from el-get failed. I would also encourage you to lookup the documentation for the el-get-sources variable as it is quite thorough and instructional on how el-get recipes work:

; Establish that some packages come from ELPA, etc.
 '(el-get                   ; self-hosting
   (:name cups
          :type elpa)
   (:name magit
          :type elpa
          :after (progn ()
                   (global-set-key (kbd "C-x C-z") 'magit-status)))

With that in place, you can put together the complete list of your desired packages to install between the pre-established El-Get recipes and the ELPA packages. From other people’s examples, it seems like the convention is to set a separate variable for your personal package list and then tell El-Get to install them:

(setq jsm-packages
       '(cups ace-jump-mode yaml-mode color-theme color-theme-solarized lua-mode
              etags-select etags-table markdown-mode cups cl-lib magit htmlize)

       (mapcar 'el-get-as-symbol (mapcar 'el-get-source-name el-get-sources))))

(el-get 'sync jsm-packages)

You can also write your own recipes. Let’s go through an example of what it would look like by creating a recipes for the “chess” package. The “chess” package is another one that is currently provided via my ELPA sources but not from a pre-defined el-get recipe. When I run “M-x el-get-install ENTER chess ENTER”, I notice that is not available. I am now going to run “M-x el-get-find-recipe-file ENTER chess ENTER” and since we already know a recipe does not exist, a new file will be created with the .rcp extension in our ~/.emacs.d/el-get-user/recipes/ directory. If this is the first recipe you are creating, then the directory probably does not exist and you’ll want to do a “M-x make-directory” before saving the file. Our recipe is going to look very simple:

(:name chess
       :description "Play chess in Emacs"
       :type elpa)

I would again direct you to the variable documentation for el-get-sources (C-h v el-get-sources) on the various options you can use. There are a lot of them and I have honestly not explored many of them.

With our new recipe in place, we can install the package via el-get with either “M-x el-get-install” or by browsing the package lists via “M-x el-get-list-packages”. After you have successfully installed the desired package, do not forget to commit your new recipe and to add it to the list of packages to be installed. Next time you re-build your workstation / laptop, you can do a quick clone of your repository and el-get will handle the rest for you.

February 19, 2012

Automatically positioning and sizing windows with Devilspie

Filed under: adminstration,blogging,linux — jonEbird @ 1:48 pm

I often talk about my media PC in the living room and how I like to stream music via Pandora in the house. Since I am using Pithos, I can maximize the desktop real estate and enjoy whatever wallpaper suits my mood. In order to best accomplish this, I tend to resize Pithos so that it only shows the current album and song as well as move it off to the corner of the desktop. Although this only takes a moment to accomplish, I’ve grown tired of doing it each and every time I need relaunch Pithos. What I really want to be able to do is automatically resize and position the window immediately when I launch Pithos. Someone has to have solved this before and it’s bugging me enough that I need to solve this once and for all.

I started looking at wmctrl to solve my problem per the recommendation of Patrick Shuff. While familiarizing myself with the utility, I ironically stumbled upon a wmctrl tips page which included a list of other similar tools and the description of devilspie sounded exactly like what I needed:

devilspie is a window-matching utility. It can be configured to detect windows as they are created, and match the window to a set of rules. If the window matches the rules, it can perform a series of actions on that window.

My needs are modest. A resize and a positioning is probably accomplished with a simple declaration to set the window geometry. Let’s install it and start playing.

Fortunately I could install devilspie directly from yum and while the manpage is quite sparse it is packaged with a sufficient README that after a few trial and error iterations, I got a basic configuration working which just ran devilspie in debug mode and could report on the current windows opened and new ones being launched.

sudo yum -y install devilspie
[ ! -d ~/.devilspie ] && { mkdir -m 0755 ~/.devilspie; echo "(debug)" > ~/.devilspie/debug.ds; }

That will continue to run in your terminal, so you may want to open another tab/terminal as we explore.

Since I am a devoted Emacs user, I certainly wasn’t disappointed to learn that devilspie uses s-expressions for it’s configurations. I also found a good unofficial devilspie documentation page written up by Gina Häußge which helps round out the education. Indeed, it looks like I’ll be able to solve my problem with devilspie. After meticulously positioning my Pithos window, I used xwininfo to record my current window geometry. I then created the simplistic config file “~/.devilspie/pithos.ds” as the following:

(if (is (application_name) "Pithos") (begin (geometry "481x163--20-17") (unshade) ))

Some more background on setting up your own configurations. If you notice when you launched devilspie, after the initial install, you can see the information on the current windows and their associated application names. For example, here is what I see for Pithos:

Window Title: 'Pithos - Bankrupt On Selling by Modest Mouse'; Application Name: 'Pithos'; Class: 'Pithos'; Geometry: 483x197+797+523

That should make it easy for coming up with rules to match application names, window names or classes when targeting your applications.

The frustrating thing for me was how each utility was reporting a different geometry value for the windows currently launched. Between xwininfo, devilspie and wmctrl they all had differing opinions on what I should use. You’d think that I could use what devilspie was telling me since that is the utility I’m indented on using but it didn’t work out for me. I’ve used xinwinfo for over a decade and I guess I’m sticking with it.

Finally, I added a final few touches to my desktop configuration before calling it complete. I created a simple shell script to relaunch Pithos indefinitely because occasionally I need to relaunch it but I actually never intend to leave it off: (See installing pithos with virtualenv if you want to see how I installed Pithos)



source ${PITHOS_VENV}/bin/activate
while :; do
    sleep 1

My cheap way of launching apps indefinitely is to run them within my main screen session. I’ll create one for the Pithos restart script and another for devilspie. Here is an excerpt from my ~/.screenrc:

screen -t emacs     0  /usr/bin/emacs -nw
screen -t local     1  /bin/bash
screen -t local     2  /bin/bash
screen -t local     3  /bin/bash
screen -t local     4  /bin/bash
screen -t local     5  /bin/bash
screen -t synergy   10 /usr/bin/synergyc -f
screen -t devilspie 11 /usr/bin/devilspie
screen -t pithos    12 ~/bin/

And all is well in my household again. Should something get borked with Pithos, perhaps due to being paused for too long or whatever, I can simply kill the window which triggers the restart script to launch another copy and devilspie will position and resize it perfectly for me. How will you use devilspie?

February 7, 2012

Python Memoize Decorator with TTL Argument

Filed under: blogging,linux,python — jonEbird @ 8:51 pm

I have been working on a troubleshooting effort on and off over the past couple of weeks. In the process of troubleshooting, I ended up writing a script to query and report on un-read buffered data for sockets across the system and today I wanted to correlate the sockets to a particular set of processes. That turned out to be not so bad knowing I could look down /proc/<pid>/fd/ for a list of the current file descriptors the particular process has open. Here is my winning Python implementation.

def get_pid_socket_nodes(pid):
    """Return a list of socket device numbers for the given process ID (pid)
    pid may be an integer or a string
    Akin to: ls -l /proc/
/fd/ | sed -n 's/^.*socket:\[\([0-9]*\)\]$/\1/p'
    nodes = []
    for fd in os.listdir('/proc/%s/fd' % pid):
        link = os.readlink('/proc/%s/fd/%s' % (pid, fd))
        if link.startswith('socket:['):
    return nodes

What I haven’t told you is the overall program may be scanning /proc/net/{tcp,udp} a lot and with each scan I’ll want to correlate values found with a particular process’s sockets. That means a straight forward implementation could mean calling my helper function get_socket_devices() at each interval for each process of interest. Also, the interval is currently controlled by a sleep interval specified by the caller. If the caller wants to monitor for socket information at an 0.1s sleep interval for five processes, I’ll be scanning /proc/<pid>/fd/ entries 50 times a second. Sure, it won’t crash the machine but it’s certainly a waste of resources assuming the processes you are interested in aren’t closing and opening sockets at an alarming rate.

I wanted to reduce the amount of /proc/<pid>/fd/ scans but I also did not want to clutter the code. “Ah ha, what I want is a memoize decorator”, I told myself, but I want to be able to specify a time-to-live (ttl) value to my decorator. Admittedly, I have only ever needed to write decorators without arguments, so this was a first for me. I also don’t write enough decorators to be able to write one correctly without looking at a sample implementation for a refresher. My implementation is basically a merge between Memoize and Cached Properties from the Python Decorator Library wiki page. (I also spent some time re-reading Bruce Eckel’s Decorator Arguments writeup as well as Elf Sternberg’s Decorators With Arguments writeup.)

class memoized_ttl(object):
    """Decorator that caches a function's return value each time it is called within a TTL
    If called within the TTL and the same arguments, the cached value is returned,
    If called outside the TTL or a different value, a fresh value is returned.
    def __init__(self, ttl):
        self.cache = {}
        self.ttl = ttl
    def __call__(self, f):
        def wrapped_f(*args):
            now = time.time()
                value, last_update = self.cache[args]
                if self.ttl > 0 and now - last_update > self.ttl:
                    raise AttributeError
                #print 'DEBUG: cached value'
                return value
            except (KeyError, AttributeError):
                value = f(*args)
                self.cache[args] = (value, now)
                #print 'DEBUG: fresh value'
                return value
            except TypeError:
                # uncachable -- for instance, passing a list as an argument.
                # Better to not cache than to blow up entirely.
                return f(*args)
        return wrapped_f

Now let’s put the decorator into use and test it. (My testing is uncommenting the “print DEBUG” lines from the memoized_ttl decorator.) To use the decorator, you use the standard decorator calling syntax and specify your desired ttl. I am restricting the /proc/<pid>/fd/ scans to a minute interval which, based on my experience, will drop the load of the script down to below the radar.

def get_pid_socket_nodes(pid):
    """Return a list of socket device numbers for the given process ID (pid)
    pid may be an integer or a string
    Akin to: ls -l /proc/
/fd/ | sed -n 's/^.*socket:\[\([0-9]*\)\]$/\1/p'
    nodes = []
    for fd in os.listdir('/proc/%s/fd' % pid):
        link = os.readlink('/proc/%s/fd/%s' % (pid, fd))
        if link.startswith('socket:['):
    return nodes

And finally, here is what it looks like looking at a couple of processes of mine with open sockets:

>>> from buffered_sockets import *
>>> pid = 23283
>>> pid2 = 23279
>>> get_socket_devices(pid)
DEBUG: fresh value
>>> get_socket_devices(pid)
DEBUG: cached value
>>> get_socket_devices(pid2)
DEBUG: fresh value
>>> get_socket_devices(pid2)
DEBUG: cached value
>>> time.sleep(60)
>>> get_socket_devices(pid)
DEBUG: fresh value
>>> get_socket_devices(pid)
DEBUG: cached value

A handy decorator to keep around which I suspect will get a lot of mileage from other scripts I end up authoring. Aside from the helpful blog posts listed above, I also found Will McGugan’s Timed Caching Decorator page after writing this entire blog post. Apparently I need to improve my google searching skills because I certainly didn’t want to re-invent what others have already completed. On the other hand, if you spend this much time creating something for the first time, you tend to remember the lessons better. I’ll take that.

Upgrading WordPress to 3.3.1

Filed under: blogging,emacs,usability — jonEbird @ 8:36 pm

Upgrading WordPress tonight from version 2.6.2 to the latest version 3.3.1. About time, right? Funny enough, my motivation was when I was configuring org2blog and noticed the URLs it was trying to hit were non-existent. That was my first clue that I needed to update. For the most users, I’d suggest following the very well documented Upgrading WordPress documentation, but I thought I’d show you how I do it. (Read: This post is pretty much for my own reference for the next time)

  1. Grab the latest wordpress release
upgrade_dir=wordpress_upgrade_$(date +%Y%m%d)
mkdir ~/${upgrade_dir} && cd ~/${upgrade_dir}
tar -xzf latest.tar.gz
  1. Following along with the Upgrading WordPress documentation.
  2. Take a backup of the current install.
mysqldump -u root -p wordpress > wordpress.dump
# Using the contents of the extracted latest.tar.gz WordPress release as my tarball file list
\ls wordpress | xargs tar -C /var/www/html -czf wordpress_backup.tar.gz
  1. Now for the actual manual upgrade
WPH="/var/www/html/" # My WordPress Home (WPH)
rm -rf ${WPH}wp-{includes,admin}
rsync -av wordpress/wp-includes ${WPH}/
rsync -av wordpress/wp-admin ${WPH}/
rsync -av wordpress/wp-content ${WPH}/
(cd wordpress; for f in *; do if [ -f "${WPH}/${f}" ]; then echo "Updating $f"; cat "${f}" > "${WPH}/${f}"; fi; done)
  1. Re-log into your site and proceed with the DB upgrade.
    Since my versions were so far off, the first thing I was greeted with upon login was a button to update the DB.

All done. The good news is I can now successfully log into my blog via org2blog plugin. Here is my elisp excerpt:

;; Setting up org2blog (Installed via ELPA)
(require 'org2blog-autoloads)
(require 'netrc)
(setq blog (netrc-machine (netrc-parse "~/.netrc") "jonebird" t))
(setq org2blog/wp-blog-alist
         :url ""
         :username (netrc-get blog "login")
         :password (netrc-get blog "password")
         :tags-as-categories t)))

Now to post this, I believe I’m supposed to M-x org2blog/wp-post-subtree. Well, that worked well and posted this as a draft. I noticed a few markup problems and after fixing them, I can finalize the posting via C-u M-x org2blog/wp-post-subtree. 2012-02-07 Tue 20:36

December 29, 2011

Installing emacs v24 on Fedora

Filed under: adminstration,blogging,emacs,linux,usability — jonEbird @ 10:05 pm

I’ve been reading about other people giving the yet to be release version 24 of emacs for some time now. When I decided to upgrade my systems to use v24, I was a bit surprised to not find anything about configuring a Fedora system to use v24 of emacs. Guess I gotta do it myself…

This tutorial is part editorial and part instructional. I thought it would be helpful to include some of the techniques I used to get emacs up and running quickly without needing to pull my hair for other’s edification.

After realizing I wasn’t going to be able to just grab a pre-built binary, I went looking for the official sources. I ended up finding the pretest download location. First step first, let’s pull down the latest emacs-24 tarball and extract it.

FILENAME=$(curl -s ${PRETEST_URL} | sed -n 's/^.*a href="\(emacs-24.[0-9\.]*tar.gz\)".*$/\1/p' )
tar -xzof $FILENAME
cd ${FILENAME%.tar.gz}

If that worked, you are now sitting in the extracted directory of the latest emacs-24 pretest source. Now for some instructional information. Any significantly large project will need a decent amount of development packages installed for a successful compile and that can be a pain to identify. Earlier I claimed that I didn’t pull my hair out which means I cheated. I grabbed the latest Fedora source rpm. I didn’t actually want to install the src.rpm but rather extract the emacs.spec file which will act like a blueprint for my build. I’m going to give you the answer later but if you’d like to know how to extract the specfile, try this:
Note: You do not need to do this step. Instructional only.

# Your SRCRPM may differ depending on what you end up downloading.
mkdir tmp && cd tmp
rpm2cpio $SRCRPM | cpio -ivd
sed -n -e 's/,/ /g' -e 's/^BuildRequires: //p' emacs.spec | xargs sudo yum -y install

Note the last command in that section was a command to install the necessary development packages for our build. Since I”m not requiring you to do that above, here is the command for you:

sudo yum -y install atk-devel cairo-devel freetype-devel \
  fontconfig-devel dbus-devel giflib-devel glibc-devel gtk2-devel \
  libpng-devel libjpeg-devel libtiff-devel libX11-devel libXau-devel \
  libXdmcp-devel libXrender-devel libXt-devel libXpm-devel \
  ncurses-devel xorg-x11-proto-devel zlib-devel librsvg2-devel \
  m17n-lib-devel libotf-devel autoconf automake bzip2 cairo texinfo \
  gzip GConf2-devel alsa-lib-devel desktop-file-utils python2-devel \
  python3-devel util-linux

The other part of the specfile you’ll typically want to look at, if you’re cheating like me, is the %build section. That is where you’ll find the actual commands used to configure and build the binaries. There I found the configure switches used so I don’t have to pick out which ones I’ll need. Again, just like figuring out the development packages, figuring out configure options can also be a chore. Let’s get to configuring, building and installing it now.

./configure --prefix=/usr/local/emacs24 --with-dbus --with-gif --with-jpeg --with-png \
  --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk
./src/emacs --version # Look good? The INSTALL doc suggests testing: ./src/emacs -Q
sudo make install

Well, that worked for me and hopefully it worked for you too. If you noticed, I used the --prefix=/usr/local/emac24 option above on my configure line which means everything got cleanly installed down it’s own separate base directory of /usr/local/emacs24. Since you won’t want to use that path explicitly each time you launch emacs, we’ll have to inform Fedora of our new altenative.

sudo alternatives --install /usr/bin/emacs emacs /usr/local/emacs24/bin/emacs 20000
sudo alternatives --install /usr/bin/emacsclient emacsclient /usr/local/emacs24/bin/emacsclient 20000

And there, we’re done. Congratulations. You have installed emacs version 24 on your Fedora system. Let me know if you’ve had any problems or have a better recommendation.

December 23, 2011

Installing Pithos on Fedora within a Virtualenv

Filed under: adminstration,blogging,linux,python,usability — jonEbird @ 12:40 pm

I listen to a lot of music while at home. I am a Pandora user and have been very happy with my Pandora One subscription now for over two years. The machine used for playing my music is what I call my “media PC”. It is called that because this machine sits in my entertainment stand and is connected to my Sony receiver via HDMI making the multimedia experience as good as I can get. If you put those two facts together, you can see that I am staring at my desktop a lot and I thought it would be nice to integrate my TV into rest of the decor of the house. I primarily do that by being very selective in finding desktop pictures and generally clearing off the desktop of any clutter. Think of the large 47″ LCD television as one big painting for the living room.

Which leads me to my one, sole problem with Pandora: I like to look up and read the Artist and Title of the track being played but I don’t want the browser to also consume my visual space. (I also don’t want to mess around with Adobe Air for the desktop version of Pandora) Enter Pithos. By this point, I should point out that my media PC is running Fedora Core 15 and I’m a Gnome user (let’s not talk about Gnome3). That is important because Pithos was written for gnome users.

Pithos is great. It’s a simple UI design, still allows for normal Pandora song control, easy drop-down for my stations, can still star (thumb’s up) songs all the while being small and unobtrusive. And now we are to the subject of this blog post: Installing Pithos on a Fedora Core machine.

This installation guide will follow my other guides in the same “copy & paste” format. That is, below you should be able to simply open a shell, copy the block of shell code and paste it into your terminal and be ready to launch Pithos. The one configurable item I left in there is whether or not you’d like to install Pithos within a virtualenv or not. I won’t go into detail about what virtualenv is for this discussion, but suffice to say that you’d choose it if you want to install Pithos in a alternative path that you own instead of /usr/local/bin/. Below, when you copy & paste the instructions to install Pithos, you can simply leave out the variable "I_LOVE_VIRTUALENV" or change the value from anything but “yes” to install the “normal” way. I choose to install via virtualenv to 1. keep my system site-packages clean and 2. also keep /usr/local uncluttered. When I do this, I mostly only have to worry about backing up my home directory between rebuilds.

Again: If you’d like to use virtualenv, keep the "I_LOVE_VIRTUALENV" variable set to “yes”.
Furthermore, using virtualenv you can control the env path via setting the VIRTUALENV variable. Some people have a separate directory for their virtualenv’s. E.g. VIRTUALENV=virtualenvs/pithos
(Copy and paste away!)

# Keep this variable to install within a virtualenv.
#   otherwise, skip this line or change from "yes" to anything else.
VIRTUALENV="" # Set this to control where your virtualenv is created
# --- Rest is pure copy & paste gold ---
sudo yum -y install python pyxdg pygobject2 \
  gstreamer-python notify-python pygtk2 dbus-python \
  gstreamer-plugins-good gstreamer-plugins-bad \
  bzr python-virtualenv
# FYI, those last two are not direct requirements but tools to complete this
cd; bzr branch lp:pithos pithos
if [ "${I_LIKE_VIRTUALENV}" == "yes" ]; then
  virtualenv ${VIRTUALENV:-pithos_venv}
  source ${VIRTUALENV:-pithos_venv}/bin/activate
  # The money shot... finger's crossed
  cd pithos; python install
  cd pithos; sudo python install --prefix=/usr/local

And there you have it. A clean, aesthetically pleasing music experience. Enjoy.
Desktop Shot with Pithos

October 3, 2011

Customize Gnome Terminal in Gnome 3

Filed under: linux,usability — jonEbird @ 7:56 pm

I recently upgraded to Fedora 15 on both the laptop and the home server and I’m still getting used to Gnome 3. Through each frustrating change, I have decided to stick with it and try to learn the new ways to do things but I have been tempted more than a few times to just switch to using XFCE. Today’s challenge: Customizing gnome-terminal.

In the old days, the customizations I would do all involved edits that could be done by updating the default profile (Menu->Edit->Profiles). The main things I would update is setting my background to a certain percentage of transparency, disable scroll bar (because we’re all using GNU screen, right?), and disable the menubar by toggling “show menubar by default in new terminals” (alt-f is reserved for emacs forward-word and not File menu). The remaining item to update is the default geometry or size of the terminal when it’s launched.

Perhaps I should blog more because I found a much easier solution than I expected. When I decided to figure this out tonight I started by finding a nice tutorial for updating gnome configurations and I thought I was going to end up recommending the following command:
gsettings set org.gnome.desktop.default-applications.terminal exec-arg "'--geometry=120x35'"
Instead, while writing the previous paragraph I realized that within the profile settings there is an option now to “Use custom default terminal size”. I feel stupid but I think I’m just stubborn in my ways after using Gnome for over a decade.

July 10, 2011

64bit Google Chrome with Flash on Fedora – Take2

Filed under: adminstration,linux,usability — jonEbird @ 10:08 am

Early last year I wrote up my procedure on getting Chrome setup with Flash on a 64bit Fedora Core 13 build. It is now dated and I hope people are not still using it. However, if you like the copy & paste style of my direct installation guidelines, I thought I’d give an updated post after a recent Fedora Core 15 install.

First things first, we still need to create new Yum repositories like we did last time. The biggest difference between last time is I would no longer recommend installing the beta build of Chrome and Adobe has moved the 64bit flash player out of a lab project to an official release. The fine folks working on the Fedora project have lend their help in instructing people on how to setup Flash as well and you may want to check that page for a more detailed explanation on what we’re doing. In particular, I’ll be using a repository which is being hosted by Fedora member leigh123linux.

Here is the final copy & paste version: (Like last time, if you are already root, take out the “sudo”)

# Creating the Google repo
cat <<\EOF | sudo tee /etc/yum.repos.d/google.repo
name=Google - x86_64
# Slip this guy in here... who doesn't want the gchat plugin?
cat <<\EOF | sudo tee /etc/yum.repos.d/google-talkplugin.repo
# Now to install the latest flash release yum repo from "leigh123linux"
latest_release=$(wget -qO- $leighURL |\
sed -n '/flash-release/s/^<LI><A HREF="\([^"]*\)".*$/\1/p' | sort -n | tail -1)
sudo yum -y localinstall --nogpgcheck ${leighURL}${latest_release}
# Actually installing Chrome and the Flash player
sudo yum -y install google-chrome-stable google-talkplugin flash-plugin
# Creating a plugins directory
[ ! -d /opt/google/chrome/plugins ] && sudo mkdir /opt/google/chrome/plugins
sudo ln -s /usr/lib64/flash-plugin/ /opt/google/chrome/plugins/

If you noticed, I slipped in the Google chat plugin. That is the necessary RPM for enabling video chat. If you really didn't want it installed, simply run "sudo yum erase flash-plugin". Enjoy your surfing.

May 28, 2011

Custom Dropbox Directory

Filed under: blogging,linux,usability — jonEbird @ 10:38 am

Ever since I rebuilt my laptop I’ve keep a file called “rebuild.txt” where I detail every little customization I’ve done. The requirement is that everything that I do has to be completely command line oriented where a block copy-and-paste would redo the same customization. So far I have things documented like setting up my local email routing, autologin to the laptop, additional RPMs w/ extra repositories, iptables rules, GTK configs, etc. The latest customization I’ve performed is when I finally decided to setup Dropbox.

I like Dropbox for it’s simplicity and the fact it integrates well with Linux. My only problem was that the directory I really wanted to have synchronized was my ~/projects/ directory. I actually didn’t do any google searches on how to change it before diving into figuring it out. I figured Dropbox would create a dot-file directory to stuff configuration and found that at ~/.dropbox/ and after that it didn’t take too much work to reverse engineer the setup.

So, here is my addition to my “rebuild.txt” file for how I would redo my Dropbox setup:
(Note: I’m running Fedora 13 but that fact really only applies to how I was installing Dropbox)

cat <<\EOF | sudo tee /etc/yum.repos.d/dropbox.repo
name=Dropbox Repository

# Now install
sudo yum -y install nautilus-dropbox
# After installing, I did launch dropbox and setup an account.

# Stop dropbox
pkill dropbox

# Modify the default location?
cp -p ~/.dropbox/config.db{,.orig}
echo "update config set value = '/home/jon/projects' where key = 'dropbox_path';" |\
sqlite3 ~/.dropbox/config.db
rsync -av ~/Dropbox/ ~/projects/

# now start dropbox again

After setting it up, I finally realized I could have google'd this and I did for curiosity sake. A common technique I saw was around using symlinks, but I found it fun to reverse engineer their configuration and was pleasantly amused that they didn't try to obfuscate the config. At this point I should probably stop poking around because I can see that the client is written in Python and I'm now finding other interesting things about the client.

Next Page »