Jan 2010: recls 1.9; commercial work; writing (QM, Monolith)

First off, Happy New Year to all. Let's hope that this one is better than 2009, in lots of ways.

I'm already busier than I expected (or wanted) to be so early in the year, but you can't complain when the sun is shining.

In terms of research, at long last I've written the new C++ mapping for the recls library, which means version 1.9 can finally be released. Apart from the release of recls.net - a 100% .NET implementation of the recls library - I haven't released any open-source stuff in over three months.

The drought's about to break, however. As well as recls 1.9 (and a final, defect-fix, version of 1.8), I will be releasing new versions of STLSoft 1.9 (1.9.88), STLSoft 1.10 (1.10.1 alpha 14), FastFormat (0.5), Pantheios (1.0.1 beta 194; hopefully the last beta), b64 (1.4), and probably some more (incl. VOLE)

In commercial work, I'm busy on three fronts simultaneously:

• A multi-screen control system for a local (Sydney) client, written in C#/.NET
• A review/remediation piece for an international financial client (C++, COM)
• A review piece for an Australian client (C++)

In writing, I'm currently busy with:

• The next instalment of Quality Matters (and fleshing out its website), my bi-monthly column for ACCU's Overload magazine
• Sorting through ideas for entries for my guru blog with DDJ's CodeTalk
• Preparing the proposal for Breaking Up The Monolith (only 3 years late!)
  

So, wishing a prosperous new year - in spirit, as well as in wallet - to all, and don't hesitate to get in contact if you need my help in commercial guise.

Matt

Measuring Process Times with ptime

I'm currently doing a little series of posts for my Windows/.NET DDJ Guru Blog covering the performance of the recls (C++) and recls 100% .NET libraries. The first study involves writing a simple application to search for C# source files (excluding Properties/AssemblyInfo.cs), and reporting how much effort it is to write, and how fast it executes.

The latter point has some interest: how do you meaningfully compare performances of tools that have strong interactions with operating system components that exhibit high and variable latency?

The answer I've been using for many years relies upon (on Windows) the use of the ptime tool. The command-lines are (for the C++ program):

ptime --r3 --ah -- ...\CSharpSourceFinder\cpp\CSharpSourceFinder\vc9\Release\CSharpSourceFinder.cpp.exe

and (for the C# program):

ptime --r3 --ah -- ...\CSharpSourceFinder\dotnet\CSharpSourceFinder\bin\Release\CSharpSourceFinder.exe

I'll leave you to peruse the ptime usage, but will comment that each of these command-lines causes the search to be run three times, and averages the times for all runs, after discarding the largest (which we can reasonably presume would be the first). It's not ultimate precision, but it's pretty useful at discarding unrepresentative measurements in such conditions, and gives figures within (I'm guessing now) 5% of their true figures.

Welcome to "The Synesis Way"

Welcome to Yet-Another-Matt-Wilson-Blog.

This one will be used to provide information about:

• Synesis Software services and events
• Synesis Software tools and utilities