Slime/Swank, Quicklisp and long running programs

I have a small problem with Slime/Swank and long running servers.

These servers run for weeks and month, with an older version of Swank loaded. I periodically connect to them to change a function or two (quick fixes and small functionality updates), without restarting.

Now, when a Quicklisp update arrives, versions of Slime on my local machine and Swank on remote machines diverge. Even if I upgrade Swank in all remote installations, I need to reload Swank  in each of these image. 

That's quite interesting if it is possible to do so w/o actually restarting the image. Will try.

Typcally slime/swank version difference does not matter much, but to be on the safe side, it is better to keep them syncronized.

A wider questoin is whether it is a good practice to upgrate your dependencies inside your running servers. And whether it makes sense to automate this.

nconc

Lispers know that destructive list functions are dangerous, that you should know that the data is fresh consed. I've known this too, but still today I was still bitten by nconc. When I applied it to two arguments that shared structure, it returned a circular list. Try this:

(setf *print-circle* t)
(let ((x (list 1 2 3)))
   (nconc x x))

Be careful!

Lisp Blog

Recently I have been programming quite a lot in Common Lisp. Full time for about 5 months on a professional code base, written by some cool guys who now work either at Lisp vendor companies or as successful independent consultants.

I have learned a number of lessons.

Community

The Lisp community does exist :)  only it has to be viewed globally. There is merit in attempting to maintain local communities, of course, but one cannot hope to achieve as much of activity around Lisp as we have around Python, for example.

Therefore, I will not continue writing this blog in Russian. Need to reach out to a wider audience.

Using Lisp in startups

It might be hard to persuade your company to use Lisp, (no, quoting Paul Graham is not enough, though it helps). However, if you encounter a company, especially a startup, that does use Lisp, despite the obvious obstacles such as lack of good Lisp programmers, and a rather steep learning curve for existing programmers, that company deserves attention. Chances are something interesting is happening there.

Lisp Libraries and Technologies

I have learned and used GBBOpen, Screamer, have seen how Weblocks is being used as a RAD tool (and want to try it myself later). I am going to write about this later in this blog so stay tuned :)

Закрыть все буфера TRAMP'а в Emacs

Вот так в emacs'е можно закрыть все буфера tramp'а. Чтобы не искать руками в ibuffer, просто набираем M-x kill-tramp-buffers. Иногда мне это нужно, чтобы не путаться, на какой машине я редактирую сейчас файлы, переходя от одной машине к другой.

;;; a shortcut to kill all tramp buffers at once
;;;
(require 'ibuffer)

(defun tramp-buffer-p (buf)
  "is this buffer tramp's one"
  (or (string-match "^\\*tramp" (buffer-name buf))
      (tramp-tramp-file-p (with-current-buffer buf
                            (ibuffer-buffer-file-name)))))

(defun kill-tramp-buffers ()
  "kill all TRAMP buffers"
  (interactive)
  (dolist (buf (buffer-list))
    (when (tramp-buffer-p buf)
      (kill-buffer buf))))

Наваял в первом приближении нечто, способное генерить код, похожий на PHP

Фактически это pretty-printer скобочный выражений, которые должны примерно соответсвовать языку PHP. Но! Есть macroexpand. Правда макросы определяются на host-языке, т.е. на Common Lisp, а не на target языке, т.е. в самом языке нет (пока) defmacro, macrolet, symbol-macrolet, (мне кажется что expansion code все равно надо писать на common lisp, а не на PHP, так что полезность defmacro et al. в target языке под вопросом). Глюков там еще хватает. Лежит на github'е но это пока довольно бесполезная штука. Потому что чем писать на PHP в скобочном синтаксисе, лучше писать в родном. В скобочном синтаксисе надо писать на LISP или Scheme, а это совсем другое, кроме макросов все же хочется иметь полноценные замыкания, полноценную lambda. Для этого надо делать flattening envionrment'а (не знаю как это переводится) через lambda lifting (тоже не знаю), что нафиг убъет всю читаемость сгенеренного кода. Вот уже неделю думаю, читаю умные книжки, надо такое делать или нет, или пускай будет PHP в скобочном варианте с макросами? Хотя emacs lisp ведь без замыканий живет и ничего. Надо осилить Lisp in Small Pieces, начиная от денотационной семантики и дальше, может натолкнет на какие-то мысли.

pretty printer

А еще в Common LISP есть совершенно замечательный настраиваемый pretty-printer, который можно использовать не только для того, чтобы печатать в синтаксисе лиспа. Вот, например, как генерится код на Паскале.

Кодогенерация: Common Lisp vs. Emacs Lisp

Одно из применений лиспа - это генерация кода, в т.ч. не только на лиспе, но и на других языках. Вот я думаю, может для этой задачи ограничиться Emacs Lisp, а не тащить common lisp?

Потенциальные преимущества:

• Emacs есть везде и под все, а Common Lisp - нет (для меня несущественно, но все же).
• Собственно генерация кода нужна именно для автоматизации программирования, что в принципе кажется Emacs'овой задачей.
• Язык сам по себе попроще будет, при этом, просмотрев исходники parenscript, на первый взгляд не нашел там ничего такого, что нельзя было бы сделать на Emacs Lisp. Местами используется CLOS, но это несущественно.

Недостатки:

• В Emacs Lisp нет READ-макросов, что несколько ограничивает создание DSL, и делает невозможными красоты типа CL-INTERPOL
• При макроподстановке не выполняется destructuring, (собственно он в Emacs Lisp обнаружен не был), что тоже может быть неудобно.
• Отсутствие lexical closures в основной верии Emacs, lexical-let не в счет - не могу понять последствия для этой задачи.