I’ve always been annoyed by not having clearly marked errors (besides the word “error”) when using gcc/g++ from shell.

Now a simple python script helps me to notice every appearing error out of lots of unimportant lines of stuff (warnings e.g.).

highlight.py:

1 2 3 4 5 6 7

import sys while 1: input = sys.stdin.readline() if len(input.lower().split("error")) > 1: print chr(27) + '[91;1m' + input.strip() + chr(27) + '[0;0m' else: print input.strip()

Additionally I created a function and an alias in .bashrc which determines the behavior of the shell:

alias gcc_real=$(which gcc)
alias gcc='gcc_highlight'
function gcc_highlight()
{
gcc_real $@ 2>&1 | python ~/highlight.py
}

alias gpp_real=$(which g++)
#...and the same for g++
}

The usage of gcc_real is very important, otherwise gcc would call gcc and so on…perfect recursion.
gcc errors are not reported over stdout but over stderr which means i had to use 2>&1 to forward them.

As I wrote in my last post you can use the “?” operator for Nullable types in .Net 2.0 but there’s one more feature:
To abbreviate a progess like that (which is very long winded)

string assign(string v)
{
string r;
if( v == null )
r = "null"
else
r = v;
return r;
}

I’d rather write a function that way:

string assign(string v)
{
return ( v == null ) ? "null" : v;
}

But the shortest and language adjusted way seems to be:

string assign(string v)
{
return v ?? "null";
}

Even if it seems cool to me I don’t think it’s the most readable way. Anyway, have fun with it

One of the “late breaking” features in .Net 2.0 is what is known as “Nullable Types” (Nothing in VB.NET).
In former times I defined a Generic struct or class (C++: “Template Class”)

struct Nullable<t>
{
public bool HasValue;
public T Value;
}

Nullable<int> x = new Nullable<int>(5);
bool b = x.HasValue();

Since .Net 2.0 you simply can write:

int? x = 5;

which is much simpler. Similarly, rather than needed to write a null test as:

if (x.HasValue) {...}

you can use a familiar comparison to null:

if (x != null) {...}

You need to convert an xml file to sql the simpliest way? I got a script for you that makes out of an xml file a clear sql dump for example to insert into a mysql database.

import sys
import xml.dom.minidom as minidom
 
#field list - same in SQL + XML
fields = "name, phone, adress"
tablename = "contacts" # table
recordset = "contact" 
 
def main(args):
    f = open(args[1])
    doc = minidom.parseString(f.read())
    f.close()
    for i in doc.getElementsByTagName(recordset):
        vars = []
        vals = []
        for j in fields.split(", "):
            for k in i.getElementsByTagName(j):
                if (k and k.firstChild):
                     vars.append(j)
                     vals.append(k.firstChild.nodeValue.replace("'", "\\'"))
        sqlstring = "INSERT INTO %s (%s) VALUES ('%s');" % (
                      tablename, ", ".join(vars), "', '".join(vals))
        print sqlstring.encode('utf-8')
 
if __name__ == "__main__":
    if len(sys.argv) < 1:
        print "Usage: %s <filename>.xml"
    else:
        main(sys.argv)

xml2sql.py (right-click Save as…)

Usage is:

xml2sql.py foo.xml

Of course you first have to change the rootnode name, subnodes and fields in the script.

When writing a pretty & small countdown script for New Year’s Eve I mentioned that we’ll be in trouble at January 19^th in the year 2038. While handling with unix-timestamps (seconds since 1/1/1970) I figgured out that the signed 32-big-integer that is used in for time_t is not big enought to hold 2147472000.

Most operating systems for 64-bit architectures already use 64-bit integers in their time_t but this doesn’t solve the problem at all because it may happen that a program regards a 64-bit timestamp from the OS as a 32-bit value. The consecution would be that just the lower 32 bits would be read. On 1/19/2038 this would cause a backshift into the year 1901. (The lower 32bits of 1/19/2038 are -2³¹ = December 13^th in 1901)

The move to 64-bit architecture is already underway and probably will be completed before 2038 but what about the embedded 32-bit based systems? Will it really be necessary to re-compile some software to make them work with a (signed) 64-bit timestamp?

What about all the databases e.g. of banks or insurance companies which are full with timestamps? Lots of questions - I’m excited…