Doing actual work...

Remember that yesterday I promised to tell you how long that Python actually took to execute? Well, I didn't wait long enough to finish. I've killed it after two hours of running. I've tried to run it with psyco. Actually, I've obtained an almost 10x increase in speed in that simple program - disk usage was at ~5MB/sec. However, this is still too slow. For 6GB at that rate, it would take around 20minutes. This can go a lot faster!

Today it turned out that I've uncovered a bug in the Phoenix-2 code. Joel has fixed it really quickly. However, I'm still struggling with Phoenix. Each time I think of some novel way of composing functions, a new problem arises. I've checked the Joel's time zone in the mail headers. He's in -7, I'm in +2. Meaning that I'm waiting half a day for an answer to a problem. (Hey, I'm not saying that he's slow.. he has to sleep, afterall! :))

Playing with Phoenix and simulating LISP in C++ is way cool. But I have real work to get done. So I have fallen back to writing the STL-style functors and this is going very smoothly. And when Joel manages to answer my questions, I will adapt it to Phoenix. That's what I'd like to use eventually, because it is much more expressive than standard C++ STL-style functors. BTW, he thinks that it's cool what I'm trying to do.

A digression: yesterday evening when I was experimenting with Phoenix, I've received a 1MB-sized (checked with the wc program) error message from g++! My next thought was: "with a sufficiently complicated (with many deep template instantiations) and broken C++ source you could almost use the compiler error output as an entropy source!" :)

And C++ definetly needs a new tool: template metaprogramming debugger. No human can really read and understand the 1MB error message! I can find the major points and the source of error, but why it happens.. I don't have a clue. Joel knows his library inside-out so I suppose he knows where to start looking in the code and how to debug it. I'm totally lost.

And GDB is also awful when dealing with templates. Just try to set a breakpoint in a specific instance of some template-generated function.