Andy Balaam’s Blog

When you first hear about the Read-Eval-Print Loop you might well think “So what?” as I did.

What’s so great about being able to type commands interactively?

But the thing is that it creeps up on you.

Everyone already knows programming is an interactive thing – we need constant feedback to validate our ideas. Programming on paper is incredibly frustrating because you have to plough on with assumptions that are probably wrong.

It’s just so comfortable to be able to try out ideas in an interactive interpreter.

I mean, it’s really not much hassle to create a new directory, make a new file, edit the file to contain the code you want to try, remember the right command to compile it, then run the program and see the results, is it?

Well, no, it isn’t, but it’s enough of a hassle that sometimes you don’t bother and you try it out in the code you are really working on, and if your work is like mine that means a minimum of 5 minutes to compile and link, and there you are playing foosball again when you could be getting something done.

The REPL gives you a place to try throwaway things extremely quickly, and when you’re working with something beautiful like Python it’s easy to get addicted.

So my mind started to wander and it struck me that a pale imitation of the REPL could be made for us poor C++ programmers, and it would generally serve the purposes I’ve described above.

So IGCC was born. Its name means “Interactive GCC” and it’s a read-eval-print loop for C++ (and, for most cases it will work for C too).

It uses the real GCC underneath, so you know you are running the exact code you would be (and it’s somewhat easier to write than a custom C/C++ interpreter) and all it does is take away the hassle of creating a simple program and compiling it with GCC.

It wraps your code in a standard C program, includes some common dependencies, and compiles it, printing the results of running them immediately. Using it looks like this:

$ ./igcc
g++> int a = 5;
g++> a += 2;
g++> cout << a << endl;
7
g++> --a;
g++> cout << a << endl;
6
g++>

Apart from all the sugar that I’d love to add, the main missing features are some kind of equivalent of the Python dir command, and code completion.

It’s not rocket science, but it might make you a little bit more interactive in your C and C++ coding, which might save you valuable foosball time.

Enjoy, improve, etc. IGCC.

Foosball image taken from http://en.wikipedia.org/wiki/File:Baby_foot_artlibre_jnl.jpg

Git is supposed to work when you upload your repository to an http server, but in reality, no-one except me seems to use it, and it’s nothing like as useful as having a proper repository that people can commit to etc.

So, here it is: http://repo.or.cz/w/gssmp.git.

Enjoy.

There was a weird bug in my last.fm support for GSSMP, where it would crash when run from the GNOME panel, but be fine when run from a terminal.

After two bugs fixes from Charles Bailey, the problem seems to have gone away, so I’ve finally been able to make a release.

Now I have to resist the temptation to choose songs to make last.fm think I’m cool, instead of songs I actually want to listen to.

And I really need to fix the debian/Ubuntu package of lastfmsubmitd so that the client exe lastfmsubmit is included in the package. Without that, using last.fm with GSSMP is a major hassle.

Obviously I should have gone to bed, but I’ve got last.fm support working in GSSMP. It’s in the git repo, and I should get a release out as soon as I’ve written a little bit of documentation.

So I’ve released GSSMP 1.1, which is guaranteed to contain one fewer bugs, and is relatively unlikely to contain any new ones. Also, thanks to João Pinto, it should build without warnings on AMD64 too!

If anyone wants to make an AMD64 package, I’d be really happy to put that up on the download page. It should be a simple matter of unzipping the source, cd-ing into the gssmp directory, and running make pkg-all.

Go on, it’ll be fun…

Get it here: http://gssmp.sourceforge.net.

This is the first time I’ve declared one of my projects stable, and given it a 1.0 version number.

Prove me wrong by downloading it and breaking it.

Enjoy.

Now I must dash – I’ve just got to finish off my other projects.

I’ve just released version 0.9 of GSSMP, and since I’ve fixed all the bugs I know about (except working around a gstreamer bug, which I will try to do before 1.0), I’ve marked this release as beta.

This is the second project I’ve marked as beta, and I am determined I am going to get to 1.0 this time. That means no more features, just bug fixes, and hopefully a 1.0 release in a few weeks, when it’s had a bit of testing.

Really, I think FreeGuide should have had a 1.0 release a couple of years ago, but I’ve always had a lot of features in mind before I feel it is complete. I think this was a mistake: it was pretty stable at one point, and it might have been helpful to label it as such.

GSSMP is not going to fall into that trap! It’s supposed to be minimal, and that is what it is.

It’s surprising how many features would be nice to have in a minimal app, though, like being a drag and drop target and checking the MIME types of files before playing them, not to mention cool stuff like gapless playback and volumne balancing…

But no, these will have to come after 1.0. My focus needs to go back onto FreeGuide after GSSMP 1.0, as I’ve been neglecting it, and it needs some love if it’s ever going to get to 0.11 … and 0.12 … and so on for infinity … and then after that, 1.0.