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

Drupal-овская Taxonomy import/export via XML в версии 1.1 работала. Я даже научился туда XML-и генерировать и было мне счастье.

А версию 1.2 они сломали (мотивируя починкой Security Advisory). Короткие таксономии работают, а попытка залить туда 200 терминов кончается фиаско.

А ведь это модуль не ежедневного использования, шансов на починку гораздо меньше чем обычно. И обычно то не чинят, а ради одноразовой штуки заморачиваться не хочется вовсе. Я вот перешел на CSV import, хотя он и менее удобен: присвоить ID терминам нельзя.

Несмотря на мой исходный пессимизм, появившееся неделю назад острое отвращение к MySQL заставило меня расчехлить напильник и наконец доработать Drupal 6.5 до устраивающей меня совместимости с PostgreSQL.

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

Несмотря на мой исходный пессимизм, появившееся неделю назад острое отвращение к MySQL заставило меня расчехлить напильник и наконец доработать Drupal 6.5 до устраивающей меня совместимости с PostgreSQL.

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

Внезапно возникшее отвращение к MySQL (каменты тоже читать) заставило посмотреть на связку Drupal + PostgreSQL еще раз.

Если аккуратно, то все работает. Т.е. к core у меня и раньше претензий не было, а сломался я в модуле Backup-Restore. Сейчас - с минимальным набором 3rd-party (Tagadelic, Inline Tags, Site Menu, Pathauto, Transliteration) все вроде живет. Точнее, Transliteration не транслитерирует, но оно этого и с MySQL не делало, но всяких сообщений об ошибках и прочих безобразий пока нет, за исключением одного:

У меня на разных инсталляциях PostgreSQL стоит разный default client_charset. Где-то KOI8, где-то CP1251, но нигде не стоит UTF8 (базы все, естественно, в UTF). Это все по соображениям совместимости - много где живут скрипты многолетней давности и вставлять в каждый из них set client_charset мучительно.
Drupal о такой подлости не подозревает (MovableType - подозревает и выставляет), что лечится простым патчем:

drupal64.pgsql.diff.gz

Завтра и послезавтра (6-7 октября) я буду на Бунинском Хайлоаде. С утра и до непонятно какого времени, думаю что до среднего послеобедья.

Принимаю подношения, раздаю автографы, развлекаю публику.... Желающие что-то обсудить узнают меня по усам, очкам и майке АиП (не перепутайте с Лешей Ивановым)

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

По идее, для этого предназначен Aggregator, но его интеграция с Taxonomy запланирована только в Drupal 7. Кроме того, pull мне очень не понравился, хочется push. Для push есть BlogAPI, там даже поддерживается установка категорий (тоже довольно диким способом, ибо информация о словарях недоступна, можно получить только список терминов), но вот установка тегов (т.е. терминов, которых в словаре может не быть) через стандартный BlogAPI невозможна. mt_tags - не поддерживаются и не обрабатываются.

Я уже почти поправил BlogAPI (всего то нужно задать один параметр конфигурации - в какой словарь класть теги, остальное все тривиально) и оно уже почти работало, но нашлось готовое решение.

Inline Tags делает все что нужно. Не стандартным путем (т.е. использовать готовое поле tags в blog-редакторе и передачу значений в mt_tags), но вполне приемлемым: список тегов пишется в [tags][/tags] и все работает (проверено).

Ссылками в комментариях спамят не только этот блог, но и мои сайты на Drupal (libraw.org,gpgpu.ru и так далее). В отличие от MovableType, антиспам-средства у Drupal развиты еще меньше, приходится пропускать без модерирования только зарегистрированных юзеров, но и это не вполне помогает.

Мировая часть проблемы в Drupal решена - ко всем ссылкам в юзерском контенте можно добавлять rel=nofollow, отчего спамить под гугл становится неинтересно. Остается яндекс, который rel=nofollow не понимает (насколько мне известно), но зато понимает "рамблеровский" (придуманный Димой Крюковым) тег <noindex>.

Сооответственно, нужно добавить три строчки кода к modules/filter/filter.module:

drupal-noindex-patch.gz

Сделано примерно так же, как для Movable Type:

• Сама ссылка заменяется на явоскриптовую
• В noscript,noindex, a.. rel=nofollow помещается слово [link] которое и становится ссылкой для Javascript-disabled people (стандартные стили у Drupal такие, что картинка переносится на новую строку и красивая стрелка не получается).

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

Ссылками в комментариях спамят не только этот блог, но и мои сайты на Drupal (libraw.org,gpgpu.ru и так далее). В отличие от MovableType, антиспам-средства у Drupal развиты еще меньше, приходится пропускать без модерирования только зарегистрированных юзеров, но и это не вполне помогает.

Мировая часть проблемы в Drupal решена - ко всем ссылкам в юзерском контенте можно добавлять rel=nofollow, отчего спамить под гугл становится неинтересно. Остается яндекс, который rel=nofollow не понимает (насколько мне известно), но зато понимает "рамблеровский" (придуманный Димой Крюковым) тег <noindex>.

Сооответственно, нужно добавить три строчки кода к modules/filter/filter.module:

drupal-noindex-patch.gz

Сделано примерно так же, как для Movable Type:

• Сама ссылка заменяется на явоскриптовую
• В noscript,noindex, a.. rel=nofollow помещается слово [link] которое и становится ссылкой для Javascript-disabled people (стандартные стили у Drupal такие, что картинка переносится на новую строку и красивая стрелка не получается).

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

Я понимаю, что уже опротивел за последние три дня, поэтому буду краток.

LibRaw 0.6.0 Release берут отсюда. Полный Changelog там, а краткий вот:

• Поддержка Nikon D90 и P6000, Canon 50D, Sony A900, Panasonic FZ28 и LX3. При этом D90 и A900 поддержаны нормально, а для остальных нет таблиц RGBG-XYZ, цвета могут быть кривоваты (и будут еще апдейты).
• Примитивное подавление бэндинга для камер Canon.

По требованиям французских и немецких трудящихся, была добавлена разнообразная функциональность:

• Обработанное изображение можно получить в виде RGB-битмэпа (ранее только в виде квадрупляев R-G-B-unused)
• Добавлены вызовы для индикации стадий обработки (рисования прогресс-баров) и досрочного прекращения обработки.
• Добавлена работа с профилем камеры/выходным профилем через LCMS
• Вспомогательные вызовы: получение списка поддерживаемых камер, получение информации о версии.
• поддержка работы с картой плохих пикселей и вычитанием темнового кадра.
• поддержка OpenMP для AHD-интерполяции и шумопонижения.
• исправлена одна ошибка в adjust_sizes_info_only

Скачать эту версию можно c сайта LibRaw со страницы downloads в разделе бета-версий.

LibRaw имеет шансы появиться в digiKam, куда оно проникает через libkdegraphics.

Что-то у меня затык и гугление не помогает.

class Bar
{
public:
    int  a;
    Bar();
    void run(void);
};

void Bar::run(void)
{
    int i,k;
#pragma omp parallel private(i) firstprivate(k,a)
    {
    }
}

Ругается вот таким нехорошим словом:
omp-test.cpp: In member function 'void Bar::run()':
omp-test.cpp:22: error: 'Bar::a' is not a variable in clause 'firstprivate'

Ну и что с этим делать?

Update Нашел (тоже не очень легко), что возможен такой синтаксис:

class Bar
{
public:
    int  a;
#pragma omp firstprivate(a)
}

А что делать, если Bar::a в одном месте должна быть lastprivate, а в другом - reduction? Временные переменные заводить?