Miscellaneous musings in beta

The other day I noticed a change in Apples iPhone Developer Program License Agreement. The controversial section 3.3.2 had a sentence saying:

No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).

It’s now saying:

Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s). Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.

Knowing Apple and the “curated” app experience, it would be an understatement to say that this is a crack in the agreement. It’s a small crack, but given the pressure fra Google’s Android platform I think it’s indicative of a movement towards being able to use interpreted code in your apps. Like Lua.

Despite being banned per the old section 3.3.2 Lua is extensively used by a lot of games currently on sale in the appstore, and it’s an excellent way to do the more complex parts of a game – like AI, game rules or pathfinding. So I’m hoping the change means that developers are now getting more tools for the task. With Apple’s approval.

To parafrase Mark Twain I guess the reports of Lua’s death on the iPhone are greatly exaggerated.

This is a text whose origin is lost in the sea of blogs citing it. Why? Because it’s rather funny – in a geeky kinda way:

- Which programming language should I learn first?

- Depends.

- To program in an expressive and powerful language: Python
- To get a website up quickly: PHP
- To mingle with programmers who call themselves “rockstars”: Ruby.
- To really learn to program: C.
- To achieve enlightenment: Scheme.
- To feel depressed: SQL
- To drop a chromosome: Microsoft Visual Basic
- To get a guaranteed, mediocre, but well paying job writing financial applications – in a cubicle under fluorescent lights: Java.
- To do the same thing with certifications and letters after your name: C#
- To achieve a magical sense of childlike wonder that you have a hard time differentiating from megalomania: Objective C

- I could go on… but I’m not feeling hateful enough today.

Installing irssi on a Mac is easy. You could just use Fink or MacPorts. However I previously have had issues with package managers and separate library paths, so I prefer to compile things myself. At least on my MacBook.

Compiling irssi is not an easy task though. And since I used many hours of trying to make irssi compile, I’d better jot the solution down. Just in case my hard drive decides to do a critical meltdown (that has been known to happen).

Luckily I didn’t have to start from scratch. This blog post helped a lot. So thanks Magnanimous Antics if you’re reading this.

First get the source. You’ll need:

Irssi (0.8.15)
Glib (2.22.5)
pkg-config (0.25)
Gettext (0.18.1.1)
Libiconv (1.13.1)

On a side note: Like MacPorts use /opt/local/ I too use a custom path for any application I compile. It’s /Users/morten/builds. By installing in my home directory, I avoid overwriting system files. And like MacPorts I just add the path to my PATH before $PATH in my .profile. If any conflicts with other installations or versions arise I can easily remove the installation again. People not wanting to do this can simply omit the –prefix part.

To compile pkg-config, gettext and libiconv (in that order) I did:

./configure prefix=/Users/morten/builds
make
make install

After libiconv I compiled gettext again – since libiconv and gettext are mutually dependent on each other.

Next came Glib. When I compiled glib by doing the above command this error popped up:

You must have either have gettext support in your C library, or use the GNU gettext Library

Pretty sure that I had just compiled gettext successfully, I Googled the error and found a solution that worked. It seems that Glib needs the linking a bit more explicit:

./configure --prefix=/Users/morten/builds LDFLAGS="-L/Users/morten/builds/lib" CPPFLAGS="-I/Users/morten/builds/include"

To ensure a 64bit version of Glib I opened glib/gconvert.c in Emacs and replaced the last three lines of this:

#if defined(USE_LIBICONV_GNU) && !defined (_LIBICONV_H)
#error GNU libiconv in use but included iconv.h not from libiconv
#endif
#if !defined(USE_LIBICONV_GNU) && defined (_LIBICONV_H)
#error GNU libiconv not in use but included iconv.h is from libiconv
#endif

with this:

#if !(defined(__APPLE__) && defined(__LP64__)) && !defined(USE_LIBICONV_GNU) && defined (_LIBICONV_H)
#error GNU libiconv not in use but included iconv.h is from libiconv
#endif

and then did a:

make
make install

Done. Finally the turn came to Irssi. Again I got an error doing the ./compile. Some Googling revealed a search and replace solution, but the commands below worked as well – and to the same effect: a 64-bit version of Irssi:

./configure --prefix=/Users/morten/builds --build=x86_64-apple-darwin10.2.0 ARCHFLAGS="-arch x86_64"
make
make install

All done.

Epilogue: I wanted to compile and run irssi-xmpp as well. After compiling the required loudmouth 1.4.3 like this:

./configure --prefix=/Users/morten/builds CFLAGS="-I/Users/morten/builds/include" --with-ssl=openssl
make
make install

my efforts stranded on lots of linking errors.

Even after changing config.mk considerably I simply cannot coerce irssi-xmpp to compile. If anyone reading this has a working solution I would definitely like to know.