Year: 2010

MassifG 0.2.2

Posted on2 Comments

Another day, another release. This release fixes:

  • Missing axis labels – now it is explicit what each axis represents
  • Inconsistencies with GNOME HIG: Button ordering in save/open dialog and missing ellipsis for menu actions which require further user input
  • A error message on canceling in the save dialog which should not have been there

Ubuntu 10.04 packages are now in the Openismus PPA. Due to scheduled downtime for Launchpad it might take an hour or two before they are built. The tarball is here, Fedora 13 packages here (i686, x86_64). Arch packages are still in AUR, and Gentoo packages in Dave’s overlay.

I’ve updated the README to include information about the roadmap and tasks to be done. Check it out if you’re interested in improving this small tool.
Hopefully there will be a massifg product in GNOME bugzilla soon (I’ve made a request), but in the meantime just report problems to me by email.

Here is yet another screenshot:
2010-09-09-122757_1680x1050_scrot

MassifG 0.2.1; now packaged for your favorite distro*

Posted onLeave a comment

*if your favorite distro is Fedora, Ubuntu, Arch or Gentoo.

This is a bugfixes-only release, and fixes regressions in print/save functionality (which rendered 0.2 kinda useless, thus the quick point release) and a parsing bug on 32-bit platforms. Behavior of the open/save dialog has also been improved. Tarball is here.

Packages:

I’ve pushed the package files for Fedora and Ubuntu to a branch in case anyone wants them. The packages should require little to no adaption to work on earlier distro versions than the tested ones. The Ubuntu package should also work fine on Debian. With time I might work to get the packages into the official repositories, but that is not a priority at the moment.

Berlin concerts awesomeness

Posted on2 Comments

A few weeks back I saw Gojira (warning: horrible flash based site, even the myspace page is better) at Knaack here in Berlin. While I hadn’t listened to Gojira much before going, it was a great show. Nice venue, sound was good, kick-ass music and performance, and the crowd loved it. What more can you ask for?
The event was promoted by a company called Trinity Concerts, and apparently they do a whole bunch of good stuff this autumn. Here are the ones I plan to go to between now and Christmas:

  • 22.09.2010 – This Will Destroy You
  • 02.10.2010 – Anathema
  • 06.10.2010 – Porcupine Tree + Oceansize
  • 05.11.2010 – Alter Bridge
  • 02.12.2010 – Irepress & Constants
  • 08.12.2010 – Caspian

I might squeeze in Dark Tranquillity or Tarot or Apocalyptica on the 24th of October, and Ludovico Einaudi on the 16th of November too. Maybe even Sabaton, depending on how good their new album is. I was also hoping to be able to see Epica while they are on tour, but they are not playing in Berlin (!), and the Oslo date does not fit with when I want to go back to Norway. I guess Poznan is only 3 hours away…
In any case, I think I know one or two people that are mighty jealous of me right now. And they ought to be.

MassifG 0.2

Posted on1 Comment

MassifG is an application for visualizing the output of valgrinds massif tool. See the first release announcement for more info. Here is the high level list of changes since version 0.1:

  • Graphing component ported to use GOffice – graphs are much nicer now
  • A detailed view has been implemented
  • Parses the heap trees found in massif snapshots
  • Menu entry for directly exporting graph to a PNG file
  • gtk-doc based API documentation

Of course there were also many minor changes, fixes and improvements. Here is how it looks now (simple and detailed view, respectively):

massifg-0.2-simplemassifg-0.2-detailed

The tarball can be found here. Packages for Arch are in AUR. I’m also hoping to make packages for Ubuntu and Fedora in the next couple of days.

Roadmap

I will probably move my focus over to C++ and other tasks now, so MassifG progress will be slower, but here is what I’d like to see going forward.

  • Show name of the function when hovering over the graph.
    Minor thing, but it will increase usability a lot as it can be very hard to see which legend entry the data corresponds to in the detailed view. Requires support in GOffice
  • Add axis labels and title with information from the massif file.
  • Improve usability on small screen/window size.
  • The detailed view currently needs a lot of space, and does not work nicely when this is not available. Need to ask the GOffice people for some hints and tips here.
  • Make an API and UI for running massif.
    This so that users don’t have to invoke massif manually, and then open the file in MassifG to visualize the results. Would additionally be nice if the graph was updated interactively while massif runs, but that is secondary.
  • Make a UI widget for visualizing the heap tree.
    Possibly a GtkTreeView. I’m open for suggestions here.
  • Expose a public library with the relevant parts of the API.
    This way, others applications can use it – if anyone is interested I’d love to have some feedback on the API. I am of course open to changing it if necessary. Support for GObject introspection would be nice too.

If anyone would like to work on any of this, give me a hint so we don’t duplicate effort. Let me know if you have any other good ideas too.

Determining physical topology of hotplugged USB devices with udev

Posted on1 Comment

As part of a bigger project of mine, I wanted to answer the following questions: How can one tell which physical port a hotplugged usb-device is plugged into on Linux? Can one do this when the device is plugged into an usb-hub (i.e: non-root hub) too? Since this is potentially useful to others out there, I share my findings here.

The usual “lsusb” or “lsusb -v” gives no indication that the kernel knows about the physical topology of the devices connected to an USB bus. However “lsusb -t” does indeed show the topology, so the kernel does know about it and make this info available to user-space. So, how to use this in udev? Prodding some USB storage class devices with udevinfo, shows that there is no attribute that gives this information directly. But, the DEVPATH attribute for USB devices actually contains this information.

For instance, an USB mass storage device connected to port 2 of the root-hub with bus number 2 has the following devpath: “/devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.0/host12/target12:0:0/12:0:0:0/block/sdb” and a USB mass storage device connected to port 5 of the root-hub with bus number 1 has the devpath “/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/host5/target5:0:0/5:0:0:0/block/sdb”. It becomes a bit confusing when there are USB hubs involved: “/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0/host16/target16:0:0/16:0:0:0/block/sdb” refers to a device plugged into port 1 of an USB hub plugged into port 1 of a second hub which is plugged into port 1 of the root-hub with bus number 2.

We see that in all cases the information about the physical topology is in the substring just before “:1.0”; “2-2”, “1-5” and “2-1.1.1”, respectively for the given examples. And that the format is “$busnumber-$port” for the simple case of connecting the device directly to the root-hub, and $busnumber-$port1.$port2  ->   .$portN for the general case, with N-1 usb-hubs between the device and the root-hub.

Just to show that this works, here is a quick and dirty udev rule and helper python script which parses the devpath and creates a symlink to the first partition of a USB mass storage device under /dev/usb based on the bus and port the device is connected to. Results might look like this:

tree /dev/usb/                                                                    Thu Jul 29 17:34:38 2010

/dev/usb/
`-- 2
    `-- 2
        |-- 2 -> ../../../sdc1
        `-- 4
            `-- 4 -> ../../../../sdb1

A more useful thing to do might for instance be passing through all devices connected to a certain physical usb-port to a certain virtual machine. Or maybe letting an embedded system responding differently to USB devices plugged into a physically secured root-hub than to one that is available to the user.

Introducing MassifG 0.1

Posted on4 Comments

MassifG is an application for visualizing the output of valgrinds massif tool. I am writing it as part of my trainee program here at Openismus. MassifG is free software, available under GPLv3. You will find the git repository at gitorious, and the tarball release for 0.1 here. Packages for Arch are available in AUR.

Used together with massif MassifG gives you a nice, simple graph of allocated heap memory over time which you can use to help evaluate if your program is leaking memory or not:

Current status

With release 0.1 MassifG can:MassifG 0.1

  • Parse and display a simple graph from massif output.
  • Open files selected on the command line or from the UI.
  • Print out the graph to a printer or file. This code was contributed by Murray Cumming – thanks!

I was hoping that I could make version 0.1 the “minimally useful” release, but I have to admit that it is not quite there yet. Instead I nickname release 0.1 “getting it out there”. The main issue is that there is massif output that breaks the graph, see under tests/ for an example.

Implementation

MassifG is written in C, and uses GTK+ for its graphical user interface. Once the ability to export the graph is implemented, it should be easy to allow the application to build and run without GTK, if anyone wants to do that.

The parser is a simple state-machine. It might have been wiser to use bison+flex, and I’ll reevaluate that when I need to implement parsing of the detailed output.

The graph functionality is implemented using Cairo and Pango. While Cairo and Pango are excellent technologies with nice APIs, they are quite low-level and that means having to care about all the details. As that brings no benefit to this application I might rewrite the graphing functionality to use the goffice library instead. Sadly there seems to be little high-level or introductionary documentation to goffice APIs, so I might have to fix that along the way.

Roadmap

In the short term I will:

  • Implement parsing and graphing of the detailed massif output
  • Fix the graphing bug(s)
  • Add the ability to export/save a graph as PNG,PDF et.c. without having to go by the printing dialog

In the longer term I’m considering:

  • Adding the ability to run massif on a program directly from MassifG
  • An interactive mode which updates the graph while the program to be analyzed is still running
  • Making a custom widget which other applications can embed

In the meantime, please do give the current version some testing, and report bugs and other issues.

LGM2010 writeup

Posted on1 Comment

This weekend I attended Libre Graphics Meeting in Brussels, and got to meet a bunch of great people from lots of different projects. Got to meet people working on similar things (at least in the same ballpark) as MyPaint, like Krita, GIMP and Nathive. Also got to meet and hang out with some of the awesome people on the Durian Open Movie project. They were using, and were more fond of, MyPaint than I thought.  Also chatted with several other users, some of which were using MyPaint as a part of their workflow in a professional environment. Good stuff.

The entire conference was very professionally executed, no technical or organizational problems, yet they were able to maintain a nice cosy atmosphere. The only thing I didn’t quite like was the food, but thats mostly a matter of personal preference (they only served vegetarian, and I’m a quite dedicated carnivore).

There were plenty of good talks, and if you’re interested in them you should check out the video recordings done by River Valleys. I also attended some workshop/BoF sessions, here is my take on them:

OpenRaster BoF

The OpenRaster BoF turned out to be quite different from what I expected. I expected only a couple of people from Krita, GIMP and MyPaint to show up. But no, we had lots of people attending, even professional standards people from Adobe, w3c and Opera! I also somewhat suprised myself (ok, I know that I like to talk and am not afraid to do so, but still), by taking an active role. We did get useful things done, like consensus on that we want to define a minimal baseline standard, and to have fallbacks for things extending upon the baseline. The concrete specs have not been settled, but hopefully we (MyPaint+Krita people mainly) can take care of that pretty soon.

I hope to try out some implementation ideas for fallbacks soon, and to improve the GIMP implementation, but school is keeping me very busy now a days. In fact, the first evening in Brussels was spent finishing my bachelors thesis report, and sunday was spent on my final report in my english class. And its far from over yet…

A Libre Graphics Foundation?

There was a birds-of-a-feather session for a potential “foundation” to support and promote libre graphics projects. Apparently these ideas have come up before, but this year it seems to be gathering some traction so it might actually happen. Different people have different views on what exactly it should be about of course; some are looking in the direction of Blender Foundation/Institute, doing open projects, funding developers, and having official teaching; others are more interested in having common documentation about libre graphics software for users. In any case, a common resource and face for libre graphics projects would be good. But in the end it will boil down to what people step up and make happen, I suspect. Discussions are ongoing on the create @ freedesktop.org mailinglist, so jump in if this tickles your fancies.

LGM2011

In the discussion during the last day, Montreal and Vietnam were proposed as locations for the next LGM. I’d love to go either way, haven’t been to Asia nor North-America. Perhaps even do a talk of my own? Still, it’s much further away, so it might require a very interesting program, depending what I’m doing at that time and how busy I am. We’ll see. If if turns out to be more of an end-user conference, and less of a developer/contributor meeting I’d love to have David Revoy and/or Ramon Miranda do MyPaint workshops. That would be beyond awesome.

In the meantime, it looks like GUADEC will be my next conference, only 8 weeks away. I’m already excited!

It’s a tragedy

Posted onLeave a comment

It’s a tragedy, that some hide behind a mask.
Pretending that everything is good,
pretending to be someone else.
It’s a tragedy, that the mask is never dropped.
Not for friends,
not for family.

It’s a tragedy, that some find life so hard
That a quick end seems the best solution.
It’s a tragedy, and it happens every day.

To H.

Hello Openismus, Hello Berlin

Posted on3 Comments

Openismus

Looks like I will be joining Openismus in Berlin from July, as one of three trainees! There is much to learn, but that’s gonna be half the fun. The other half will be working with something I really like, free and open source software, and with great people in a very good environment.

Going from living in my childhood home with my parents, studying at the local college, to my own place in a big city in a foreign country training/working as a software developer is going to be a big change. But I feel like a change, and I don’t think it could have gotten much better than this.

But before that; Hello bachelors thesis completion and Hello exam preparations!

Grapikslabor, MyPaint meetup, attending LGM2010

Posted onLeave a comment

Very sorry about the wall-of-text-with-no-images. I’ll do better in the future, promise.

While on my trip to CERN I spent a couple of days in the area of Zürich. On Sunday 2th of May I traveled from Geneva to Zürich (coming directly from a night-shift, ugh). There I attended Grapiklabor, which is a series of workshops on graphics using free software held by Alessandro Rimoldi, a Scribus community member. On the schedule that day was vector based graphics with Inkscape. It was a very useful workshop for me, I now have at least a pretty good idea of how to use Inkscape to solve real problems.

MyPaint developer meetup

In Zürich I also meet up with Martin Renold, the creator of MyPaint. In addition to attending Grapiklabor with me, he was kind enough to let me stay in his home in Winterthur for a couple of days. On Monday we went for a longer hike in a nearby forest, an I got a tour of the city. Of course, with the two most active developers together, the meeting also involved some MyPaint hacking:

– We did some design for our oldest bug; adding some sort of fixed size image functionality. The challenge is doing that without compromising on MyPaints  infinite canvas feature, but still being intuitive and efficient for users, and being able to inter-operate with other applications in a good way.
– We also approached the usability issue with the current brush settings dialog, got a significant improvement committed, and a even better solution, in my opinion, sketched out.
– Also committed was support for layer visibility attributes in OpenRaster, both in MyPaint and in GIMP.

I’m going to LGM 2010!

I’ve now also confirmed that I’m going to Libre Graphics Meeting in Brussels, plane tickets have been ordered and everything. It will be my first LGM, heck, my first conference of any sort! There I will meet up with Martin, Alessandro and many other great people in the free software graphics community. Drafts of the program has been published on the create mailing list, and I’m really looking forward to both the social and technical aspects of the conference. Great things have come out of LGM before, I bet this year will also have some in store.

I might also have another, exciting trip abroad upcoming. If so, more on that later 😉