marathon runners

It occurred to me this morning:

The difference between the average runner and a marathon runner is that on off days the average runner is off, but the marathon runner only runs five miles.

By the way, I'm still in the first group, but trying to get to the second. This little quip occurred to me while running in the rain this morning and hating every minute of it. I usually find running to be very enjoyable, but today I just felt off and every step seemed to take a monumental effort. Anyway, since my goal is to be run a marathon, I figured I'd better forge on.

I think this anecdote is more generally applicable, imagine if you got "five miles worth" done on your off days in other aspects of life too. How great would your "on" days be!

introducing jsqueeze

Not that I want to get into any js framework debates, but I've been using prototype and scriptaculous for my ajax ui toolkit recently. However, I do have to give a nod to the dojo team for their javascript compressor, shrink safe. It seems to me that any javascript compressor/obfuscator must know about the underlying structure of the language if it wants to save every last byte.

As much as I like the idea of shrink safe, I have to confess that patching the rhino javascript process doesn't seem to most elegant way to harness its power. So, with that in mind, I managed to adapt the shrink safe code to simply use the rhino api to accomplish the same task. I've called by javascript compressor jsqueeze (or jsqz for short).

Anyway, if your interested and want to give it a spin, you can download the source here.

autotools mono integration

In short:

configure.ac:

AC_ARG_VAR([MCS], [the Mono C# compiler])

PKG_CHECK_EXISTS([mono])

MONO_PATH="`$PKG_CONFIG --variable=exec_prefix mono`/bin"

AC_PATH_PROG([MCS], [gmcs], [AC_MSG_ERROR([not found])], [$MONO_PATH])

Makefile.am:

EXEEXT=.dll

LINK=$(MCS) -target:library -out:$@

bin_PROGRAMS=foo

foo_SOURCES=foo.cs

foo_LDADD=$(foo_SOURCES)

win32 native mono from scratch

As a command line jockey, linux expert, and general unix fanatic, you can imagine my dismay when I learned I would be maintaining a significant C# code base. Until recently, I had never give the mono project a second thought (other than to question why a team of obviously talented programmers would want to spend their time implementing a language from microsoft), but suddenly, I find by daily programming productivity, prowess, and general happiness utterly depends on being able to build my C# apps with a reasonable open source tool chain. Enter mono.

Building mono from scratch proved to be a bit of a challenge, most of the instructions I was able to find either require that either mono be first installed (can you say circular dependency) or that some binary packages be downloaded. Neither of these solutions seemed quite satisfactory, so here are my instructions, for building mono, from scratch, using cygwin/mingw32.

First, you will need a basic cygwin installation, including gcc and the gcc-mingw32 packages.

Second, you will need to get the source for each of these packages:

libiconv (I used version 1.12)

gettext (I used version 0.17)

glib (I used version 2.14.5)

mono (I used both 1.2.6)

Next, we will build libiconv.

./configure --build=i686-pc-mingw32 \

    CC="gcc -mno-cygwin -mms-bitfields" \

    CXX="g++ -mno-cygwin -mms-bitfields"

make

make install

The key here is to make sure that you include the "-mno-cgywin" flag for gcc to ensure a native win32 executable (or library in this case).

After, libiconv, we can build gettext in a similar fashion. We do need to take care to ensure that gettext can find libiconv built and installed above.

./configure --build=i686-pc-mingw32 \

    CC="gcc -mno-cygwin -mms-bitfields" \

    CXX="g++ -mno-cygwin -mms-bitfields" \

    PATH="<libiconv-path>/bin:$PATH" \

    LDFLAGS="-L<libiconv-path>/lib"

make

make install

Note, windows uses PATH to find libraries as well as executables, as opposed to LD_LIBRARY_PATH. Also, I like to disable stuff I don't need, so I'll add --without-emacs, --disable-java, and LINGUAS="" to that configure command, you can pick and choose your own options as well.

glib is probably the most difficult of the mono dependencies to build. For one, in addition to libiconv and gettext, it requires the win32 api provided by mingw32, but can't seem to find it without some help (note the -L/usr/lib/w32api entry in LDFLAGS).

./configure --build=i686-pc-mingw32 \

    CC="gcc -mno-cygwin -mms-bitfields" \

    CXX="g++ -mno-cygwin -mms-bitfields" \

    CPPFLAGS="-I<libiconv-path>/include -I<gettext-path>/include" \

    LDFLAGS="-L<libiconv-path>/lib -L<libiconv-path>/lib -L/usr/lib/w32api"

make

make install

You may also find that line endings (win32 prefers crlf, while cygwin and the gnu toolchain may only expect lf) get in the way of some of the autoconf test. I had to fix up the configure script with the following sed one-liner.

sed -i 's/\(fopen *(.*\)"w"/\1"wb"/' configure

Finally, we are ready to build mono. So here goes.

./configure --build=i686-pc-mingw32 \

    CC="gcc -mno-cygwin -mms-bitfields" \

    CXX="g++ -mno-cygwin -mms-bitfields" \

    PKG_CONFIG_PATH="<glib-path>/lib/pkgconfig"

    CPPFLAGS="-I<libiconv-path>/include -I<gettext-path>/include -I<glib-path>/include"
\

    LDFLAGS="-L<libiconv-path>/lib -L<gettext-path>lib -L<glib-path>/lib -L/usr/lib/w32api"

make

make install

Nothing really new there, just as before, add the path to the glib headers to CPPFLAGS, the glib libraries to LDLFAGS, and the glib pkgconfig path to PKG_CONFIG_PATH (ok, I guess the pkgconfig part is kind of new).

Congratulations, if you've gotten this far, you should have a working native win32 version of mono built from scratch. Next, you'll want to checkout how to use autotools to build that C# project using your shiny new mono compiler.

my new landing place

previously, you could find me here. I've finally gotten around to migrating...

A glimpse into my twisted mind

The proper perspective for viewing my obsession with all things computer oriented has become clear. If I were a painter, would it be considered unusual for me to not paint for a week, but then suddenly spend three straight days locked in my studio (I'm not a painter, but the inspired-artist cliche leads me to believe this is normal). Anyway, this is how I work with computers.

Take for example a talk I was giving the other day. Now, I could have just grabbed a random power point off the departments shared drive, deleted/edited/replaced... But no, that could never be good enough. First of all, latex is my preferred method of document publishing, and I seriously doubt that any amount of power point wizardry could produce such quality presentations.

Given the short attention span of net readers, I ahead to the end before continuing...
So, many hours later, I now have a beamer template nearly identical to our standard power point one, I've learned to draw all sorts of things in metapost, and now have an insatiable urge to design a new typeface that I can bend to my every whim (for some reason I find myself drawn to proper small caps and old style numerals).

Ironically, I just found