Kickstarter Video Games and GNU/Linux

I actually don't play video games very much (maybe a couple hours per week at peak, but more commonly zero), but I have been buying a lot of them the last few years (Humble Bundle), and helping to fund several game development initiatives on Kickstarter. What the heck is going on?

Long video game hiatus

First, this is coming from someone who as a young man, adored video games and spent way too much money on them. But when I got to college I stopped for financial and study reasons. Up until a few years ago, I bought very few video games. To put it in perspective, I stopped buying games back when they came in gigantic boxes, back when actual voice acting was reason enough to buy any game, when DRM was called copy protection and it often times involved looking up a particular word in the manual, or a spinny decoder wheel thing. However, the way I see it now, video games are more important than ever to my future happiness.

Something new has started recently. Relatively well known developers are starting Kickstarter campaigns to fund video game development. This is pretty cool in itself, but what makes it much cooler is that many the developers are going to be making truly cross-platform games (MS Win, MacOS, GNU/Linux).

I am putting out money for these games that I might, in all reality, never play. I'm doing this for one reason, they are showing a willingness to support GNU/Linux systems. Now, don't pigeon hole me as a person that thinks all software should be FOSS (even though that is what I believe), my reasoning is more that I want and need a more stable platform from GNU/Linux than is currently available and I think that video games are an important first step towards that goal.

Video games drive stability

Here is the way I see it. Video games make beaucoup bucks. With that money, people start to think about how they might make it easier to make more money, and that is where the stability will increase. If you look at the shortcomings of GNU/Linux as compared to MS Windows systems, the most glaring problem that I see is that hardware is poorly supported. The best way to get hardware supported is to impose a financial incentive to have them work and work well. That financial incentive scales with the number of users. The number of users is highly correlated with the number of well programmed flashy computer games. I will go so far as to say that there is likely a causal relationship where a vibrant games market draws more users.

But there aren't enough GNU/Linux users out there

Of course, to a studio that sells millions of copies of a game, the number of home PC GNU/Linux users might seem negligible. I actually don't think this is the case. Now, I don't know if anything can ever de-throne MS Windows in the PC game market, but if we look at the numbers from such promotions as the Humble Indie Bundles, we see that a good chunk of that money is coming from GNU/Linux users. Fairly consistently, we have seen the money from GNU/Linux users hit around one eighth to one quarter of the total money raised. In the last bundle, GNU/Linux contributions hit around the one sixth mark; that's \$100k that would have been lost if not for the GNU/Linux support. We can discus why this is the case (my guess is a combination of record numbers for GNU/Linux users and a form of video game starvation), but I think it is hard to argue that this number is negligible.

For a project like Double Fine Adventure, perhaps it is not too far off to think that \$550k was due to the GNU/Linux support, and perhaps \$350k for Wasteland 2. To contrast, one wonders what to expect for another project I would have been very interested in, Shadowrun Returns, which has announced that they will not have GNU/Linux support. Are they missing out on one sixth of their possible funding? Is the cost of porting to GNU/Linux more than that lost funding? Update: Shadowrun Returns has announced that if \$1M dollars is reached, there will be an effort to port to GNU/Linux after the release. This is pretty nice and while it would be great to have Linux support promised now and without the post release delay, I'm pretty sure that \$1M will be reached and any support is better than none. Yay! I won't pick on Al Lowe here, as budget is his primary concern right now, and it is too soon to tell what is going on with Jane Jensen's project. I wish you both the best and I'll be watching for other (hopefully new) titles on Kickstarter. I will say that I am kind of over LSL (much more of a Space Quest and King's quest fan) but if there was a GNU/Linux version, I'd throw \$15 at it to support it.

So, here is the point. I think these projects should be supported. Go do it, now. But I also think people might want to start considering GNU/Linux as a deployment platform, and not for the novelty of it ala Id Software, but for the profit of it. Now, I realize that game developers are not reading this blog (I know this is true because no body is reading this blog ;) but maybe if you are reading it, and you run into someone that does make these kinds of decisions, some of these ideas will leak through during your conversation.

Also, since I don't want to post on this stuff again, a quick note. The Humble Bundle started as a promotion where the games were released as FOSS after a certain goal was reached. This is no longer the case or this goal is very high. I guess I just want to relay my own data point to the world on the value of libre source. I paid \$30 for the first bundle after I heard of the possible source release. Now I have dwindled to around \$5 for each. Just a word of advice, releasing the code as FOSS is valuable to people and people are willing to pay more for it.

Uh, did you forget about Libre Software?

Oh, right… Well all of this stuff happening in our little nook of the world of video game development is great, but not exactly perfect. However, I have a differing opinion on video games than the FSF has.

To me, closed source is 'okay' for DRM-free, non-mission critical software.

Contrast against something like a computer algebra system that you use for your job, a financial books program that you use for your personal or work finances, or an operating system where you run everything. Having these be closed source means that you have relinquished a great deal of knowledge of how useful your work is, and correct and accurate your financial records are, and how safe any of your private data is. Having these be open source but non-Libre means that you have relinquished control over these things, but at least you know where you stand. In an ideal world, everything would be FLOSS and we would have come up with a widely applicable funding mechanism, but this isn't an ideal world yet. If there is going to be something non-Libre in the mix, I suppose that a video game that is fundamentally a luxury, is the best one to have, but only so long as there is no DRM attached to it. This is a big 'but' and I cannot stress this enough. If there is one place where we have demonstrative proof of the abuse of proprietary software, year after year after year, it is with DRM for video games.

So, let me reiterate. Libre games would be a boon for gamers. I would like games better if they were Libre, all else being equal. But, the importance of a particular piece of software being Libre Software is directly proportional to how much of my life depends on it. For video games, this is sufficiently unimportant to the point that I feel that it is okay to support DRM free video games, particularly if there are fringe benefits like attracting more users, developers, and hardware vendors to GNU/Linux.

Running a Command Whenever a File Changes

Every once in a while you probably would like to have a command run every time a particular file changes. I know I did when I was writing some Latex based presentations with Beamer and was using the latex to dvips to gs chain of commands to compile the document into a PDF file. I came up with a way to ease these steps by detecting changes in the document's DVI file that Emacs writes for me. I later thought of a couple of other methods and figured I would put them up here in case anybody ever needed something similar. I included all of them as you never know when you need to put together a hack on some old or limited system, or just a system that you don't control and thus cannot install new software.

I decided that the interface of my little script should be to specify a file to watch, the watch file, and a command to run when it changes, the on change command. The on change command should take one argument, the watch file.

Watch File Modification Times

In this version we look at the watch file modification time and compare it to a reference time that is updated every time the watch file changes. This is definitely a cheap way to find these updates. The easiest way I could find to check the modification time of a file was to create a temporary file which acts as a time stamp. We just check which file is newer and touch the temporary file any time we want to update the time stamp.

#!/bin/bash

watched_file=$1
command=$2

# First we need a temporary file to test against
marker=$(mktemp /tmp/on-change-XXXXXX)

# We have to trap the EXIT signal as we want to clean up our tmp file
trap "rm -f $marker" EXIT

# Loop until killed
while true
do
    # If the watched_file is newer than the marker...
    if [ $watched_file -nt $marker ]
    then
        # Wait for a bit to make sure that the file is done being modified
        sleep 1
        # ... run the command ...
        $command $watched_file
        # ... and reset the marker
        touch $marker
    fi
    sleep 2
done

One thing to note is that this script, like many scripts, has a race condition in it. If it happens to detect a modification of the watch file but the modification is not yet complete, it will trigger the on change command and then probably get an error from it, then detect another modification the next iteration. This will continue until the program modifying the watched file has completed its work. This is bound to happen for short polling times (here we use two seconds) or long running programs that modify the watch file. This is the reason I added one second delays after the modification time based test. The delay is to try and give time for anything that is currently underway to complete. It helps, but of course fails to help other times.

A possible problem here is that it is easy to trick this into doing more work than it should. The watch file might be repeatedly touched but never actually modified, which would lead to unnecessary execution of the on change command. The key is to note that the newer modification time is a necessary but not sufficient condition for the file to have changed. It leads to false positives, but is very cheap.

It should be noted that, in the case of compiling Latex documents, while this can happen, it is a pretty rare event. But, if we are building a general purpose tool, it is something we should worry about.

Watch File Hash

How can we eliminate the reprocessing of identical files? File hashes.

The next technique is to poll the file for actual file changes. We don't need to keep an old copy of the file, or anything like that, we just keep track of the file's old hash value. Every two seconds (plus the time it takes to hash the file) we compute files hash and compare it to the old file's hash. If they differ, we run the specified on change command and update the stored hash value.

#!/bin/bash

watched_file=$1
command=$2

# Compute the reference hash value
hash=`md5sum $watched_file | cut -f 1 -d\ `
while true
do
    # Grab the files hash
    newhash=`md5sum $watched_file | cut -f 1 -d\ `
    # If it has changed...
    if [ $newhash != $hash ]
    then
        # ...run the command...
        $command $watched_file
        # ...and record the new hash
        hash=$newhash
    fi
    sleep 2
done

This has the advantage that it never needs to run the on change command unless there is an actual change in the file. This means that for an expensive on change command the method works very well. However, for very large watch files the hashing becomes unnecessarily expensive.

However, the race condition is still there and this time it is worse. Whereas in the modification time test method we could try to give the modifying process extra time to complete, this time we don't have that option. We just have to blindly try again until we get it right.

Use INotify

As is often the case, you find something that is a better solution than what you have hacked together after you have long since found a good enough solution to your problem. This is the case with the me and INotify.

The INotify kernel facility was designed for just the problem I was attacking. It provides, via a kernel interface, a way to hook into the file system and receive notifications on events such as reading from, writing to, opening, and closing files. If you are on one of the mainstream distros and have been keeping things even remotely up to date, you probably have an INotify ready kernel, but might not have the shell tools installed. We will be using inotifywait, which blocks until a specified file system event is triggered. In this case, we are interested in file modification events, so we will pass the option -e modify to the program. Just a note, this is taken almost verbatim from the inotifywait man page.

#!/bin/bash

watched_file=$1
command=$2

while inotifywait -e modify $watched_file; do
    # Wait a bit, in case the modifier is still working
    sleep 1
    # Then run the command
    $command $watched_file
done

This is much simpler than the other methods. A real strength here is that this is short enough that it really doesn't need to be a script at all. You can just memorize this. This is definitely a pretty good version, but it still has that race condition. So, one last version, where we will wait for the file to not be modified for a few seconds before we run the command on it. We can do this because inotifywait provides a timeout which exits with a 2 if it did timeout.

#!/bin/bash

watched_file=$1
command=$2

while inotifywait -e modify $watched_file;
do
    while [ 2 != $(inotifywait -e modify -t 1 $watched_file; echo $?) ]
    do
        echo waiting...
    done
    $command $watched_file
done

This catches most of the race condition issues, I think, but the price you pay is that you have to wait at least one second after the file has been modified before the file can be processed by your script.

Of course, without a proper synchronization mechanism, which needs to be agreed upon by both programs and thus is largely incompatible with the shell idea of small self contained programs, you will never get rid of this race condition. It is firmly up to the user to ensure that two different programs are not accessing the same file at the same time (actually, I think we can go a long way towards solving this by using lsof and checking if the watched file is still open. I don't have time to explore this but lsof $watched_file seems to be promissing).

Combine The Methods

We can have the best of all of these methods by combining them into one monster script that checks for changes using INotify (with a modification time check fall back) and then confirms that the file has actually changed by comparing the file hashes. But I wont bother because this is already too long, both in words and time spent typing and editing.

Using It To Automate Latex Builds

I said I wanted this to make compiling Latex documents easier. In order to do that you just use something like:

on-file-change presentation.dvi dvipdf

Of course the best method would be to figure out how to make Emacs run this post processing for me. However, I have so far failed to figure that out and this little tool is applicable to more than just this scenario anyway.

The Broken Weight Problem

Some elderly academics were sitting next to me at the cafe today and they were discussing some mathematical puzzle, "The Broken Weight Problem." I'm not the best eavesdropper so I gathered a few search terms and popped them into Google, and viola.

Basically the idea is this. A merchant accepts goods in 40 pound increments. He uses a simple balance scale and a 40 pound weight to weigh the goods. One day, he accidentally dropped the weight and it broke into four pieces. After a bit of consideration, the merchant realized that, quite amazingly, each piece was an integer number of pounds in weight and, using his broken pieces of the weight and his balance scale, he was able to measure out any integer value from 1 to 40. The question is, what are the weights of the pieces? Hints and solutions after the break

---

Okay, a hint in case you are really stuck. You do realize that with a balance scale, the merchant is able to place some pieces on the other side of the scale which will act as a counter balance? This means that a five pound and a three pound piece can also measure two pounds, for example.

---

Now for solutions. Since we probably have a Common Lisp REPL close by, the easiest thing to do in this day and age is to just plug it in and have a computer solve it. But how do we do this? Well, it is simple enough using Screamer.

I start by grabbing a few libraries I will use, Iterate and, as mentioned, Screamer.

(ql:quickload '(:screamer :iterate))
(use-package :iterate)

First we define a test to see if a given set of piece weights can build an integer:

(defun check-integer (i w x y z)
  (iter (for s1 from (- w) to w by w)
    (finding
     s1 such-that
     (iter (for s2 from (- x) to x by x)
       (finding
        s2 such-that 
        (iter (for s3 from (- y) to y by y)
          (finding
           s3 such-that 
           (iter (for s4 from (- z) to z by z)
             (finding s4 such-that (= i (+ s1 s2 s3 s4)))))))))))

This function is pretty self explanatory. Given a set of weights, each weight can be in one of three places, on the right side of the scale, on the left side of the scale, or not on the scale at all. When applied to the balance of the scale (where zero means we have a balance) these states correspond to a negative value of the weight, a positive value of the weight, and a zero value for the weight. This is exactly what we are doing with these loops. Since there are only three states for each, it is simple to see that this will only require checking $3^{4}$ different possibilities at worst case.

Then we delve into the magic world of nondeterminism.

(screamer::defun stone-split (total-weight)
  (let* ((w (screamer:an-integer-between 1 (1+ total-weight)))
         (x (screamer:an-integer-between w (1+ total-weight)))
         (y (screamer:an-integer-between x (1+ total-weight)))
         (z (- total-weight w x y)))
    (if (and (> z 0)
             (iter (for i from 1 to total-weight)
               (let ((works (check-integer i w x y z)))
                 (always works))))
        (list w x y z)
        (screamer:fail))))

Here we are defining our function that will find zero, one, or several solutions to this problem depending on how we call it and if solutions exist. I left a free parameter total-weight so we can play with it, though it proves a bit boring to play with only that value. Things to note:

1. We need to use the defun from within the screamer package. This version of defun is special as it allows for simulated nondeterministic computation (via CPS I believe, but I'm not the guy to ask about that). The library suggests that you use screamer:define-screamer-package to make a package with the proper defun interned, but I am lazy.
2. The forms using screamer:an-integer-between tell Screamer that the solutions to this problem are some integer in that range. Screamer will handle figuring out which.
3. The screamer:fail form informs Screamer that it has chosen the wrong value. This will force Screamer to backtrack to the last integer range with values left and pick a new one.

We need to execute this function from within a "Nondeterministic Environment," which is commonly either inside a screamer:one-value or screamer:all-values form. So we invoke it like this ( fixed package namespace thanks to Derrell):

(screamer:one-value (stone-split 40))

…and it finds the correct result. Admittedly, this could be solved very simply without the use of Screamer, but I would argue that it requires less mental overhead when and produces much more flexible code using the Screamer route. What is the correct result?

---

I looked at it this way. You have three values a piece of weight $w$ can take, $-w$, 0, or $+w$. Therefore it seems to me that we have a set of equations:

\[ \alpha_i w + \beta_i x + \gamma_i y + \delta_i z = i ~~~~~\forall i \in {\mathbb N}_{1}^{40} \]

Where I use ${\mathbb N}_{1}^{40}$ to denote the natural numbers (starting from 1) less than or equal to 40. We know from the problem description that $w,x,y,z, \in {\mathbb N}_{1}^{40}$ and that $(\alpha, \beta, \gamma, \delta)+1 \in {\mathbb N}_{0}^{2}$. You could go about trying to solve these very over determined equations (edit: Actually it's underdetermined, hence we get multiple solutions. Limiting the values to integers is what makes it hard), however, this all might start looking familiar. This looks very much how you would calculate the value of a number in some (possibly irregular) base where the Latin symbols denote the value of each digit and the Greek symbols denote the value in that digit place. In this case, we are limited to three different values in our digit places, so it seems prudent to use base three. Thus the values of each digit place should be powers of three. Thus the answer should be 1, 3, 9, and 27.

How do we know we will have a solution? We need our trinary representation at least reach 40. Since half of our numbers are negative, we actually need to reach 80 in the positive only encoding. The largest value for four digits of trinary is (+ (* 2 27) (* 2 9) (* 2 3) (* 2 1)) or exactly 80. Also, it is a happy coincidence that our numbers also add up to 40, everything works just fine. If we look at how many unique solutions exist for other total weights we see that it seems that 40 is the largest weight we can get to with four pieces. This is a direct consequence of 80 being the largest 4 digit trinary number.

Total Weight	Number of unique solutions
4	1
5	1
6	2
7	3
8	4
9	5
10	7
11	7
12	9
13	10
14	10
15	11
16	12
17	11
18	12
19	12
20	11
21	11
22	12
23	9
24	9
25	9
26	7
27	7
28	7
29	5
30	5
31	5
32	3
33	3
34	3
35	2
36	2
37	2
38	1
39	1
40	1
41	0
42	0
43	0
44	0
45	0

On LaTeX and Microsoft Word

Sorry, this is a ranty post. Adjust your desire to read appropriately.

I was busy writing my APS abstract this last week. When we got near the end I was having a heck of a time getting Bibtex to work with Latex and insert my references properly. Later on I realized that APS doesn't really allow for citation ala Latex and Bibtex, but whatever. I was struggling with this, and mentioned to my advisor, jokingly, "Man, I hate Latex." He says, also jokingly, "you could use Microsoft Word." I say sure, despite the fact that the APS website says they prefer Latex and that Latex is actually easier for the submitter, MS Word is no problem. In fact, that is kind of the point. I wrote my abstract using Org-Mode precisely because it made little to no assumptions on the end result. I can export to Latex or one of the many other formats or just grab my text and paste it into MS Word with no problems. I can also send it to any human being in the world with a computer and that person can open it and understand what they are seeing. Hell, in a handful of keystrokes I could post it to this blog.

Later, when printing, my advisor changes from his joking suggestion to insist that I use MS Word (presumably so that I can export to a Rich Text Format document that the APS accepts). This will make it easier, right… So, I copy/paste it over to a document and save it as an RTF file. Low and behold, of course, the equations are not interpreted by word. It would take at least 15 minutes and perhaps up to an hour to figure out how to get the proper symbols, fonts, and kerning into the document for submission. The last kick to the nuts is that the APS provides an RTF template, but in order to use it, you must actually type the document into it yourself, by hand. If you copy and paste it into the template something, apparently, will get screwed up. I will repeat that, the American Physical Society requires you to actually, physically, press the keys on your keyboard while their template is open in order to submit an abstract (though I imagine something like xdotool might serve me well here). This is what happens with you use things you don't understand people. You get black magic crap like this.

Point is, I miss my previous colleagues and advisor, nay entire department, nay entire institution where they held the opinion that any individual in the sciences should be using Latex as their format for correspondence. Also, bravo to the APS for encouraging people to use Latex for submitting abstracts.

Time Lapse Fun with FFMPEG and Mencoder

I was in the office early this morning and saw the sun rising. I captured some video of it (my phone can do 30 minutes of 720p, though it doesn't look that good). However, the thirty minutes of video is rather boring to watch in real time. So I decided to speed up the video.

Speeding up the video was actually much more difficult that I thought it would be (and I am somewhat acclimated to the troublesome nature of FFMPEG and Mencoder). Anyway, in order to perform the speed up I used the FFMPEG filter select to only pass every n^th frame. The large the n, the faster the speed up. At the same time I chose to convert to WebM (the phone puts out H.264+AAC and placed in an MPEG4 container format). This produces a video file with only every n^th frame, but the video just hangs for the time it would have been displaying the other frames. To fix this, I then passed it through another program, mencoder. This program fairly similar to ffmpeg in purpose. The mencoder program has a special option, -speed, that will speed up the video stream by a factor you specify. This means that if we use -speed n then we should get the desired video frame rate. Refer to the man pages and FFMPEG manual for more insight for what is happening here.

ffmpeg -i VID_20111025_071454.m4v -vf select='not(mod(n\,50))' -an temp.webm
mencoder -ovc copy -oac copy -speed 50 temp.webm -o faster.webm

This would have been all it would take, however, since I am using Maverick Meerkat, the version of FFMPEG included doesn't have support for filters. This means that, ugh, you can't use the first command. Not unless you install a newer version. I avoid compiling libraries from source like the plague. Instead I added this PPA to my software sources and updated my software. This actually gave a lot of scary errors and almost tricked me into a dist-upgrade to Natty, (shame on you apt, I wouldn't do that to my worst enemy). But in the end, those commands did work (as evidenced by the videos).

The end result, we have a video where only every 50th frame show up in the output. This resulted in a pretty good effect. I didn't actually point the camera at the sunrise as that would cause problems with the contrast and I couldn't balance the camera on the window sill pointing that direction from my office. So it's not as dramatic as an actual sunrise.

I also captured another 30 minutes later that morning as the clouds forming as the air passed off the flatirons was a pretty cool dynamic effect.

Of course, all of this is kind of stupid (neat, to me, but stupid), as time-lapse is usually done by taking individual frames spaced seconds to minutes (or more) apart. Also, there are several options available on the Android Market. Though I wouldn't install them without researching the application and developers.

Fixed Point Emacs Completion

One of those annoying things about GNU Emacs is that when a window is popped up containing completions, it derails what you were doing.

First, completion windows take up half the frame. I can't actually figure out how to change this easily. Think of how you use the completions window. One primary way I use it is: I try to complete a symbol, realize that it doesn't have enough information, then type more and try again. In this case, having so many options doesn't help at all. I only need to know if there the symbol can be completed or if there are multiple possibilities.

Second, the position of the cursor on the screen is almost always changed when a window is popped up, and interestingly enough, not even in a predictable way. This means that if I try to perform a completion which I expect to have only one completion, thus not popping up a window, but it actually has several possibilities, I have an annoying situation. This could happen as a result of a symbol I didn't know about making the completion ambiguous resulting in a pop-up and a partial completion or it could be due to a typo. In either case, I need to examine what is at the command prompt in order to find out the proper course of action. This is unavoidable. What is avoidable, however, is the need to move the command prompt around the screen forcing the user to go searching for the new location.

In addition to these pretty legitimate claims, I also just find the entire process to be jarring. I often find myself kicked out of my current train of thought as I search for where my cursor has gone. Here is an example of how completion tends to work in Emacs.

When these two effects combine, I got so frustrated I started leaving my frames split in half so that completions will show up in the other window without effecting the window I was editing in at all. In a recent Reddit conversation with Stassats, he states that he also always maintains a completion window. To me, this is a big waste of screen space, but at least the point doesn't jump.

There are other solutions to this problem. My guess is that many people struggle with this and each produce their own solution. For instance, here is a post of how to designate a particular window for completions in someones (rather complicated for my taste) completion window setup.

My solution

The code is here, though I can't vouch for it being bug free.

My solution is to have windows pop-up with completions but have those windows be smaller than half the screen. An important distinction is that when a completion window pops up, it will not alter the screen location of the point. In order for this to be the case, we need to pop-up a window in an area of the frame that the cursor isn't utilizing. So, we handle this by identifying where in the frame the point is, then popping up a smaller completion window in either the top or bottom of the frame depending on its location.

To be precise:

1. See if there already is a visible completions window. If one exists, use it.
2. See if the current frame has only one window (when not counting the minibuffer). If it does, we know that a popup is desired.
   1. If the current window is actually the minibuffer, create the popup at the bottom of the frame.
   2. If the point is above the halfway point in the frame, create the popup window at the bottom of the frame.
   3. If below the halfway point, create it at the top of the frame.
3. If it matches none of this, let Emacs do as it would have.

Here is the result:

This works pretty well for me, but I imagine that is just because I might use Emacs in a quirky way. For instance, I usually have one desktop where all of my Emacs windows are. If they are on different desktops, perhaps the "use completions window if 'visible'" won't work very well. I don't know how Emacs handles this. What about terminal emacsclient instances and how does completion there interact with open X windows. All of these things should be configurable.

Anyhow, if anybody else finds this useful and wants to push patches back to me, please do. If anybody wants to grab this code and take over the project, or include it in your project, again, please do.

Other completion extension libraries

While I haven't found anything out there that does exactly what Fixed-Point-Completions does, there are a few libraries that also tweak completion. Most notably, popwin and icicles extend the completions functionality. Icicles is a bit heavy handed for my taste, changing many things in how Emacs functions. Popwin does a lot towards fixing my completion issues, but not enough. The thing which is really missing from both of these is that they still shift the visual location of the point at times.

Modf support on ABCL

No posts in a long time, sorry for that.  Probably going to be dead around here until PhD is taken care of.    I take solace in the fact that nobody reads this blog ;)

One good piece of news that crossed my RSS feed today: ABCL 0.26.2 was released.  Normally this isn't something I would really care that much about, but the change log says they fixed the apply/setf problem, which is a current failing of Modf on ABCL.  This means that, while Modf will still fail the test suite (due to no MOP, which is needed to expand class accessors if the user didn't specify an expander), it will work much more closely to how it does on other Lisps.  I think it is correct to say that Modf will work as long as all expanders are actually specified (i.e. not expanded at run time).  This is great news for any ABCL+Modf users of which I'd bet there are approximately zero.  Maybe now there will be some.

This should just work without any changes to Modf, but I'll try to find time to test it sometime soon.