MaW’s Blog

Firstly the hysterical laughter. I know I mentioned it last in the topic, but it’s very, very funny and deserves to go first, so first it has been put.

With that out of the way, what else was I going to write about? Ah yes. Towel proceeds. It needs a good deal more polishing, but it’s gradually getting there for another release, this one with significant enhancements. The things I’m aiming for are:

• metadata caching in saved playlists, leading to improved load times
• don’t have GDK markup errors on track titles with double quotes in
• use GStreamer 0.8 (done)
• use GStreamer for metadata reading, instead of id3lib, libvorbis and libflac
• metadata editing using GStreamer
• miscellaneous UI improvements
• anything else that seems like it’ll fit

After that, the next release will likely dual-build with gtkmm 2.5, which is important because there are some handy new widgets I would find useful, lots of nice bug fixes and stock icons for play, pause etc.

Another project I’m starting to help with related to Towel is gstmm, the C++ bindings for GStreamer. They use the same system as gtkmm does, so they should be eminently compatible with a gtkmm application such as Towel. Development has unfortunately been stalled for quite some time, so hopefully Bryan Forbes and I will be able to get something passably wrapping GStreamer 0.8. And hopefully it won’t take us all year to do it.

Last night was the penultimate Tai Chi before Christmas. Not many people came so we didn’t do a new move in the longsword form, but instead spent quite a while doing Chi Kung and pushing hands. Learned some interesting things, improved my technique in one kind of movement particularly. Then we revised the longsword form as far as we have reached, which was useful to pick up on the details that tend to get lost in those first few weeks after doing a move where you’re more worried about which arm to stick out than the finer points of the move. Curiously, everyone at Tai Chi thinks the way Christmas is handled by the shops is very irritating. Where are the people that the shops are doing what they’re doing all this for?

Not sure what I’m doing for Yule yet this year. We shall see. The full moon group are doing a Yule ritual, so it’s likely I’ll go to that. It is highly likely to be a significant improvement on doing one solo.

NaNoWriMo continues. My novel is now flagging slightly behind the 60,000 word pace. It’s difficult to keep up the momentum once work starts to take over, and my sudden urge to restart hacking on Towel doesn’t help very much. For the uninitiated, Towel is a fairly simple audio player for GNU/Linux and FreeBSD. It started off as little more than a pretty GTK+ frontend to GStreamer, but now it’s a little more complicated than that, as the playlist system is rapidly becoming more and more complex. I think it may have reached its natural limit now, and is gradually getting filled out with missing functionality.

Recently I’ve been working on getting it to compile on my native 64bit Linux system, which wasn’t too hard because it was fairly intelligently coded the first time around (actually the most serious problem was with printf format strings generating warnings about variable sizes). The nastiest work was porting to GStreamer 0.8, which should have been done a long time ago but is done now and works quite nicely.

Currently I’m implementing properties dialogs for groups and tracks, which will help people figure out what the checkboxes in the groups and tracks views are for as they can be set from the properties dialogs as well — this is until GtkTreeView gains proper tooltip support, but I suspect that might take a while and may even be a GTK+ 3.0 feature. Also on the list are metadata caching, so Towel doesn’t have to probe every file in the library for its title/artist/length data every time it starts up, better handling of file read errors (there are going to be some holes exposed by the metadata caching system, as previously we relied heavily on all the files being read at startup), and general UI love for the library window.

Moving onward, there’ll be a release, then I’ll port to gtkmm 2.5 to take advantage of some useful new features, such as ellipsizing labels and stock icons for play, pause, stop and so forth. For now I intend to keep the project at SourceForge, but it’s going to have to move into a Subversion repository somewhere at some point; I just can’t be doing with CVS anymore.

And many thanks to Bryan Forbes, who says he’ll do some testing and offer assistance with the UI design.

Now I just need to get hold of Jonathan again…

Got this from UFies.org — it’s titled about web designers, but I think it’s true of commercial software development in general. Oh, how it’s true.

Come to think of it, it also applies to Free Software development, and it’s mostly down to people not knowing what they want. In the commercial world, that’s because the sales people don’t know what the customers want, because the customers haven’t thought it through properly, so the sales people figure out what they think the customers are going to buy, and pass that on to the developers with the air of ‘do this and the company will be rich’.

If I sound cynical right now, it’s because I am. Don’t you like nice, simple reasons?

The last few days I’ve been reading ‘Perl 6 and Parrot Essentials’, 2nd Edition, in order to get a better handle on this whole Perl 6 design issue. A lot of the language design I kind of knew, but bits of it have changed since I last looked at them, and it’s nice to have everything set out in a book, although I know for a fact that some of the bits of the book have now changed as well, because Larry Wall was talking about them on perl6-language the other day. But that’s life when you’re following an under-development language.

Anyway, I mostly got the book to get a decent introduction to Parrot, the Perl 6 runtime, and such it is. Such a good introduction in fact that I’ve decided that, just for fun and to do something different and because I’m pining to write code in a functional language, I’d pick up my final-year project (a compiler for a toy language called Triangle, written in Haskell), rip out the code generator (which doesn’t work very well anyway), and replace it with one which produces Parrot assembly.

Remarkably, this is turning out surprisingly well. I suspect I’m going to have to delve into Parrot’s object definition system in order to simulate records accurately, but most of the rest of it is quite easy — easier than generating C was. Wish I’d done this to start with, I might have actually finished the generator in time for hand-in. I couldn’t have got more than a first for the project of course, but I could have got a higher grade anyway. I like playing with languages, and I like high grades too.

Forgotten how much fun it can be. I know I should really be working on Towel or Westlands, but neither of those really enthuse me at the moment. Towel’s in C++, which I do a lot at work, and Westlands is in PHP, which after doing Perl so much at work is just confusing. Programming professionally has its drawbacks.

If I get all the Triangle compiler up and running to target Parrot, I think I’ll send it over to Graham Hutton, who was my dissertation supervisor. Just to prove I’m still doing things. Maybe I should do that PhD after all…

Well it’s unlikely anybody involved in the whole thing will ever read this, but I have to write it now because it’s getting on my nerves.

Currently in the GNOME world there is a debate going on, and I don’t think it’s ever going to be resolved to the satisfaction of the participants. The main cause of this debate is the Mono project. As many people who read this blog will know, Mono is an open-source effort to implement a clone of Microsoft’s .NET platform, complete with common language runtime, class libraries and C#, Visual Basic and JScript compilers (at the very least). There’s an ASP.NET container, GTK+ bindings and all that stuff too. Now this is all very fine and dandy and I actually quite like C#. It’s like Java done right.

Now, Mono was developed by Ximian who are now part of Novell, so Novell (which also owns SuSE) is now pushing Mono. Evolution, GNOME’s mail/PIM client, is also developed primarily by Ximian. People there want to start extending it in Mono/C#.

Red Hat have decided that Mono is not suitable for shipping in their products. They believe the patent issues are too problematic. Seth Nickell, being a Red Hat person, agrees with them in a most articulate fashion, as does Havoc Pennington. Who is also a Red Hat person.

I, personally, find the patents issue rather alarming. While it wouldn’t actually be all that beneficial to Microsoft to do it (well, it might be in their muddy world view, but it’s not in mine), they could potentially decide that the RAND grant on their patents on the standardised parts of .NET doesn’t cover open source implementations under the GPL. Bam. Instant court case. And actually one they have a chance of winning. This we do not want.

Imagine that happening if GNOME’s core was by that point partially written using Mono.

Okay, now you’ve recovered from that, let’s look at the alternative most people are punting: Java.

The truth is that Java is at least as bad a choice as Mono. For one thing, it’s a disgusting language, although I admit I’m not necessarily representing the entire world’s opinion on that. Some people actually like it.

For another thing, the licence for Java implementations has some really rather nasty clauses in it, making projects like gcj and GNU Classpath, which are currently the only way we’re going to get Free Software Java, a little bit potentially dodgy. Sun have control over Java and they want to keep it. Microsoft, as is entirely probable, want to keep control over .NET. Fair enough to both of them.

So what can we do? The whole debate assumes of course that GNOME needs a high-level programming language to be used in the core. This is probably true - at least for the applications. I don’t really think it’s appropriate at the moment to write the core libraries in anything other than C, for the sake of the language bindings if nothing else, but…

The main attraction to .NET is not just the C# language, but the CLR. This allows applications to be written in many different languages, which can all, through the CLR, access each others’ objects. C# may create a subclass of a class defined originally in Managed C++, and that class might contain an instance of another class which was defined in JScript, or Python (yes there is a Python implementation on .NET now, and it’s very quick too).

So that’s great. Makes multilingual development pretty good. You can even use Java with it these days (why would you want to though? Still, the choice is there).

But there’s the patents thing, and there’s the fact that the patents are held by Microsoft. Do we trust Microsoft? Of course not.

So. What do we do?

I think everyone should go have a look at Parrot. People may dismiss it, because it’s not ready yet and because it’s being designed as the Perl 6 runtime engine. Which it is, but it’s also a multilanguage runtime which can give us multilingual object access and other such things much like .NET’s CLR does. And guess what - Free Software.

Plus Perl 6 rocks, of course. If GNOME is going to move to anything higher level, I’d really like to see Parrot considered as a runtime, with Perl 6, Perl 5 (Ponie), Python (implementation for Parrot under development) and anything else that runs on Parrot as initial implementation languages. I know they probably won’t run as fast as C# on .NET, being dynamically typed languages and all, but something tells me Parrot has the potential to make a significant impact on GNOME’s advancement.

The question is, do we want this impact to come from the Free Software community, or from Redmond?