copton.nethttp://blog.copton.net
2.4263102175e-12en-usAlexander Bernauer2013-02-20T22:52:46+01:00http://blog.copton.net/archives/2013/02/20/moving_to_blogger_com/index.html
http://blog.copton.net/archives/2013/02/20/moving_to_blogger_com/index.htmlmoving to blogger.com2013-02-20T22:52:44+01:00Alexander BernauerI have decided to migrate this blog to alexander-bernauer.blogspot.ch/. This instance will stay to serve existing hyperlinks, but new posts will all go to blogger.com.]]>http://blog.copton.net/archives/2012/01/10/scrab_your_boilerplate/index.html
http://blog.copton.net/archives/2012/01/10/scrab_your_boilerplate/index.htmlScrab your Boilerplate2012-01-10T18:00:37+01:00Alexander Bernauer VortragSince this year, there is a Haskell user group in Zurich. And recently we have started a series of workshops to share experience and knowledge all around the Haskell language, its libraries and tools.

Scrap Your Boilerplate in combination with the Language.C library gives you the power to implement source to source transformations of C programs with very few lines of codes. That's why I make heavy use of it in the implementation of the Ocram compiler.

]]>http://blog.copton.net/archives/2011/10/15/bitcoin/index.html
http://blog.copton.net/archives/2011/10/15/bitcoin/index.htmlBitcoin2011-10-15T17:10:04+01:00Alexander Bernauer VortragToday I gave another talk on Bitcoin at the 0sec conference. Compared to previous talks on this topic I went much more into the technical detailis. It surprised me to find out how much more is behind this system. Check out the Bitcoin script language for example. And make sure to read about Namecoin.

]]>http://blog.copton.net/archives/2011/02/27/react_a_command_line_tool_for_inotify/index.html
http://blog.copton.net/archives/2011/02/27/react_a_command_line_tool_for_inotify/index.htmlreact, a command line tool for inotify2011-02-27T14:54:37+01:00Alexander Bernauer PublikationenYes, it's 2011 and I am still using vim for software development. Damn, this
editor is so good ;-). But it is not an IDE. Thus, one thing I was missing is
automatically executing the compiler or the test suite.

Fortunatelly, there is the inotify API on Linux and associated inotify tools. They let you register callbacks in the user land when something happens on the file system. And even better, there is the PyInotify project, which provides Python bindings for inotify.

So, I went on and wrote react, which is a command line tool for inotify that is based on PyInotify. This tool monitors a directory recursively and triggers an external script every time a file that matches a user provided regular expression or shell file pattern is created or modified.

This tool really speeds up my vim-based software development. And it shows the value of bindings to a scripting language as I managed to finish the tool in under two hours. And as a side note: Python's argsparse is awesome! It is so good that I accepted to depend on Python 3.2. Hopefully this does not exclude too many users for now.

]]>http://blog.copton.net/archives/2010/03/03/when_new_features_collide_with_old_syntax/index.html
http://blog.copton.net/archives/2010/03/03/when_new_features_collide_with_old_syntax/index.htmlWhen new features collide with old syntax2010-03-03T22:19:43+01:00Alexander Bernauer C++My C++ times are over. But Roker keeps on feeding me with input. And I could not let this one go by unnoticed.

At first sight it looks like everything is ok. We know that references to temporaries must be const, which is the case here. So we think, d is going to be a Y object which was initilized with a temporary X object. In this case, the program should output "fnord".

But it doesn't. Instead it prints nothing. Mysterious you think? So did I. So I started debugging the issue while Roker was giggling. So, if d is not a Y object, what is it then? Let's ask the compiler and the C++ runtime:

The program now prints "F1YPF1XvEE". Hmm, I can not decrypt this, can you? We need to demangle the name in order to see it's real C++ nature:

$ c++filt -t F1YPF1XvEE
Y ()(X (*)())

Who can decrypt this? If you can't, here is a howto on reading C type declarations, because the unfamiliar syntax for function types is a C heritage. And what does this type mean after all? It means, that d is a function which returns a Y object and expects a pointer to a function which returns a X object and expects nothing. Got it? If not, here is how I would write it, in case I would need such a type:

This program prints Y ()(X (*)()) which is the type of d from the original program.

Ok, so now we know, what the program does. It declares a function. That's why there is no X object ever created. So, although the code could mean what we originally intended, the compiler chooses to understand something else, which is also possible due to the C syntax rules. Although I still don't know what function declarations inside other functions are good for, the compiler again prefers them. Anyway, what's the C way of removing ambiguity from syntax? Right, it's parantheses:

Now, the program prints "fnord" and "1Y" which is the mangled name for the type Y.

To sum it up, this is yet another example for why I consider the C heritage to be a major source of trouble for C++ developers. The C syntax was never designed for temporary variables and combining both yields to what we have seen here: ambiguity, ugly workarounds and surprise and furstration for the developer. Don't get me wrong, though. I still think that C++ could hardly have been made better given the design goals which where taken those days. I truly have a love-hate for that language.