1. You provide a list of keywords
2. lazy-slides finds pictures from the internet matching those keywords
3. lazy-slides creates a presentation/slideshow from those pictures
4. You present!

Right now it’s a bit rough. The only image source I’ve coded up is for flickr (if you don’t count the dummy test source.) Also, the only output backend it supports is beamer. In both cases, it should be relatively straightforward to extend lazy-slides.

This release is focused on the logging module. It addresses a number of design issue and defects, and the sphinx documentation for logging is much more complete. It even includes example code for much of the module.

As many people have pointed out before, emacs does not come with any packages for managing software projects. It comes with almost all of the parts you would need – debugger support, compilation modes, etc. – but it doesn’t come bundled with any way to tie a bunch of files together in to a project. Certainly this isn’t required to do software development, and, just as certainly, there are a myriad of ways to approach the concept of “projects”. This latter issue is likely why the basic emacs installation side-steps the issue.

In any case, I recently decided to look into the available project management options for emacs. I’ve used enough other big IDEs and tools to know that projects can be really useful, so I was curious what I could get for emacs. I wanted one that didn’t disrupt my normal emacs flow, one that had a clear and explicit model of what the project comprises, and ideally one that was highly hackable.

I looked at a number of tools, include CEDET (probably good but too bulky-feeling), proel (nice, but I didn’t fit it’s model of the world), and mk-project (not really sure…just didn’t work for me.) Honestly, I didn’t spend a whole lot of time vetting these. My sense was that if the package didn’t click with me quickly, then it wasn’t what I was looking for.

The winner: eproject

Ultimately, I settled on eproject. eproject essentially comprises three concepts:

• a top-level directory for a project
• a collection of files in the project
• a collection of commands that can be run relative to the project directory

A project is simply stored in a file in the project directory, and there is a central collection of projects stored in a file in your .emacs directory. It’s a very simple model, and everything is easily accessible.

I won’t go into any details on how to use eproject; the project page and emacswiki do a fine job of that, and I don’t really have anything to add. I do suggest, however, that you run eproject through its paces a bit on some smaller project just to get a feel for it. All in all, though, I found it intuitive, well documented, and easy to work with.

NOTE: There is another emacs project package also named eproject. The name conflict is unfortunate and confusing, so be aware. I did try this second eproject in my search, and while it’s a fine piece of software it didn’t really fit my needs.

Using eproject with anything

Many emacs users are fans of the excellent anything, and for good reason: it’s awesome! Fortunately, Daniel Hackney (good programmer name) wrote anything-eproject which marries the two projects. anything-eproject allows you to access your projects and project contents via the anything interface by providing two new “sources”.

Making it work

Putting this all together in your emacs configuration is pretty simple. Just download the eproject, anything, and anything-eproject packages to your .emacs directory and add something like this to your configuration:

; load eproject
(load-file "~/.emacs.d/eproject/eproject.el")

; Disable automatic addition/removal of files from projects. Optional.
(setq prj-autotracking nil)

; anything + eproject integration
(require 'anything-eproject)

; let project files be sources in anything
(add-to-list 'anything-sources 'anything-c-source-eproject-files t)

; let projects be sources in anything
(add-to-list 'anything-sources 'anything-c-source-eproject-projects t)

Future work

While eproject works well, there are some things I would like to add. First, it can be a bit cumbersome to add a lot of files to a project, especially if the files in your project are spread across many directories. I’ve developed a small extension to eproject that tries to address this, and I’m working with the author to get this change in.

Second, I’d like support for “cloning” projects. I often work with multiple versions of very similar (often identical) projects, and it would be nice if eproject would let me bootstrap a new project definition based on an old one. This should be relatively simple, I think.

It wasn’t.

So, after a few abortive attempts to install packages I found on the web and such, I determined that what I really needed to do was just build gcc from source. I’ve done this a number of times in the past, so I knew what I was getting into, and by-and-large the process was very straightforward. I had to patch the gcc build files in a few places, though, so I figured I should document the process to save me and others time in the future.

NOTE: This is on an amd64 machine, building a compiler for the same platform. YMMV.

Install a few packages

For the build to work, you’ll need to install a few other packages that provide headers files, etc. The packages you’ll need are:

• linux-header-<kernel-version>
• gcc-multilib

(There may be others, and I’ll try to update this list as I hear about them.)

Make MULTILIB look in the right directories

In gcc/config/i386/t-linux64 you need to correct the directories used for MULTILIB stuff. Change line 9 from:
MULTILIB_OSDIRNAMES = ../lib64 ../lib
to
MULTILIB_OSDIRNAMES = ../lib ../lib32

Change the “version” string that the build expects from ld

The gcc build parses the output of “ld –version”. Unfortunately, ubuntu decided to change that output, causing gcc to think that the ld version is really old. In libstdc++-v3/configure change line 8284 from:
sed -e 's/GNU ld version \([0-9.][0-9.]*\).*/\1/'`
to
sed -e 's/GNU ld (GNU Binutils for Ubuntu) \([0-9.][0-9.]*\).*/\1/'`

The full patch

You can download the patch from pastebin.

Be aware that this patch is only against gcc-core and gcc-g++, not against the entire gcc suite.

Step-by-step

These steps should more-or-less do everything you need to download, patch, build, and install gcc/g++-4.1. Everything will get installed to /usr/local/gcc-4.1/[bin,lib], and the programs will have the suffix “-4.1″.

wget ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-4.1.2/gcc-core-4.1.2.tar.bz2
wget ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-4.1.2/gcc-g++-4.1.2.tar.bz2
tar jxvf gcc-core-4.1.2.tar.bz2
tar jxvf gcc-g++-4.1.2.tar.bz2
<download patch from pastebin>
cd gcc-4.1.2
patch -p1 < ../FKkiciZz.txt
./configure --prefix=/usr/local/gcc-4.1 --program-suffix=-4.1
make
make install
...set up symlinks to /usr/local/gcc-4.1/bin/g++-4.1, etc...

Thialfi aims to emulate that feature. For example, I want to be able to send an email to Thialfi (using a custom address for my account, which only accepts emails from addresses I register) with a subject like “Remind me to top off the gas in the yacht next Wednesday at 5pm”. Next Wednesday, a little before 5, Thialfi will send me an email saying “Top off the gas in the yacht.” There are refinements and extensions to the idea (repeated events, SMS), but that’s the crux of it.

When Sandy went dark, some of its users talked about creating a replacement, but as far as I know none ever materialized. There are some other similar services I’ve tried, but none of them had the sheer simplicity and effectiveness (never mind the personality) of Sandy. That plus the fact that it’s an interesting project led me to start Thialfi. There’s not much there yet, and part of the curve will be learning more about Google’s AppEngine and web_app, but hopefully I’ll keep motivated long enough to create something really useful.

You can follow the action (or join in!) at the google code page.

* Thialfi is, by some estimations, the messenger of the gods in Norse mythology.

1. Immutability: users shouldn’t be able to modify the value at runtime
2. Simplicity of definition: They should be easy to define
3. Uniqueness: Two enum values aren’t equal unless they are the same, no matter what their numeric value is
4. Iteration: The user can iterate over the values in the enum
5. Pickle-able: Naturally…

Here’s what I came up with.

It uses a metaclass to add a custom __setattr__, __getattr__, and __iter__ to the user’s “enum class”, and it looks like this:

import enum

class Level(metaclass=enum.Enum):
  LOW=1
  MEDIUM=2
  HIGH=3
  
x = Level.LOW
Level.HIGH = 19 # Throws an AttributeError
etc...

I don’t know how or if linseed will continue to grow. I’m using it as a bit of a platform for learning things about distributing python, and especially using some of the new extension/plugin systems, so that may result in changes. Also, linseed is linux-only right now, so perhaps someone will decide that it needs to be extended for windows or something.

• Remembering user language selections between sessions. The normal usage pattern is to translate between between the same two languages almost all of the time, so I added a cookie which remembers.
• Added a “swap” button, much like you find in Google Translate.
• Moved some controls around. The language selection controls are above the text window now. The text window still gets focus by default, but now if you press TAB from that window you give focus to the “translate” button. Again, this is based on what seems to be the normal pattern of use.

I’d also like to give a big thanks to the gaeutilities project. I’m using their session implementation for cookie management; it gets the job done, was easy to use, and seems solid.

As always, you can use PitaTranslate at http://pitatranslate.appspot.com. If you find any bugs, have any ideas, or whatever, the project page is at http://bitbucket.org/abingham/pitatranslate/.