Quite a few months ago we received an unusual request from some students at Dramstadt University, Germany. They were building football playing humanoid robots to compete in various championships around the world and wanted to use Performance Validator to profile their robots looking for hotspots and bottlenecks with a view to improving the performance of the robots.

We provided Performance Validator to them to see what they could do. Today we found out.

The Darmstadt Dribblers have just taken their robot Isra to RoboCup 2008, held in Suzhou, China. They came 4th in the championship (24 teams competing), losing to the championship winners (also from Germany). The other two quarter finalists were both from Japan. Thats a good result, against some good competition.

Isra running to the ball.

Isra tackles an opponent.

Isra scores a goal.

This YouTube video shows Isra in action at Suzhou:
http://www.youtube.com/watch?v=QTbGXqQNkqQ&feature=PlayList&p=28F7B3DCA3198715&index=7

The Dramstadt Dribblers have uploaded various videos here:
http://www.youtube.com/profile_videos?user=DarmstadtDribblers

Still think software engineering can't be fun?

We'll be reporting on the Dribblers' performance as they enter more competitions.

In this post I'm going to describe some of the changes we've been making to the user interface of our software tools and also why this change has become necessary.

Over the past few months we have made a variety of wide ranging changes to the GUI of our software tools. Earlier versions of our tools used some 3rd party tab controls and some 3rd party grid controls that could also function as tree controls. These controls were very useful and enabled us rapidly create the user interfaces we needed.

However, over time we found a few special cases where we needed something more powerful. This resulted in the virtual tree/grid control we now use to display the potentially very large datasets the tools can collect. We haven't found any 3rd party tree or grid that can handle the volume of data the virtual tree/grid control can handle.

The result of this is that there were several competing styles of tree/grid control, some with white backgrounds, others with darker backgrounds, all with different visual styles for the way the grid was draw and the way it behaved in response to user input. This, while effective, was less than ideal.

At the same time, we have customers and potential customers asking us when our software will run on 64 bit Windows, or when it will run on Linux and Mac OS / X. We've been looking at the Linux and Mac OS / X issue for some time, evaluating which technology route to go with for the port, writing tools to automate as much of the port as possible (we have over 30 software tools to port if we port every tool) and assessing the "weak points" in our codebase that will cause us trouble.

Some customers having become used to our rapid turnaround of bug fixes have been somewhat surprised at how long we have taken to produce our ports to non-Windows operating systems. The main reason for the delay is that we want to port all the software tools that are appropriate, rather than just port Ruby Performance Validator and Ruby Memory Validator.

Having written the porting tools, we then ran up against our major weak points, consisting of the 3rd party tab control and 3rd part tree/grid controls, used in many, many places throughout our software. Thus, alongside our usual development goals of introducing new functionality and attending to customer issues, 2008 has been spent writing even more tools to aid us with the transition from the 3rd party tab control to a custom tab control and from the 3rd party tree/grid control to the virtual tree/grid control.

Today marks the first day without the 3rd party controls in our software. We still have some work to do before we can let the automated porting tools we've written loose on our codebase to product the cross-platform single source codebase we desire. However this is a significant step forward in that process.

Although we are not there yet, I hope this posting has provided some insight to what we are doing to those of you that are interested in this work.

Future postings will cover this topic as we have more to say about porting from a large MFC codebase to Linux and Mac OS / X.

About a month ago we hadn't heard of XULRunner. Then the folks at Songbird emailed us asking if our JavaScript tools supported XULRunner.

Its easy to miss a new tool or technology what with all the various development directions people are taking. XULRunner is a platform independent way to write applications using the same technology used to create Firefox and Thunderbird. You use the XPCOM, XUL and JavaScript technologies to create your application. With a bit of magic it then runs on your platform of choice. Songbird are using XULRunner to create a platform independent media player. I guess they know their target market, they are founded by the same people that did Winamp and Yahoo! Music Engine.

Given that we already supported JavaScript for Firefox and Flock support for XULRunner seemed like a natural fit. Ideally it would have worked out of the box, just change a few settings on the UI of our tools and off you go. It didn't turn out that way, although now we've made the appropriate changes, its as trivial as selecting xulrunner.exe instead of firefox.exe when you are choosing the JavaScript runtime.

The first problem we had was that xulrunner.exe doesn't use the js3250.dll DLL directly, it does it via the xul.dll DLL. As a result the UI and the stub couldn't find the js3250.dll and thus couldn't determine the version information we use to choose how to interact with js3250.dll. So we needed to support that.

The second issue was that each js3250.dll we've encountered has some internal differences that make line numbers inconsistent unless you use a build against the same header files used for that build. Very annoying, but thats how it is. So we need to know if its Firefox 1.0, 1.5, 2.0, Flock 0.7, or xulrunner to choose the appropriate way to interact with the target. If our tools don't know they assume you are using the latest and greatest and give you the firefox 2.0 treatment. XULRunner needs the 1.5 treatment not the 2.0 treatment so we had to put in a check for that. Also, the version ids on xulrunner.exe shipped with Songbird are "Personal" and not a version number. Excuse me? Whats up with that? Not very useful information. It should read "1.8" or something similar given that XULRunner is currently at 1.8.0.4. Hopefully someone will fix that.

A third issue was a killer. Songbird triggers a hook that causes a fatal crash. Whoops, how did that get past testing? Same way any other bug does I guess :-( Thats life, we are not perfect, so chalk that one up to experience.

We also needed a few XULRunner specific tweaks. For example when you are launching a XULRunner application you are looking for .ini files not .html/.js files.

To sum up, all our JavaScript tools now support XULRunner. This should help all of you using XULRunner to create platform neutral apps using Mozilla technology. If you have any specific issues please let support know at the usual address.

We've spent the last few years creating our software tools for C++, Java and all the funky scripting languages that are now getting the recognition they deserve (Python, Ruby, JavaScript, etc).

During all this time we've have been asked if we have .Net versions of our tools, nearly always a question related to C#. We had to answer "No, but we will have .Net versions at some time in the future.". That time has come. We now have .Net versions of Memory Validator and Performance Validator available as beta products.

Users of our popular Memory Validator software tool (for C++, Delphi...) will notice that the UI for .Net is quite different. This is because detecting memory leaks in garbage collected environments requires different approaches to collecting and analysing data. We have some innovative ideas in .Net Memory Validator, including the Allocations view, which provides a breakdown of objects allocated per function name; the Objects view, which provides a breakdown of objects allocated per object type; the Generations view, which provides an easy to read display of how many objects allocated per generation per object type. You can easily spot the trend graph of object usage and determine which objects are climbing or falling. A reference view allows you to view the object heap as a graph. The hotspots, memory, analysis, virtual and diagnostic tabs will be familiar to users of the original Memory Validator for C++.

.Net Memory Validator has the same user interface features you will find on our other Memory Validator products for other garbage collected languages (Java, JavaScript, Python, Ruby, etc) making ease of use when switching languages a doddle. As with all our products the .Net version, although different under the hood has the same team behind it. You are probably familiar with the case of a company creating a software tool for language X and then porting it support language Y, but the language Y version is lacking because it was a ground up rewrite, often by people unfamiliar with the language X version. This leads to incompatiblities, differnt UI behaviour, new bugs. That isn't how we create our new language versions. Each version has its own code base, which allows for the radical under the hood changes to accomodate each language. But it has the same team and keeps the same user interface elements where applicable. So even if the code under the hood changes you get the same experience regardless of language.

This also allows our bug fixing to be improved. Many bugs from one version of a product apply to our other language versions. Thus if we find and fix a bug in say Java Memory Validator that bug fix can often be applied to JavaScript Memory Validator, Python Memory Validator, Ruby Memory Validator and .Net Memory Validator, etc. And our customers usually get the bug fix the very next day. This development method has been carried into the .Net line of software tools.

.Net Performance Validator continues this trend of the same user interface. If you know how to use any of our Performance Validator products (including the C++ version) you will know how to use .Net Performance Validator. Its that easy.

The callstack view provides a real time insight onto where a particular thread is running. Raw Statistics lets you inspect the raw data collected about performance and Statistics lets you inspect this data in a more orderly fashion. Relations provides the same information but allows you to view which function was called from which function. Call Tree provides the a call tree which you can expand and contract to view the performance data. Call Graph provides this information as a graph with each function listed as infrequently as possible. Call Graph is a very useful way to find an expensive function, then right click, choose goto Call Tree Node and the first node in the call tree that relates to the same node in the Call Graph expands with the node highlighted and source code displayed if available. Analysis allows complex queries onto the data and the diagnostic tab provides information about the instrumentation process.

Cheers for now, we have more .Net tools to work on.

Linux? MacOS X? Not right now, but some time in the future. Where have you read that before? :-)

To provide the memory tracking, heap dump and object referencing facilities in Ruby Memory Validator we had to reverse engineer some hooks into the Ruby executable. This is not the easiest task in the world and beyond the abilities of anyone with less than a cursory knowledge of x86 assembly and Win32 hooking techniques.

To make it easier for this work to be done, to make it more reliable and to make these hooks available for those that just want to mainly work with Ruby and write a little C (as opposed to getting immersed in PE formats, x86 assembly and so on) we have created an extension to Ruby that provides for memory allocation and deallocation tracking, heap dumping and object reference determination. The extension is in the form of a simple C API.

You can read about this work, download the source code and download a working Ruby DLL with the extra code here.
http://www.softwareverify.com/ruby/customBuild/index.html

If you have any comments, please contact support at the usual address.