Going back to school has really ate into my Anime watching time. I suppose it’s all for the best, but my Anime Tierlist sucks this season, because I haven’t seen very much. So it’s pretty simple:
When developing Riker, I had a bit of a choice – I could either write (from scratch) a new library to interface with the MusicBrainz XML webservice, or I could create bindings to access the existing libmusicbrainz library from within Vala. Up to today, I’ve gone a little ways down both paths, and both have problems.
If I write new bindings from scratch, they’ll have some nice features like integrating into the Glib main loop, and automatically determining proxy settings from the environment. But it will be a lot of coding; and even more debugging.
The existing libmusicbrainz code is better tested, and writing bindings is less overall code to write. Unfortunately, I’m writing Vala bindings for the C bindings to a C++ library. The extra steps cause some weirdness, which means that the bindings are more complicated than I would like.
And then there are a few things with the C bindings to libmusicbrainz that it simply gets wrong. For example, it has no working typechecking! As a result, even some of the internal test code gets types mixed up, causing hard to debug issues. I’m working on a patch to correct this, which will change the C bindings API slightly. (But curiously enough, not the ABI).
But in the end, simply to get started faster, I decided that the bindings are the way to go. The hypothetical GObject-based MusicBrainz webservice library will have to wait for another day.
Take a look at my progress so far on the vala bindings at libmusicbrainz4.vapi.
Maybe I’m just used to having too much power at my fingertips. Git was designed, from the ground up, to provide operations to do absolutely anything to a repository, right down to the most basic level of manually creating individual objects in the repository. Using user-visible command-line tools that can be operated from scripts. It is literally possibly to reimplement most of the user visible Git commands (such as “commit”!) using shell scripts and some of the more-basic Git “plumbing” commands.
So, there’s no surprise that Git commands support special script-friendly output modes. A good example: git log --numstat will print out a summary of the changes in a commit in a parser-friendly tab-delimited format. Mercurial doesn’t have this option. (Someone wrote a patch to add it, but it was rejected!)
And then there’s the issues with speed. I’m writing a script that generates a summary of the differences between two branches based on which commits have been merged into each branch.
$ time git log --pretty=oneline --numstat brancha..branchb
real 0m1.081sSo, about one second. Not bad for a command that’s summarizing around 400 commits from a 250 MiB repository. Lets see if Mercurial can keep up:
$ time hg log -r "ancestors('branchb') - ancestors('brancha')" --template "{node} {desc|firstline}\n" --stat
real 3m51.994sOk… That command took over 230× as long in Mercurial as Git. Amusingly, the same repository in Mercurial is around 500 MiB – twice the size! (For the record, it’s mainly the --stat that slows it down. If I remove the stat, Git takes 0.167s, and Mercurial 0.421s). This is completely unusable.
So, why is Mercurial around 200× slower to calculate the differences contained in a commit? I don’t know. But they really should fix it.
This season honestly doesn’t look that great. But there’s a few multi-season shows which I am continuing to watch, and a couple of new things on my radar. Here goes:
I waited, and I saw. (Or didn’t see, as the case may be.)
As always, a more well-rounded opinion and a more complete overview can be found at Anime News Network’s Summer 2011 Anime Preview Guide and in the Summer 2011 Anime Chart.
Hmm. Some interesting stuff this season, mixed in with some less interesting stuff. I’m bored, so I simplified the list even more!
As always, this list will change once I actually start watching stuff… (There’s far too many things on the “Awesome” and “Yes” lists right now.)
Don’t forget to also check out AnimeNewsNetwork’s Anime Preview Guide, or the Spring 2011 Anime Chart.
Instead of making up arbitrary numbers about how awesome (or not) each show is, I have simplified the rating system based on a simple measure: How likely am I to watch a new episode of a show when it comes out? Here’s the ranking.
Updates whenever I feel like it. Check back later, collect them all!
I will not miss a single episode of one of these shows. I’ll be polling the internet waiting for notifications of new episodes to come out…
These shows have shown themselves to be pretty good, so I’ll watch them if I notice a new episode’s come out and I have some time to spend on it.
I like these shows, but not enough that I’ll force myself to keep up with them. There’s a chance I might not ever finish them, or that I’ll finish them after the season’s over.
These shows are barely amusing enough that if I’m bored I might go check to see how many episodes I missed.
These shows don’t interest me at all, and I’ll probably never watch them unless someone somehow convinces me to.
These series I either haven’t seen or haven’t heard enough about to place on my ranking list. Give them a couple episodes and some word-of-mouth, and they might show up somewhere. Or not.
This is the initial release of the waitproc tool.
Download it from the Github Release
With the SHA-1 checksum:
68fa23ee77abef48552ab9d82819fa9fece36f2b waitproc-1.0.tar.gz