Last time I introduced sp-error-visualizer and sp-rich-core. Now it’s time to take a look at a couple of the other sp-tools in Chinook.

sp-endurance

The sp-endurance suite provides tools to save and analyze data from endurance testing. Endurance testing could be defined as repeated testing over a long(er) period of time. This kind of testing usually reveals memory and resource leaks. Due to the nature and requirements of endurance testing, it is usually done once the application is nearly complete. In my opinion it is one of the most important steps when moving from beta to release quality.

The sp-endurance suite consists of two packages; sp-endurance and sp-endurance-postproc. The first one is meant to be installed on the device and provides helper scripts for data collection. The second one provides data post-processing tools for data manipulation and report generation and it’s meant to be used on the PC.

You still need to do the hard work of actually designing and executing the endurance tests, sp-endurance is there to help you analyze the results. The Chinook toolset also contains some tools for test automation and you could consider using those when designing your test cases.

sp-stress

Ever wondered how your program behaves under a heavy CPU load or how it handles itself when memory is low or unavailable? sp-stress provides you with utilities to easily put the system under different kinds of stress and thus let you test your application in these scenarios.

The sp-stress package provides three utilities; cpuload, ioload and memload. Their names are already indicative of their purpose.

cpuload will generate the given background CPU load, which you can select from 1% to 100% or have it generated randomly.

ioload will perform read and write operations on a given file generating a lot of I/O load on the filesystem.

memload will allocate a given megabyte size chunk of memory.

Depending on your program, it may be a good idea to test how it behaves with a constant or varying load of one or more of the sp-stress utilities.

More about tools

See maemo.org for usage examples and to learn more about these and other tools:

We as the team behind the latest maemo 4.0 SDK (Chinook) would like to hear from you! Please give us your comments on the SDK and its tools and documentation. You can drop an anonymous comment here at this blog or send your feedback to chinook-feedback@maemo.org. Feel free to be direct, love us or hate us! Your improvement ideas are very much appreciated for the next SDK.

The Chinook SDK has been out now for a while and it feels like a good time to highlight some of the tools that were released with it.

Like mentioned earlier, a set of previously closed tools was made open source with the Chinook SDK release. These tools were made in-house by and for our developers. Now they’re also available for you through the Chinook SDK repository.

This time I’m going to talk about sp-error-visualizer and sp-rich-core.

sp-error-visualizer

The error visualizer tool pops up a notification banner every time something matching a pattern gets written to the syslog. It’s a simple idea that will help you notice those sporadic errors that you just can’t reproduce reliably and otherwise might go unnoticed in the log writings. You can naturally define the match pattern to whatever you are looking for.

This tool is especially useful on the device where you often can’t view the logs while running an application.

sp-rich-core

The rich core is one of my favorites. The idea is to provide a better view of the whole system’s state at the time your program happens to crash.

Normally when a program crashes it will produce a core dump file, which is the run-time memory and state dump of the program. The developer can then open this core dump with a debugger (gdb) and observe the state of the program at the time it crashed. Many times this is enough to reveal the reason to the crash, but sometimes it can be difficult to understand why the program ended up in that state. At those times any extra information is a blessing.

With the sp-rich-core installed, when a program crashes it will not only produce the core dump file, but it will also take a snapshot of many things in the system. Then all these files are compressed together with the core dump to a rich core (.rcore) package.

The developer can now open up this package with the rich-core-extract utility and have all the extra information of the system’s state available along with the normal core dump file.

I wanted to write a few words about the tools released last week with the Chinook SDK.

The Chinook SDK is a collection of libraries, tools and resources that enables you to develop new applications and port existing ones to the IT OS2008.

With the SDK we wanted to release tools that are known to work and that are also used internally for software development in order to provide a verified set of utilities for you developers in the maemo community.

The tools and the SDK are now in the same repository and this has created a situation where the omission of certain library -dev packages has raised some eyebrows. The reason for this omission is that those libraries are only needed as a run-time dependency for one or more of the tools that are in the same repository. It is also an indication that if your application needs to use that library, you need to make sure it’s available for the non-developers from some other repository than the SDK, preferably from the Chinook extras repository. Your application should not depend on something that’s only available in the SDK repository.

There’s a plan to provide a separate tools repository the next time we publish an SDK. This will hopefully make the separation of the tools and the SDK more clear. This will also make it safer to activate just the tools repository on the device without having to worry about all the ‘noise’ the SDK repository creates in the Application Manager.

From Bora to Chinook

In Bora SDK the included tools were a small collection of standard Linux tools. This time with Chinook we’ve released more well known tools and also some that were developed internally and haven’t been available to the open source community before.

Oprofile is now available accompanied with a graphical user interface. Valgrind has been updated to a new version along with gdb in order to better support glibc2.5.

Most of the internally developed tools and helper scripts are in packages named “sp-something”. These utilities help in tasks like simulating different kinds of system load or collecting and analyzing debugging data or just provide help in starting up the various other debug tools correctly. The main goal of these “sp-tools” is to offer a variety of utilities to help you increase the quality of your applications by facilitating easier and more powerful testing.

The tools documentation pages were updated and the tools were categorized by task to help new developers easily see what’s available. Each tool that got categorized has its own subpage with a description, usage examples and links to other sources of information.

Maemo Tutorial and Maemo Porting Guide have been updated to contain the latest changes in Chinook, and they have now been published on out website. If you wish to start developing for maemo 4.0 now, please take a look at:

I announced yesterday that new documentation for the upcoming maemo 4.0, codename Chinook, has been released. In addition to updating the how-tos that give useful bits of information of maemo platform here and there, we have been busy with another goal in documentation. A completely new guide written for developers completely unfamiliar with maemo is finally getting to a beta stage.

So far, at least I have not been satisfied with the level of documentation of our platform. There is no easy place to start learning. Vast amount of information is available from the how-tos, tutorials, wiki, mailing lists and IRC not to mention the upstream projects’ documentation. However, even the basic definitions of “maemo”, “maemo platform”, “Hildon” etc. are lacking.

The “maemo 4 Quick Start Guide” strives to give an overall picture of software development on an open platform for Nokia Internet Tablets called maemo. The prerequisites for the reader of this guide will be basic GNU/Linux C programming knowledge. GTK+ experience will not hurt but it is not necessary, neither is previous embedded or mobile programming experience. This all might still be asking a lot, but the guide would not be a “quick start” if for example GNU/Linux would have to be explained in the scope of 30 pages.

Instead of publishing the guide right now I challenge you to give feedback on the table of contents of the document. Just comment this blog or drop a line to documentation@maemo.org. This is your chance of affecting what you think is relevant for maemo beginners to know. Thank you in advance!