Threaded's Eclectic Blog


<xsl:stylesheet version="1.0

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

<!-- IF_THE_PIVOT_IS_A_SUBTYPE_IT_NEEDS_TO_GO_IN_HERE -->

>


<xsl:output method="text"/>"


    <xsl:template match="//PIVOT_GOES_IN_HERE">

        <xsl:apply-templates select="*" />

        <xsl:text>&#x0D;&#x0A;</xsl:text>

    </xsl:template>"



    <xsl:template match="//PIVOT_GOES_IN_HERE//*">

        <xsl:choose>

            <xsl:when test="count(child::*) > 0">

                <xsl:apply-templates select="*" />

            </xsl:when>

            <xsl:otherwise>

                <xsl:text>"</xsl:text>

                <xsl:value-of select="."/>

                <xsl:text>"</xsl:text>

            </xsl:otherwise>

        </xsl:choose>

        <xsl:if test="position() != last()">

            <xsl:text>,</xsl:text>

        </xsl:if>

    </xsl:template>


</xsl:stylesheet>




Labels: programming

man chattr > 1; man chmod > 2; diff -u 1 2 | less

Labels: fun, joke, programming

A Google shows this quote "Never trust anything that can think for itself if you can't see where it keeps its brain." as coming from J. K. Rowling. I think the sentiment is older, and came from another, science fiction author, whose name currently escapes me.

Anyways, the wibble I have today: in performance testing a rather complex system I noticed that some sets of tests ran quicker than expected. After a thorough inspection I discerned that there are various levels of cache and that several caches exist distributed throughout this distributed system, and the combination appeared to be learning the sequence of the tests.

Spooky!

Occam's Rasor: "Entia non sunt multiplicanda praeter necessitatem", initially had me looking for Charlie co-worker mucking me about.

Labels: programming, work

Realised what obvious means: those things you write instructions for, for the use of those who don't embrace obvious quite so easily.

Labels: joke, Pavlovs dog, programming, zen buddhism

Just don't do it: you will save yourself a great deal of pain.

Usual clue when you have one of these infestations is when someone asks if you can see anything wrong with a particular regex as they know it's the cause of their transient problem but just can't see anything wrong with the code.

The reason is pretty simple: regular expressions can only be parsed by a state machine and this is coupled with the general inability of many programmers to code state machines nicely for multi-threaded environments.

(The reason for using state machines in this is not so simple and one day I might fill out this post with the details, but essentially regular expressions are a type of finite state machine.)

The mistake many coders of these things make is using some class variable to hold state, this is where the problem is created. Now when two threads try and do something with a regular expression concurrently the result is anyones guess. At best things just crash, but generally the regex matcher for one side fails giving a strange result.

As regex is usually buried deep in a library, such as an XML parser, your options include replacing the entire library, or even change programming language. As this is generally not possible one is stuck to removing the regular expressions...

How can the programmers of regular expression parsers help their customers? Simple really don't hold state in the class, don't reuse an instance (unless you know it's been finished with) .

Labels: programming