тяжело быть идиотом...

Только сегодня выяснил, что тесты из предыдущего поста я проводил на отладочной сборки своей библиотеки. Новые измерения - на офисных файлах обганяем в 4 раза, а на всех остальных - почти в 40. Однотредовая программа в итоге определяет типы около 6 тыс. файлов/сек.

о засильи xml...

В который раз уже сталкиваюсь с тем, что у людей имеется рефлекс на использование XML в различных программных продуктах - в качестве ли конфигов, или в качестве протокола для передачи данных. При этом, очень часто люди не задумываются о том, как и кто будет эти данные использовать. И очень часто удобство разбора XML в программе за счет доступного API делается в ущерб удобству использования этих данных, особенно когда эти данные могут изменяться человеком. В итоге либо человек вносит изменения в конфигурацию/правила/... долго ругаясь, либо ему приходится пользоваться специально заточенным монстрообразным GUIем (обычно на .Net или Java, разработчики которых наиболее подвержены этому влиянию).
А ведь часто стоит задуматься о том, что простой текстовый файл с данными "имя = значение", или с простым языком, становятся гораздо понятней и удобнее для использования чем XML, пусть даже ценой немного больших усилий со стороны разработчика.
Сегодня в очередной раз в этом убедился рассматривая конфигурационные файлы TriD, где простое правило из 2-3-х сигнатур, выраженное в XML, занимает целый экран, хотя могло быть выражено в чем-то более простом, например:
offset N1 == XXX and offset N2 == "YYY"
То же самое относится и к использованию XML в качестве формата обмена данных - существуют более компактные вещи, например, json или google protocol buffers, и которые имеют реализациия для практически всех языков программирования.

еще раз про форматы файлов

Набрел тут на библиотеку OutsideIn для определения форматов файлов, которая производится Oracle, и используется в продуктах нашей новой компании. Почитал описания, скачал и поигрался с нею. Впечатления сумбурные - несмотря на то, что в документации перечислены сотни форматов файлов, как выяснилось, многого она не знает - 7z/lzma, cpio, .deb, rpm, .arc, .ace, .chm, .hlp и еще много чего, мне просто надоело. Ну и не определяется много само-распоковывающихся архивов
Про скорость работы я даже говорить не буду. На офисных файлах мой детектор обгоняет их где-то на 30%, а на миксе из разных файлов на выборке в 45 гигабайт, мой детектор уделал их библиотеку более чем на порядок....
Стоит отметить, что определение типов - одна из задач этой библиотеки, и вроде они обещают, что умеют извлекать текст и метаинформацию из множества офисных и т.п. файлов, но это мы будем проверять немного позднее...

haskell + couchdb

Кажется нашел в чем проблема заключалась. Очень похоже на багу в HTTP модуле, который при формировании запроса запихивал в request path полный урл, включая хост и порт. Странно, почему оно работало на линуксе

к предыдущему посту...

а на линуксовой инсталяции couchdb все работает как надо.
вечером буду запинывать couchdb на предмет логов на входе. у меня такое впечатление, что mochiweb где-то дурит...

уже практически сломал себе мозг...

развлекаюсь с haskell'ем и couchdb и набрел на забавный глюк, который не могу найти.
закидываю новый документ в базу, с клиента уходит запрос вида 'PUT /db/doc_name_1' (я вижу это в tcpdump'е - я даже ключики вспомнил :-), а в логах couchdb я вижу только 'PUT /db/do' -- имя документа обрезается до двух символов, это видно в заголовках, которые couchdb напечатал в логи.
а если я закидываю документ с помощью curl, то все нормально - имя документа ровно столько символов, сколько я указал.
цитируя классические мультфильмы хочу сказать "ничего не понимаю!"

Сворачивание определений функций, классов и т.п.

Только сегодня обнаружил, что в CEDET есть поддержка сворачивания определений функций, классов и т.п. Этот функционал работает для всех языков поддерживаемых в Semantic. Включить можно с помощью следующего кода:

(defun my-semantic-hook ()
  (semantic-tag-folding-mode 1))
(add-hook 'semantic-init-hooks 'my-semantic-hook)

после входа в соответствующий буфер (и после того, как он будет обработан Semantic'ом), в области fringle, напротив мест определений функций и других объектов, появятся маленькие треугольники, нажимая на который можно сворачивать или разворачивать соответствующий кусок кода
Update: в принципе, должно хватать следующего кода

(global-semantic-folding-mode t)

после загрузки CEDET, но почему-то оно у меня не пошло :-(

Интерфейс к HLint из Emacs'а

Написал небольшой модуль для более комфортной работы с HLint прямо из Emacs. Имеет все те же возможности, что и compilation-mode - навигация по ошибкам и т.п.
Использовать вот так:
(require 'hs-lint)
(defun my-haskell-mode-hook ()
(local-set-key "\C-cl" 'hs-lint))
(add-hook 'haskell-mode-hook 'my-haskell-mode-hook)
и после этого, при открытии файла с исходным кодом на Haskell вы сможете выполнять команду hs-lint используя сочетание клавиш C-c l

Слегка похакал blorg.el

Слегка похакал blorg.el, который используется для генерации блога на моем сайте (в основном это анонсы статей и т.п.). Сделаны следующие изменения:

• Правильная генерация ссылок на файлы, без явного указания схемы file://
• Удалил копирование файлов в собственные каталоги пакета - чтобы не плодить копии файлов, которые уже есть
  
• Сделал правильное маскирование символов <, >, &, ", которые раньше вставлялись как есть, что приводило к генерации неправильного html/xml

Надо доделать правильную генерацию названий файлов для заметок с полностью русскими названиями, и тогда можно считать что пакет более-менее готов к использованию. Ну и для своего сайта - настроить генерацию внешнего вида, а также генерацию ссылок для JS-Kit Comment Widget
Пример сгенерированных страниц вы можете найти тут, а сам модифицированный пакет можно скачать вот тут.
P.S. хотя все равно хочется переписать большую часть пакета более правильно