CUSP = lisp made easy.

Well, I had a good look at CUSP today, and I must admit: it is suspiciously easy to get started and enormous fun to use (for me as an amateur lisp lover). Installation was a breeze (it installs all sbcl on its own. easy!). Up and running in no time.

Respect!

python closure problem

>>> def acc_gen(initial_value):
...   total = initial_value
...   def acc(to_add):
...     total += to_add
...     return total
...   return acc
...
>>> a = acc_gen(5)
>>> a(3)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in acc
UnboundLocalError: local variable 'total' referenced before assignment

I'm shocked! That doesn't make sense to me. Cfr:

[1]> (defun acc-gen (total) (lambda (to_add) (incf total to_add)))
ACC-GEN
[2]> (setf a (acc-gen 5))
#
[3]> (funcall a 3)
8
[4]> (funcall a 3)
11

I'm a little bit clueless, but I'm pretty sure that this is what they mean with "python doesn't support proper lexical closures"

desperate-programmer-seeking-companies

It's really funny. For months now, the same 2 companies keep popping up on the google ads on my blog. They must really be desperate. Most notably Jane Street Capital. They used to be looking for ocaml programmers, but right now they seem to be targeting anyone with any functional language experience. Although I'll admit that the profile they are looking for is pretty heavy. Looks like they do really cool stuff though.

The other one is QueroMedia. But they seem to be looking for a php developer. eeeewwww! :)

Take note: git rules! Especially git-svn. I lost some interesting links I had on the subject, but this page seems to be very informative (haven't read it yet, just skimmed through it).

the silly 3gb memory barrier

Crap, I got sucked into the 3Gb memory barrier. Ridiculous how they all keep bending over backwards to have backwards compatibility (pun intended :) ).

Also worth mentioning is that on most regular x86_64 based systems with more than 4gb of ram, you will still have a hole between 3 and 4 gb. I tell ya, backwards compatibility just seems like such a dumb idea. Really. I could live without old windows crap. No worries.

The problem(s) with online backup

Ok so everybody needs backup. No doot aboot it. Everything hoses, given time. The solution? Redundancy! (That's my favourite line actually: The key to success is redundancy.)

Alright, so there's a problem. Now for a solution... what are the requirements here?
It should be
* transparent (like, hardly knowing it's there)
* unlimited
* cheap

So I looked around a bit and signed up for a free 2GB online backup with Mozy. They look decent. The software looks clean and functional. And hey, 2GB goes a long way towards backing up text and source code and such.

It definately meets the 'transparent' requirement. They have 'unlimited' paid accounts, but that's marketing bull. Has to be. They're not the only ones either. Plenty of others. The market has exploded over the last year or so.

Cheap? I guess they are.

But does it actually work? nope, at least not for me.
Why? One word: bandwidth.

Every one these days has tons of data. (tons of mp3's, tons of movies, tons of pictures). I know I do. It's just not an option. I would need a professional internet connection, with high upload speeds (a minimum of 1 Mbit/s, and even then it'd take weeks for the initial backup to finish), and tons of bandwidth usage per month.

Trolltech releases Qt Jambi

Trolltech releases Qt Jambi... I wonder how soon Jambi-based Java apps will start appearing, and what the impact will be on the Java community. I have no plans to use it yet, because I'd rather avoid Java, but I suspect it might provide quite a few companies an 'easy' migration path away from C++.

google reader supports google gears

Works really smooth. I've been testing it on the train to work. Can't wait till they add support to gmail and google calendar!

return, break and continue

Funny how any programmer will always tell you that goto's are evil. Ofcourse they are. But every programmer also effectively uses them all the time. The return, break and continue statements that exist in most programming languages are goto's in disguise. And good ones too. I guess they were invented when language inventors realized these represent safe usage patterns of the goto statement. Not using them will generally result in indentation bloat, because they are naturally suited to preconditions (for programming languages that don't support preconditions in the language itself, which happens to be most of them). Hence, not using them makes your code harder to read.

Ofcourse I'm right, because the zen of python clearly states "flat is better than nested" :)

If you really push it then any iteration construct itself (without break or continue) is also a goto (or even multiple goto's) in disguise, but ok, no point in going there.

the evolution towards lisp

I was discussing the "all programming languages evolve towards lisp" theory with a colleague recently. Paul Graham explains it quite well:

If you look at these languages in order, Java, Perl, Python, you notice an interesting pattern. At least, you notice this pattern if you are a Lisp hacker. Each one is progressively more like Lisp. Python copies even features that many Lisp hackers consider to be mistakes. You could translate simple Lisp programs into Python line for line. It's 2002, and programming languages have almost caught up with 1958.

But I think there is another clear sign of the evolution towards lisp. The increasing popularity, especially in the eclipse community, of code generators. Since reading 'Practical Common Lisp', it would seem silly to invent huge blobs of code generating code in Java, when the world already has the greatest code generating tool, the lisp macro.

the choice of distributed version control system

Reading about mozilla's move to mercurial, it's still not clear to me which one is best: git, mercurial, bazaar, monotone or darcs? I've happily been using subversion for quite some time, but now I feel a real need for a distributed vcs. It also feels conceptually right.

One good point made in the reasoning for mozilla's move is that it's not a disaster to make the wrong choice; all of these vcs' contain all the information necessary to convert between them. For me, win32 support is an issue, and I need a plugin for trac. Analog to TortoiseCvs and TortoiseSvn, there should be a TortoiseGit, TortoiseHg, TortoiseBzr, TortoiseMtn and TortoiseDarcs. Uhm, wait a second, there is a TortoiseDarcs! A TortoiseBzr seems to be in the works. The other tortoise's pop up on google, but with nothing substantial.

So anyway, for each of these, you can easily find people who are passionate about it. But I suspect that that's just because cvs left such huge scars on everyone. It is high time for cvs to be erased from our collective memories and start being picky about the features these new (distributed) systems have to offer.

Lisp's major problem

So I've progressed quite a bit into my lisp book. And I'm impressed. There really is no limit to the level of abstraction that you can reach. But that's exactly the problem with lisp. Though programmers are generally quite intelligent, I'd say any individual is still pretty dumb anyhow. These days, it's hard to get anything done unless you're good at working in a team, and good at communicating ideas, abstractions, patterns, or whatever stuff there is that has a certain complexity to it. The major issue here is the speed with which one absorbs this kind of information.

And that's why languages like Java are popular and quite successful for large projects: They are limited/optimized to the kinds of abstractions that the majority of programmers out there can easily absorb and use productively. One lisp programmer may get more done than 5 Java programmers, but 25 Java programmers might get the better of 5 lisp programmers. And where Java programmers bumped into Java's abstraction limits (which you bump into pretty soon), they turn to well documented Design Patterns. And those patterns are, being well documented, easy to communicate.

I'll be honest and tell you that I don't know. I can't know because I haven't got enough lisp experience (obviously). It's just a hypothesis. I'll test it when I've achieved Lisp Guru Level ;)

Some I/O performance stats

I was a bit curious about the performance stats of my flash drive, especially with regard to Vista's ReadyBoost (which I haven't tried using yet). The idea is that a flash drive has much better random access performance than a harddrive, whereas a harddrive's sequential throughput is superior, but irrelevant for swap. So I tested it on my laptop's harddrive and a 2GB USB flash drive, using this simple but very useful tool called CrystalDiskMark. There's something I didn't expect: the random 4K write test was slower on the flashdrive.

How is that going to improve performance as a swap device? Is it filesystem related maybe? Still, the random read stats are quite telling. And the write performance might be ok if the system swaps well in advance.

Bram and I were discussing how to merge sorted lists...

import time
import heapq
from random import randint

def report(*arg): print "%-20s: sorted %d lists with a total of %d elements in %d milliseconds" % arg

domain, listsize, nlists = 100000, 5000, 500

lists = [ sorted([ randint(0, domain) for j in range(randint(1,listsize)) ]) for i in range(nlists) ]
indices = dict([ (i, 0) for i in range(nlists) ])

start_time = time.time()
result = sorted(sum(lists, []))
end_time = time.time()
report("primitive method", nlists, len(result), int((end_time - start_time) * 1000))

heap = [ (lists[list_index][0], list_index, 0) for list_index in range(nlists) ]
heapq.heapify(heap)

start_time = time.time()

result = []
while len(heap):
  min_value, min_list_index, min_value_index = heapq.heappop(heap)
  result.append(min_value)
  min_value_index += 1
  if min_value_index < len(lists[min_list_index]):
    heapq.heappush(heap, (lists[min_list_index][min_value_index], min_list_index, min_value_index))

end_time = time.time()
report("better method", nlists, len(result), int((end_time - start_time) * 1000))

Reading some of these "Road to lisp" stories (thx, Lars) does make me wonder... How well do people know a programming language before moving on to a new one? The stories do not always make sense. I mostly got upset by some people claiming ruby is better than python, whereas I *know* ruby, and I *know* it isn't. I would like people to demonstrate to me where ruby provides a truly higher level of abstraction than python. Please, enlighten me.

Anyway, I expect to raise to a new level of abstraction in lisp (I believe I maxed out in python a while ago). I also fear it won't come with as many "batteries included" as python.

I bought a book on Common Lisp this week. I couldn't help but feel strangely attracted to it. The urge to start learning lisp grew incredibly strong over the last year, and finally I succumbed :). Maybe it's an age thing, an experience thing. You have to have had a certain walk of life before you get to it. I'm not planning on doing anything useful with it (yet), but it just feels like I could not consider myself to be a 'complete' programmer until I learned lisp.

The reason, I guess, is that my personal evolution is indeed very similar to many other people's tales of their evolution in programming. Starting off procedural, low level, (pascal, C) and then growing into object orientation, mastering what polymorphism has to offer (C++, Java), and moving on to loving python. Python seriously wetted my appetite for solving problems with a more functional approach. List comprehensions were truly liberating for me. Python made me a much better C++ programmer. But also very much a frustrated C++ programmer.

So now there's lisp. People say lots of things about lisp. Things that drew my attention. "Learning lisp made me a better programmer in any language". Hmmm. Familiar. "The programmable programming language". Interesting. I continuously tend to go more "meta".

The only thing that worries me now is that the author seems to have more of a background in perl, rather than python.

Bruce Eckel has some interesting notes on PyCon 2007. Particularly the bits about crunchy, and IronPython getting around the global interpreter lock. But there's more.

I went to FOSDEM yesterday. I never got around to it in previous years, something always got in the way. But I'm really happy I made it this year, even though it was only for a few hours.

So I attended Miguel De Icaza's talk on mono, which was very interesting. He's a very good speaker! He gave a good overview, and I was surprised that he mentioned boo several times. I've been lurking on the boo mailing list for quite a while now, and it's definately something I want to get into, time permitting. I simply had no idea it was already this popular. Ironpython was given a few minutes as well, and the performance stats are pretty impressive (I had seen them before though). The embedding of mono in games for scripting purposes was also pretty cool. During the workshop later that day, Miguel also briefly demonstrated an embedded boo interpreter in, I think, Banshee. Sweet stuff.

Another thing he mentioned was the IKVM project, which is also very impressive. I had looked at it before, and I was thinking this time that it would enable me to use the Eclipse Modelling Framework on mono.

It's making me unhappy as a C++ programmer though. :(

Hmmm. Strange, I just realized I haven't seen any eclipse related presentations on the schedule, but maybe I didn't look carefully enough.

Miguel also jokingly mentioned that "unlike java's generics, the dotnet generics actually work". I haven't read any criticism of Java's generics yet, nor have I used them, so I obviously can't know what he means. It's been a while since I messed with Java... (to be investigated)

More apps mentioned: Monodevelop (nothing new here, but I saw some people get really excited. I mean *really* excited, like, 'I hope they didn't spoil the seats' excited), and Reflector (neat!)

Oh, and he's embarrassed they haven't got any proper debugging support yet. "Real men don't need debuggers". (cough, cough)

I watched the KDE 4 presentation for half an hour, but after miguel's presentation, it was shockingly amateuristic. I'm sure they have some good things going there, but I'm just not a KDE person and they definately failed to convince me.

Unfortunately, attending the mono presentation meant I had to miss the SQLAlchemy and Elixir presentation, which is a major bummer as am also very interested in sqlalchemy. Crap. But there were a lot more presentations I wanted to see, so I'm hoping there's going to be some video material available for download on the fosdem website eventually. (or at least just the presentation documents).

And it's a damn shame I didn't take my (euh, my wife's) photo camera with me.

it's quiet now, and as i think my thoughts alone,
i try to keep my head straight but i think i'm too far gone.
for in this silence, the truth rings even louder.
a constant grinding begging recognition of its power.
through its eyes i take the trip, destiny: the place
of pain and pleasure absolute, where sorrow has a face
a place if time where spirit, asked to stand and hold its ground
has lost all equilibrium and is slowly sinking down.
down into the darkness that the lack of will affords,
down into the shadows, past the junkies past the whores
down into the mire, suffocating all that lives,
but if i say "i care" i lie for i've no more left to give.
well i suppose a hand would help. oh yeah, there's no one here.
guess that's what i wanted (once again my greatest fear).
i just long to hear a bird song, just to let me know there's light.
for as we all know a songbird never sings its song at night.
but, it's quiet now.

"it's quiet now", derrick carter

I heard it a long time ago on the intro of a Sander Kleinenberg dj set. Googling seems to point it to a dj called Derrick Carter. I'm pretty sure that the girl that sings it is not older than 15 or so.

That's a nice, sharp contrast.

I'm so happy I found this three column blogger template! Way better than before. Now I'll get started on setting up trac and such, and link it.

My opengl polygon tessellator. Works great! Unfortunately, I still haven't figured out how to get code pasted properly. Grrrr. Blogger is not off to a good start for me.

Anyway, it nicely demonstrates how to do opengl polygon tessellation in C++ and retrieve the triangles later. The Point_2, Polygon_2 and Polygon_with_holes_2 are CGAL typedefs, the others are simple stl typedefs.

I was just playing around and comparing triangulations.

Update Feb 20, 2007: I added the webcpp css to the template, so it looks better.

class Tessellator
{
private:
 typedef         vector<Point_2*>          Point_2_Vec;
 typedef         pair<GLenum, Point_2_Vec> Poly;
 typedef         vector<Poly>              PolyVec;

 GLUtesselator*  m_tessellator;
 PolyVec         m_polygons;
 Point_2_Vec     m_all_vertices;

 static void vertexCallback(Point_2* point, Tessellator* tess)
 {
   Poly&         poly      = tess->m_polygons.back();
   Point_2_Vec&  vertices  = poly.second;
   vertices.push_back(point);
 }

 static void beginCallback(GLenum type, Tessellator* tess)
 {
   tess->m_polygons.push_back(Poly(type, Point_2_Vec()));
 }

 static void combineCallback(GLdouble coords[3], Point_2*[4], GLfloat[4], Point_2** outData, Tessellator* tess)
 {
   Point_2_Vec& vertices = tess->m_all_vertices;
   vertices.push_back(new Point_2(coords[0], coords[1]));
   *outData = vertices.back();
 }

 static void errorCallback(GLenum code)
 {
   const GLubyte* error_msg = gluErrorString(code);
   cout << "opengl error: " << error_msg;
 }

 void  _glTessPoly(Polygon_2& poly)
 {
   gluTessBeginContour(m_tessellator);
   for (Polygon_2::Vertex_const_iterator vertex_it = poly.vertices_begin(); vertex_it != poly.vertices_end(); vertex_it++)
   {
     Point_2* p = new Point_2(*vertex_it);
     m_all_vertices.push_back(p);
     GLdouble v[3] = { to_double(p->x()), to_double(p->y()), 0.0 };
     gluTessVertex(m_tessellator, v, p);
   }
   gluTessEndContour(m_tessellator);
 }

public:
 Tessellator(const Polygon_with_holes_2& poly): m_tessellator(gluNewTess())
 {
   gluTessProperty(m_tessellator, GLU_TESS_WINDING_RULE, GLU_TESS_WINDING_POSITIVE);

   gluTessCallback(m_tessellator, GLU_TESS_VERTEX_DATA,  (_GLUfuncptr)Tessellator::vertexCallback);
   gluTessCallback(m_tessellator, GLU_TESS_BEGIN_DATA,   (_GLUfuncptr)Tessellator::beginCallback);
   gluTessCallback(m_tessellator, GLU_TESS_COMBINE_DATA, (_GLUfuncptr)Tessellator::combineCallback);
   gluTessCallback(m_tessellator, GLU_TESS_ERROR,        (_GLUfuncptr)Tessellator::errorCallback);

   gluTessBeginPolygon(m_tessellator, this);
     Polygon_2 outer = simplify_polygon(poly.outer_boundary());
     _glTessPoly(outer);
     for (Polygon_with_holes_2::Hole_const_iterator hole_it = poly.holes_begin(); hole_it != poly.holes_end(); hole_it++)
     {
       Polygon_2 hole = simplify_polygon(*hole_it);
       _glTessPoly(hole);
     }
   gluTessEndPolygon(m_tessellator);
 }

 virtual ~Tessellator()
 {
   gluDeleteTess(m_tessellator);
   for (Point_2_Vec::const_iterator it = m_all_vertices.begin(); it != m_all_vertices.end(); it++)
     delete *it;
 }

private:
 void _collect_triangle_fan(const Point_2_Vec& points, list<Polygon_2>& triangles)
 {
   Point_2_Vec::const_iterator it = points.begin();
   Point_2* center   = *it++;
   Point_2* previous = *it++;
   for (; it != points.end(); it++)
   {
     Polygon_2 new_poly;
     new_poly.push_back(*center);
     new_poly.push_back(*previous);
     new_poly.push_back(**it);
     triangles.push_back(new_poly);
     previous = *it;
   }
 }

 void _collect_triangle_strip(const Point_2_Vec& points, list<Polygon_2>& triangles)
 {
   Point_2_Vec::const_iterator it = points.begin();
   Point_2* first  = *it++;
   Point_2* second = *it++;
   bool switcher = true;
   for (; it != points.end(); it++)
   {
     Polygon_2 new_poly;
     new_poly.push_back(*first);
     new_poly.push_back(*second);
     new_poly.push_back(**it);
     triangles.push_back(new_poly);
     if (switcher) // keep them counterclockwise
       first   = *it;
     else
       second  = *it;
     switcher = not switcher;
   }
 }

 void _collect_triangles(const Point_2_Vec& points, list<Polygon_2>& triangles)
 {
   for (Point_2_Vec::const_iterator it = points.begin(); it != points.end();)
   {
     Polygon_2 new_poly;
     new_poly.push_back(**it++);
     new_poly.push_back(**it++);
     new_poly.push_back(**it++);
     triangles.push_back(new_poly);
   }
 }

public:
 void collect(list<Polygon_2>& triangles)
 {
   for (PolyVec::const_iterator poly_it = m_polygons.begin(); poly_it != m_polygons.end(); poly_it++)
   {
     const Poly& poly = *poly_it;
     switch (poly.first)
     {
       case GL_TRIANGLE_FAN:
         _collect_triangle_fan(poly.second, triangles);
         break;
       case GL_TRIANGLE_STRIP:
         _collect_triangle_strip(poly.second, triangles);
         break;
       case GL_TRIANGLES:
         _collect_triangles(poly.second, triangles);
         break;
       case GL_LINE_LOOP:
         throw runtime_error("Tessellator does not support GL_LINE_LOOP");
         break;
       default:
         throw runtime_error("Tessellator cannot handle this geometry type");
     }
   }
 }
};

I noticed blogger isn't very code-posting friendly. I want to create a post with some C++ code, and it really doesn't work very well.

Ideally, ofcourse, The code should also be colorized :) So maybe I should just run it through some tool that produces html from c++ code. I know it exists, but still, it complicates matters.

Well, I've updated my dns records to point pushistik to blogger. But I'm not sure what I'm going to do with this blog.

To be continued.