Исходный код cl-libxml2 теперь на github

В общем, окончательно принял решение переводить все свои открытые проекты на git. Поскольку Project Hosting on Google Code не поддерживает git (а mercurial я не хочу), то решил воспользоваться github. Подобный перевод требует некоторого времени, поэтому буду переходить поэтапно, первая "жертва" - cl-libxml2. Т.е. проект по прежнему будет жить на Project Hosting on Google Code, но исходный код на github. Посмотреть его (исходный код) сейчас можно здесь, а получить так:

git clone git://github.com/archimag/cl-libxml2.git

В принципе, svn я не выкидываю полностью, документация (хотя её сейчас и откровенно мало), как и раньше, будет публиковаться через неё (svn), сейчас её можно смотреть здесь

cl-pdf и кирилица в структуре документа

PDF как формат я полюбил ещё до знакомства с lisp, ну а после перехода на CL открыл для себя замечательную библиотеку cl-pdf. Библиотека и правда замечательная, но с самого начала у меня не получалось с её помощью создавать структуру документа (закладки), содержащую русские названия. Тогда в CL я разбирался ещё совсем плохо и поэтому на проблему просто забил. Но вот теперь захотелось для одного генерируемого документа сделать всё красиво, ибо он большой и нужны нормальные средства навигации. Начал разбираться и нашёл проблему в функции pdf-string, причём, видимо, эта проблема проявляется только в sbcl: код этой фукнции подразумевает, что, например, (code-char 254) имеет тип base-char, но в sbcl это extended-char. В итоге родился небольшой патч, решающий эту проблему:

diff --git a/pdf.lisp b/pdf.lisp
index 16d8f6f..b54b5a6 100644
--- a/pdf.lisp
+++ b/pdf.lisp
@@ -235,21 +235,20 @@
   (setq unicode (notevery #+lispworks #'lw:base-char-p
                           #-lispworks (lambda (char) (<= (char-code char) 255))
                           string)))
-    (with-output-to-string (stream nil :element-type 'base-char)
-      (write-char #\( stream)
-      (when unicode            ; write the Unicode byte order marker U+FEFF
-        (write-char #.(code-char 254) stream) (write-char #.(code-char 255) stream))
+    (with-output-to-string (stream nil :element-type 'base-char)
+      (if unicode
+          (write-string "<FEFF" stream)
+          (write-char #\( stream))
   (loop for char across string
         for code = (char-code char)
         if unicode
-            do (write-char (code-char (ldb (byte 8 8) code)) stream)    ; hi
-               (write-char (code-char (ldb (byte 8 0) code)) stream)    ; lo
+            do (format stream "~4,'0x" code)
         else if (> code 255)
         do (write-char (code-char (ldb (byte 8 0) code)) stream)    ; lo
         else do (case char ((#\( #\) #\\)
                             (write-char #\\ stream)))
                   (write-char char stream))
-      (write-char #\) stream))))
+      (write-char (if unicode #\> #\)) stream))))

(defmacro with-outline-level ((title ref-name) &body body)
`(unwind-protect 

Отладка в hunchentoot-1.0.0

Недавно я писал о проблемах с отладкой приложений для новой версии hunchentoot. Проблема обсуждалась в рассылке и наконец Andreas Fuchs предложил решение этой проблемы, как оказалось, достаточно тривиальное. Оригинальное сообщение можно посмотреть здесь: http://common-lisp.net/pipermail/tbnl-devel/2009-April/004688.html. Я несколько модифицировал этот код (добавил управление режимом через пресловутую переменную *catch-errors-p*):

(defvar *catch-errors-p* t)

(defclass debuggable-acceptor (hunchentoot:acceptor) ())

(defmethod hunchentoot:process-connection ((acceptor debuggable-acceptor) (socket t))
 (declare (ignore socket))
 (if *catch-errors-p*
  (call-next-method)
  (handler-bind ((error #'invoke-debugger))
    (call-next-method))))

(defmethod hunchentoot:acceptor-request-dispatcher ((acceptor debuggable-acceptor))
 (if *catch-errors-p*
   (call-next-method)
   (let ((dispatcher (handler-bind ((error #'invoke-debugger))
                       (call-next-method))))
     (lambda (request)
       (handler-bind ((error #'invoke-debugger))
         (funcall dispatcher request))))))

Теперь, для получения удовольствия от использования отладчика достаточно просто использовать debuggable-acceptor вместо hunchentoot:acceptor при запуске сервера (hunchentoot:start).

Про патчи

Я тут недавно писал о том, как добавить к babel (а значит и к cffi) новую кодировку. Писал это я не просто так, а потому как возникла необходимость работать с cp1251, поддержка которой ещё не была реализована. Собственно, последовал своим же рекомендациям (тут возникает вопрос о курице и яйце, но неважно), написал код и отправил его в список рассылки проекта. Не прошло и двух недель :-) как мне пришло сообщение, что код принят и включен в проект. Со следующей версии (0.4) (только когда она будет?) будет доступен общественности, либо можно прямо сейчас забрать свежую версию из репозитория:

darcs get http://common-lisp.net/project/babel/darcs/babel

Сам код поддержки cp1251 (полностью списанный с iconv) можно посмотреть здесь.


Ещё недавно я показывал патч для mod_lisp, который позволяет lisp-серверу получить имя пользователя (REMOTE_USER), успешного прошедшего аутентификацию на стороне apache. Но вот беда, как я уже писал, новый hunchentoot не поддерживает mod_lisp. Это заставило меня задуматься и теперь я вообще не понимаю какого я полез использовать этот mod_lisp (да и зачем он вообще нужен не понимаю): стандартный прокси (ProxyPass) решает все проблемы. Ну, не совсем все. Опять таки, возникает проблема передачи lisp-серверу имени аутентинфицированного пользователя. К счастью, эта проблем достаточно легко решается средствами mod_rewrite следующим образом:

RewriteEngine On
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
RequestHeader set REMOTE-USER %{RU}e

Немного похоже на магию, но работает: добавляет к заголовку запроса поле REMOTE-USER, которое можно использовать на стороне lisp-сервера.

Утерянная отладка в hunchentoot

Недавно вышел принципиальной новый релиз hunchentoot - 1.0.0. Я попробовал обновиться и через два часа мытарств был вынужден откатиться к предыдущей версии. Да, там большие изменения, но для меня камнем преткновения оказалось только одно: утеряна возможность отладки с помощью стандартного отладчика. Раньше, если переменная *catch-errors-p* имела значение nil, то hunchentoot, в случае возниковения ошибок просто вызывал invoke-debuger и давал возможность насладиться всеми прелестями разработки на Common Lisp. Этой переменной больше нет... И вызова invoke-debuger в коде тоже больше нигде нет. Новый hunchentoot перехватывает всё и предлагает несколько вариантов обработки ошибок, типа логирования. Но мне нужен отладчик, иначе это будет не разработка, а сплошное мучение.

Сегодня (за чашкой кофе) пошёл почитать что пишут в списке рассылки. К моему удовлетворению, это проблема затронула и обеспокоила не только меня. После достаточно жаркого обсуждения Hans пообещал "что-нибудь придумать" по этому поводу в следующем релизе. Будем ждать.

P.S. Ну и задно подписался на рассылку, что бы ничего не упустить.

Что делать, если cffi не поддерживает нужную кодировку

Во-первых, cffi не при чём, поскольку за кодировки не отвечает, а полагается в этом на другую библиотеку - babel. Ну хорошо, виновного выяснили, теперь дело за малым - пропатчить babel. И это не сарказм, пропатчить babel действительно очень легко, даже если вы соврешенно ничего (ну т.е. как и я) не понимаете в кодировках. Чтобы убедиться в этом достаточно просто открыть описание какой-либо кодировки в исходниках babel, а на соседнем мониторе (надеюсь, что у вас их по крайней мере два) файл с описание той же кодировки, но в исходных кода libiconv и вам все сразу станет очевидным. Фактически, babel это не что иное, как Common Lisp порт библиотеки libiconv. Но libiconv содержит очень много разных кодировок и разработчики babel, вероятно, ещё не успели (и, вполне вроятно, не очень то и спешат) их все перенести. Так что, если вам нужна какая-то кодировка, а babel её ещё не поддерживает, то просто найдите эту кодировку в libiconv (это несложно) и замените синтаксические конструкции "C" на соответствующие синтаксические конструкции Common Lisp и добавьте полученный файл к исходному коду babel (а также, отредактируйте babel.asd). Останется ещё пара мелких деталей, так что стоит, для их уточнения, глянуть описание какой-нибудь уже имеющейся в babel кодировки. Всё.

P.S.Только не забудьте после этого перекомпилировать cffi (например, путём удаления соответствующих .fasl файлов).

P.S.P.S. Ну и когда убедитесь, что всё работает правильно, не забудьте отправить разработчикам babel патч с вашими наработками.

Новый ресурс о Common Lisp

Некоторое время назад запустили новый ресурс о Common Lisp: http://lisp.catap.ru. Отличительной (как это не странно) чертой этого проекта является язык реализации - Common Lisp (кроме того, на сервере достаточно широко используется XSLT).

Проект находиться в стадии самой ранней альфы (суммарно, на него было потрачено около 4-5 дней). Сейчас он предоставляет планету русскоязычных блогов о lisp, очень простенький форум и некоторое колличество статей (целых 3!) о Common Lisp.

Собственно, проект нуждается в обсуждении и критике (это можно делать на форуме, как раз протеститься). Кроме того, не исчезает надежда, что могут найтись люди, способные и желающие помочь в разработке. Пока кодом занимаюсь только я. Ну и от дизайнерских услуг я бы не отказался :-)

http://lisp.catap.ru