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.

GUI with Gambit

There doesn't seem to be any real GUI libraries for Scheme. I spent
some time looking for a GUI framework that I can interface with
Gambit. WxWidgets was the first place I looked. I wasn't fully sure
that I could interface a C++ GUI framework with Gambit. The docs
mentioned it, but I didn't want to spent time exploring and debugging
C++ issues this time around.

Tk is a GUI library that is cross platform, works almost everywhere
without a hitch. I had spent a lot of time coding in Tcl/Tk a few
years back, and so getting back on the Tk bandwagon looked
appealing. The latest "Tile" updates to Tk also improves the
look-and-feel considerably. So, what options did I have for Scheme +
Tk?

On obvious way is to look at STKlos. The only reason, I didn't want to
do that, was because I wanted to stick to Gambit for the
moment. Gambit allows me to create a standalone application. Having a
standalone exe simplifies application delivery, esp. on Windows.

My first thought was to have a native interface to Tk. I thought about
a FFI interface to the Tk dll itself. Again no luck here. There was a
Snow package for Tk available but Snow itself seems to be dead with no
development happening on it.

I came across PS/Tk. PS/Tk uses Tcl as a bridge to Tk. You need to
have TCL installed though. We can get past this, if we use tclkit and
so, it looked like a good starting point.

The whole PS/Tk is just one file - pstk.scm that you download. Just
load the file and it should be good to go.

A-ha one Gotcha!

That doesn't work. What you need is to modify the file for specific
scheme support. There is example code written up for each scheme
implementation that PS/Tk supports and its just a question of
uncommenting the right one. For Gambit the code looks like so -

; GAMBIT
;   (run-program
;     (lambda (program)
;       (let ((port
;               (open-process
;                 (list path: "/bin/sh"
;                 arguments: (list "-c" (string-append "exec " program))
;                 stderr-redirection: #t))))
;         (list port port))))
;
;   (flush-output-port force-output)

Uncommenting this won't do as its Linux specific. Some small changes
and we should be able to use it on Windows. The changes are -

; GAMBIT / Windows
(run-program
(lambda (program)
 (let ((port
   (open-process
    (list path: "c:/tcl/bin/tclsh85.exe"
   stderr-redirection: #t))))
   (list port port))))

(flush-output-port force-output)

Once that's done, we are good to go. We can create a simple frame with
a button like so -

(define f (tk 'create-widget 'frame))
(define b (f 'create-widget 'button))
(b 'configure 'text: "Hello World")
(tk/pack b)
(tk/pack f)

Next stop - change from a full fledged Tcl/Tk installation to Tclkit.

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)