I finally replaced my vintage 2008 ThinkPad X200s, after months of agonising over which of keyboard, form factor, hidpi display, and software freedom to compromise on. Just in the nick of time, Dell released a developer edition of their widely-lauded XPS 13, which is spot on: same comfortable form factor (with 2015-era thin-ness); huge display with minimal bezel; conservative, usable keyboard layout; supplied and supported with free software; and the Sputnik team are very amiable on Twitter. I’m very happy with it.
I was less happy with how ludicrous Bustle looked on it, with its total ignorance of hidpi scaling and retro Gtk+ 2 stylings. I finally found the spare evening I mentioned 18 months ago and freshened it up to not let the amazing screen down.
Source tarball and x86-64 binary available from the usual place.
The freedesktop.org git repository is temporarily out-of-date due to some poorly-synchronised GPG and SSH key migrations, so for now it’s at GitHub.
(Hey, actual Bustle users! How do you feel about it as a piece of software? I’d be interested to hear.)
It’s Bustle release season! Here is version 0.4.3’s flagship new feature:
(Previously, it would crash.) I fixed a couple of other crashes, too, spurred by Sujith Sudhi reporting a i486-only crash. I feel compelled to point out that all of these crashes occurred in C code or at the inter-language boundary.
No Gtk+ 3 yet, I’m afraid, though experimental support in the Haskell binding was released a couple of days ago so it’s just a matter of a spare evening…
Meanwhile, why not follow my latest Twitter bot, @fewerror? It will provide you with 100% accurate corrections on a tricky point of English grammar.
Breaking with the “every six months or so maybe” release tradition, here’s the second Bustle release of the month. What’s the new hotness this time? You can record D-Bus traffic by just clicking File → New, and watch the diagram being drawn before your very eyes. After years of on-off development, Bustle can finally liberate you from needing to open a terminal to monitor D-Bus traffic. Here’s a super-brief video tour.
Grab it for x86_64 or i486 today! Unlike the previous release, these work on both Debian and Fedora and have a strong change of working on pretty much anything with a modern-ish Glib and Gtk+2. (Thanks to my fellow Collaboran Guillaume for testing these tarballs, and to Scott Tsai for his suggestion.) Source and so on at the usual location.
Today’s surprising Bustle-assisted observation is that switching to and from the Shell overview causes the Shell to retrieve
/desktop/gnome/shell/windows/button_layout from GConf 29 times. (Presumably that number is proportional to the number of windows I have open?) This was extremely useful for testing the live-logging feature, but is perhaps not ideal in many other ways.
It’s a cold evening here in Cambridge, but I’m being kept warm at Collabora Towers, sipping a revitalizing mug of fresh applicative functor soup.
A mere five months after I demoed its features at the Desktop Summit in Berlin, here’s Bustle 0.3.1. Whereas previous versions of Bustle only recorded and showed you the names, senders and destinations of D-Bus messages, this version also records and shows you the contents of the messages.
The statistics page also takes advantage of this new information: you can now get statistics about the sizes of messages in the log. Grab your copy today from the usual location. Beside the source, I’ve also uploaded a 64-bit binary tarball to save you some compilation time. Give me a shout if you have trouble with it.
32-bit version to follow when I get my chroots straightened out.
I have good news and bad news. Good news: here’s a 32-bit binary tarball. Bad news: seems like Debian and Fedora have differently-sonamed libpcaps. Why is distributing software so tedious?
Bustle 0.2.5—“Why go all the way to Glastonbury to not watch U2 when you can just not turn on the BBC at any point this weekend to not watch them?”—is out now. This release adds a sidebar containing statistics about the log: namely, method call and signal emission frequency, and total/mean times spent in method calls.
This code has mostly been sitting around in a branch since Plumbers in November. Sorry, dear users!
Just released Bustle 0.2.4. Various bits of clean-up and bug fixes were kicking around in master that should have been released months ago. The viewer’s much more Postel-compliant, so if you’ve had trouble with your D-Bus logs being rejected with cryptic errors messages, you should upgrade. Also, Sergei Trofimovich contributed a build fix: thanks!
While we’re here: Bustle finally has a bug tracker! Bugs are in the Bustle component on freedesktop.org Bugzilla. And the Git repository has moved to freedesktop.org too. With luck, the next release will be more exciting.
I just released Bustle 0.2.3. The notable improvement is that you can now view a pair of D-Bus traffic logs side-by-side on the same chart. So if you’ve taken a trace of the session bus and the system bus, and want to see how the bus traffic matches up on the two, this is the release you’ve been waiting for! (If not, well, I made the ugly pink lines a more tasteful grey, and fixed some bugs you never noticed.)
While I was refactoring to support the second log, I would have liked to have been able to run Bustle in a “batch” mode to render straight to a file, and then run some kind of visual diff tool to compare the output of the branch versus the last release. Coincidentally, when I opened my inbox, I found a mail requesting the same feature! I imagine that this could come in handy for producing automated reports: maybe you’d have a weekly cron job that produces some stats about the traffic using bustle-count and, if it goes significantly up or down, sends an email to tick off or congratulate the relevant team as appropriate with an attached diagram. If anyone fancied having a crack at this, it shouldn’t be too hard.
A couple of days ago, I released version 0.2.1 of Bustle, someone’s favourite D-Bus profiler. As the version number suggests, there aren’t really any big new features; most of the changes just make it a bit nicer to use, like showing you all the bus names a service owns, ellipsizing strings, a slightly less spartan UI, etc. Having finally gotten around to cutting a release, I’ve started wondering what to work on next. There are various small things I have in mind, such as searching, filtering, integrating the various statistic tools (bustle-time and friends) into the UI, and so on, but it’d be nice to have a larger goal to work towards.
One recurring feature request is the ability to see messages’ arguments. This isn’t currently possible because the simple plain-text logs produced by the monitor (which is a variation on the theme of dbus-monitor --profile) only includes the message header. I’ve thought for a while that the right thing to do would be to log the raw dbus messages, together with a timestamp, but wasn’t sure what the files would look like. (Maybe shove the timestamps into the message headers?) Rob had a nice idea: why not log to pcap files? This avoids inventing a new format—the UI would just use libpcap and feed each message through the dbus parser—and would also let you look at the logs in WireShark, if you’re into that kind of thing. I’m hoping to find some time to give this a shot soon. (Maybe on a cold Christmas evening, in front of a fire?)
In the meantime, have a peek at what your D-Bus-using applications are up to, and let me know what’s missing!
When working on Telepathy, I’ve often wanted to be see which D-Bus methods are being called on whom, when signals are emitted, and so on. Timing information is also handy: I’d like to figure out why cold-starting Empathy takes 12 seconds, and it’d be much easier if I could look at a diagram rather than staring at the unreadable output of dbus-monitor.
Previously, Alban wrote a tool that used a patched version of mscgen, and produced appropriate input with a dbus-monitor-like Python script. I wanted some more D-Bus-specific diagrams, and ended up reimplementing both the monitoring component (by forking dbus-monitor, as its --profile output did not contain quite enough information) and the diagram-drawing component (using Cairo). I’m happy to present an initial release of Bustle:
There’s a Telepathy-specific hack in the tool to shorten object paths, but it shouldn’t make the tool any less useful for looking at other D-Bus traffic.
I haven’t made binary packages yet, I’m afraid, so you’ll need to grab the source tarball and build it if you want to try it out. In Debian-land, the dependencies are libdbus-1-dev libglib2.0-dev libghc6-mtl-dev libghc6-cairo-dev libghc6-gtk-dev libghc6-parsec-dev; see README in the source tree for how to build and use it.
The astute among you may have noticed from the dependencies that the diagram-building component is implemented in Haskell, using the excellent bindings to Gtk+ and Cairo. I got a prototype going within a few hours, and the strong correctness guarantees that the type system provides meant that I could refactor it mercilessly with confidence. I’m sure that I would have spent many frustrating hours chasing type bugs had I written it in Python, which is a more conventional high-level language for prototyping and writing tools like this. Next time you’re frustrated by such bugs, you should give Haskell a try.
Edit: Bustle now lives at willthompson.co.uk/bustle.