вторник, 17 марта 2009 г.

Про патчи

Я тут недавно писал о том, как добавить к 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-сервера.

пятница, 6 марта 2009 г.

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

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

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

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

четверг, 5 марта 2009 г.

Что делать, если 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 патч с вашими наработками.

понедельник, 2 марта 2009 г.

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

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

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

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

http://lisp.catap.ru