An unscientific comparision of different tiling window managers

I was intrigued by tiling window managers and decided to try using them. If you don't know what they are, here's the wikipedia page - http://en.wikipedia.org/wiki/Tiling_window_manager

I spent Saturday installing and trying them on out on my ubuntu box. Since I run ubuntu on a virtual box, unity is very sluggish. I explored StumpWM, DWM, Bluetile and finally Awesome.

StumpWM

I started with StumpWM because I drawn by its implementation. Its implemented in Common Lisp and that was very interesting to me. It means we can change stuff around and they will instantly appear and be accessible.

DWM

DWM is the granddaddy of all Tiling Window Managers. Its the antithesis of StumpWM because nothing is configurable. You want to change something? Modify the code and rebuild it.

Bluetile

Bluetile is very user friendly. Its built on top of xmonad but the key difference is that unlike xmonad you don't have to install a full Haskell development environment. Configuration is limited to a few items only. 

Awesome

And finally Awesome. What can I say? Its really awesome! Highly configurable, with a number of layouts, themes and yet quite thin.

Implementation

1. StumpWM - Common Lisp. This makes is very configurable and changes are instantaneous. Unfortunately you need to download and install a CL implementation and a couple of libraries.
2. DWM - Straight up C. Less than 2000 lines of code. 
3. Bluetile - Haskell. 
4. Awesome - C and Lua. Lua makes configuration easy and that part of the Awesome if very well documented. 

Dynamic or Manual

1. StumpWM - Manual. It means you need to place windows by yourself. After trying the others, I found this to be a little painful because the point of tiling is productivity. If you have to set things up yourself, then you lose that part.
2. DWM - Dynamic.  It sets up the layout for you
3. Bluetile - Dynamic with a couple of different layouts to choose from. Its also very easy to switch between the layouts
4. Awesome - Dynamic with a number of different layouts and tiling algorithms. 

Conclusion

1. StumpWM - I didn't like it that much unfortunately because placement is manual and it seems very "raw". Its very closely tied to Emacs and Screen philosophy and so even the prefix key by default is CTRL-T. The best part is that it uses CL and so, you can change things, add new commands/shortcuts without restarting stuff. The sky's the limit for the things you can do, but its elitist in the sense you need to understand common lisp to do that. Its not a problem for me but that may not appeal to everyone.
   
2. DWM - Very minimal. As long as you don't fight the flow its great. Unfortunately, I had to read the code to understand what the different shortcut keys. I even uninstalled it because I didn't know how to start. Once I read the code, I found that dmenu is tied to Mod4 (Windows Key) + P, then things started to work. One funny thing though was that firefox didn't show up. Looks like it doesn't play nice with firefox and so, I suspect it will not play nice with other GUI driven applications
   
3. Bluetile - Super easy to get started with. Sadly, there is not much configuration that you can and so, its more like a demo for tiling rather. Plays nice with gnome as well. I wanted to install xmonad once I saw it but didn't want to download and install a bunch of stuff that I wouldn't use. If you are a haskeller, then go to xmonad directly, There's even a configuration available to make it look like bluetile.
   
4. Awesome - I found this to be the best. Awesome is a fork of dwm with the explicit idea of configuration.Tons of layouts and plus it understands and implements several Freedesktop standards. So, it plays nice with gnome and you get menu integration as well. Only part I didn't like was the name because it makes googling difficult. Its the only one in the list for which the first hit on Google isn't the windowing manager. I also found that resizing didn't work. I'm not sure why but didn't spend time on it. Googling also showed up another person complaining about the same thing but no solution.

So,  I liked Awesome in the end. Its newbie friendly. The only real grouse is that you can't google for it easily. Bluetile is also very nice. DWM and StumpWM is more tuned for the power users. I really like the small size of dwm and the dynamic configuration of stumpwm but those points in themselves don't sell.

Once you use tiling for windows, there's no going back. One note of caution though. Other than Awesome and DWM, the others don't work with lightdm's menu without tweaking on Ubuntu 11.10. In all cases, you lose the panel (unless you install it yourself and its no longer part of GNOME 3).

Quicklisp updated

Quicklisp has been updated - http://blog.quicklisp.org/2011/10/october-1-quicklisp-dist-update-now.html.

Time to run (ql:update-dist "quicklisp").

Language fads

R-Bloggers has a post about hipster programming languages where they talk about the emergence of Clojure, Scala and Coffeescript.

While I'm not really experienced in any one of them, I wonder about what's the venerable languages that these cool cats are missing. C is a must for the embedded system work that I do for sure and what is cool is often size reduction. In an environment where every byte counts and memory access is key, C remains king.

Now if we can get more lisp or scheme usage in the embedded world.

Creating PDF files from Common Lisp

The CL-PDF library allows you to create PDF files directly from common lisp. The easiest way to use cl-pdf (or for that matter many other libraries) is to download and install LibCL. CL-PDF comes with LibCL and makes the installation a snap.

I have a hello world pdf program written.
Just run this and it will generate a PDF with a big Hello World!

SICP on the iPAD

SICP in ePub format

If you want to read SICP (and you should!), on the iPad, then you are in luck. The digital format is old school HTML pages generated from texinfo. While there is nothing wrong in that format per-se, it just doesn't allow you read this wonderful book on an iPad (or another other tablet for that matter).

iBooks uses ePub as the ebook format. Just download SICP in ePub format from here (Ian Eure's git tree), add it to your iTunes library and sync. That's it. 

The link shared above is a git tree on github and it's always nice to fork and fix any issues that you find. The actual download link is also present on the github project.

SICP on other devices

If you have a Kindle, then Jonathan Patt's sicp-kindle git tree on github is the place to go. I don't know much about Kindle (don't have one), and instructions are from http://irreal.org/blog/?p=274

PDF version

Finally, there is always the PDF version that you can download from http://sicpebook.files.wordpress.com/2012/11/sicp.pdf

Paperback Edition of the SICP

Of course, another option is to get the dead wood edition from MIT press directly - http://mitpress.mit.edu/books/structure-and-interpretation-computer-programs. Then again, having a paperback or hardcover is nice if you have a personal library shelf. I learnt that this can be a pain esp. when moving/changing houses because you will need to pack everything up and unpack them once you are in your new place.

Thinlisp

Came across Thinlisp today while browsing cliki. Sounds interesting - develop in CL and then deploy in C. Its similar to ECL in the way of using C as a bridge but in reality its completely different. ECL is a CL implementation that uses C as a compiler. Thereby you can generate very small and very efficient standalone executables.

Thinlisp on the other hand, is supposed to work on any CL implementation. It uses CL to generate C. It works with a subset of lisp and doesn't support any garbage collection. I had a look at it today, its pretty old. The code looks like its been abandoned by Gensym. Nevertheless, I decided to give a try. Will post results as I get going it with, but I do expect some amount of bit-rot. Vladimir Sedach seems to have hacked at it a few years back, and has posted tarball. That would be my starting point.

functions in plists

Common Lisp Plists are easy. A plist is just a list with properties. Any element with ":" prefixed is a property. The next element to a property is its value. We can then manipulate the plist using functions such as getf and setf. We give the property name to getf/setf and they fetch/set the appropriate property.

Here's a simple plist

'(:name "sid" :language "lisp")

Now, if we want to put in a function in the plist as a value, then the quote will not work.

'(:name "hello" :function (lambda () (format t "Hello World~%"))) ; Bad

The correct way is to backquote the plist and comma-escape the lambda.

`(:name "hello" :function ,(lambda () (format t "Hello World~%"))) 

We can then extract the function using getf and then finally call it using funcall. If we want to use an existing function, then we need to not only comma-escape but also add a #' so that the reader knows that a function symbol follows.

In C the equivalent would be to have a struct with a function pointer. What makes Lisp cool is that

1. You can define an anonymous function in the plist itself
2. You can have functions with different arity, inputs etc.. all in a list of plists. Lisp won't complain, but in C, the function pointer needs to be function of a particular signature only.
3. Lisp also allows you to define structs which are more powerful than just plists, but a plist is good enough for this example.
   

SBCL - FASL files

One aspect of SBCL that you *will* run into if you upgrade, is that older FASL files will no longer load. SBCL ties the FASL format to a specific version. That means that you recompile all the files when you upgrade. The manual gives a convienent snippet if the files are using ASDF.

The PLT Scheme advantage

I was doing a lot of builds at work today. While waiting for it to complete, I decided to spend some time coding in Lisp. Clozure CL host irc logs for #ccl, #scheme and #lisp on their website. I thought it would be cool idea to download the logs for a particular date by writing a CL program. 

What it turned out to be was a huge waste of time. I decided to try the trivial-http library. I downloaded the tarball. Then I didn't quite know how to install it. Some amount of googling gave me links to asdf-install. I then spent the next couple hours trying to get it work. It doesn't work. Checked on #lisp, and #ccl but no responses. 

In frustration, I turned on DrScheme and grokked the documentation. There is a net/url library that is shipped with PLT Scheme. Two minutes later my code looked like so

(require net/url)

(display-pure-port (get-pure-port (string->url "http://ccl.clozure.com/irc-logs/lisp/2009-12/lisp-2009.12.28.txt")))

I'm not sure if any other scheme (other than maybe chicken) would have allow me to get going so quickly.  I doubt whether any further example is required for a batteries included distro of CL. 

Update: Finally got something in CL - a TCP stream descriptor. So, we aren't there yet. But here is how it goes. 

1. Don't bother about asdf-install - it takes care of downloading asdf packages in order and compiling them. To use ASDF packages, we don't need asdf-install.
2. Download trivial-http and usocket asdf packages and untar them. I put them in my libcl installation. My libcl is in d:/programs/libcl. It doesn't need to be here, but having it here makes my directory structure clean.
3. Update ccl-init.lisp for asdf:*central-registry* to see the new asdf locations. Eg. for usocket we do - (pushnew #P"d:/programs/libcl/usocket/" asdf:*central-registry* :test #'equal) 
4. At the REPL compile the new asdf files. E.g for usocket we do - (asdf:operate 'asdf:compile-op 'usocket)
5. Next at the REPL load the compiled asdf. We need to load only trivial-http. ASDF automatically loads usocket - (asdf:operate 'asdf:load-op 'trivial-http)
6. We can now see that that trivial-http is available by doing (list-all-packages).
7. Finally, (require 'trivial-http) and (trivial-http:http-get "http://ccl.clozure.com/irc-logs/lisp/2009-12/lisp-2009.12.28.txt")

What we have now is just a stream. We now need to read the stream. That's for later.

1. 
   
   

Size of a file

Rosetta Code is an interesting project where you can see code in different languages for the same problem. Its a wiki project and you are encouraged to put in your solution if one does not exist in your language of interest.

Here's a small bit contribution from me - Get the size of a file in scheme.

(define (file-size filename)
 (call-with-input-file filename (lambda (port)
   (let loop ((c (read-char port))
              (count 0))
     (if (eof-object? c)
         count
         (loop (read-char port) (+ 1 count)))))))

(file-size "input.txt")
(file-size "/input.txt")

Lisp Epiphany - Native Code vs Byte Code

What does "Native code" Compiler mean in Lisp terms? If we look at SBCL which is a Native Code compiler and compare it against CLISP which is a Byte Code compiler, then we can get a better idea.

Coming from a C and Scripting background, the first thought that came to my mind was that a Native Code compiler generates executables whereas a Byte Code compiler does not. Once I dug in a bit more, I realized that is not the case. To assume SBCL is a sort of GCC that reads in code and spits outs an ELF executable is completely wrong. It does nothing of the sort.

Both SBCL and CLISP can save environments as a standalone executable. So, there is no real difference from an application delivery perspective. The real difference comes when we look at how SBCL and CLISP compile functions that we define.

Common Lisp has an environment function - disassemble. If we define a simple function and pass that function to disassemble, then we can see how different SBCL and CLISP are.

Consider the following function -

 (defun square (x) (* x x)) 

Its pretty straight-forward. Just a function that squares its input. Now we call disassemble on this function.

 (disassemble #'square) 

In CLISP we see the following output

Disassembly of function SQUARE
1 required argument
0 optional arguments
No rest parameter
No keyword parameters
4 byte-code instructions:
0     (LOAD&PUSH 1)
1     (LOAD&PUSH 2)
2     (CALLSR 2 57)                       ; *
5     (SKIP&RET 2)
NIL

whereas in SBCL we see something completely different -

; disassembly for SQUARE
; 23B6C274:       8BD3             MOV EDX, EBX               ; no-arg-parsing entry point
;       76:       8BFB             MOV EDI, EBX
;       78:       E8304049FE       CALL #x220002AD            ; GENERIC-*
;       7D:       7302             JNB L0
;       7F:       8BE3             MOV ESP, EBX
;       81: L0:   8B5DFC           MOV EBX, [EBP-4]
;       84:       8BE5             MOV ESP, EBP
;       86:       F8               CLC
;       87:       5D               POP EBP
;       88:       C3               RET
;       89:       CC0A             BREAK 10                   ; error trap
;       8B:       02               BYTE #X02
;       8C:       18               BYTE #X18                  ; INVALID-ARG-COUNT-ERROR
;       8D:       4D               BYTE #X4D                  ; ECX
NIL

What we have in SBCL is real machine code whereas in CLISP we see its Virtual Machine byte code. That's the real difference. SBCL actually compiled our square function into machine code but CLISP didn't.

Both approaches have their advantages and disadvantages but I won't be putting that in this post.

CLisp application delivery

Here's the simplest way to deliver an Hello World program on Windows. I'm going to use clisp for this, which does not compile to native code, but only bytecode.

The program that prints hello world is simple - 

(defun hello-world ()
 (format t "Hello, World~%"))

(progn
 (hello-world)
 (format t "Enter any key to exit...")
 (read)
 (exit))

Save the code in as hw.lisp and now fire up clisp. At the repl do the following

[1]> (compile-file "hw.lisp")

This will now generate a bytecompiled file - hw.fas. 

Now, save an image of the clisp

[2]> (saveinitmem "hello.exe" :executable t :quiet t
                 :init-function #'(lambda () (load "hw.fas")))

Now, this will generate an executable - hello.exe. 

Copy hello.exe, hw.fas into a new directory that you want to use as the installation target directory. Copy readline5.dll, libintl-8.dll and libiconv-2.dll from \base to this new directory.

Now you can zip this directory or create an installer using InstallJammer or NSIS. 

That's it!

One caveat though. You may need to ship readline as well. That's available in \readline.

Building an hello world program using gambit

We know that gambit-c allows you to compile scheme code into native executables by generating C files and then running them through a C compiler such as gcc. There are real advantages of doing so. You can even compile scheme to run an app on the iPhone.

On Windows, follow these steps to write your first hello world program that gambit then compiles to an executable.

1. Download and install Gambit.
2. Download and install MinGW
3. Set your path to allow gsc to view gcc
4. Write your hello world program
5. run gsc -exe on the code and that's it.

You now have an exe that prints hello world.

Here's a small scheme example that prints hello world.

(define (hw)
 (begin
   (display "Hello World")
   (newline)))

(hw)

Its my baby

Started implementing my own stack based language. I have played a bit with factor and liked it, so I decided to base some things from it. I also have started to read a little more on forth and have now understood how some basic constructs can be created. Especially useful is jonesforth. The code is a must read!

So, the design goals I have in mind are as follows.

1. Must be in embeddable in C. My main goal here is to be like Lua. A small library that you can call from C. The main users of this language would be hardcode C programmers esp. on embedded linux and embedded linux system testers. 
2. Must be written in ANSI C. Factor implementation has moved to C++ and also has a lot work going on in creating a fast and optimizing VM. I don't have that goal, as I want to be able to port my language very quickly to different hardware. The easiest way to port? Just recompile. Obviously, you lose out on some performance, but that's ok. The target audience will code most of the fast bits in C anyways.
3. Must be simple. System testers should be able to use this language very quickly to write small tests. The main part of the test application itself would be written in C, but the scripting part would be in this language.
4. Support for quotations, sequences. Ideas from Factor (and lisp) and good ones too!
5. Reader macros would primarily be from C. 

So far, I have the basic language working. It supports numbers, strings and quotations. You can define your own "words" and run them. There is a "if" control structure and a "loop" control structure. The implementation is still very buggy though. 

Will keep posting as I progress.