Now that I finally found some tuits to do it, the next problem became obvious: doing a quick commit often lead to a quick build fail. Gendarme would have no use if it didn’t find anything, no? So the missing piece was integration into Visual Studio. Arthur hacked together a little XSLT+PowerShell and voila, Gendarme now runs on every build right from the studio and populates the “Error List” window with properly linked entries. Yay!

Read on for the details of the implementation. The complete source is downloadable at the end of the article.

First, the XSLT (“gendarme.xslt”), transforming Gendarme’s XML to properly formatted text.

<?xml version="1.0"?>
<xsl:stylesheet
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  version="2.0">
  <xsl:output method="text"/>

  <xsl:template match="/">
    <xsl:call-template name="rules">
      <xsl:with-param name="detailnodes" select="//results/rule"/>
    </xsl:call-template>
  </xsl:template>

  <xsl:template name="rules">
    <xsl:param name="detailnodes"/>
    <xsl:for-each select="$detailnodes">
      <xsl:call-template name="defects">
        <xsl:with-param name="detailnodes" select="target/defect"/>
      </xsl:call-template>
    </xsl:for-each>
  </xsl:template>

  <xsl:template name="defects">
    <xsl:param name="detailnodes"/>
    <xsl:for-each select="$detailnodes">
      <xsl:value-of select="@Source"/>: error :[gendarme] <xsl:value-of select="../../problem"/> Target: <xsl:value-of select="../@Name"/>.
    </xsl:for-each>
  </xsl:template>

</xsl:stylesheet>

Second, the powershell fragment to execute gendarme and transform the output (“gendarme.ps1″).

param($SolutionDir)

function Convert-WithXslt($xmlFilePath, $xsltFilePath, $outputFilePath)
{
    $xsltFilePath = resolve-path $xsltFilePath
    $xmlFilePath = resolve-path $xmlFilePath
    $outputFilePath = resolve-path $outputFilePath

    $xslt = new-object system.xml.xsl.xslcompiledtransform
    $xslt.load( $xsltFilePath )
    $xslt.Transform( $xmlFilePath, $outputFilePath )
}

if(-not $SolutionDir)
{
	$SolutionDir = ".";
}

"." > $SolutionDir\bin\gendarme.txt
gendarme.exe -config $SolutionDir\gendarmerules.xml --xml $SolutionDir\bin\gendarme.xml $SolutionDir\bin\Debug\blahblah.exe
convert-withxslt $SolutionDir\bin\gendarme.xml $SolutionDir\gendarme.xslt $SolutionDir\bin\gendarme.txt
(get-content $SolutionDir\bin\gendarme.txt) -replace '\(\D?(\d+)\)', ' ($1,1)' | set-content $SolutionDir\bin\gendarme.txt
exit 0

Instead of blahblah.exe, put your own assemblies you want to check.

And last but not least, the post build step to actually run the whole thing.

powershell -command $(SolutionDir)gendarme.ps1 -SolutionDir:$(SolutionDir)
type $(SolutionDir)bin\gendarme.txt


This can be added in your project properties on the “Build Events” tab, as “Post-build event command line”. In our project this is executed in one of the unit-test projects which has dependencies on all other projects and thus builds last.

Don’t forget to enable the RemoteSigned execution policy of the powershell; either by running

set-executionpolicy -executionPolicy RemoteSigned


from a Administrator’s shell or by adding one or both of the powershell.executionpolicy.reg and powershell.executionpolicy.wow6432.reg files to your registry.

You can find all files in this ZIP archive.

The behavior of float and real follows the IEEE 754 specification on approximate numeric data types.

[emphasis mine]

The XPath article states it clearly:

However, float(53) is not exactly IEEE 754. For example, neither NaN (Not-a-Number) nor infinity is used.

.

For completeness, here’s a little review about other DMBS’ support for NaNs and Infinity:

• MySQL does what it always does if it encounters “strange” values: according to this comment by Carl Fischer (bottom of the page), MySQL transforms the special values quietly to zero when writing them into the table.
• Oracle (starting at version 10g) supports all IEEE754 single and double precision values and provides constants for NaN and Infinity in its SQL implementation. This is implemented using the BINARY_FLOAT and BINARY_DOUBLE data types.
• PostgreSQL uses the underlying system’s float representation and allows input of NaN and infinite values.

[2009-10-16 15:02:09 - ddms]Failed to reopen debug port for Selected Client to: 8700
[2009-10-16 15:02:09 - ddms]Address family not supported by protocol family: bind
java.net.SocketException: Address family not supported by protocol family: bind
	at sun.nio.ch.Net.bind(Native Method)
	at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
	at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
	at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
	at com.android.ddmlib.MonitorThread.reopenDebugSelectedPort(Unknown Source)
	at com.android.ddmlib.MonitorThread.run(Unknown Source)

[2009-10-16 16:29:40 - ddms]Can't bind to local 8600 for debugger
[2009-10-16 16:30:14 - ddms]Can't bind to local 8601 for debugger
[2009-10-16 16:30:14 - ddms]Can't bind to local 8602 for debugger
[2009-10-16 16:30:15 - ddms]Can't bind to local 8603 for debugger
[2009-10-16 16:30:25 - ddms]Can't bind to local 8602 for debugger
[2009-10-16 16:30:25 - ddms]Can't bind to local 8606 for debugger
[2009-10-16 16:30:25 - ddms]Can't bind to local 8607 for debugger
[2009-10-16 16:30:25 - ddms]Can't bind to local 8610 for debugger

As it turns out, the debugger tries to connect to “localhost” which is resolved by Windows Vista via the Windows\System32\drivers\etc\hosts file, which contains the IPV6 address “::1″. Since Android’s IPv6 support is still under development, none of the development tools can cope with it, resulting in above error messages.

Substituting the IPv4 127.0.0.1 as localhost address made it work fine.

dd if=/dev/zero of=/dev/vg/lv

Since I had ten logical volumes, I also ran ten instances of dd in parallel. They were on a RAID and I was decommissioning the server, so I didn’t really care about performance. Speaking of which, I like to spy on running processes, call my a techno-voyeur if you want!

Anyways, vmstat was telling me that the system was chugging along nicely, reading(sic!) and writing approximately 16MB/s each. Something was clearly wrong. Note the “bi” and “bo” columns, denoting kB/s read and written:

david@hetz:~$ vmstat 10
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
[...]
 0 12   6416 270676 1601220   9628    0    0 16628 16553 4481 7638  1 21 26 52

I had forgotten to specify the block size which dd should use to make the transfer. And if the program is writing the zeroes one by one into the target file, the destination has to be read before it is modified, since the kernel cannot (and should not!) guess that the rest of the block (which is all we’re talking about at this stage) will be overwritten too.

To test my hypotheses, I restarted the processes and told dd to use nice 1MB sized blocks. I had ten threads to keep the hardware busy, so that shouldn’t make any problems.

dd if=/dev/zero of=/dev/vg/lv bs=1M

Really, in this configuration, the system stabilized around a nice 55MB/s writes. The kernel was able to recognize that the 1MB sized writes would cover complete blocks and that their content would be overwritten. No need to load them beforehand:

david@hetz:~$ vmstat 10
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
[...]
 0 12   6416  16308 1749688   5312    0    0     0 55644  551 1576  0 23  1 76

While I was waiting for the last process to finish, I noticed that throughput had risen to 60MB/s:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
[...]
 1  3   6416  15336 1750492   6088    0    0      4 62892  545  232  0 28 32 39

To summarize: having only one process running is ~10% faster than having ten processes running and using a non-trivial blocksize is more than three times faster than specifying none at all.