For the geeks

Posted on

Normal people can just close this browser tab and come back another time.

If you’re a geek (like this site’s author) and frequent it for juicy tidbits on geeky things, I know you’ve been sorely disappointed for quite a while. What, with all the talk about foxy nurses and sweet-scented women and such.

Fear not my over-nourished, under-active cohorts, things are about to change.

Over last weekend, after ages, I tried to build GNOME from CVS. Contrary to popular belief, I am thankful for the fact that it’s freaking cold out in these parts. This keeps my otherwise-extremely-flaky laptop cool and alive at 100% processor usage for the evening or whatever it takes to build GNOME and its cohorts. No more “thermal event” system failures. Yay!

For the next 8 months, anyway.

Me building GNOME

Turns out, it wasn’t worth the pain [PDF]. Try zooming into that figure, and it’s like an infinitely dense fractal. No matter how deep you go, the dependency arrows still seem like a mangled mess. After toying around with some small sample apps, I gave up and decided to wait until the distribution folk packaged the bigger apps like Evolution. Along the same lines, I did embark toward modern doohickeys like Xgl, but soon gave up on that idea as well.

Honestly, I muttered something akin to “Screw that, life is too short”. But I have to say,

» zenity is the most simply-useful thing I’ve seen in a long while,
» what the fuck is up with so much Python use? Don’t people realize using anything other than C is nearly-automatically dog slow? Don’t even get me started on Java. Why not just start using Haskell or LISP, or heaven-forbid, C# everywhere?,
» after so long, gnome-terminal finally doesn’t seem sluggish,
» and why is esound still around?

But all was not lost. During the course of mucking around, I realised Emacs could be built using GTK as its widget toolkit and using Xft for anti-aliased fonts. So, in between writing something, I checked it out and built it.

Voila!

Emacs before the facelift

Emacs after the facelift

It’s so sweet, this post is being typed up on it. All the Emacsy flavour you love, none of the calories!

Here’s how you can go about getting it yourself:

  1. Fetch the sources from savannah’s CVS.
    export CVS_RSH=ssh
    cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/cvsroot/emacs co emacs
    cd emacs
    cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/cvsroot/emacs up -Pd -r XFT_JHD_BRANCH
  2. Configure and build it.
    cd emacs
    ./configure —prefix=/your/fav/place —with-gtk —with-xft
    make bootstrap
    (Wait 19,000 years.)
    make
    make install
  3. Run it and have enjoy!
    /your/fav/place/bin/emacs --font "Bitstream Vera Sans Mono-10"

7 thoughts on “For the geeks”

  1. > what the fuck is up with so much Python use? Don’t people realize using
    > anything other than C is nearly-automatically dog slow? Don’t even get me
    > started on Java

    I am not sure where in GNOME python is used heavily. I know the GNOME library is all C/C++. I wouldn’t be surprised if the GNOME developers just exposed core desktop components (like panel, menu etc) as libraries and most of the actual applications (like weather applet etc) are written in Python using those libraries. Python (or other scripting languages) are so much more easier to develop applications with.
    About Java, it is not slow by design. In fact, theoretically, executing Java bytecode should be faster than statically compiled C code because of the dynamic compilation system (the JRE). But current implementations of JRE are not up to the mark. They are getting there, though.

  2. It is exactly how you described it. GNOME, as in the core (however it is referred to) is primarily C. Even C++, is just a language binding/wrapper like other esoteric things like Eiffel. That isn’t the problem. But that isn’t all of GNOME either. Counting all the numerous useful applications that make up the desktop platform (or whatever), you soon have a number of programs written in these higher level languages which (for the lack of insanely optimised implementations of things like the JRE) suck. I understand that wrappers primarily fall back on the exposed C API components for functionality, but they aren’t all the way there.

    Anyway, I thought more about this after reading your comment. I realized my problem with all of this is partly elitist, and is probably rooted elsewhere. I’ve seen how much easier it is to develop in an environment like Python or C#, as opposed to mucking around with things like GTK+ (or god-forbid, MFC) in C. I’ve associated this with the lowered barrier to entry and therefore associate this with any random person coming in and writing a program. Which means, in my head, not a necessarily good or efficient program, but something that works because it was easy enough to do. Which I assume, by definition, will be slow.

    Psycho-analysis apart, I don’t see how dynamic compilation can be faster than static compilation. But then again, I am a physics person, not a computer scientist.

  3. A dynamic compilation system has a whole lot of runtime information which is not available to the static compiler. Every pointer is resolved, bias on every branch is known, etc. So the JIT compiler can potentially produce more optimised code than a static one time compiler. But you have to take into account, the warm-up time for profiling the code, the overheads due to profiling instrumentation etc. Dynamic compiler is pretty good for long running server side programs, and there is where they are used heavily I think.

  4. Ah, that does make sense. I was beginning to think about branch prediction, but I wasn’t thinking about other information being known, like all pointers resolved.

    My whole initial thought was only looking at the other expensive things you mentioned later on, with very little thought to the positives.

    Great, I learn something every day!

Comments are closed.