Earlier I blogged about Epresent, which is basically a piece of code for making Org-Mode suitable for preparing presentation slides. There are times when I can’t resist mentioning the innovative Racket programming language in a presentation. In those situations I tend to want to have syntax-highlighted Scheme code on my slides, and also to evaluate the code snippets and insert the results next to the code listing. This is apparently the sort of thing one can do with Org-Mode Babel, for a variety of languages.

Text rendering in Emacs has been looking mighty good since 23.1, and this opens up possibilities to do even more in Emacs. For example, I recently came across something called epresent.el on GitHub, by Eric Schulte et al. The epresent.el Emacs Lisp file leverages Org-Mode to implement a simple presentation mode for Emacs. Using Org-Mode is, at least for me, faster than struggling with something like OpenOffice.org Impress.

C++ is a good language in that it is widely supported and has a large ecosystem around it. As a result, it has a large number of libraries, including extensive cross-platform frameworks (such as Qt). There are also entire operating systems written in C++, of which Symbian is an example. All of this provides ample motivation to use C++ (or at least its libraries) from time to time.

Some days ago I released a little code generation utility that I have been using for well over a year in cranking out repetitive C++ code. Koog is—for lack of a better established term—a mixed-code generator. It is similar to other tools of its kind (such as Cog), but the only one that I know of that uses the Scheme language for specifying what code to generate.

I’ve tried GCCE version 4 before for building Symbian software, but have been somewhat put off by all the warnings it produces, mostly due to incompatibilities with the header files in the existing S60 SDKs. Well, I finally managed to get a working S60 application built with GCCE 4 without any warnings. Mind you, this was just one application, and not built with the full Symbian toolchain, but still.

Symbian’s ABLD build system tends to produce a lot of output, especially when run with the verbose flag (-v), as I like to do to see the compiler invocations. Also, ABLD likes to run to “completion” despite individual build steps failing. The end result is that it takes some effort to look for the errors and warnings in the output.

Earlier I wrote about a problem with restoring data to my Nokia E71 after a firmware upgrade. Well, there was also another problem. Once again, I started getting the “Untrusted software found on memory card. To install, go to Application manager.” complaint upon my Nokia E71 booting or otherwise mounting the memory card. Application Manager showed no applications marked as “Not installed”, and reinstalling the applications I tend to have installed didn’t fix the problem.

So I upgrade the firmware of my Nokia E71 from v200 something to v300 something.

S60 3rd Edition has been out for quite a while by now, and for me, the one thing that has all but killed the pleasure of developing native software for the platform has been the humiliating wait—dismiss dialog—wait—dismiss dialog—wait—dismiss dialog—wait procedure during installation of the software being tested and developed. For one-off installations the installation procedure is no problem, but when you’re a developer it gets old real fast.

Earlier releases of the Miso PyS60 extension had a take_photo function, for taking photos (without a viewfinder). This functionality (and more) has since then been integrated to PyS60 itself in the form of the built-in camera module.

Early last year at HIIT I hacked the Python for S60 inbox module to have it support querying for the content and metadata of messages in the device Inbox that have been sent via Bluetooth OBEX Push. (The built-in inbox module apparently only supports accessing SMS messages.) I changed the name of the hacked module to pyinbox, to avoid conflicts with the built-in Inbox access module.

In the PDIS project at HIIT we developed a socket library for Python for S60. The library consisted of both a native extension and quite a bit of Python code. The native extension was called aosocketnativenew, and became somewhat well known as an extension supporting non-interactive Bluetooth discovery.

I am a big fan of Python’s keyword argument facility, and especially its support for *args and **kwargs function parameter declarations. *args and **kwargs capture any explicitly undeclared positional and keyword arguments, respectively, and this facility in many cases allows one to avoid repeating function interfaces. This is both less typing and more future proof, and makes it easier to see the parameters that directly concern a function. Contrast this with Java, which not only has no keyword arguments, and no support for *args style declarations, but which also forces you to repeat caught exception declarations in function signatures.

There are a few Symbian software authors who occasionally write a piece of Symbian code, possibly with no intention of ever touching the code again, package it up as a SIS file, and then “fire and forget” that SIS file to some web site in case someone should find it useful. Or forget until such time that someone complains about the SIS file having been expired.

Some operations on the Nokia E61 are painfully slow. For instance navigating the applications menu can be time consuming, especially if the folders being opened have many items in them. The other day I managed—by (un)installing some SIS files—to get the icon server of the device to crash (it produced a panic). This resulted in an iconless applications menu, with only application names visible, but otherwise seemed to have no adverse effect. And navigating the menu had become much faster, with no folder taking more than a fraction of a second to open.

The SDK API Plug-in package for S60 SDKs has quite a few interesting APIs, such as the Browser Launcher API and the New File Service Client API.

When designing socket code to be implemented in C, it may well make sense to first sketch out the design in Ruby. The Socket class provides thin wrappings for just about all of the relevant C standard library functions. There also is the fcntl module, and select in Kernel. The socket code can thus be just about the same in Ruby as it would be in C, but trying out different designs for say managing sessions in a server is much less tedious in Ruby.