Author: root42

Limiting the number of lines in the compilation window

For large projects, the output in the compilation window can become quite large. Furthermore, I use the ANSI coloring functionality, so that colored build systems look nice. These two things together can slow down Emacs significantly. However, when the compilation buffer gets so long, the output is most probably only success messages anyway. The errors would already have stopped the compilation process. So I wrote the following function to trim the compilation buffer:


(defun my-limit-compilation-buffer ()
  "This function limits the length of the compilation buffer.
It uses the variable my-compilation-buffer-length to determine
the maximum allowed number of lines. It will then delete the first 
N+50 lines of the buffer, where N is the number of lines that the 
buffer is longer than the above mentioned variable allows."
  (toggle-read-only)
  (buffer-disable-undo)
  (let ((num-lines (count-lines (point-min) (point-max))))
    (if (> num-lines my-compilation-buffer-length)
        (let ((beg (point)))
          (goto-char (point-min))
          (forward-line 
           (+ 
            (- num-lines my-compilation-buffer-length)
            (/ my-compilation-buffer-length 10) ) )
          (delete-region (point-min) (point))
          (goto-char beg)
          )
      )
    )
  (buffer-enable-undo)
  (toggle-read-only)
  )

Of course, now you still have to register this function to be actually applied to the compilation buffer, so I read about customization variables. And out came this, to introduce a customizable variable for toggling the compilation-trimming behaviour: 


(defun set-my-compilation-buffer-length (symbol value)
  (set-default symbol value)
  (if value
      (add-hook 'compilation-filter-hook 'my-limit-compilation-buffer)
    (remove-hook 'compilation-filter-hook 'my-limit-compilation-buffer)
    )
  )

(defcustom my-compilation-buffer-length 2500 
  "The maximum number of lines that the compilation buffer is allowed to store"
  :set 'set-my-compilation-buffer-length)

This is my first shot at such “complex” Emacs Lisp functions, so maybe it’s not optimal, and I don’t know much about the Emacs Lisp API either. Improvement suggestions are welcome!
Update: Over at Stackoverflow someone pointed me to a function that is already built into Emacs. So here’s the alternative solution: 


(add-hook 'compilation-filter-hook 'comint-truncate-buffer)
(setq comint-buffer-maximum-size 2000)

This function is used for other comint buffers as well, such as the shell.

Emacs whitespace-mode

I just found out about whitespace-mode. Very useful if whitespaces are of syntactic value. For example in Makefiles. Emacs’ makefile-mode already shows leading spaces as pink, but leading and trailing spaces might be problematic in other cases as well. The whitespace-mode shows all kinds of spaces, eight spaces are highlighted in bright yellow (“no tab”), tabs are also visualized, as are newline characters.

Make emacsclient work with raise-frame

Emacs has the wonderful emacsclient for quickly editing files in Emacs from external tools, e.g. the shell. I am using the following alias to edit a file using emacsclient: 


alias ec='emacsclient -n'

However, then Emacs’s window does not get raised, nor activated. There is also a bug in Emacs’ raise-frame function, which hinders any efforts. The best solution so far for this is described here, which uses wmctrl to activate and raise Emacs. My Emacs runs on Desktop 1, so I use wmctrl also to first switch to my Emacs desktop. You could probably make a more elaborate function which first finds the desktop that Emacs is running on, but this is good enough for me. So here is the slightly adjusted code snippet from the above link: 


;;
;; Start emacs server
;;
(server-start)
(defadvice raise-frame (after make-it-work (&optional frame) activate)
    "Work around some bug? in raise-frame/Emacs/GTK/Metacity/something.
     Katsumi Yamaoka posted this in 
     http://article.gmane.org/gmane.emacs.devel:39702"
     (call-process
     "wmctrl" nil nil nil "-s" "1")
     (call-process
     "wmctrl" nil nil nil "-i" "-R"
     (frame-parameter (or frame (selected-frame)) 'outer-window-id)))
(add-hook 'server-switch-hook 'raise-frame)

Quickly toggle last two buffers in Emacs

I don’t have much interesting stuff to post this month, so I’ll just go with one little snippet for Emacs. Next months will be better, I promise!
In Emacs, you can switch buffers by hitting C-x b and typing a buffer name. If you just hit C-x b RET, Emacs will just go to the last buffer. This is an awful lot of keys for such a simple function. So quite a long time ago, I found this useful small function, but I forgot where. In my config I’ve bound it to F4. I use the function keys quite a bit for file and buffer operations, maybe because I am a big fan of the Midnight Commander…


(global-set-key [f4] (lambda () 
                      (interactive) 
                      (switch-to-buffer
                         (other-buffer 
                             (current-buffer) nil)
                      )))

Parallel Algorithms are Strange

I am currently reading about the P-RAM (Parallel Random Access Machine), which is kind of the Turing Machine for parallel algorithms.
This machine consists of a bunch of CPUs acting on a shared memory. It is very similar to current SIMD and multiprocessing implementations, apart from the memory. The kind of memory access for P-RAM comes in different flavors. Reads and writes can be concurrent or exclusive. Usually, when you talk about P-RAM you imply the CREW P-RAM. This means concurrent reads, but exclusive writes. This sounds rather natural, since reading (from RAM or rather from a cache) could happen concurrently on most real machines, but writes should be exclusive, otherwise it is not clear which result will actually be stored. The latter aspect is usually not implemented by real hardware, so a bit of trickery needs to be done. There seem to be publications on this topic.
Much nicer would be a real CRCW P-RAM, which in literature is also called the W-RAM. This is a very general parallel machine, and it allows for some very efficient algorithms. For example, take a look at the following program, which computes the minimum value of an array: 

import random

minimum = None
n = 10
M = [ 0 ] * n
C = [ int(1000 * random.random()) for x in range(0, n) ]

print C

for i in range(0, n):
    for j in range(0, n):
        if C[i] < C[j]:
            M[j] = 1

for i in range(0, n):
    for j in range(0, n):
        if M[i] == 0 and i < j:
            M[j] = 1

for i in range(0, n):
    if M[i] == 0:
        minimum = C[i]

print minimum
On a sequential machine, this algorithm obviously runs in O(n^2) time and O(n) space. Your standard implementation of a sequential array-minimum computation would run in O(n) with O(1) space. However, if you were to have a CRCW P-RAM, you could change all the outer for-loops to parallel-for loops, similar to what you can do in OpenMP. Assuming that you have O(n^2) processors available, which is not that unthinkable nowadays anymore, this will reduce the whole time complexity to O(1), with O(n) space complexity. Awesome, isn’t it?

Xcode 4.3, boost and the directory /Developer

Xcode 4.3 changed a lot. Most notably, all the stuff that was once under /Developer now resides under /Application/Xcode.app/Contents/Developer. And the SDKs have moved under the *.platform subdirectories. This breaks a lot of stuff. Especially auto-detecting build systems, such as boost jam. Will write back when I have some work arounds…

Update: I prepared a quick-fix for boost, so it compiles with Xcode 4.3 and builds the framework (see boost ticket #6686. However, I still get compile errors in my project, since clang is very picky and complains about boost:

I think this might be a genuine boost bug. It’s probably already known, but I haven’t checked. Will post another update when I find something.
The quick fix is also available in my github repo, see here.

Update 2: This is a known error, and it has been fixed in later revisions of boost (I am using 1.48 right now). The solution here is that instead of size, there should be size_arg. I wonder how this could ever have worked…

What about C++11 in Xcode?

This started out as a very small problem: I am using C++, Objective C++ and Objective C mixed in one project. This usually works pretty well. However, when including MapKit, the compiler choked on an Objective C++ file. It seems the MapKit.h header wants to use isinf(). This function has been introduced with ISO C 99, but it it is not included in ISO C++ 98. Hence the failure of Xcode’s gcc and clang compilers.

To work around this problem I was thinking of trying to set the project settings to use ISO C++ 11, or C++ 0x, since Xcode’s compilers are not that up to date. This is pretty easy:

And I guess this would work for most people. However, I am also using boost in this project. And I guess it is rather up to date, concerning the new language specification. However this also means that there is a problem with clang’s support of the language. I get a ton of errors in boost when switching to C++ 0x in clang:

In short, I think the C++ 11 support is not quite there yet with Xcode 4.2 and clang 3.0. I will try to post updates when future Xcode releases are coming out. If, alternatively, someone has hints on how to compile boost with clang 3.0, I am also glad to try that out.

Update: There is a fork on gitorious of the boost on iPhone build script, which already uses the clang compiler. I hacked the script even more to use –std=c++0x as a flag and it builds fine. Now I will try to link this new framework to an iOS project compiled with clang using C++ 0x.

Update 2: I found the root of the problem. The fantastic people over at #boost on freenode helped me figuring it out. In short: boost::fusion defines nil, which is an Objective C keyword. Thus we get lots of problems. Objective C defines nil and Nil in objc/objc.h. A minimal program that compiles successfully:

#include <boost/phoenix/core/reference.hpp>
#import <CoreFoundation/CoreFoundation.h>

int main()
{
    return 1;
}

Using this command line: 

/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang++ 
-isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk 
-framework Foundation -Fpath/to/boost/framework --std=c++0x -arch armv7 
-stdlib=libc++ -mthumb -miphoneos-version-min=5.0 foo.mm -o foo

If you swap the to include / import statements, the program will not compile, since now the ObjC nil makes boost break. There is a boost ticket tracking this issue, with a proposed patch attached, which renames the boost nil to nil_.

Update 3: The patch works fine, but now I get internal compiler errors from clang. The compile triggers a segmentation violation at some point during the compilation of my project. I guess clang 3.0 is still a bit experimental. I submitted a bug report and will revert to using the default settings of Xcode for the time being.