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

Книги по ЛИСПу

Хочется самые правильные книги по LISP проработать качественно. А именно хочется прорешать все упражнения. У Эли Бендерского заняло чуть меньше года прорешать весь SICP на Common LISP. У меня прорешать его на Scheme заняло месяца 2 или 3. Но во первых не все, а где-то три четверти, и я довольно плотно за него тогда взялся. Сейчас так не получится, так что надо рассчитывать, что PAIP со всем упражениями займет не меньше чем полгода, а то и год. Чтобы все это мне не надоело, его надо будет это чередовать с другими книжками, так что, надеюсь, On LISP и Let Over Lambda будут прочитаны гораздо раньше чем PAIP. Остается домучить LISP in Small Pieces, и AMOP. Еще есть в электронном виде какая-то книжица по CLOS, даже не знаю стоит ли она прочтения. Вобщем, минимум на год вперед чтения по LISP'у хватает, быстрее все осилить может и можно, но зачем?

Обзор Common LISP

Прослушал обзорный доклад Всеволода о среде Сommon LISP' а, включая особенности языка, ИДЕ, библиотеки, коммьюнити и пр. Я ничего не ожидал от этого доклада, ну что еще можно сказать. На удивление, презентация была очень хорошо подготовлена, и оказалась рассчитанной примерно на мой уровень, уровень человека, который уже успел попробовать Common LISP на практике, но еще маловато знает. В презентации оказалось полно buzzwords, которые нужно знать, я надеюсь, он ее выложит, и там будут кликабельные ссылки.

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

Guide to Lisp Style

Хочется выписать отдельно тут:

  • Be specific
  • Use abstractions
  • Be concise
  • Use the provided tools
  • Don't be obscure
  • Be consistent

PAIP

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

четверг, 21 мая 2009 г.

Немного отвлекся от Common LISP и наваял первую наивную прогу на Emacs Lisp :)

Берет бинарный файл, и оформляет в виде C-шного массива:


(defun file-to-c-array (filename)
"convert a binary file into a C array of characters"
(interactive "fFile Name: ")
(let* ((buf (find-file-noselect filename))
(oldbuf (current-buffer)))
(save-excursion
(insert "\nconst unsigned char key[] = {")
(set-buffer buf)
(beginning-of-buffer)
(let ((i 0))
(while (not (eobp))
(let* ((c (following-char)))
(forward-char)
(set-buffer oldbuf)
(when (zerop (mod i 8))
(insert "\n\t"))
(incf i)
(insert (format "0x%x, " c))
(set-buffer buf))))
(set-buffer oldbuf)
(delete-backward-char 2)
(insert "\n};\n"))))

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

Насчет FFI - не все так хорошо по сравнению с ctypes

Нужно было прикрутить библиотеку к ЛИСПу на винде. Взял Clozure CL. Использовать его FFI на винде как-то не получилось, долго разбираться. Пытался поставить CFFI через ADSF-Install, но ASDF-Install на винде тоже работать не захотел :( Ну я понимаю, что, помучавшись, можно все сделать, но я плюнул, запустил питон, оказалось, что тоже вполне юзабелен из Emacs'а (я к Emacs'у фактически начал привыкать после SLIME'а, до этого всегда и везде был vim). Ну и через минут десять я эту библиотеку из питона уже юзал. И только где-то через час-другой стало нехватать лиспа. Вобщем, сделайте кто-то нормальный LISP environment под виндой с FFI, очень надо!

среда, 13 мая 2009 г.

Зачем нужен ЛИСП C программисту?

Например, что вы делаете, когда вам нужно научитья пользоваться программой? Читаете документацию? Или просто запускаете и смотрите что и как? Скорее всего и то и другое. А что если нужно научиться пользоваться новой для вас библиотекой? Документация - замечательно. А как запустить? Если у нас есть DLL'ка, ее нужно сначала загрузить в адресное пространоство процесса, а затем уметь дергать функции в этой DLL'ке с правильной calling convention, передавать правильные аргументы и правильно интерпретировать значания. Кажется, без написания тестовых программ никак.

Но я уже достаточно давно использую для похожих целей python. В начале, я попробовал (на C++) Boost.python и Python C API - хорошо, но можно потеряться в темплейтах если что-то вдруг не заработает c Boost.Python. Затем, юзал SWIG. Тоже ничего, но там такое надо бывает написать в .i файле, придумывать какие-то typemaps для чуть более чем тривиальных случаев. Не хочется такое повторять. Boost.Python и SWIG плохи тем что интерфейс надо оборачивать и писать какой-то код. Быстро поэкспериментировать не получится.

Ничего особо писать не нужно в ctypes, но как-то сложилось, что я его не слишком использовал. А зря.

Сейчас обнаружил, что все варианты FFI в Сommon LISP чем-то похожи на ctypes. Итак, если разобраться в FFI в LISP, что же мы получаем? У нас есть некий процесс, в пространство которого мы можем загрузить любую DLL'ку, подергать ее. При этому это все делается в REPL, плюс под рукой есть мощный язык с помощью которого можно всем этим рулить, прототипировать, экспериментировать. Python с ctypes тоже тут неплох, просто в SLIME получше среда, да и макросами можно весь FFI быстро обернуть. См ранее об libgcrpyt

Имею кучу гемора с установкой чего-то нормального лиспового на винде

Чаще всего рекомендуют CLISP, якобы на винде работающий нормально. Мне, правда больше по душе Clozure, и вроде встало нормально, SLIME запустился. Сначала не появлялся REPL отдельным окном, но потом прочилал в доке, что теперь REPL'а по умолчанию нет (!), и надо специально попросить, сказав в Emacs'е (slime-setup '(slime-repl)). В Clozure CL интересный FFI, будем смотреть сейчас.

среда, 6 мая 2009 г.

О полезности рестартов для долгих вычислений

Я не сильно пока вникал в conditions/restarts, ну то есть прочитал, и все. Пока использую высокий уровень: error, warn, ignore-errors, unwind-protect. Но что классно: запускаешь длинную-предлинную задачу (сейчас пишу нечто, что обрабатывает файлики размером по 12-15G) потом всегда можешь нажать Ctrl-C, и после этого нажать нолик и продолжить с того места где прервал! При этом можно посмотреть как себя задача чувствует, какой прогресс, можно поправить чего-нибудь, вобщем, красота! Можно даже придумать такое извращение, как периодчески слать сигнал процессу затем, чтобы рисовать прогресс бар :)

На C получилось 3500 строк

И то потому что сделал там свои списки и intern, плюс автоматическую чистку ресурсов, с возможностью при ошибке тупо делать longjump. Все это сократило количество кода.