Monthly Archives: May 2005

Expect downtime

I will be moving things to Charleston starting tomorrow, since the movers
will be here in two days. I will be taking my computer with me. My computer
is grammarian.homelinux.net.

So, expect some downtime, both for kdesvn-build (although you can find it
both at kde-apps.org and in the KDE source repository), and for my blog.

I Love Mail

I was feeling a bit depressed earlier because 14:00 had come around and I
still didn’t get any packages. So my wife and I went out for a jog. We came
back, no note on the door. So we went out to buy some groceries.

When we came back there was a UPS truck blocking our parking spot. Yay!
In this case, a book I ordered (Scott Meyers’s Effective C++ 3rd Edition)
arrived. After reading it for about 20 minutes I get a knock on the door.

It was the FedEx guy, delivering some Home Star Runner merchandise,
including the 3 DVD Strong Bad e-mail set, some window stickies, and a “The
Cheat” T-Shirt. :-)

So in twenty minutes I went from a little disappointed to happy.

Great week

First off, Nintendo has announced their next system. Which is going to be, finally, backward compatible. So Prince or Persia won’t be obsolete as soon as I plug it in!. ;-)

Better yet, there’s apparently some sort of plan to open up the Nintendo archives and allow downloadable games all the way back to the Nintendo Entertainment System. I will say this sounds good, with a few provisos.

  1. This “feature” isn’t going to do well if Nintendo can’t get at least partial access to the third party titles. I’d pay to play Super Metroid, but I’m willing to bet many more people would pay to play Final Fantasy VI.
  2. There are many programs out there which will play old NES and SNES games. Nintendo’s next system needs to adopt some of their features, including pausing the game whenever, enhanced graphics and sound. Save states (where you can save the game literally anywhere by dumping the memory) would be nice, but I’m not holding my breath.
  3. Also, don’t make people have to pay every time. Either do a subscription model, or let people pay a one-time higher fee to keep the game.
  4. Finally, there has been an active ROM Hack/Translation community around, which has performed a lot of neat (and not so neat) things with various games. It would be neat if Nintendo could enhance the replay value of their old classics by promoting some of the better alterations.

I was worried at first when I heard that the system would “only” be 3 times as powerful as the Gamecube. But then I remembered a few years ago, when the Gamecube was coming out, and it was looking like PS2 was supposed to kill the Gamecube in performance. It turned out that Nintendo had been quoting real-world performance figures the whole time, while MS and Sony were quoting absolute top-peak-in-theory numbers. The Gamecube ended up as one of the more powerful systems of its time. And while I don’t expect the next system to top either XBox 360 or PS3 in performance, it doesn’t need to. It just needs to remain fun.

I was thinking that I might pick up a PS3 or XBox 360 in addition to the Nintendo. But they both look like they’re going to be expensive, and they both look like they’ll need a shoulder strap. I hate huge systems, which makes the Nintendo even more appealing. I’ve seen a lot of positive comments about the PS3’s styling, but I’d be afraid I’d drop it because of all the round edges. ;-)

Also, I watched Star Wars Episode III last night. Let me tell you, nothing will make you feel better about yourself than seeing a line for of people in Darth Vader and Jedi and Sith outfits, engaged in mock lightsaber battles. Unless you’re one of them I guess.

I thought of a great idea, I was going to go in line dressed up a Spock from Star Trek. Unfortunately, I thought up the idea while I was in line, so nothing came of it. ;-)

As far as the movie itself goes, I think think that George Lucas should get hired to write dialogue for soap operas. Because that seems to be the upper range of his romantic-writing skills. Luckily the rest of the movie more than made up for it. It was really quite good overall.

Getting back into coding

It’s weird. All said and done I must have made at least 8 separate commits in the past 24 hours. And I’ve done a lot of work in the past couple of days as well, which really is nice.

I’ve done a lot of work with kdesvn-build, including merging patches from Thiago Macieira and levipenumbra to add support for printing build progress, and building API documentation. That and a bugfix or two was in 0.95. The version in HEAD has the dest-dir option I wrote based on a suggestion by coolo.

What dest-dir does is allow you to choose a different name on-disk for a module (which is handy for mapping extragear/games to extragear-games if one wanted). Although it’s not a difficult change, it exposed a lot of assumptions in the code as to where files will end up, so it feels a lot cleaner now.

I’ve been working on adding the ability to perform module updates in the background while a module builds, which would speed the whole process up. Threading is the obvious solution, but I have to say that Perl’s concept of threading is el crap. Apparently you can’t really rely on threading to be present either, but I don’t want to have to fork kdesvn-build processes and deal with all the IPC. *sigh*. A test app that I wrote to test it out did work pretty well though, so it is possible if your Perl has ithreads. I just need to integrate it into kdesvn-build and make it works with and without threads.

Finally, I’ve been doing some work on JuK as well. The major change in HEAD is the addition of the Cover Manager code. There’s not much user-visible change at this point (although you can rename the Artist or Album field of a track with a cover without losing the cover). Hopefully I’ll be able to lift the restriction on tracks without an artist or album before too long.

Thanks to some suggestions by wheels you shouldn’t notice much difference in startup time, as even though the cover manager will import old-style covers, it will delay that until the absolute last minute. Also, now that the covers are centralized, I was able to implement a cover cache, that way the covers shouldn’t all be loaded into memory at once.

I’ve also made some tweaks to the search line. You can press F6 to focus the search widget above the playlist. After typing your search, you can hit the Down key to highlight the playlist and select the song you want, and hit Enter to play it. So hopefully habitual keyboard users will find JuK easier to quickly use.

Charleston, and stuff

I’ve been cooped up here in Charleston for a few days now. It’s kind of
annoying. I can’t go home since I’ve checked in, but apparently the Navy has
no transient housing in Charleston, so I have to stay at a hotel. The
gov’t will reimburse me, but it’s boring as all hell here. I’m hoping to get
to talk to the officer in charge of students checking in who haven’t classed
up yet and see if I can return to Jacksonville on phone muster, since all I’m
going to be doing here is (essentially) showing up at 8:30, saying Hi, and
leaving again.

In my downtime today I managed to be productive. I made a new release of
kdesvn-build,
which has the virtue that I can work on it even when my only connection with
Linux is an ssh terminal connection.

Also, I’ve figured out a way for svn+ssh users to not have to type their
username when connecting to svn.kde.org. It actually wasn’t that hard, I
just needed to remember that it was ssh that needed help with that, not svn.
So, what you do is, open up your ~/.ssh/config for editing. At the bottom of
the file, add the following:

Host svn.kde.org
User 

Where is the username that you use to connect to svn.

Sweetness

I guess that since kdesvn-build is now one of about two scripts out there that can build KDE from Subversion, that there is more interest in using it.

I’ve received lots of advice and actual code from Thiago Macieira, who is apparently planning to switch from his custom scripts to kdesvn-build. Duncan Mac-Vicar, meanwhile, has been using it since it was called kdecvs-build, and has started on a Ruby-based rewrite that uses the same configuration file format so that it can eventually supplant kdesvn-build.

I fully support the idea of rewriting it in Ruby. Perl has been a good language to use for the core, due to the fact that it supports regular expressions right in the language, among other things. However, Perl has many shortcomings compared to Ruby.

First of all, Ruby has a far superior set of KDE bindings at this point. More importantly, it has supports Object-based programming that doesn’t stink. I’ve been meaning to clean up kdesvn-build for months now, but even after quite a bit of weeding I’ve done over the past two days, it still resembles an application straight out of 1986.

With Ruby as the language, we’d still have great support for regular expressions built into the language, but we’d also get objects and the possibility of building in a GUI for essentially free. In addition I’d be able to abstract a lot of the hacks that I’ve had to put into my script.

Many places in my script special-case qt-copy, for instance. It would be nice if, instead of having to do:

if ($module eq 'qt-copy') {
    # do some special qt-copy thing
}
else {
    # normal module
}

everywhere I needed to deal with qt-copy, I’d be able to abstract it away into some kind of qt-copy module. Even now kdesvn-build has the same kind of idea in many places, with functions named like get_module_builddir(), but like I said, it’s straight from 1986. ;)

In other news, the kdesvn-pywizard script has been ported to support kdesvn-build, and improved as well. It requires PyQt, and you can find it in /trunk/kdenonbeta/kdecvs-build. Before breaking anonsvn down, you should realize that it’s strictly a configuration file wizard, which actually should be less useful than it sounds now the kdesvn-build has some sane option defaults.

Finally, I thought it would be neat if the meta info for .torrent files would tell you how many people were seeding and/or downloading the file. Turns out I’ll probably have to improve my .torrent-reading code first, since apparently arbitrary non-zero-terminated strings can be used as keys for the b-encoded dictionary used by the tracker, which of course my code doesn’t cope with yet. =D

If no one sees me for the next few days, it’s because I’ve gone to check in at my next duty station. My school doesn’t start until early June so hopefully they won’t have me holed up twiddling my fingers between breaks to an Internet cafĂ© ;-)

tada

To celebrate KDE’s migration from CVS to Subversion, I have ported kdecvs-build to kdesvn-build. The biggest change is, of course, the fact that it pulls source using svn instead of cvs. However, there were a few other changes to boot.

  1. Colorized output (it can be turned off, and it’s still rather sporadic)
  2. It should be able to build a sane basic system without a configuration file.
  3. It supports the new layout of the /playground and /extragear directories. If you use those directories you should add kde-comon as well, I forgot to make that happen automatically.

It could use more testing, so feel free to have at it! Note: it’s probably still quicker to start download the source first from the tarballs at http://ktown.kde.org/~coolo/svn/, just make sure you remember to run svn switch –relocate if you use this method.

KDE has now migrated to Subversion

You didn’t hear it from me, but I was just able to make my first commit into KDE’s new svn repository (Sorry for not waiting for you, coolo!). The first line of code that I added was:

// BWAHAHAHA EVIL HACK

so I’d say the future looks pretty bright. :)

There’s a guide for KDE contributors online here. Users of my kdesvn-build script might have to wait for me to work any lingering bugs out.

Redesigning the JuK cover storage system

I’ve been working the past couple of days on designing and implementing a new cover storage system for JuK. The current system, although it works, has a few limitations:

  1. It requires the artist and album information for an album to be filled in, due to the way the cover is stored on disk.
  2. The system simply associates cover art with tracks based only on the artist and album information. This can be useful as it means that you only have to tag one song to get cover art for all songs from that album. But it also means that all songs from the same album must share cover art, which a user may not want.
  3. Things like compilation albums simply don’t work well under the current system, as you have to store a duplicate copy of the same cover for every track. This also affects things like songs from the same album, some tagged as Disc 1, others tagged as Disc 2.

The new system I’ve designed should be more suited to dealing with those problems. The way it works is, instead of having cover art for an artist and album combination, each piece of cover art is registered with a Cover Manager, which keeps track of each piece of cover art, any data associated with it, and what tracks use that piece of cover art.

What this means is that there isn’t a lot of data that needs to be stored with a track, as each track is basically given a reference to its cover art, which the Cover Manager will use to grab the right file.

All that I’ve implemented so far is basically what we’ve already had, but now the potential for improvement is there (and shouldn’t be that difficult to implement). For example, it shouldn’t be hard to assign a piece of cover art with just an album name instead of needing the artist information, or to allow overriding’s JuK’s choice for a track’s cover art.

I think what we’d need is some sort of Cover Manager dialog that would allow you to manage your covers, drag a cover onto tracks, etc. I’ll have to ask wheels about it.

In other news, now that KDE is in the process of migrating to Subversion I thought I’d let everyone know that an initial port of kdecvs-build to use iswas in KDE CVS (kdenonbeta). I’m not sure of the new layout of kdenonbeta, but it’s sure to be in the shiny new Subversion repository as well.