Через полтора часа я уезжаю в Москву. Утром 15 улетаю в Новосибирск. Встретиться с москвичами не получится, извините, дела (__ronin__ тебя это не касается).
В Новосибирске буду в семь вечера .

Новосиб! Академ! Кто хочет меня видеть - + 7(960)250 61 33. Либо звоните, либо (если обламывает факт роуминга) кидайте смски (не забывайте подписываться, от кого). До встречи

Назад вылетаю 22 утром, утром же буду в Москве. Видимо, я там тоже буду занят, но это под вопросом - ближе к делу спишусь с вами, ребята.

Отвалился интернет. А у меня deadline.
Слава yota! Не зря резервный канал покупал.

Уезжаю на неделю, беру у друга EEE PC.
Никто не подскажет, под ebuntu пашут USB-модемы от билайна?
А то в Новосибе нету Yota, а мне на связи надо быть =(

Сегодня меня перевели в другую группу. Как мне сказали теперь я буду заниматься ИИ.

Теперь я сижу в другой комнате. У меня другой непосредственный начальник. Огромное количество кода, просто неприличное количество кода. Я вообще удавляюсь как эта сотня модулей (наш тренажер) запускаемых на разных машинах работает и не глючит.

Так эта группа работает в достаточно старом бранче у меня другая студия (2003), другой буст (1.32). Другой coding convention.

Прям как будто сменил место работы. Хотя всего-то: пересел в соседнюю комнату.

Всё новое, незнакомое. Очень интересно. Сегодня я почти не устал, хотя сидел весь день не отрываясь.

UPD: Что меня больше всего беспокоит это то, что к системе ИИ относится замечательный проект ModOffenders. Проект, в котором все классы имеют по 5 шаблонных параметров, объём временных файлов при компиляции у него 1.5Гб, а если забыть в нём поставить точку с запятой, то можно получить сообщение об ошибке на 30Мб. Поэтому, увидев начало сообщения об ошибке, надо скорее нажимать Ctrl+Break, а то студия повиснет, до тех пор, пока это сообщение не выведется целиком.

Ещё не ночь, но я уже ненавижу хеши.
Неведомая ёбанная хуйня на каждом шагу.
Тут указатель не так привёл, тут offset'ы перепутал, тут про size от varchar забыл.
А самое дрянное - оно падает иногда с corrupted stack - ищи-свищи, добрый молодец.

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

Вот и наступил на грабли. Бустовый контейнер такие штуки любит.
Обидно обнаруживать дыры в знаниях.

Отсюда - бага при интеграции boost'а в физический план. Значения в физическом плане передаются при помощи генераторов, а генераторы знают откуда достать "текущую строку" - указатель на неё + размер в случае varchar. Потому вставка происходила так - аллоцировал память для вставки, делал вставку, контейнер, естественно, просил мою стратегию вычислить хеш-функцию, и отдавал ей указатель на память - я же на него ложил болт, и считал хеш по значению генератора. Оптимизация, типа. Не делать перекладку из генератора в контейнер до тех пор, пока мы не убедимся что данный ключ - не дубликат.

Ночью не выспался, потому отрубило на рабочем месте минут на 15.
Откинулся на кресле, поспал.
Как хорошо-то!

Дневной сон одобряю!

При помощи osm2pgsql перегнал osm в PostGIS, подключил в geoserver.
Теперь ищём десять отличий:
geoserver:
( Read more... )
openstreetmaps:
( Read more... )

Что ещё ему нужно, чтобы он показывал красивую карты с буковками?

P.S. со стилями игрался. Не помогло.

Господа. Как бы вы отнеслись к следующим плюсовым библиотекам.

1 Класс контейнера (со стандартными итераторами), имеющий value_type char, содержимое которого представляет содержимое файла. Реализуется через меп файла в память.

Rationale: Он предоставляет удобную работу с файлом (а-ля вектор), когда файл большой и его нельзя засунуть целиком в память. Для быстрых операций чтения-записи можно сделать перегрузку std::copy.

2 Генератор (класс, который из OutputInterator делает InputInterator). Он базируется на моей идее про генераторы [1] [2]. Только там сопрограмме передавалась функция yield, а здесь OutputIterator. И yield не возвращает не bool (надо/не надо завершиться), а бросает исключение с случае если новых элементов больше не требуется. Это даёт возможность состыковывать её с алгоритмами стандартной библиотеки. Приведу на примере.

template <typename InputIterator>
void process(InputIterator first, InputIterator last)
{
   typedef std::iterator_traits<InputIterator>::value_type            value_type_t;
   typedef generator<std::iterator_traits<InputIterator>::value_type> generator_t;

   generator_t g([=](generator_t::output_iterator o) {
      std::transform(first, last, o, [=](value_type_t const &) {
         // some transformation
      })
   })

   for (generator_t::iterator i = g.begin(); i != g.end(); ++i)
   {
      // handle one element
   }
}

Мы даже могли бы передать g.begin(), g.end() другому std::transform и получить последовательность std::transform применяющихся по мере необходимости (!).

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

Rationale обсуждался в посте про генераторы.

3 Преобразователь из InputIterator в ForwardIterator. Ну понятно как. Надо просто запоминать элементы, выдаваемые InputIterator'ом. При этом из исходного ForwardIterator'а могут сделать много копий и они будут указывать на разные места последовательности. Если взять минимум прозиций всех итераторов, то всё, что находится до этой позиции можно не хранить.

4 Преобразователь из InputIterator в RandomAccessIterator. Аналогичная конструкция, только помнит все когда либо выданные InputIterator'ом элементы. Возможно опционально (как хак) можно сделать функцию позволяющую отбросить все хранимые элементы до данного итератора.

Rationale: С InputIterator'ами может быть неудобно/опасно работать. Во многих алгоритмах хочется иметь на входе как минимум ForwardIterator. Кстати, поддержка InputIterator'ов в utf8cpp была сделана не сразу и требовала некоторых тонкостей в коде. С ForwardIterator'ами работать куда проще.

Такая же конструкция (как 3 и 4) может быть полезна и для Питона. Основная проблема там, то что функции делающие yield возвращают Питоновский аналог InputIterator'а.

Посмотрел презентацию про GIL. Страшная штука. Кажется такие вещи в здравом уме твёрдой памяти никто писать не будет. Оказалось пишут.

Вся правда о GIL.