Skip to Content

Программирование

AMD/ATI и GPGPU

Втр, 01/12/2010 - 21:50 — lexa

Я как-то не уследил, потому что AMD/ATI-шными видеокартами начал интересоваться с выходом HD5xxx, а оказывается все очень весело. На gpgpu.ru это уже пообсуждали, ну я сюда наброшу, в более концентрированном виде.

Раньше высокоуровневым средством для разработки считалок на видеокартах у ATI был Brook+. Однако начиная с какой-то беты ATI Stream SDK 2.0 Brook из SDK исчез.

Читаем в ATI-шном форуме (это август-2009):

Yes, this SDK 2.0 beta is for CPU only. It focuses on OpenCL 1.0 for CPU. Brook+ is now available on SourceForge: http://sourceforge.net/projects/brookplus

Ну ладно, Stream SDK Beta-1 вообще не поддерживает никаких видеокарт, смешно.

Миграция Movable Type -> Drupal. Синхронизация с ЖЖ, наведение марафета, финал

ЧТ, 01/07/2010 - 23:53 — lexa

Руководство по прыжкам с парашютом, издание второе, исправленное

Теги/рубрики/категории

При миграции контента с тегами и категориями был предложен такой метод

  1. Делаем категории тегами (чтобы не заполнять значения).
  2. Импортируем.
  3. Меняем тип таксономии категории на "Multiple select/Mandatory".
  4. Правим пути к категориям.

Увы, но где-то на этом пути теряются категории у изрядной части записей и теги - у единиц, повторный импорт лечит только частично. Я подозреваю, что крышу рвет, если есть теги, совпадающие с категориями, но не уточнял.Теги портит LJ Sync, пришлось его еще шашкой....

Пришлось написать скрипт (качать тут), который правит эту проблему, анализируя таблицу mt_posts самостоятельно (запускать после импорта, когда все теги/категории уже созданы).

С шашкой на Drupal: LiveJournal Sync Ugly Hack

СР, 01/06/2010 - 17:43 — lexa

Синхронизация Drupal с ЖЖ оказалась гораздо более простым делом, чем в случае Movable Type:

Ну, если быть точным, то для LJ Sync нужно поставить еще патч из его pending patches, а то синхронизированное туда приезжает тут же обратно, второй копией.

А если быть совсем точным, то LJ Sync не работает с PostgreSQL. REPLACE INTO {table}, убил бы нафиг....

Но. LJSync делает куда больше чем не нужно:

  • Вытаскивает из ЖЖ записи, которые там появились независимо. Это хорошо, если есть адын standalone-блог и адын ЖЖ, но у меня два стандалона гадят в один ЖЖ.
  • Темизирует look-and-feel Друпала "под ЖЖ". С синенькими заголовками комментариев и заголовками записей в ЖЖ-шном духе.
  • Для всех ЖЖ-шных комментаторов заводится аккаунт на Друпале. Оно так и на MT у меня было, но на MT эти аккаунты были бесправные, а тут в них можно авторизоваться (если OpenID включить) ну и типа писать.
Всего этого я ну никак простить не мог.

Миграция MovableType -> Drupal. День 2: миграция контента и URL

Втр, 01/05/2010 - 21:53 — lexa

Предуведомление

Описанная ниже методика предназначена для заливки пустого сайта на Drupal. Задача доливки контента на сайт, где уже что-то есть - не ставилась. Более того, на стадии импорта комментариев все старые комментарии точно будут стерты.

Если вам нужно пополнение имеющегося сайта, то описанные ниже скрипты нужно взять за основу и допилить.

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

Импорт записей

Задача: вытащить записи (посты) из БД MovableType и запихать их в БД Drupal в виде объектов типа Story. Создание Drupal-объекта связано с заполнением нескольких таблиц (node, node_revisions и прочие node_*, url_aliases), пополнением таблицы тегов, другими словами эту работу не хочется делать вручную (SQL-запросами), а хочется перевесить на внутреннюю механику Drupal (ведь при создании записи оно как-то само все делается...).

План работ тривиален и прост:

  • Ставим модули Table Wizard и Migrate.
  • Добавляем нужные поля в структуру данных записи Story (не вручную, включением готовых модулей).
  • Запускаем скрипт, который перенесет нам данные постов в БД Drupal.
  • Импортируем образованную таблицу с постами в Table Wizard.
  • Делаем импорт через Migrate.
  • Полируем результат.
Первый пункт особых вопросов вызвать не должен, обычные модули. За собой потянут Views и Schema, их тоже надо выкачать и поставить, до кучи полезен и Views UI.

Drupal: pathauto и транслитерация

Втр, 01/05/2010 - 16:40 — lexa

В качестве короткой заметки на тему вчерашнего и ряда следующих текстов.

Для Drupal есть модуль Pathauto, который делает человеко понятные урлы: заменяет пробелы на минусы (или подчеркивания), меняет ужасные /taxonomy/term/NNN на /tags/имя-тега и так далее.

Все из себя настраиваемое и вообще хорошее, если бы не одно но:

  • Оно умеет транслитерацию (в частности, URL данного текста странслировался бы в ...i_transliteratsiya.....
  • Оно умеет формировать URL-ы из кучи макросов (дата, рубрика и все такое), этого богатства более чем хватает для жизни.
  • Но! Включение транслитерации - глобальное. Или мы транслитерируем все (URL заметок, теги и т.п.) или не транслитерируем ничего.
А у меня в блоге принято, что теги русские, а URL заметок - латинские.

Короче, патч: pathauto-transliterate.diff.gz

Если в паттерн для формирования URL включить текст 'no-transliterate-me', то данный текст будет удален, а то что осталось - не будет транслитерировано.

Все очень на скорую руку, только для таксономии (тегов), но там по образу и подобию несложно доточить для других типов - муторно, но можно.

К сожалению, модуль написан достаточно плотно, транслитерация делается на очень ранней стадии, поэтому сделать более удобные макросы по месту [notr-macro] и [macro] - сходу не получилось.

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

При случае, подумаю про эту тему еще.

Миграция MovableType -> Drupal. День 1: постановка задачи

Пнд, 01/04/2010 - 15:53 — lexa

Предуведомление

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

Короче, не нравится - не читайте :)

Статус этих записок

Записки пишутся по горячему, с небольшой задержкой относительно реальных действий. На момент написания первой части (которую вы сейчас читаете) есть ощущение, что все получится, но реальный перенос данных даже на тестовой машине сделан частично. Но уже есть ощущение успеха, минимально необходимая функциональность точно будет, а дальше будем посмотреть.

Зачем переезжать

Моя причина очень простая: мне надоело поддерживать две платформы (Drupal и Movable Type). При этом, по комплексу свойств Друпал побеждает, а значит с MT пора прощаться. А новогодние каникулы - хороший повод позаниматься чем-то полезным.

О несовершенстве мира

СР, 11/25/2009 - 17:16 — lexa

Второй день собираю Qt 4.6-RC при помощи VS2008, с каким-то очень переменным успехом:

Если собирать Qt SDK, то ломается при сборке вебкита, moc генерирует файл нулевого размера. Ошибка висит в Qt-шном багтрекере со статусом "не удалось воспроизвести", гугление показало что она бывала и на Qt 4.5.2, хотя у меня 4.5.2 собирался без проблем.

Кроме того, не срабатывали такие вот строчки: 

#if QT_VERSION >= 0x040400
    void unsupportedContent(QNetworkReply *reply);
    void downloadRequested(const QNetworkRequest &request);
#endif
хотя версия у меня самая что ни есть 0x040600

При сборке варианта без Qtcreator наблюдался целый ворох странных проблем, тот же moc.exe создавался без прав на исполнение. По десятому разу вроде полегчало и конкретный WebKit вроде собрался без ручных пинков (с пинками, т.е. подменяя файл длины на нормальный - получалось и в первом случае, но неаккуратненько).

Одновременно узнал про jom, на 4-ядерном процессоре ошибки компиляции возникают вчетверо быстрее, ура!

Я вот как подумаю, сколько сил стоит поддержка Qt на всем чудовищном мировом зоопарке, так мне сразу хочется год эдак в 85-й.

Bye-Bye, Movable Type

Втр, 11/17/2009 - 11:56 — lexa

No-MT.png Как нам пишут в комментариях, а потом мы и сами читаем:

Q: On http://www.movabletype.jp/documentation/mt5/db/mysql-from-sqlite.html I read: From the Movable Type 5, SQLite and PostgreSQL are no longer supported.
A: Yes, it's true. MT5 will deprecate core support for SQLite and PostgreSQL. But, these databases can still be used with MT if a plugin is written to add support; the Enterprise Pack defines the drivers necessary to use the Oracle database with MT.

Вот и выяснилось, чем придется заниматься на новогодних каникулах, писать тестировать LJ-кросспост для Друпала (оказалось, он уже есть, что же я торможу?)

Если кто-то общается с командой MT, передайте им при случае, чтобы думали верхней жопой передней головой, платформа их была выбрана мной исключительно за поддержку PgSQL и только это ее и берегло.

PostgreSQL 8.4.0 UTF conversion

ЧТ, 09/10/2009 - 18:36 — lexa

Представим себе типичную ситуацию: есть таблица в 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 не понравился, слишком уж много дополнительных условий, в которых я не уверен.

Linux и Large Files

СР, 08/12/2009 - 18:13 — lexa

А вот представим, что у меня есть библиотека, собранная с -D_FILE_OFFSET_BITS=64
Все fopen/fseek/fread/fclose там делаются внутри, снаружи только имена файлов прилетают.

А потом я к ней линкую приложение, компилированное без этого флага, просто gcc -c

Вопрос: оно будет работать? Или возможны моментики?

Нет, я не ленивый и конечно попробую, но у меня этих линуксов под рукой штуки две и с новыми ядрами, а что будет со старыми ядрами/glibc/whatever?

P.S. Назначение LARGEFILE_SOURCE/LARGEFILE64_SOURCE так и не понял, вроде бы для позиционирования за 2 гигабайта и чтения мелкими кусками достаточно _FILE_OFFSET_BITS

P.P.S. Единственная система, где вообще не надо париться - FreeBSD :) Какой, оказывается, кусок жизни с этой LFS прошел мимо меня...

Drupal + PostgreSQL (опять, да)

ЧТ, 05/14/2009 - 09:51 — lexa
Передайте разработчикам <программы такой-то>, что лучше бы они ее больше не разрабатывали

Похоже, что тестировать варез становится просто немодно, чем дальше, тем больше огорчаюсь.

Про моральных индусов я уже плакался, но там речь шла о 3rd-party модуле, а сейчас удивляюсь прямо таки на Drupal core. Удивляюсь, соответственно, сильнее, ибо для core поддержка PostgreSQL заявлено, а вот с тестированием... впрочем я повторяюсь.

Угадал, блин

СР, 05/13/2009 - 10:59 — lexa

Довелось оказаться пророком.

В комментариях к записи про анонс NVidia работающего OpenCL я предположил, что

Конечно, сейчас начнется, они вполне могут начать с драйверов для Линукса (или для 32-битной XP, что от меня столь же далеко)
И угадал, блин. Именно XP-32 и Linux-32. XP-шные бинарники на Висте не работают, несмотря на драйвер нужной версии, ругаются что не могут создать OpenCL context

А у меня Vista (32/64) и MacOS. Ну в Маке, ладно, обещали в заснеженном леопарде, а с вистой что? Руки же чешутся....

На закуску: согласно спекам OpenCL, его можно/нужно кормить исходником прямо на этом самом OpenCL (а это практически C). То бишь компилятор этого самого C сидит прямо в драйвере....

Интересно, насколько успешно это пойдет в индустрию, ведь получается что computing kernel засекретить не выйдет, можно же подсунуть приложению драйвер похожий на настоящий и почитать им исходника. Видятся мне OpenCL-обфускаторы.

LibRaw Lite

ЧТ, 05/07/2009 - 15:22 — lexa

почти копия анонса с сайта

По многочисленным заявкам нелюбителей GPL выпущена LibRaw-Lite

Как следует из названия, это облегченная версия LibRaw, основные отличия которой от полной версии таковы:

  • Лицензия LGPL, что позволяет использовать (немодифицированную) библиотеку в не-опенсорсных приложениях.
  • (увы) нет поддержки Foveon в силу лицензионных ограничений на этот кусок dcraw (откуда растут ноги у LibRaw). Мы работаем над этим и возможно предложим какую-то замену.
  • Нет целого ряда улучшений (сделанных нами относительно функциональности dcraw):
    • черная рамка (маскированные пикселы) не извлекается, эти пикселы приложению не доступны;
    • вычитание точки черного и прочая пред-интерполяционная обработка RAW-данных не отключается;
    • способ, которым получены цветовые данные (матрицы RGB-XYZ и т.п.) не запоминается;
    • нет поддержки OpenMP.

Другими словами, все то хорошее что мы сделали в расчете на разработчиков RAW-конверторов, анализаторов RAW и прочие программы, которым нужен доступ к исходным RAW-данным - в Lite-версии отсутствует.

Счастье виртуализации достижимо

Втр, 04/28/2009 - 10:50 — lexa

У меня дофига работы происходит под VMWare и все полностью устраивало, кроме одного моментика: если засаспендить большую виртуальную машину (скажем с 4-мя гигами RAM), то хост-система (Vista x64) на довольно долгое время (минут 5) впадает в депрессию: реактивность понижается до нуля, на кнопки не реагирует, на мышь тоже, думает о чем-то своем.

Рабочей гипотезой было то, что саспенд пишет в файл, этот файл кэшируется в файловом кэше, а потом медленно и печально выливается на диск. Кэш при этом, естественно, тоже вымыт нафиг и любая мелочь (DLL-ки там) требует доставания с диска, что в свою очередь интерферирует с вышеуказанным выливанием на диск.

Помогли следующие настройки виртуальной машины (которые я ставил вовсе для другого): 

MemTrimRate = "0"
sched.mem.pshare.enable = "FALSE"
mainMem.useNamedFile = "FALSE"

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

Vista x64 driver signing hell

ЧТ, 04/09/2009 - 15:30 — lexa

Я сделал это!

Потеряно два вечера и еще полдня, система два раза поднималась с бэкапа, но я таки подписал драйвера для Висты-x64 и они таки работают.

История вопроса

Есть такой Argyll CMS, который я уже многократно хвалил за качество CMM-модуля. И вообще, похоже что это необычайно ценный мех варез, ибо качество строимых им профилей необычайно хвалят.

Помимо этого, Argyll умеет работать с i1 Pro в точном режиме: со спектральным разрешением 3.33 нанометра вместо стандартных 10нм, что тешит мою склонность к перфекционизму.

Кроме того, тамошний дисплейный профайлер очень хвалят, хотелось попробовать самому.

Мешало пользовать эту полезную зверушку следующее обстоятельство:

  • Argyll использует libusb, которая конечно есть для Windows, но тамошние драйвера неподписаны, а значит на 64-битной висте можно этим пользоваться, только если при загрузке нажать F8 и выбрать режим, отключающий проверку подписи.
  • Если ставить кроме libusb еще и тамошний модуль фильтра (чтобы можно было использовать тот же i1 и из стандартных приложений), то без загруженного драйвера вся система не работает, а входит в вечный цикл перезагрузки.
  • Но нажимать всякий раз F8 на загрузке - мучительно и противно.
Syndicate content