I Heart Ryan

I wanted to give you all anonymous access to my public git repositories, and I wanted to add a special field in my Drupal "Blog Post" content type to allow it.  (Results can be seen in my post about dbgp).  It was all pretty standard.  I added a field to my content type.  The field was of type "Link", as provided by the Drupal Link module.

I ran into a small stumbling block, however:  When I attempted to post my git:// url, the Link module told me that it was an "invalid url".  It's not.  It just has an unusual protocol name.

It turns out that the Link module  checks a variable called "filter_allowed_protocols", which was defined by the core "Filter" module.  Apparently, nobody provides a UI to edit this variable.  So I had to insert it into the database by hand.

First, I selected for that variable:

SELECT * FROM variable WHERE name='filter_allowed_protocols';

As it happened, my results were blank -- it was using the defaults. So I pulled the defaults out of the source code, and I wrote a little php, added 'git' as one of the allowed protocols, and then wrote a php script to print out the serialized version of this array.  (The reason for this step is that the 'values' in the Drupal variable table are supposed to be stored as serialized php variables).

My script looked a lot like this:

echo mysql_escape_string(serialize(array('http', 'https', 'ftp', 'news', 'nntp', 'telnet', 'mailto', 'irc', 'ssh', 'sftp', 'webcal', 'git')))."\n";

Finally, I stuck the results of that back in the database:

UPDATE variable SET value='a:12:{i:0;s:4:\"http\";i:1;s:5:\"https\";i:2;s:3:\"ftp\";i:3;s:4:\"news\";i:4;s:4:\"nntp\";i:5;s:6:\"telnet\";i:6;s:6:\"mailto\";i:7;s:3:\"irc\";i:8;s:3:\"ssh\";i:9;s:4:\"sftp\";i:10;s:6:\"webcal\";i:11;s:3:\"git\";}'
WHERE name='filter_allowed_protocols';

And now, I can post my git repositories and you can clone them.  Horray!

I just struggled with a ...bug?? that drove me a little crazy.  My site was chugging along just fine and then I would save a node, or a configuration or something, and suddenly all my views that used votingapi would blow up.

I kept looking for things that caused it -- was it the module I just enabled?  Was it this?  That?

I found out the problem, and it was subtle.

When the views blew up, I looked at the views UI screen and found that all my references to votingapi fields and sorts had been messed up -- replaced with blank lines with no descriptions and no options.

I found out that, when the views module called "module_implements('views_tables')", the votingapi module had not been loaded yet.

The solution:  I had to go into my database and decrease the module weight of votingapi.

UPDATE system SET weight=-1 WHERE name='votingapi' AND type='module';

Apparently, the two modules had the same weight, so whether or not they loaded in a propitious order depended on the random whims of their order in the database, which would sometimes change when I poked random data in there.

I don't think this is actually a bug, so much as an inevitable consequence of drupal. But mostly, something that a potential user of votingapi should know about.

You may have noticed from some of my previous posts that I'm the kind of guy who likes to use the command-line, even when there's a perfectly good gui solution. In fact, I almost regard a gui-only solution as a non-solution to many problems.

And one rather shocking probelm that I haven't seen a non-gui solution for is this one: PHP Debugging.

Since PHP is the one of the hotter programming languages for web applications nowadays, I think we're long overdue to have a good debugger for it. It gets in the way an awful lot, to not have one.

Of course, the problem of PHP debugging is being looked into. Just not the way I like it. XDebug provides us with a remote-debugging protocol for PHP. The remote-debugging protocol has its own name - dbgp. The authors gave it a name in the hopes that other programming languages could also implement the same interface. Then, we could have one debugger that could work on any programming language. That's a pretty admirable goal, in my opinion.

The problem is that we don't yet have a good client for dbgp. By "good", I mean one that has a command-line that uses gnu readline.

Here's what we do have.

We have a dbgp plugin for eclipse. Of course, eclipse is a programmer's IDE. I prefer to use the older and much more mature programmer's IDE: Unix.

Closer to home is the dbgp plugin for vim. This is actually what I use at work, and I find its workings to be adequate.  There are things I don't like about it.  For one, that when I print out values to the screen, I want to see them in a format like that of var_dump or print_r.  Instead, I get a weird format that doesn't allow me to see keys and values at the same time, and also truncates output to some arbitrary length. Furthermore, it partitions my vim windows up all weird, making it impossible to copy/paste anything out of there.  Also, because it doesn't have the command-line metaphor, I can't easily repeat evaluations I've made or anything like that.  Finally, it doesn't seem to allow me to define watchpoints.  That's just my list of grievances off the top of my head.

Most of those could be fixed within the context of the vim plugin, but there's one thing that can't be fixed in there:  Aesthetics.  I want a command-line debugger like gdb or winpdb, for Python.

Well, I tell ya.  I started work on that a little while ago.  I started from the source code of the vim plugin, and I'm trying to use the functionality of that while providing a different, command-line, interface.   I'd like to modularize it enough that the two interfaces can coexist in the same file, but behave as a vim plugin if executed in vim context or a cli program otherwise.

If I do it this way, both sides can benefit from the development of each other.

I would make one change, though:  The original is MIT licenced.  I would like to re-licence it as GPL. That's either so that I can distribute it with gnu readline support, or just because I don't want to work in my spare time on software that some huge corporation can steal from me.

If you'd like to help, feel free to grab what I've got so far from my git repository.

In a previous post, I talked about my command-line program that opens files in the same manner as gnome would if you had double-clicked it in nautilus.
I have another piece of integration that I'd like to see: Clipboard integration.

The Problem

I'm always editing text files in vim, or viewing them in less, in a terminal window. Sometimes, though, I want to take that file and copy it to the clipboard so that I can paste it into, say, a textarea in my web browser.
I could normally just drag my mouse, or select all, or whatever, then copy/paste. But using the terminal breaks that metaphor, because selecting all just selects all the things on the screen (or at most the scrollback buffer). If my file is longer than the screen or the scrollback buffer, it's difficult to get it onto the clipboard.
What I usually do in that situation is to open the file in gedit and then select all, copy, then paste. Pain in the butt!

The Solution

Why not skip the middleman? make a program that runs on the command line, takes stuff from stdin (or a named file), and then uses the gnome or X11 apis to put that text onto the clipboard. Easy as pie.

% cat blog-entry-I-wrote-offline.txt | enclip

Sure, GUIs are nice and all, but I'm more of a command-line user. But does that mean that I have to cross the rubicon into command-line land and never come back? I should hope not!

One thing that happens with me a lot is that I'm typing on my terminal, and I find I want to open that spreadsheet document. At this point, I am faced with a choice. I can either strain my brain to remember what command-line options it takes to start the OpenOffice program correctly (was that ooffice -calc? Or openoffice -calc? Or soffice -calc? Or maybe openoffice-calc...). If I decide not to go that route, I could always open up a nautilus window at my home directory, and then navigate down whatever thorny pathways I've taken to reach the little crevasse in my filesystem that I'm working in. Sure, I did it once and I could do it again, but I've already got a command prompt right there!

Mac OS X offers a program called "open", where you type open <filename> and you get the same behavior you would've gotten if you'd double-clicked it in the finder. Excellent! That way, you don't need to even remember which application you have set as your preference for opening pdfs.

I set out to implement a similar feature for users of Gnome. I call it gnopen. Now I can do something like:

% gnopen SpreadsheetFile.xls

and it'll open just as if I had double-clicked it.

About the name

Normally, I am opposed to giving programs names that start with "g", or "k" or "py" or "lin". I think, "Hey, just give your software a discriptive name. I don't need to know how much you like gnu." Plus, it can get embarassing if you write a portable application (which you should). For example, my favorite python debugger is called "WinPDB", despite the fact that it works on many platforms. Or what about people who play "Lincity" under FreeBSD?

The reason I chose to name this program after its tech stack is that it is inherently not portable. What the program does is open files the way Gnome opens files. One day, there can be a"kopen", as well, and it would be handy to not have their names conflict.

Imagine how convenient it would be if you could convert between different document formats from the command-line. You could take that word document and turn it into HTML. You could print out some HTML and have a link on your page saying "Download this as a word document". You could have your email program automatically convert Word documents into OpenOffice documents.

One application you could see is an open-source replacement of Google Docs. Right now, our rich-text editors like TinyMCE and FCKEditor do a pretty good job of doing wysywig editing of documents. The only problem with them is that they can only generate HTML. So if you want to download your document as a Word file or an OpenOffice file, then you'll have to get the HTML, fire up your heavy-duty OpenOffice application, then do "Open" and "Save As". Very labor intensive. Websites can't even count on people having this application around. Indeed, if they did, they might be using that instead of an online document manager.

So then I heard about something called eyeOS, which provides a webpage that acts like a computer desktop, with a TinyMCE-based word processor. Their pages indicated that you would be able to save your documents as Word docs.

"Oh boy," I thought. "Someone has finally solved the problem of bulk-converting between different document formats."

But I looked at it, and was disappointed. You know what it's doing? It is opening up OpenOffice and clicking on "Open" and "Save As". Seriously! It uses Xvfb to open up OpenOffice behind the scenes, then communicates with it, possibly using DCOP, to open your file and then save it.

You could not have a less efficient process unless you tried.

The thing that drives me crazy about all this -- and especially eyeOS's solution, is that we have this code, people. The secret to converting between these different document formats is not a secret at all. It is part of OpenOffice, which is under the LGPL.

So all it would take is somebody ripping out the conversion code from OpenOffice, and the internal model of documents, and jettisoning all the UI stuff that we don't need. I'm imagining a package like netpbm -- a bunch of little tools that convert from anything to OpenOffice format, and then from OpenOffice format to anything.

It'll be great. We need this. I hope to do it soon.

In setting up this site, I accidentally forgot to allow anonymous users to vote on my posts. Sorry about that. It's fixed.
But I did uncover a bug in the "Fivestar" module that I was using for voting.
Even though I told it to put the voting widget above the text of the node, it ended up putting it below for anonymous users. I fixed the bug. You can read all about it on my bug post, or download the patch from me.
The patch applies against fivestar 5.x-1.12.

Update

This was applied to the CVS in upstream, in both the drupal5 and drupal6 branches. The next release of the fivestar module will likely have it.

Unlike most people, I seem to be able to both stand and understand computer-generated speech.  I've had the computer read stories to me, and I've enjoyed those stories.  One thing I've always found lacking, though, was the ability to pause, rewind, fast forward, and bookmark.  I mean, come on, I'm not always going to be able to read every word of that short-story in one sitting, without going to the bathroom, getting a drink of water, or whatever.  Even a pause feature would be useful.

Finally, I found  something that does this.  Ksayit (I can't find a better link.  It's apparently a standard part of the kde3 desktop, so it doesn't seem to have space all its own on the kde website).  Problem solved.

But this is what I'm like -- once I solve one problem, I want to create a new one.

I recently got myself an mp3 player.  The Sansa c250. This is an excellent piece of hardware.  It's got an fm radio.  My favorite feature was the micro-SD card reader, so that if I wanted more music, all I had to do was buy a new card.  But for some reason the firmware they ship with it lets you take advantage of nearly none of its features.  It can't read about half the id3 tags I throw at it, so almost half my music is "untitled artist" "untitled album".  Every time it turns on, it spends about five minutes updating its catalog.

Fortunately, the open-source community came to the rescue and gave me RockBox, an open-source firmware for it.  RockBox transformed my barely-working mp3 player into a powerful, portable computing platform.  I can play doom on it, fer chrissake.  No joke.  I can play videos.  I can play more reasonable videogames.  I can play oggs.

Of course, now I'm thinking "Hey, I have something in my pocket that I can program."

So here's what I want to do:  Write an application for RockBox that will read text files that I put on there, and allow me to pause, rewind, fast forward, and bookmark.

It already has text-to-speech on there (for reading the menus), allowing me to choose which engine I want:  Festival,  eSpeak, and I think one more.  So really, it's just a matter of writing a UI for it.  Let's see if I do it!  I hope I do.  I would exercise more, and read more blogs if I could do both at the same time.

I often find myself ripping CDs that don't have metadata on the web yet. Of course, I want to help out the community by adding this data, but sometimes I'm too lazy. To me, this sounds like a situation where the data entry should be made easier.
Sound Juicer has a menu item that says "Submit Track Names", but all this does is take me to the Music Brainz website, looking up the TOC for the CD. Then, the Music Brainz submission process is a little complicated.
I wish that it worked where I could enter the data in Sound Juicer and then hit "Submit Track Names" and it would submit the data I just entered into Music Brainz for me, perhaps giving me some confirmation things to click on.
It seems that the main barrier to that right now is that Music Brainz has to data-submission web service API. They expect you to enter everything through the website.
I will be making a post to their mailing list as soon as I get a chance. http://musicbrainz.org/doc/NewFeatureSuggestions.

I use Sound Juicer to rip music. I use it quite a bit to rip music, seeing as how I'm a DJ at WCBN. Also, I'm often ripping pretty obscure stuff, which doesn't have metadata listed online. This means that I have to enter the data myself.
The problem I have is that Sound Juicer isn't very data-entry friendly. When entering the names of several tracks, I have to use the mouse to click between those tracks. I wish that I could use spreadsheet-like keys -- tab or enter to move between columns and rows. I am not a fan of using my mouse. One day, I'll get a headband that I can wear so that I can move the mouse around with my mind, but until then, I want applications to be keyboard-friendly.
It's true, I should be entering my tracks into MusicBrainz. I would do that if it were easier to do. See my next post about Sound Juicer.

Update

It turns out that there are some standard keyboard shortcuts that I just didn't know about. It's not exactly as intuitive as I was hoping, and it's a little bit more cumbersome than ideal, but it works. It turns out that you push enter, and you'll be able to edit one column. When you're done, push enter again and you'll be back in "navigation mode", where you can use the arrow keys to move around and push enter again to start editing another column.
In my opinion, arrow keys are almost as bad as the mouse, but not quite. It would be ideal if the straight-up spreadsheet-style key bindings worked. It would probably mean subclassing some or other widget. But the existence of these key bindings makes it so that this is no longer important enough for me to worry about, I think. I'll be posting again if I find that it still annoys me.