патчи

Беда, коль сапоги начнет печи...

Вот, казалось бы, хорошая идея - давить пиковые выбросы прямо в RAW-данных. Hot pixels так можно задавить. Вот мне для LibRaw такой патч и прислали, причем, как я понимаю, он уже вовсю работает в одном опенсорсном RAW-процессоре.

На картике слева (кликабельна, по клику увидите как оно на экране при 150%) показан результат применения этого веселого подхода к снимку resolution target. Сверху - результат фильтрации, снизу - без фильтрации. Холст, масло, Canon 500D, снимок взят с imaging-resource.

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

И ведь не индус какой прислал этот патч, а вполне уважаемый человек, помянутый RAW-процессор пишет, который даже многим нравится.

Такое впечатление, что тестировать результаты собственного программирования - просто не принято в последние годы. Я эту красивую картинку получил в первом же (!) тесте (то, что туда попалась resolution target - случайность, но артефакты полезут на любых контрастных границах).

Похоже, что я излишне суров к Adobe, дивный новый мир опенсорца - гораздо хуже.

P.S. Второй содержательный патч из того же источника - не тестировал пока, хотя он мне идеологически тоже не нравится. Он давит maze artefacts, но должен и малоконтрастные детали тоже сгрызать.

PostgreSQL 8.4.0 UTF conversion

Представим себе типичную ситуацию: есть таблица в UTF8, какой-то клиент вводит туда данные, работая, скажем, в кодировке windows-1251 и вводит, например, знак номера.

Потом другой клиент, работая уже в KOI8-R сделает по этой таблице SELECT и вместо результатов выборки увидит

ERROR: character такой-то of encoding "UTF8" has no equivalent in "KOI8R"

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

Начиная с 8.1.4 я делаю патчи для этой функциональности: вместо выдачи ошибки и прекращения запроса невыводимый символ просто меняется на пробел. Дошла очередь и до 8.4.0:

Патчи для старых версий тоже можно брать у меня:

Стандартный дисклеймер: если вы не знаете что такое "патч", то он вам не нужен.

P.S. Своего мнения про 8.4 пока не имею, сформирую - напишу. Пока тестирую, в бой выставлять рановато. pg_migrator не понравился, слишком уж много дополнительных условий, в которых я не уверен.

Лечение проблем LC_COLLATE при использовании UTF-8 в PostgreSQL под FreeBSD

Как я уже писал, при использовании UTF-8 в PostgreSQL под FreeBSD результат больно бъется: сортировка русских букв неправильная (касается это только буквы ё). Причина - в кривой locale под FreeBSD (и Mac OS X).

Естественно, на эти грабли уже много раз наступали и для PostgreSQL 8.1 существуют патчи имени Palle Girgensohn, позволяющие использовать IBM-овскую библиотеку ICU в которой все сделано правильно для безумного количества языков.

Postgresql 8.3b1 UTF conversion patch

Я уже писал (а потом писал еще), что, в силу многих причин, стандартное поведение PostgreSQL при конверсии из UTF-8 в однобайтовые русские кодировки меня не устраивает. Ну нельзя обижаться и ломаться в ситуации, когда мы, например, импортировали текст в кодировке windows-1251 с кавычками-лапками, а показать хотим его в KOI8-R, где кавычек-лапок нет.

Патч для версий 8.1.4-8.2 можно найти по ссылке выше. Для 8.3-beta1 он не подходит, поэтому пришлось сделать новый: postgres-8.3.b1-conversion.patch.gz

Это хак, правильность которого я обсуждать не желаю, ибо идеологически он неверен, но без него не работают старые приложения.

Кросспост из MT в LJ

Продолжаем патчить MovableType.

Многим, вероятно, удобнее читать мои упражнения через френдленту ЖЖ. Следовательно, нужен кросспост туда. Коллективный разум предлагает два решения:

  • ljcrosspost — сделан неудобно, предполагает публикацию через выполнение тега, что означает перепубликацию при любой перевыкатке отдельных статей. Не понравилось.
  • MTLJpost сделан более человечно, публикация происходит при нажатии кнопки Save в редакторе т.е. вместе с trackback pings, нотификациями блог-поисков и еще один RPC call погоды не сделает.
Берем и ставим второй. Выясняется:
  1. Машинка глючит, если нет картинки (юзерпика), соответствующего категории. Но править это соответствие после каждого редактирования категорий - мучительно.
  2. Не хватает пары мелочей:
    • постинга тегов в ЖЖ
    • запрещения комментариев (с комментариями хочется всех загнать к себе)
Впрочем, пять минут работы напильником и готов очередной патч. Этот патч:
  1. Передает в ЖЖ теги
  2. Чуть лучше разбирается с ситуацией, когда не найден юзерпик
  3. запрещает комментарии.
Если запрещение комментирования не нужно, то из патча нужно удалить строчку
+   $lj->Setprop_nocomments($event,1);
upd: после ряда экспериментов, я матчинг юзерпика и категории вообще убрал нафиг. Странное оно и дикое

Русификация MovableType

Русификация MovableType состоит из таких шагов
  1. Русификация дат
  2. Русификация имен файлов для dirify
  3. Перевод темплейтов и системных сообщений
Первые два пункта требуют правок кода, каковые правки и были сделаны. Все действия производились над MovableType 3.33

UTF-8 и только он

Мы живем в 21-м веке, когда передача лишних байтов через всю планету не стоит вообще ничего. Работа с многобайтовыми кодировками сейчас поддержана везде, на очень старые версии браузеров закладываться смысла нет (примечание от меня, как от автора Russian...

Postgresql 8.2, UTF8 и русские буквы

В отличие от PostgreSQL 8.1.x, табличка преобразования UTF8<—>CP1251 уже нормальная, € там имеется.

Однако сама идеология осталась порочной, мне не нужны ошибки при попытке конверсии, я хочу их маскировать. Впрочем патч от 8.1.5 вполне подходит и к 8.2

Postgresql 8.1.x и UTF-8

В PostgreSQL начиная с версии 8.1.4 ужесточили правила конверсии из UTF-8 в однобайтовые кодировки. Если раньше при неконвертируемом символе было предупреждение, которое попадало в лог (или в приложение, если оно читало Warnings) и все работало, то сейчас неправильный символ приводит к ошибке и запрос не выполняется.

Тут же выяснилось, что у этих криворуких уродов таблица преобразования из/в windows-1251 неверная, там пропущен символ €. Пришлось, как водится, править.

патч для таблиц перекодировки UTF8<->CP1251 PostgreSQL 8.1.4 и 8.1.5

Заметим, что введение такой безусловной функциональности в minor-версии &mdash это моветон. Разработчики нам обещают, что в пределах minor-а все будет работать без backup/restore базы, а это нифига не так, приложения просто перестали работать совсем. Впрочем, багу с конверсией посчитали vulnerability, что вполне верно если перекодировке подвергается пользовательский ввод. Но не во всех приложениях это впрямую пользовательский ввод, более того у нас правильность символов контролируется на этапе ввода, а значит нам такая неотключаемая проверка нафиг не нужна.

Пришлось делать патч, который ее относительно safe выключает: все неизвестные символы при преобразовании UTF8->однобайтная кодировка меняются на пробел. Вот этот патч: качать. Естественно, этот патч можно рекомендовать только тем, кто понимает что делает.

Subscribe to патчи