суббота, 22 мая 2010 г.

[prog.bugs] Маленький рассказ о баге в SObjectizer

Позавчера исправил баг в SObjectizer-е. История с этим багом оказалась очень интересной: в реальной жизни сработали сразу два “закона подлости”.

Первый.

“В любой работающей программе есть, как минимум, три бага. При исправлении любого из них в программу вносится еще, как минимум, три бага.”

В начале мая удалось обнаружить причину проблемы с ACE-овским реактором при рестарте SObjectizer. Устранил эту проблему. Реактор начал работать. Но некоторые unit-тесты стали подвисать при завершении своей работы. Оказалось, что мое исправление содержало ошибку, приводившую в некоторых случаях к тупикам. Вот так, одну ошибку исправил – одну новую внес. Закон сохранения, однако ;)

Второй.

“Не верь глазам своим!”

Поиск ошибки занял много времени и отнял много сил. Из-за того, что я поверил тому, что увидел в отладчике.

Ошибка была нестабильной. Чтобы ее спровоцировать пришлось гонять в бесконечном цикле набор unit-тестов. Иногда она проявлялась на первой сотне запусков, иногда гораздо позже. Но рано или поздно один из unit-тестов зависал. Тогда я запускал Visual Studio, подключался к подвисшему процессу и смотрел, что у него внутри.

Внутри были все признаки классического тупика: две нити, одна висит на одном mutex-е, вторая на втором. Только у одной нити нормальный call stack, а вот у второй – очень и очень странный. В нем только одна запись, указывающая куда-то в дебри ACE-овской реализации Thread_Mutex-а. А в контексте вызова все указатели явно недействительные. Что наводило на мысль, что где-то затиралась память, из-за чего портился, в том числе, и call stack. Это был первый ложный след.

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

Поэтому долго я пытался разобраться, как наследование агентов приводит к порче памяти. В качестве подтверждения такого предположения сыграло еще и то, что я нашел unit-тест, который стабильно подвисал на 100-150 запусках. Когда я сильно урезал его, убрав наследование, он не зависал и после 2000 запусков.

Ситуация становилась очень странной. Механизм наследования, который стабильно работал многие годы, вдруг засбоил. Причем не только под VC++ 9.0, но и под VC++ 7.1, не только под ACE 5.7.8, но и под ACE 5.6.8. Верить в такой сбой мне не хотелось, хотя показания отладчика недвусмысленно указывали на то, что память таки портится.

Тут мне повезло второй раз. Сбойнул тест, в котором наследования вообще не было. И сбойнул точно так же. Вот тогда-то я перестал верить тому, что видел в отладчике.

Вскоре после этого ошибка нашлась. Как водится, ларчик открывался просто. На рабочей нити реактора я вызывал reset_reactor_event_loop() и входил в цикл обработки событий реактора. На основной нити приложения выполнялись действия теста, после чего вызывался метод end_reactor_event_loop() и выполнялось ожидание завершения рабочей нити реактора. Так вот, когда тест отрабатывал очень быстро, метод end_reactor_event_loop() вызывался еще до того, как рабочая нить реактора в первый раз получала управления. Т.е. признак завершения работы реактора уже был выставлен, но я его сбрасывал посредством reset_reactor_event_loop() и входил в цикл обработки событий реактора. Которых уже не могло быть в принципе. Обычные гонки двух нитей. Почему Visual Studio не смогла показать в этой ситуации нормальный call stack – фиг знает. Еще один повод бросить какашку в мелкомягкий софт :)

В заключение хочется сказать о везении. Мне очень крупно повезло, когда я случайно наткнулся на этот баг. Помнится, я проводил контрольную компиляцию под Linux-ом и GCC 4.4.1 ругнулся на какую-то банальную ошибку в каком-то из тестов (вроде забытого #include <cstdio>). Ошибку под Linux-ом я исправил, но для очистки совести решил повторить контрольную компиляцию и под Windows. И тут-то один из unit-тестов завис. Потом несколько компиляций прошло нормально, но зерна сомнения во мне уже зародились. Прогнал еще несколько циклов unit-тестов и зависание повторилось. Тогда я понял, что shit таки happened и нужно копать.

Вот так. Повезло.

пятница, 21 мая 2010 г.

[prog] Выпустил очередной патч для SObjectizer 4.4-beta6

Сегодня. Таки сделал. Скачать можно на SourceForge.

Оказалось, что найденный мной ранее баг я исправил так, что появился другой баг, который я долго и мучительно разыскивал. Но нашел :) Было интересно. Подробности позже.

Самое главное – сейчас SObjectizer 4.4-beta6 можно использовать вместе с ACE 5.7.8. А это значит, что открывается прямая дорога к поддержке и Visual Studio 2010. Что не может не радовать :)

[comp] Выдернул флэшку из компьютера – пришлось ее переформатировать

Записал на 16Gb флэшку A-Data перекодированный фильм и оставил флэшку в компьютере. Через полчаса просто выдернул ее (безопасное извлечение устройства не делал) и флэшка перестала читаться.

Попробовал несколько утилит для восстановления данных. Дальше всех прошла DDR Removal Media Data Recovery – нашла на флэшке каталоги. Но, поскольку демо версия не имеет функции восстановления, а покупать полную версию смысла не было, то я и не узнал, восстановила бы она что-то или нет.

Поскольку ничего ценного на флэшке не было, то я ее просто переформатировал.

Но наука на будущее теперь твердо усвоена: извлекать флэшки из компьютера после записи на них отныне буду только через безопасное извлечение. Вне зависимости от того, сколько времени прошло после записи.

четверг, 20 мая 2010 г.

[prog] MxxRu обновился до версии 1.5.1

Сегодня нашлось время для выпуска обновленной версии MxxRu – 1.5.1. Основных изменений два:

  1. Исправлен способ определения платформы Windows. Так что теперь MxxRu должен корректно работать как с Ruby, который компилировался MS-овским компилятором (host_os в этом случае mswin32), так и MinGW (host_os в этом случае mingw32).
  2. Реализован очень простой способ определения C++ тулсета в случае, если переменная среды MXX_RU_CPP_TOOLSET не задана. Сейчас MxxRu поступает следующим образом:
    • если работа идет на платформе Linux, то в качестве C++ тулсета выбирается gcc_linux;
    • в противном случае в переменной PATH ищутся строки, специфические для Microsoft Visual Studio разных версий. Например, если есть строка Microsoft Visual Studio .NET 2003\VC7\BIN, то в качестве тулсета принимается vc7 (аналогично для vc8 и vc9).

Так что сейчас для мейнстримовых платформ/компиляторов использование MxxRu станет еще проще – достаточно выполнить gem install Mxx_ru и все :)

Взять новую версию MxxRu можно либо вручную с RubyForge, либо выполнив команду gem install Mxx_ru (для обновления с предыдущих версий следует выполнить gem update Mxx_ru).

Документация по MxxRu пока не обновлена :(

Пользуясь случаем выражаю благодарность всем (вольным и невольным) пользователям MxxRu – постоянно растущий счетчик загрузок не дает мне забросить этот проект.

[life.photo] Настоящий водный мотороллер :)

Ченнай, Индия. После сильных дождей.

Снимок найден в очередном выпуске WSJ’s Pictures of the Day.

[life.sport.darts] Сизалевая мишень – это совсем другое дело!

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

Бумажная мишень – редкая гадость :) Правильные дротики прошивают ее насквозь и со всей дури втыкаются в дверь, на которой висит мишень. Из-за этого игра в дартс в офисе была весьма шумным занятием. Еще хуже то, что бумажная мишень со временем перестала держать дротики – они из нее просто вываливались. Что пагубным образом сказывалось на здоровье хвостовиков и оперения.

Поэтому я дозрел до покупки “правильной”, сизалевой мишени.

Сначала хотел заказывать мишень в Москве. Но в самый последний момент мне сказали, что видели на днях очень толстую мишень в Гомеле. Я пулей смотался – действительно, толстая, сизалевая. Китайский нонейм, но впечатления все равно совсем-совсем другие.

Мишень толщиной около 10 см. По окружности – массивный железный обруч, обратная сторона из ДСП. Весит около 5-6 килограмм. Круглая стальная проволока для разделения секторов. Выглядит все это очень солидно. В качестве неожиданного бонуса – два комплекта весьма неплохих латунных дротиков.

Бросать в нее дротики одно удовольствие. Входят они в мишень с мягким, тихим звуком. Отверстия от входа иглы дротика со временем почти затягиваются – волокна сизаля возвращаются на свои места. В общем, играй в свое удовольствие. Что я и делаю :)

Получается пока не очень. Но, временами, находит озарение, и случается что-то типа вот такого (бросал в центр мишени):

Пока такие достижения происходят эпизодически, но уже неоднократно :)

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

Если есть возможность, лучше купить мишень, у которой разделение на сектора сделаны либо из очень тонкой проволоки (это самые дорогие мишени), либо из трехгранной. Поскольку от круглой стальной проволоки дротики отскакивают на метр-полтора назад.

А теперь хочется послать несколько лучей поноса. Первый в адрес продавцов аксессуаров для дартса в Москве. Такое впечатление, что они проповедуют russian business в чистом виде – все, что не приносит 200% прибыли – нерентабельно. Вот, например, дротики Phil Taylor Golden Hero с 95% содержанием вольфрама. В российском интернет-магазине unicorn.ru они стоят 4790 RUR (~$160). Английский интернет-магазин a180 продает их же за ~$64. С учетом доставки и пр. соотношение будет $70-75 против $160. Не хило, однако. На более дешевые дротики и хвостовики разница в цене, помнится, была еще серьезнее. Поэтому мы с коллегами заказали себе дротики+хвостовики+перья в Англии. Недели через три должны доехать.

Второй луч поноса в адрес продавцов спортивных товаров в Гомеле. Уж если вы продаете дротики и мишени для дартс, то продавайте и хвостовики. Пусть они будут даже в пять-шесть раза дороже, чем в Англии. Но это такая штука, которая нужна здесь и сейчас. Сломался хвостовик – зашел в ближайший магазин и купил за $5-7 новый комплект (при реальной стоимости меньше $1). Поскольку вольфрамовые дротики можно подождать месяц. А вот ожидать столько же комплект пластиковых хвостовиков мне не хочется. Я лучше переплачу, но куплю их в тот же день, когда они мне понадобятся. Так ведь не возят, редиски! Некоторые магазины их вообще не завозят, некоторые “кормят пятницами”: мол, в пятницу должны подвезти, звоните. Бизнесмены, мля.

Ну да ладно. Чтобы разрядить обстановку предлагаю посмотреть внимательно на фотографию. Мишень висит на двери. Если присмотреться, то можно увидеть на филенке двери множество мелких дырочек ;) Таки да, не всегда в мишень попадаешь :) Поэтому мишень нужно вешать туда, где стены не жалко. Либо вешать под мишень специальное защитное кольцо, чтобы дротики втыкались в него, а не в стену/дверь. Хотя есть у нас снайпера, которые промахиваются на 20-30см мимо мишени, так что и защитное кольцо не поможет ;)

среда, 19 мая 2010 г.

[life] В продолжение темы запахов матраца из натурального латекса

В догонку к заметке о сильном запахе, который был у купленного нами нового матраца. Оказалось, что все не так просто. Говорят (здесь и здесь), что у натурального латекса сильный специфический запах, похожий на запах резины (и на запах 88-го клея). Так что, поскольку мы заказывали матрац из натурального латекса, то становится понятно, почему он так вонял.

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

Запаха так же не имеет искусственный латекс.

Напрашивается интересный вывод: если продавцы матраца уверяли, что в нем натуральный латекс и купленный матрац воняет резиной – то латекс действительно натуральный, но дешевый. А вот если не воняет – то тут либо более дорогой натуральный латекс, либо же он вообще искусственный. Ну и всегда есть вероятность, что продавцы/производители тебя накололи :)

[comp] Грядут ли iPad killer-ы от Intel, ASUS и прочих?

На днях стало известно, что Intel собирается в начале июня обнародовать подробную информацию о своем планшетном компьютере.

Работы над своим планшетным компьютером ведутся и в ASUS. Правда, лично меня, не прельщает планшетник за $750. Имхо, планшетный компьютер должен попадать в диапазон от 300 до 500 долларов. За большие деньги разумнее будет взять нетбук или даже ноутбук.

В HP делают свой Slate. Который, возможно, даже будет работать под управлением webOS, попавшей в закрома HP после покупки Palm-а.

Но успех Apple iPad (коего продано уже более миллиона экземпляров) прельщает и других игроков. Вот здесь, например, перечисляется четырнадцать моделей планшетных компьютеров. Которые либо планируется запустить в продажу, либо они уже запущены. Как итальянский Ekoore ET10TA. Однако, по сравнению с iPad-ом Ekoore выглядит громадным чемоданом.

В этот же список я бы добавил еще и Neofonie WePad. Который работает под Google Android (по слухам, за счет эмулятора ARM).

В общем моя мечта идиота валяться на диване с тонким, легким девайсом в руках, обретает все более и более реальные очертания :)

[life] На новом матрасе так сразу и не поспишь ;)

Дошло дело до закупки новой мебели в спальню. Кровать будет ехать еще, как минимум, неделю. А вот матрац вчера уже привезли. Затащили мы его в квартиру не распаковывая и решили сразу же выбросить старый диван, чтобы место освободить. Разобрали, выбросили, место освободили. Распаковали матрац. Выпали в осадок.

Такого сильного запаха 88-го клея я не встречал со времен школы. Полежишь на таком минут пять и начнешь мультики смотреть без телевизора.

Заподозрив неладное прочли инструкцию. Оказалось, что распакованный матрац рекомендуется оставить в хорошо проветриваемом помещении на 24-36 часов для устранения остаточных запахов.

Она как. Программерская привычка не читать документацию негативно сказывается и в обычной жизни. Прочитай мы инструкцию до того, как выбросили старый диван… :)

PS. Матрац производства Жодино. Не самый дешевый, но дешевле конкурентов вроде “Кондора”. Возможно, приличные матрацы от других производителей воняют меньше.

вторник, 18 мая 2010 г.

[blog] Неожиданная настройка размера шрифта в Windows Live Writer

Уже давно пользуюсь Windows Live Writer в качестве основного редактора блога. Хоть в нем и есть несколько неприятных моментов, но зато он орфографию проверяет. Что при моей грамотности далеко не лишнее ;)

Одной из неприятностей было отсутствие в настройках WLW размера шрифта, который используется в редакторе. Шрифт по умолчанию для меня мелковат. Как его размер изменить – фиг знает. Можно для текста назначить шрифт и размер, но тогда это распространится и на опубликованный блог-пост, что не есть правильно.

Сегодня довелось воспользоваться IE8 для веб-серфинга. На какой-то страничке текст был слишком мелким. Я зашел в меню View->Text Size и выбрал другой размер. Потом запустил WLW. И тут опаньки! Шрифт в WLW так же стал больше.

Она как! Тесная интеграция продуктов Microsoft – это не пустой звук :)

[prog] Microsoft завершила свой проект Software Transaction Memory for .NET (STM.NET)

Сегодня прочитал об этом в заметке на InfoQ: Microsoft’s Experiments with Software Transactional Memory Have Ended (сама заметка от 13-го мая), а официальное уведомление об этом в блоге команды STM.NET было написано 12-го мая.

Самое ценное в сообщении на InfoQ, на мой взгляд, – это ссылка на большой рассказ Джо Даффи об истории экспериментов с STM в MS: A (brief) retrospective on transactional memory. Рассказ, действительно большой. Я смог осилить лишь его половину. И то, не многое из написанного я понимал, т.к. от проблем Transaction Memory был очень далек. Но сухой остаток я понял – попытка внедрить STM в уже устоявшуюся технологию, в реальные проекты, в условия огромного количества унаследованного кода, ничего не знающего про какие-то там TM-ы, завершилась неудачно.

Думаю, что интересующимся темой TM и STM прочитать рассказ Джо Даффи нужно обязательно. Отдельный интерес, думаю, это повествование будет представлять для функциональщиков-хаскелистов. Как я понял, в Haskell-евых реализациях STM посредством системы типов жестко ограничивается контекст, в котором транзакции могут применяться. Т.е. изменять значения чего-либо можно, а вот обращаться к коду с побочными эффектами – нет. Что существенно упрощает реализацию STM и избавляет от кучи проблем, с которыми сталкивались Джо Даффи и Ко. Хотя остается вопрос – а нафиг кому-нибудь тогда такой STM ;)

У меня самого приятное впечатление от этой новости осталось. Разговоры о ТМ (как в виде STM, так и Hardware TM) ходят уже давно. Иногда с легким налетом “серебрянной пули”. Но разбираться с этим времени катастрофически не было. Успокаивал себя отговорками: “мол, когда это приблизится к мейнстриму, тогда и посмотрим”. Не зря, выходит, не тратил время на изучение TM. Не дойдет оно до мейнстрима :)

понедельник, 17 мая 2010 г.

[prog] Проект Rubinius достиг версии 1.0

После нескольких лет разработки проект Rubinius достиг таки версии 1.0. Что не может не радовать, хотя с Ruby я в последнее время имею дело все реже и реже ;)

Вкратце: Rubinius – это попытка сделать специализированную виртуальную машину для языка Ruby, а на ее основе – реализацию интерпретатора Ruby на самом Ruby. Виртуальная машина в Rubinius написана на C++ с использованием наработок LLVM. Значительная часть Rubinius написана на Ruby. В Rubinius есть JIT и есть инкрементальный сборщик мусора (чего не было в MRI Ruby).

Ну что тут сказать. Событие, наверное, знаковое. Правда, я не очень понимаю, в чем смысл выпуска версии 1.0. Ведь Ruby 1.8.7 поддерживается не полностью, поддержка Ruby 1.9 планируется только в будущем, платформа Windows не поддерживается, готовые бинарники предоставляются только для MacOSX :(

В общем, мне, как старому Ruby-исту, будет интересно посмотреть, что из этого выйдет дальше. Когда, например, появятся замеры производительности на Language Shootout Game. Хотя есть у меня большие сомнения, что я когда-нибудь буду использовать Rubinius :)

[life.rip] Dio умер

Вчера, 16 майя 2010, умер Ронни Джеймс Дио. Тот самый, который просто Dio.

Блин, вот понимаешь же, что все смертны, и что рано или поздно все умирают. Но когда такое происходит, чувствуешь, как в каких-то уголках твоей души теперь всегда будет пусто и темно.

Покойся с миром, Дио!

воскресенье, 16 мая 2010 г.

[life.photo] Швейцария на фотографиях Дмитрия Кузнецова

В конце недели довелось пообщаться с коллегами о том, как нам реорганизовать рабкрин как можно повысить quality of life в отдельно взятом трудовом коллективе. Много думал. Один из выводов – очень сильно мешает оставшийся в многих из нас совковый менталитет. Посему в очередном выпуске “Знакомства с фотомастером” захотелось опубликовать чего-нибудь чисто европейского. По принципу – хорошо там, где нас нет.

Посему сегодня представляю фотографа Дмитрия Кузнецова (так же рекомендую посетить его сайт). Он снимает природу и пейзажи Швейцарии. Очень хорошо снимает.

Луч света в тёмном царстве

Col Croix

Весеннее пробуждение

Каменные танцы

Весенний ветер в контражуре

Холодные звёзды

Луч света в Окне

Горное озеро

Каменные россыпи неброской расцветки

Закат в голубых тонах

Осень - время пейзажей

Борьба солнца, ветра и гор

Glion - город цветов

Неравновесие

Одноглазый и луна

Межсезонье

Время снега и винограда

Ежик на склоне, ежик в тумане

Смотрящий вдаль

Ещё о реке Времени...

Там, где встречаются холодная зима и жаркое лето

Меланхолия летнего вечера

Луч света в синем царстве

Угощение для мармотов

Швейцария - цивилизованная деревня

Классический вид Маттерхорна, №1