After having been online for about 9 years now, i am being forced to take s11n.net offline. I.T. salaries in Europe have stayed flat since over 10 years while the cost of living increases practically weekly, and i can no longer afford to shell out some 300 Euros/year for hosting (my effective salary is probably half of what i made 10 years ago, despite having increased my skills/effectiveness by over 10x). i will TRY to get the blog ported over the wanderinghorse.net (my (MUCH cheaper) primary hoster) but i seem to have been shut out of shell access at this account and am too old and tired to deal with it, so it might just get deleted.

i cannot yet say WHEN it will go offline. i will cancel the contract in the next week or two but things like this take time in Germany, and it might take anywhere from 2 weeks to 3 months or more before it goes dark.

It’s been fun, but it has gotten too expensive to justify. If you do in fact follow this blog or my other works, please continue to do so over on android.wanderinghorse.net, which is my current blog. The other wanderinghorse.net domains still house my various projects, and s11n will eventually move over there (where hosting costs less than 1/6th of what i pay at 1&1), but the domain itself will probably not (because 1&1 intentionally makes it really painful to get out from under their thumb).

Happy Hacking!

—– stephan beal

As i begin my semi-official migration away from abusing the s11n.net domain for anything and everything, i have started another blog centered around software development on the Android platform: http://android.wanderinghorse.net

Unlike blog.s11n.net, the new one uses a modern WordPress which allows people to log in via social networks and has other cool features. (i have not upgraded this site because of the risks of losing 7 years of posts.)

If you are at all interested in Android development, stop on by.

In related news: sometime around September i will be moving s11n.net to a new hoster. The domain will be kept (because i can do so cheaply), but there might be some down-time while i port. (And i hope to Gawd that i don’t lose all the old posts when porting the blog…)

Happy Hacking!

—– stephan beal

i’ve been a happy, dedicated Ubuntu user since i left Kubuntu when they switched from KDE 3 to KDE 4 (which was, and still is, utterly useless as a work environment). i had been a happy, dedicated Kubuntu user since switching from Suse. i had been a happy, dedicated Suse user since the summer of 1998, shortly after i moved to Germany, and only left them because their package management tools simply got atrociously bad (i’m sure they have since gotten better, but once you’ve used apt-get and friends you can’t ever go back to an RPM-based system). Before Suse i would use various distros and had no real favourite (i started using Linux in 1994). i think i was using Slackware most of the time back then.

When Ubuntu 11.04 came out i diligently upgraded. “Upgrade,” he says! Upgrade!!! Right! It was supposed to be an upgrade! But the Ubuntu project went with some eye-candy desktop environment with the same core properties as KDE4: it looks beautiful but is absolutely useless as a work environment. i need a WORKstation, not a PLAYstation (that’s what my GameBoy is for). So i back-revved (upgraded!) 11.04 to 10.10 and was once a happy, dedicated Ubuntu user.

And then came 11.10, and i felt compelled to try it out. BAD IDEA! Not only does it have that same goddamned Mac-like user interface, they’ve moved the app menu to the top of the screen. Steve Jobs isn’t dead - he went to work for Ubuntu.

I HATE HAVING THE MENU ON THE TOP OF MY SCREEN. After reading several blog posts about how to remove it, nothing worked. So i installed the LXDE desktop on it, which is actually quite nice but has the fatal flaw that it cannot properly do multi-head (or it has no tool for setting it up like Ubuntu and friends have). My netbook (my only PC) gets continually moved between two different external monitors and i need a work environment which can do that. Ubuntu handled that beautifully, without any restarting or other Windows/Firefox-like behaviour. So LXDE is ruled out.

At this very moment i’m running the LiveCD version of Mint Linux, and it’s installing as i’m writing this (try doing that in Windows or Mac!).

GOODBYE, UBUNTU! i once loved you, but this betrayal is too much. i cannot live with a menu stuck at the top of my screen and a desktop with which i cannot work. Even in “Gnome Classic” mode that goddamned menu sits at the top of my screen, continually taunting me. i can’t have my PC taunting me, so off you go, back to the toybox where your Unity desktop belongs.

The installer is finished now, so it’s now time to go get all my packages installed and whatnot. What a waste of time. This type of thing was fun 10 or 12 years ago, but i’m too old for that - i want a system which just works and keeps working. Kinda like Ubuntu did up until version 11.04.

Despite the fact that the world has tons of wiki managers/back-ends, i felt compelled hack one of my own together. The initial inspiration for this came from the Fossil, an SCM which integrates source control, a wiki, and bug-tracking into a single application binary which can be used from the command line, a standalone web server, or as a CGI on an arbitrary web hoster. (i host many of my own projects using Fossil CGI over on fossil.wanderinghorse.net.) Through my use of fossil, i’ve come accustomed to maintaining non-API project documentation in a wiki, and love the ease-of-documentation this gives me (i’m a documentation maniac). Despite my love for fossil, however, i always felt that i was betraying the only wiki syntax i really like - the one used by Google Code. Since fossil doesn’t provide the features i need to replace its wiki handler with one of my own… you guessed it (or read it in the first line of this post)… i wrote a new wiki back-end.

In April i started work on whiki (the WanderingHorse.net Wiki), a “different sort” of wiki back-end, and it is now in a functional state (hosting three live wikis as of 17 May 2011). Like most wiki back-ends, it uses a database (sqlite3 or MySQLv5) to store its pages. What differentiates whiki from other wiki back-ends is:

• It is implemented in C and runs as a CGI application (or, to some degree, from the command line). i’m not personally aware of any other wiki manager/back-end implemented in C.
• It consumes and produces only JSON data. Requests are sent in the form of simple HTTP GET or (for more complex requests) POST requests (with JSON payload data) and responses are in the form of a JSON object tree.
• It has no “native” wiki format. Instead it tags each wiki page with a “content type” label (e.g. “text/plain” or “wiki/googlecode”), and applications can use that hint to determine how they should render a given page. Client applications can, with little effort, support multiple content types in the same logical wiki (e.g. plain text, source code (to be syntax-highlighted by the renderer), HTML, or even multiple wiki formats).
• It has no “native” user interface. UIs can be written using client-side languages like JavaScript, Java, or PHP, which interact with the whiki back-end via JSON messages. The main whiki website is implemented entirely in JavaScript, CSS, and HTML, and primarily uses the wikiwym GoogleCode-syntax wiki parser for rendering its pages (but it also supports several other content types).
• It allows clients to attach arbitrary JSON data to each page. This can be used for any number of things, e.g. implementing “tags”, marking certain pages as “featured” or “important”, defining intra-page relationships (e.g. for rendering a hierarchical menu), or flagging a certain page as the “home page.”

whiki is not, and will never, be an industrial-strength back-end like the one used to power Wikipedia (or any number of other large wikis). It is intended to supplant my fossil-based wikis (meaning anywhere from 5 to 20 pages or so). It is also missing some features which would certainly be of critical importance to many potential users. e.g. it has no search functionality, only two access levels (all or nothing), and has no support for storing historical versions of each page. (With another contributor or three we could fix those shortcomings, but i personally have relatively little need of them.)

If the following applies to you:

• You’re an eccentric C hacker who wants to host his own small wiki but doesn’t want to use PHP or…
• You’re a lone hacker who wants to an easy way to host wiki-style documentation for one of his pet projects or…
• You currently use Fossil but aren’t quite satisfied with its wiki

… and you have the ability to compile and run C applications on your web hoster…

Then whiki just might be slightly interesting for you:

http://whiki.wanderinghorse.net

Happy Hacking!

—– stephan beal

(If you have no idea what a “v8 hacker” is then this post will mean nothing to you.)

i would like to announce a new v8-based project…

v8::convert is a header-only utility library for Google v8 with a very small focus:

• Converting between v8 and native values, including client-defined types.
• Converting C/C++ functions/methods to v8::InvocationCallback implementations.

With those two features we have almost everything we need for most class-binding purposes. The the ability to convert functions to have v8::InvocationCallback signatures has proven especially useful, and allows us to plug in in many C-standard or 3rd-party APIs with ease. Conversions are compile-time typesafe where possible and runtime conversion failures fail gracefully (e.g. by throwing a JS-side exception).

The core components are in no way project-specific, and can be used in conjunction with arbitrary other function/class binding mechanisms. Since the implementation is header-only, it’s particularly easy to include into other projects.

The API is trivial to use. The client API contains a good number of classes and functions, but most client code needs only one or m/ore of the 5 main function templates: CastToJS(), CastFromJS(), FunctionToInvocationCallback(), MethodToInvocationCallback(), and ConstMethodToInvocationCallback().

The missing parts are:

- Binding JS accessors to native values/functions. i have the code in v8-juice but need to port it to this API’s conventions.
- A class binding mechanism which takes care of the WeakPointer bits. There is such a mechanism in v8::convert, but it is not considered a core component because hackers tend to each have their own favourite class binding mechanism.

The code is largely a spin-off of the core-most v8-juice components, but the function-binding parts were re-implemented from scratch so that we can use function-pointer-style template parameters (which, IMO, are more readable than the v8-juice’s approach). Additionally, instead of inheriting v8-juice’s huge collection of weirdly-named function-binding templates, clients now need only 3 templates to bind functions (one each for free functions, const- and non-const member functions).

The idea of doing a header-only spin-off has been brewing for some time, but i was recently inspired to finally do the work by two other v8-users list members:

- James Pike: when i saw how vu8 takes advantage of function-pointer-style template parameters, i just had to have that feature for myself.

- Fuzzy Spoon: the separation of const- and non-const member handling was prompted by Fuzzy’s report about MSVC not being able to select the proper template specializations when the the member functions differ only in constness.

v8::convert is only about 3 nights old, but already has at least as much API documentation as v8 itself. There is an overview and example code here:

http://code.google.com/p/v8-juice/wiki/V8Convert

The source code is at:

http://code.google.com/p/v8-juice/source/browse/#svn/convert

It includes a standalone demo application and a demo v8-juice plugin.

Happy Hacking!
—– stephan beal

i couldn’t resist the urge: i had to try my hand at writing a JSON library for C:

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

cson (pronounced “season”) is my first JSON API for C. Its design is based largely on that of its “genetic stepbrother”, libnosjob (C++ JSON library).

It’s brand new and “might” still have a few bugs. It uses more memory than it really should when reading JSON, but i hope to eventually rectify that. Its main claim is that it can read JSON from damned near anywhere and write it to damned near anywhere. I/O implementations are provided from reading/write JSON from/to C-standard FILE handles and strings, and adding support for new i/o types (e.g. C++ strings or other custom stream types) is really easy.

If you’re (still) looking for a reasonably nice C API for consuming and generating JSON data, cson might be interesting for you.

Happy Hacking!

—– stephan beal

While i tend to write absurd amounts of technical documentation, mostly in the form of API docs and other code documentation, it’s been several years since i’ve published a technical article.

For those 5 or 6 remaining aspiring C programmers in the world, i’ve got a new article which demonstrates a useful 999(shit, my left shift key just quit working…)… ahem… demonstrates a useful (in my opinion) model for implementing object-oriented data structures and APIs in C. DAMMIT, AND NOW MY ENTER KEY BROKE!

(thank god for the numeric pad’s enter key…)

Since my keyboard just died, i’ll keep this short… the article is here:

http://wanderinghorse.net/computing/papers/

happy hacking1

9you never truly appreciate the left shift key until it’s gone…0

—– stephan beal

Update:

LOL! (i’ve now got my backup keyboard…) At the very same time my keyboard broke i began being affected by this new Google Chrome bug:

http://code.google.com/p/chromium/issues/detail?id=66071

(Short version: mouse wheel cannot scroll up, but can scroll down.)

i thought, because my keyboard and mouse (in Chrome, anyway) weren’t working, that maybe my USB bus was dying.

i just wanted to take a moment to point out an extremely useful little library for handling UTF8 and UTF16 in C++: Nemanja Trifunovic’s utfcpp (http://utfcpp.sourceforge.net/)

utfcpp follows the STL’s iterator model, and this model allows one to decode and encode UTF8 and UTF16 from and to damned near anywhere using a really simple API.

If you have to deal with UTF encoding/decoding in your C++ applications, i can heartily recommend utfcpp. It’s trivial to use, it has a header-only implementation with no external dependencies (except the STL), and it has very liberal licensing conditions (basically “do what you want, but keep this copyright notice intact”).

Happy hacking!

—– stephan beal

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