Full details are in the bug report:

https://bugs.launchpad.net/ubuntu/+bug/571958

If you’re going to use Ubuntu 10.4, make damned sure your shell scripts do not depend on case-sensitive shell expansion!

(Yes, i have backups, but i’ve got to pull them from 20 different source repos and a 15GB Dropbox, and the whole point of the exercise which revealed the bug was to avoid having to pull down 30GB of data from the net.)

>:-(

And how for something very different…

A couple of days ago i was looking for JavaScript code which can parse the Google Code wiki syntax reasonably well. i stumbled upon (via a link in a bug report) some code by Fabien Ménager which did most of the work. After coming across a few too many corner cases, i sat down to re-implement the parser using a char-by-char scan, rather than regexes, for most of the work.

It’s now about 20 hours after that work started, i haven’t slept in 26 hours, and Fabien and i now have:

• A reasonable parser (only missing a few markup features): http://code.google.com/p/wikiwym/
• An application to demo it: http://wikiwym.googlecode.com/svn/trunk/index.html
• And another application which allows the user to load arbitrary wiki pages from arbitrary Google Code-hosted projects and preview them in raw and HTML modes. That code can then be pasted back into the Google Code wiki editor when editing is finished: http://fossil.wanderinghorse.net/demos/wikiwym/

Basically, that last app provides an editor environment for people who edit wiki pages of arbitrary Google Code projects. The app cannot save the data back to Google Code for you, but it provides a relatively effective interface for editing wiki markup. If you make a mistake while typing in the editor, for example forgetting to close an inlined markup tag (bold, italics, etc.), the preview mode will prominently mark the error so you know where to fix it (and what to fix).

If you’re looking for a wiki parser implementation in JavaScript, this one might just suit you. If you’re a parser guru and would like to help us improve the parser, then please get in touch!

Happy hacking!

—– stephan beal

Interested in how it was being done, i followed the source code links, downloaded it, and set it up locally. After spending the whole day hacking on it, and sharing several mails with the author (who goes by the moniker Chromakode), i’m really interested in exploring this idea for web GUIs a bit more…

For those interested in truly geeky things, the source code is here:

http://github.com/chromakode/xkcdfools

i’ve tied that into an experimental JavaScript app framework i’ve been tinkering on the past year:

http://wanderinghorse.net/computing/javascript/jquery/jqapp/console.php

That page demonstrates tying in the CLI interface with JSON-centric RPC. e.g. the “ping” command sends of a JSON-structured RPC request to the server, the server dispatches it to the appropriate event handler, the handler answers and sends us back another JSON object describing the result. Such an interface could be used to write some exceedingly geeky web applications.

In any case… not something of general interest, but in case there are a few other hackers who find the Web/CLI mixture interesting… see the above links.

Happy Hacking!

—– stephan

(If you don’t program in C (or even know what that means) then the following won’t interest you in the slightest. If you are a C programmer, it might interest you in the slightest.)

It is common for C code to use the venerable void pointer, and (despite what our OO teachings might tell us), the void pointer isn’t the bad guy. Mis-use of void pointers is the bad guy. Because there are lots of ways to abuse a void pointer, void pointers are, at least in higher-level APIs, generally to be avoided. Lower-level APIs often cannot get by without them.

Today’s talk is not about void pointers in general (there’s an awful lot to say about void!), but specifically about using a void pointer to hold a function pointer.

Did you know that passing a function pointer via a void pointer, casting that void pointer to the original function pointer, and dereferencing (i.e. calling) the casted function results in undefined behaviour? That’s what the C standard says.

What does that mean? It means the following code is invokes undefined behavhiour in any country or providence which respects the C Standard:

typedef int (*my_callback)( void * state );
my_callback cb = some_callback_function;
void * ptr = cb;
((my_callback)ptr)( ... ); // <--- undefined behaviour!

The above code is rather contrived, but it demonstrates a feature which is seen from time to time in ancient C code. It is also used in some OS-level functions which open DLLs (e.g. based on dlopen() on POSIX systems). DLL-loading systems often look for a symbol with a specific name within the DLL right after they open it. If they find it, they treat it like a function and call it. Some DLL-loading systems provide a similar feature for closing a DLL. Higher-level “plugin” systems, common in today’s applications, often use this approach to fetch a factory function from the DLL, which is then used to create an instance of the plugin.

If such systems expect their magic symbol(s) to be a function (and in my experience they do!), then they are relying on undefined behaviour. And we abhor undefined behaviour, don’t we?

There is a portable, and only slightly inconvenient, workaround. In short, we add a level of indirection between the function we want to fetch from the DLL and the symbol name the DLL-opener expects to find. That level of indirection is a tiny struct:

typedef int (*my_callback)( void * state );
typedef struct my_callback_struct {
    my_callback callback;
} my_callback_struct;

And in our DLLs we use that indirection like so:

/* implements the my_callback() interface. */
static int private_callback( void * state );
/* The symbol our DLL/plugin system will look for: */
const my_callback_struct TheExpectedSymbolName =  {private_callback};

In the DLL opening code, we look for “TheExpectedSymbolName”, but instead of casting it to a function pointer, we cast it to a my_callback_struct pointer. From that object, we can invoke its member function without invoking undefined behaviour. Obviously, if the DLL contains a non-my_callback_struct with the expected symbol name, behaviour is undefined, but the function-pointer approach has the same problem.

This approach can easily be expanded to provide open() and close() routines for plugins, or any other application-specific plugin functionality. It can be combined with macros to allow clients to easily implement a plugin by calling the macro and passing pointers to their callback implementations. Since the DLL lookup symbols must unique, however, it means we have a limitation of one logical plugin per DLL file. (That is the norm in most plugin systems, but this limitation makes it an explicitproperty of such systems.)

In C++ (as opposed to C), the ability to to construct objects and call functions during the DLL’s static initialization phase (i.e. while it’s being opened, before the DLL opener gets it back) allows for an elegant solution to all of the above-mentioned problems and limitations. We won’t go into that here, but for interested readers there is a detailed article about it, called Classloading in C++, over at http://wanderinghorse.net/computing/papers/.

Happing hacking!

—– stephan beal, 2 March 2010

A few days ago i came across a trick in C. It isn’t new, but i hadn’t seen it used quite this way before and i wanted to share it…

Background: i have several mini-libraries which i tend to copy directly in to other projects. It has happened that i then use two other libraries together, and both of them internally use the same underlying mini-library. In some cases i want each to continue to use their own copy (maybe a different/incompatible version), but not collide with the other copy. Here’s one way to do it…

In the lib’s main header, before we declare any of its API:

#if !defined(MY_NS)
#  define MY_NS(X) my_namespace_prefix_ ## X
#endif

We then declare our types and functions using that macro:

int MY_NS(func1)( ... );
struct MY_NS(type1) { ... };

And throughout the implementation and client code we use:

int x = MY_NS(func1)( ... );

Each library which wants to import and rename the API then simply has to redefine MY_NS while building the included mini-library.

The major down-side is that this construct makes reading the docs through tools like doxygen more difficult.

Happy hacking!

The past year or two i’ve been working on various C-based projects. Through that work i’ve taken a strong interest in conserving memory and reducing the number of calls made to make new memory available (e.g. via malloc()). For example, i’ve spent many hours optimizing the whefs embedded filesystem library to run with fewer than 2kb of dynamic memory for the average use case (and as little as 96 bytes(!!!) for a highly-optimized case).

The past few days, that latent fascination with saving calls to malloc() has culminated into a new library:

whalloc (the WanderingHorse.net Allocator) is a small C library which provides an alternative memory management approach. It is initialized with a block of client-supplied memory, typically a stack-allocated char buffer, and then it can slice up that memory and use it for allocations and deallocations. The whole process looks a bit like:

whalloc_bt pool = whalloc_bt_empty;
enum { BufLen = 1024 * 8 };
unsigned char buffer[BufLen];
whalloc_size_t blockSize = sizeof(my_type);
int rc = whalloc_bt_init(&pool, buffer, BufLen, blockSize );
if( whalloc_rc.OK != rc ) { … error … }
my_type * m = whalloc_bt_alloc(&pool, sizeof(my_type));
// ^^^ m now lives somewhere inside of buffer
…
whalloc_bt_free(&pool, m); // makes the memory available for re-use
whalloc_bt_drain(&pool); // “deallocates” all allocated objects at once

The most interesting part is how it stores its memory management information: by taking up a small slice of the memory it is managing. It needs only two bits of storage for each block of memory it manages (there are (memBufferSize/blockSize) blocks in the buffer). The allocator takes up, worst-case (block size of 1 byte), 18-19% of that memory, dropping to 11% for 2-byte blocks, 6% for 4-byte-blocks, and halving for each additional doubling of block size. With a block size of 64 bytes it uses less than 0.5% of the memory for its own purposes. If its storing only a small number of blocks (default setting=128) then it can use its own few-byte-long internal cache and must reserve none of the client’s memory for its own purposes.

For the average use case, where objects are destroyed in reverse of their allocation order, it can perform O(1) if the allocations are equal to or smaller than the defined block size. Its worst-case performance is O(N), with N being a function of the number of blocks being allocated, the total number of blocks managed, and current memory pool fill status. Deallocation is always O(N), with N being the number of blocks being deallocated. For deallocation, finding the underlying management data is always O(1) - a simple hashing operation which uniquely maps any given pointer to its memory block index.

There’s also a variant of the allocator which requires 2 bytes (instead of 2 bits) per managed block. The primary difference is that it stores the requested size of each allocation, whereas the optimized variation simply knows whether a block as a whole has been allocated or not.

The allocators optionally support a client-provided mutex, to lock the allocator, and fallback allocation/deallocation functions, which they can use if their own pool runs out of space (e.g. falling back to malloc() and free()).

For those of you interested in C, in particular in shaving off a few bytes of dynamic memory in your C apps, the code is available (it’s in the Public Domain) over on the whalloc web page:

http://fossil.wanderinghorse.net/repos/whalloc

Happy hacking!

Which came first: the chicken or the egg?

And i think the point of it is that nobody really knows. Kind of like the ancient Egyptian saying, “if a tree falls in the dunes of the Sahara desert and no one hears it, did it really emit audible vibrations?” (Though the original hieroglyph looks something like a man with an axe in one hand and the other hand cupped to his ear.)

But i think there might be a solution:

A chicken, by definition, comes from an egg. Not just any egg, mind you, but a chicken egg. Thus it is impossible that the chicken came before the egg. Ergo, what laid the first chicken egg was not a chicken. That creature might indeed have been hatched from an egg, but because it cannot have been a chicken egg (as we just established), the first chicken egg still came before the first chicken.

Elementary, dear Watson!

Late last year i started working on an embedded filesystem library for C. The library uses “container files” (called embedded filesystems, or EFSes), in which the client can store “files” (i call them “pseudofiles”). The API allows random read/write access to them using a flexible i/o device interface. If you’ve ever programmed with sqlite - whefs is similar in concept but creates an embedded/virtual filesystem instead an embedded/virtual SQL server.

While whefs is still beta and open for lots of experimentation, it seems to be in a usable state.

To give whefs a more public home, a couple days ago i moved whefs over from its original source repository to Google Code:

http://code.google.com/p/whefs/

The project is of course open to collaboration, and i invite any interested C hackers out there to get in touch.

Happy hacking!

…

This is addressed those of you who are new to fossil and those who have used it for a while but just aren’t quite sure whether they like it or not…

Sometime in late 2007 i came across a link to fossil on sqlite.org. It was a good thing i bookmarked it, because i was never able to find the link again (it might have been in a bug report or something). The reasons i first took a close look at it were (A) it stemmed from the sqlite project, which i’ve held in high regards for years (e.g. i wrote JavaScript bindings for it: http://spiderape.sourceforge.net/plugins/sqlite/), and (B) it could run as a CGI. That second point might seem a bit archaic, but in practice CGI is the only way most hosted sites can set up a shared source repository with multiple user IDs. (i’m not about to give out my only account password or SSH key for my hosted sites, no matter how much i trust the other developers, and none of my hosters allow me to run standalone servers or add Apache modules.)

So i tried it out. The thing which bugged me most about it was having to type “commit” or “com” instead of “ci” for checking in (as is custom in all other systems i’ve used), despite the fact that fossil uses “ci” as a filter in things like the timeline view. Looking back now, i have used fossil for about about 95% of my work in the past year (http://blog.s11n.net/?p=71), in over 15 source trees, and i now get tripped up when i have to use svn or cvs.

So, having got over typing “fossil com -m …”, here’s why i love fossil so much…

Point #1: CGI

Again, this sounds archaic, but fossil has allowed me to share source trees which i cannot justifiably host in other projects i work on (they don’t belong to those projects), which i cannot host in Google Code (because google code doesn’t allow/recognize Public Domain as a license, and i refuse to relicense just to accommodate them), and for which SourceForge is overkill (and way too slow). With fossil i can create a new repo, have it installed on my hoster (http://fossil.wanderinghorse.net), and be commiting code to it within 5 minutes.

Point #2: Wiki

i hate wikis. i really do. Always have. They all have a different syntax and the content tends to get really disorganized really quickly. Their nature makes it difficult to reorganize them without replacing old pages with lots of “has been moved to [TheNewPage]” links. i’m one of those “code for tomorrow” coders (i.e., code such that it’ll be easy to reorganize/refactor later). i like to document the same way, and wikis make that problematic. Then again, no documentation system is really good in that regard.

That said, fossil has made me love having a centralized, common documentation platform. Whereas i used to document everything in the API docs (header files) and often include an ODT file for a library manual, fossil has become my preferred platform for non-API documentation because it’s just so easy to do. No matter where i am, i can log in and write (i write a lot). The added ability to export my wiki pages, edit them in xemacs, and re-import them just makes it nicer, as i can tweak as much as i want without ending up with 10 “updated wiki page SoAndSo” messages in the commit log.

Point #3: running a server locally

Fossil runs not only as a CGI, but as a server. i don’t WANT to host my own server (and don’t have the rights to on my hosters). i hate server-side maintenance (a hate born from years of administering systems). But the server has other uses. When working on the wiki, bug reports, etc., the local server is the way to do it. It’s blazingly fast and much more productive. When you’re done, just run “fossil push” and everything’s synced.

Point #4: the single-file repository

Having all controlled content inside a single container file has been a godsend when it comes to backups and copying/moving a repository. There are no access or file ownership issues, which are often problematic with other server-side systems (at least on the initial install). For about 5 years i administered a CVS repo for a company for, and every time someone added a directory to the (huge and dynamic) source tree i had to log in and “chmod 4775″ the directory before others could commit to it. Fossil’s model inherently eliminates that type of problem, and i’m a *huge* fan of solutions which inherently (that is, due to their very nature) avoid certain foreseeable problems. The single-file repository model’s flexibility would seem to become more problematic for massive repositories (a few hundred MB+) with many users with differing levels of access (e.g. OpenOffice, Firefox, or the Linux Kernel), but 99.9% of projects never reach anywhere near that size or complexity. (For that level of project, it would seem the world is quickly migrating to git.)

In summary:

i remember my first reaction to fossil being, “this will be an excellent solution for small projects [like the dozens we've all got sitting on our hard drives but which don't justify the hassle of version control].” A year of daily use in over 15 source trees has confirmed that, and i continue to heartily recommend fossil to other developers i know who also have their own collection of “unhosted” pet projects.

Even if fossil stagnates today, never adds another feature, and never gets another bug fix (what bugs?), this is a tool i see myself using for many years to come. (No, honestly, i don’t know what bugs you’re talking about.)

Happy hacking!

On this day in 2004, i made a post with the subject line “3… 2… 1.0!” to announce the release of libs11n, which had been in heavy development for almost 18 months at that time. A year later, 1.2.0 was released. Since then, libs11n’s 1.2.x branch has been fairly stable and has undergone only relatively minor updates and a few bug fixes.

This year i don’t have a new libs11n release to make :`(. That library is stable and useful, and the improvements i’d like to make would require some significant rearchitecting in areas where (A) i’m simply not the right man for the job (e.g. i118n/wide character support) and (B) i have little interest and therefore correspondingly little drive to work on them.

But that doesn’t mean i haven’t been coding. In hindsight, 2008 has been a record year for me in terms of number of lines of code produced, on par with 2004 (when i would sometimes spend 60+ hours per week hacking on s11n - one particular week saw about 100 hours of hacking and less than 20 hours of sleep). Quite unlike 2004, where i expended 100% of my energy on libs11n (and its supporting code/subprojects), 2008 saw the birth of several new pet projects.

So, though i don’t have another 1.0 (or 1.1, or 1.5) release to present at the end of this year, i thought i’d post a bit about what software i’ve been working on this year. This post is not to brag, but does serve a few purposes:

• i won’t deny it: publicity for new personal projects which might be of interest to some other hackers out there.
• i’m trying to justify to myself why i spent so little time with my family (Simone and Baako) this year. Likewise, my parents and friends probably wonder why i’m so uncommunicative.
• Help me internally sum up what’s just passed, to help me sort out what comes next.
• We all started coding somewhere, and we all draw inspiration from different places. It is my hope that some young hacker out there may be inspired to explore his love of computing. With some effort on his part he may someday surpass us all in ability.
• And lastly, to set up the scene for my “coming out” at the end of this post.

So, here it goes…

(In case you’re more interested in a quick summary, just read the text marked in bold.)

The first half of the year was quite slow, in terms of coding. i had just moved back to Munich and was settling in. On this very night one year ago we didn’t yet have a flat in Munich, and were stuck in a hotel room so small you could practically step into the bed from the doorway.

The code i do remember working on includes what i now call whprintf, a custom printf() implementation which i took from the sqlite3 source tree and refactored so that it can send its output to an arbitrary destination (e.g. a GUI widget, stdout, a socket, or a memory buffer) via a callback mechanism. Aside from that, i mainly experimented with utility classes for C, such as managed memory buffers and hashtables (i couldn’t code my own hashtable from scratch, but i hacked quite a lot on one written by Christopher Clark).

In April or May of 2008 i came across PEGTL, a C++0x library for creating PEG parsers using C++ templates. PEGTL inspired me tremendously, and PEGTL’s author (Dr. Colin Hirsch) and myself exchanged over 100 emails on the topic inside of a month or so. Unsatisfied with some of his design decisions, i of course took it upon myself to take a crack at the problem. My first attempt, named parse0x, was also a C++0x library. It did almost everything pegtl did and i was happy with it. i was, however, unhappy that i couldn’t use parse0x in real projects because it requires C++0x support, which is still far from leaving beta status in the next generation of C++ compilers.

So i sat down to approach the problem from C++9x, and hacked out parsepp, which is similar to both pegtl and parse0x, but nowhere near as powerful as libraries like Boost.Spirit.

And all was good. Two projects behind me and the year not quite half over, i got a sudden urge (for reasons i don’t remember), to rewrite an old program of mine for playing boardgames on the PC (tactical/strategy games are a hobby of mine, though i haven’t actually played any in some years). So i spent much of June getting back into Qt by writing QBoard. As is usual with Qt apps, QBoard grew way beyond the minimalistic app i wanted to write (Qt just makes it easy to keep adding features), and within a month or two it was doing 90% of everything i would probably ever want it do, and QBoard now sits quietly, awaiting the next urge to hack on it. If you use (or are aware of) libs11n, it might interest you to know that libs11n was originally written to support the rewrite which would become QBoard. That is, QBoard is largely the reason libs11n ever came into existance.

The last time i did any significant work on QBoard was September, after which i was again enchanted by the idea of PEG parser generators…

In the end of 2007 i got involved on the fringes of the Fossil project, where i contribute patches now and then. Fossil re-awakened my interest in C (which i used heavily in 1992-1995, but not since discovering higher-level languages), and since early 2008 i have spent a significant amount of time banging out little C libraries, both to get back into practice and to build up components for other planned projects. That re-emergence of interest in C, combined with my fascination of the concept of PEG parsers, led me to try tackling the PEG problem again, but from a much different direction than before.

And thus pegc was born. pegc was to be my third PEG parsing library in 2008, but this time it was implemented in C (and in fact has turned out to be somewhat more interesting than the C++ variants). As far as i have been able to determine, pegc is the only C library of its kind (there are some C code generators for PEGs, but no C libraries). After getting pegc to a “90% there” point, i put it down for a while to put some more thought into a few of the internals, and didn’t hack on it for a couple months. Unaware that anyone else knew about pegc (other than google, of course, but i thought he could keep a secret), another coder surprised me by sending me an email in which he explained that he had implemented a LISP-based PEG generator using pegc as the back-end. That has (yet again) re-awakened my interest in PEGs, and there is certainly more work to be done in this area in 2009.

The year was a couple months short of ending and i had accomplished much coding and solved some problems which interested me. But, as i would later find out, the year was far from over. My two greatest challenges were to be found hiding in the bushes up ahead…

Encouraged by pegc’s development, i decided to expend some effort on a problem which i had original discounted as “too much trouble to be worth the effort” - the generic serialization of objects in the C programming language. (Ouch!) So in late October i sat down to hack. Within a few days c11n was born. While c11n cannot reach the ease of use levels of C++ serialization libraries (because C is not “dynamically expressive” enough to do so), it does work and wasn’t nearly as difficult to implement as i had initially anticipated (it was simply a matter of finding (err… stumbling across) a useful model).

It was sometime in early December, the year almost over, when i got the itch to work on yet more C code.

There’s a problem i’ve contemplated for years but never really knew where to start - a virtual/embedded filesystem. Google reveals little non-commercial activity in this area, so there aren’t many decent starting points to study. This type of problem is C’s bread and butter, and having lost much of my previous distaste for C, i took what i’d learned over the previous year and tried to apply it to what was (in my mind) my most challenging C program yet. Truth be told, i was largely anticipating a crash-and-burn coding session, at the end of which i would be so frustrated as to leave C forever.

After a day or two of hacking i had the basic filesystem generator in place, but wasn’t happy with the i/o model (based on the C-standard (FILE*) API). So i scraped out the i/o layer API from c11n (which i had grown quite happy with), extended it to support random-access devices, and forked that to create the whio i/o library. The primary reason for this step was so that the VFS could use arbitrary back-end storage (provided it’s capable of random-access), and to that end i added implementations for treating standard file handles and in-memory buffers as i/o devices.

With whio in place i reimplemented the embedded filesystem (now called whefs) around it, and within a week or ten days i had gotten the rest of the significant bits in place. As of a few days ago i’ve got a working embedded filesystem library, which is like my little Christmas present to myself (just a few days late). Now i’ve just got to find a use case for it. (That said, googling has revealed very little open source code in this area, so there is potential for whefs to become a useful niche market product.)

Whew!

And now i’m tired and have sworn not to program a single line of code for the rest of 2008. All 4 hours and 39 minutes of it. I might write some documentation, but i’ll (somehow) avoid the temptation to code. i think i can do it. Wish me luck.

It wasn’t my intention to turn 2008 into a running hackathon, nor to set a personal record, but that’s essentially how it turned out. Truth be told, little of this is code which i will use on a regular basis. Nonetheless, i immensely enjoyed hacking on these projects, and some of them will certainly see continued development for some time (namely c11n, pegc, and whefs).

According to David Wheeler’s SLOCCount, it would have cost a company around half a million dollars to get it all written and out the door, whereas a garden variety hacker can do it all from the comfort of his living room using nothing more than freely-available tools like XEmacs, GNU Make, gcc, and google. Though he also isn’t likely to get paid for it.

And speaking of hackers…

(Now for the “coming out” announcement…)

Per long-standing traditions, programmers are never to call themselves hackers until another hacker calls them a hacker. This is fair and respectful, and in deference to this ideal i have always been careful about who i publically dub to be a “hacker.” i have in fact been called a hacker by other hackers, but i don’t normally proclaim myself to be a hacker. Part of the reason is the misinformed public opinion that a hacker is one who breaks into computer systems (something i’ve never had an interest in and certainly never done), where as we (that is, anyone who would read so far into this blog post!) all know that a hacker is someone who not only loves working on software, but is also particularly good at it. Another reason i’ve avoided using the word in reference to myself has been because i have not always felt that i am quite qualified to wear the title. i won’t claim to be a guru in any given area of computer science (and i’m certainly a zero in many areas!), but i can confidently say that i am a fairly good general-purpose programmer.

But i’m also now convinced that i am indeed a hacker. The past year i somehow managed to implement three programs in particular (c11n, pegc, and whefs) which i would have thought impossible (for me) half a decade ago. That might be reason enough to be dubbed a hacker. The more compelling reason, however, has nothing to do with lines of code or architecture or the number of functions in one’s API. Simone has sometimes asked me, “how can you be so tired from your six hours at work, and then sit here for 12 hours programming?” The answer took me some time to find (as i had never given it any thought before), but is in principal simple. Everything we do requires an expenditure of energy. Working as a Unix system administrator (my current job) takes a lot of energy. It sucks me dry at times. Programming, on the other hand, not only takes relatively little energy (per unit of time), but often literally gives more energy than it takes. That has convinced me that i may unashamedly use the title Hacker (though i’ll use a small “h”, to keep it in proportion ;).

So, there you have it. i’ve just written the world’s longest “i’m a hacker” post.

Happy hacking!

PS: i’ve still got 3 hours and 14 minutes before i may hack again.

Update: 1 hour and 47 minutes