CLISP and Mel-base

Unlike Python, Lisp doesn’t come with any standard libraries for SMTP client. The folks at #LISP on IRC suggested I try mel-base. It was a complete disaster. The way common lisp is, one can expect to spend more time fiddling with libraries than writing code.

ASDF-install of mel-base started smoothly.

asdf-install:install :mel-base

Unfortunately it barfed when it tried to compile the following.

#+openmcl
(defun gethostname ()
  "Returns the hostname"
  (ccl::%stack-block ((resultbuf 256))
    (if (zerop (#_gethostname resultbuf 256))
    (ccl::%get-cstring resultbuf)
    (error "gethostname() failed."))))

I didn’t know what a reader macro #_ was at this stage, and apparently cmucl has one defined.

I tried patching mel-base source to define the reader macro for CLISP but it did not work. In the end, adding the following to the initialization file .clisprc fixed that problem. With Python, it-just-works. With LISP, alas, it is just the opposite. I don’t see any solution out of this conundrum of having to change the initialization file when adding any libraries. This makes packaging and deploying software really difficult.

(make-dispatch-macro-character #\_ )
(set-dispatch-macro-character #\# #\_
    #'(lambda (s c n)
        (read s t nil t)))

The next problem with mel-base on CLISP again illustrates how badly Common Lisp implementations needs to have a standard library that people can rely on to be present on all platforms. The following code fragment simply doesn’t work on Windows CLISP. posix:uname-nodename is not defined.

#+clisp
(defun gethostname ()
  (posix:uname-nodename (posix:uname)))

I had to end my session at this spot because it was simply taking too much time. Lisp libraries was starting to feel like C libraries. Full of unexpected twists and turns, and macros that aren’t properly tested. Without a standard base of libraries to build on, too much time is spent making the underlying bits work. Another thing that python got right over Lisp is that platform specific code is defined in separate files, rather than having ifdefs sprinkled throughout a source file. This makes maintenance easier.

Update 14 May 2006

The latest mel-base.0.7 still had problems

environment.lisp needs to be patched:

#+(and :clisp :unix)
(defun gethostname ()
  (posix:uname-nodename (posix:uname)))

#+(and :clisp :win32)
(ffi:def-call-out c-gethostname
    (:name "gethostname")
    (:arguments
        (name (ffi:c-ptr
            (ffi:c-array-max ffi:char 256)) :out :alloca)
        (len ffi:int))
    (:language :stdc)
    (:return-type ffi:int)
    (:library "wsock32.dll"))

#+(and :clisp :win32)
(defun gethostname ()
    "Returns the hostname"
    (multiple-value-bind (success name) (c-gethostname 256)
        (if (zerop success)
                 (ext:convert-string-from-bytes name custom:*FOREIGN-ENCODING*)
            (error (strerr errno)))))

And there’s still this unresolved problem:

*** - READ from
       #<input BUFFERED FILE-STREAM CHARACTER
         #P"C:\\cygwin\\home\\Chui\\
            .asdf-install-dir\\site\\mel-base_0.7-0\\
            rfc2822.lisp" @323>
      : there is no character with name "vT"

2 Responses to “CLISP and Mel-base”

  1. Alakhazam writes:

    Why not try and improve the library instead of whining like a lil bitch on your blog?

  2. Chui writes:

    I was going out for dinner, and there were two diners. One was clean and the waiters polite, the other one was dirty and waiters rude. Guess who got my business?

    I’m not a lisper, and was going to give CL a shot, but the defects in the implementation became obvious but I was in no position to fix because I couldn’t bootstrap myself into a position where I can be useful.

Leave a Reply