Программирование on Алексей Пахунов

Загрузка кода в чужой процесс на Linux

Sun, 18 Jul 2021 19:56:02 -0700

Оказывается грузить свой код в чужой процесс на Linux ничуть не менее увлекательно, чем на Windows. Я раньше не наведывался в этой темный угол, а вот на днях заглянул. Содержимое угла привычно обнадежило: залатанный древний загрузчик, дохлые мухи, пара растяжек, и грабли кругом. Все как мы любим. Задача была такая. Есть несколько загружаемых с помощью LD_PRELOAD модулей. Модули переопределяют поведение небольшого числа POSIX функций. Требовалось перенести сборку модулей на более свежую версию GCC. Казалось что может быть проще?.. Да, давно уже не ощущал себя насколько наивным, аж ностальгия пробивает. Ниже следует список обнаруженных граблей.

Грустное про обратную совместимость

Sun, 31 Jan 2021 16:14:44 -0800

На Hacker News давече разгорелась очередная дискуссия про трудности перехода со второго Питона на третий. Этот случай, без сомнения, должен войти в учебники как пример того, как делать ни в коем случае не надо. Очень показательно, что официальное руководство по переходу ссылается на две статьи: Питон 3: вопросы и ответы и Почему Питон 3 существует. Обе статьи признают, что переход создал множество проблем, но при этом многословно объясняют почему третий Питон был необходим. Обе статьи были бы гораздо честнее, если бы авторы просто сказали “Простите. Мы ошиблись”.

Мое мнение по этому поводу можно свести к двум тезисам:

Питон 3 не предложил ничего, что оправдало бы обратную несовместимость со вторым Питоном.
100% покрытие кода тестами - необходимое условие для того, чтобы безболезненно переписывать код на Питоне.

Чтобы проиллюстрировать это мнение, я собрал немного статистики по миграции небольшого проекта на 38 тысяч строк. Проект состоит из коллекции тестов, проверяющих поведение операционной системы на целевой платформе, и обвязки, которая позволяет эти тесты запускать на железе. Код проекта покрыт юнит тестами плохо. Юнит тесты занимают всего около двух с половиной тысяч строк. Это имеет рациональное объяснение - покрывать код тестов тестами вроде как особого смысла нет. Но на легкость переписывания кода это, само собой, влияет.

Основной перевод кода с py2 на py2+py3 начался в июле прошлого года и занял ровно две недели, 14 пул-реквестов и примерно чуть более 5% измененного кода. Если включить автоматическое переформатирование кода, то дельта увеличивается до 30% кода. Для сравнения, в два раза более крупное, похожее по характеру изменение в проекте на С++ (150 тысяч строк кода) заняло 4 дня от начала до конца.

Здесь кстати есть еще один характерный момент. Переход на третий Питон - это почти всегда переход на код, совместимый с обоими версиями сразу. Просто потому, что невозможно перевести сколь-нибудь крупный проект за раз. Но, как мы помним, эти версии умышленно несовместимы друг с другом. Так что костыли вроде six просто необходимы.

Какие же изменения были сделаны за эти две недели? Да все же тот стандартный список:

Байты и строки.
Целочисленное деление.
int vs long.
print стал функцией.
Некорректные управляющие последовательности в строках.
Отсутствующий sys.maxint.
Отсутствующий xrange.

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

Обидно, что даже самое полезное новшество - раздельные строки и байты не требует ломать обратную совместимость. Ну совсем. Что нужно было сделать? - дать возможность явно указать, ожидает ли код байты или строки в новом коде, а старый код обложить диагностикой, которая ловит ошибки. Добавить специальный режим проверок во время исполнения, если требуется. Что сделали разработчики Питона? Переименовали str в bytes, а unicode в str. Чем сломали ожидания огромного массива существующего кода.

Однако авторам этого показалось мало и они добавили еще кучу тривиальных, и совсем ненужных несовместимостей. К примеру убрали iteritems() или убрали оператор print. Что мешало оставить первый и позволить второму быть и оператором и функцией - это выше моего понимания.

Но если вы думаете, что за две недели эпопея закончилась, вы сильно ошибаетесь. Это был только первый тикет в баг-трекере. Спустя полгода их заведено уже 15. Заслано 33 пул-реквеста. Крайний и видимо не последний баг, вызванный переходом, был найден неделю назад. Как минимум три тикета еще предстоит исправить. Вот такие дела.

Фонтанный код

Sun, 06 Sep 2020 15:23:17 -0700

Недавно совершенно случайно узнал про фонтанный код и поразился насколько элегантно работает этот алгоритм. Этот код позволяет надежно передавать данные по каналу с потерями без обратной связи и с минимальными накладными расходами. Более того передатчик и приемник не обязаны синхронизировать начало и конец передачи данных. Фонтанный код позволяет передатчику генерировать бесконечный поток пакетов, кодирующих исходное сообщение, а приемник может начать слушать в любой момент. Все что требуется - это принять минимально необходимое для декодирования количество пакетов. Raptor code, - одна из наиболее практичных реализаций, требует всего лишь передать всего 0.2% дополнительных пакетов для успешного декодирования с вероятностью 0.999999. При этом вероятность успешного декодирования стремительно приближается к единице с каждым дополнительным пакетом.

Зачем это нужно когда уже есть протоколы надежной передачи по двухстороннему каналу, скажем тот же TCP/IP? Оказывается существует ситуации, когда организация обратного канала связи требует изобретения машины времени. Когда нам нужно восстановить данные со сбойного сектора на жестком диске, мы не можем послать “запрос на повторную передачу” в прошлое - в то время, когда сектор нормально читался. Все что мы можем сделать - это записать избыточные данные в другой сектор или на другой диск заранее.

Контрольная сумма UDP

Sat, 11 Apr 2020 21:16:34 -0700

Большинство проектов, над которыми я когда-либо работал, так или иначе не работают без передачи данных по сети. Последним проектом не выходящим за рамки одного компьютера была поддержка Wow64 в ядре Windows. Тем не менее возится с кодом, непосредственно обрабатывающим IP пакеты мне довелось всего пару раз. Оба раза я столкнулся с одной и той же ошибкой вычисления контрольных сумм в IP стеке. В одном случае, сетевая карта ошибочно помечала хорошие пакеты как испорченные. В другом - две библиотеки, написанные разными людьми, неверно вычисляли контрольную сумму некоторых пакетов. Одна из библиотек широко использовалась в “боевых” условиях. Немного удивительно, что ошибка оставалась незамеченной так долго.

Корнями этот баг уходит в 1980-й год, когда был опубликована спецификация протокола UDP. Чтобы разобраться в чем заключается ошибка, нужно сначала разобраться как работают контрольные суммы в IP стеке. В IPv4 пакете есть две контрольные суммы: контрольная сумма IPv4 заголовка и контрольная сумма протокола следующего уровня (UDP, TCP, ICMP, и т.п.). Контрольная сумма IPv4 заголовка защищает только IPv4 заголовок. Контрольная сумма протокола следующего уровня защищает тело пакета и некоторые поля из заголовка.

Когда 1.0 = 0.0

Mon, 16 Dec 2019 22:49:36 -0800

Столкнулся недавно с новой для себя областью - ловлей багов в компиляторе. Ловить баг в процессоре мне уже доводилось, а вот с компиляторами до недавнего времени как-то везло.

Началось все очень прозаично. В нашем репозитории есть своя реализация умного указателя. Ну, вы знаете, как это бывает. Обычная история на самом деле… Этот класс был написан в древние времена, тогда и С++03 еще на свете не было. С тех пор уже и С++17 появился и С++20 не за горами, но класс по-прежнему активно используется. Мы его давно хотели заменить на что-нибудь более стандартное и современное, но все руки не доходили. “Работает - не трожь”.

В один прекрасный день в этом классе нашлось неопределенное поведение, что стало последней каплей, ~~переломившей верблюду соломинку~~. Указатель был переписан на корню и стал тонкой оберткой вокруг std::shared_ptr<>. На следующий же день сломался один неприметный юнит тест на одной из платформ. Причем на первый взгляд никакого отношения к переписанному указателю этот тест не имел. Но от фактов было трудно отвертеться. С новым указателем тест падал, а со старым - нет.

В одном бите от ядерной катастрофы

Thu, 21 Mar 2019 22:05:47 -0700

А хотите я вам страшилку на ночь расскажу? На данный момент большинство всех важных решений принимают и выполняют компьютеры. Совершенно автоматически. Не верите? Смотрите, подъезжаете вы к перекрестку на котором в этот момент не кстати загорается красный свет. Вы плавно нажимаете на тормоз и привычно останавливаете машину. Знакомая картина? На самом деле все происходит совсем не так.

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

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

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

Чем сложнее система, тем больше вероятность того, что человек не приминает никаких решений напрямую. В самолетах концепция fly-by-wire давно победила ручное управление. Ракеты изначально летают в полностью автоматическом режиме. Финансовые системы практически полностью существуют в виртуальном мире. Решения о покупке и продаже принимаются автоматически. Медицинская техника? Это только кажется, что человек нажимает кнопку и что-то при этом решает. На самом дале нажатие кнопки всего лишь запускает глючный код, который определяет дозу рентгена, которую получит пациент. Атомные станции? Ядерный арсенал? Управляется опытными операторами? Не смешите мои тапочки. Опытные операторы только кнопки нажимают. Компьютеры принимают все решения.

Как компьютер принимает решение? А вот так:

if (speed < desired_speed)
{
    accelerate();
}

Для процессора, который выполняет этот код, принятие решение выглядит как одна-единственная инструкция условного перехода. Если условие истинно, то перейти по этому адресу, я если нет - то по другому. Один бит.

Достаточно ошибится в одном бите, чтобы выполнить действие, прямо противоположное действие задуманному. Разница между “отдать штурвал от себя” и “потянуть штурвал на себя” - один бит.

Страшно?

Волшебство Питона

Tue, 20 Nov 2018 22:36:35 -0800

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

Непонятно как все это счастье держать в одной куче. Неужели все живут за счет 100% покрытия тестами? Не верю. Или все на PyCharm сидят?

Расскажу про очередной прикол Питона. Итак есть простой код:

def init(factories):
    """Convert a list of factorie into a list of objects.""" 
    return [factory() for factory in factories]

def cleanup(objects):
    """Clean up objects in the reversed order of their creation."""
    for obj in reversed(objects):
        obj.cleanup()

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

from itertools import permutations
import mock

def test_cleanup():
    """Verify cleanup() order."""
    # Try all permitations of initialization order. 
    for init_order in permutations(range(3)):
        cleanup_order = []

        def factory(index):
            def cleanup():
                """Record the clean up order."""
                cleanup_order.append(index)

            def create():
                """Return a mock implementing cleanup()."""
                obj = mock.Mock
                obj.cleanup = mock.Mock(side_effect=cleanup)
                return obj

            return create

        # Create objects in the desired order.
        objects = init([factory(index) for index in init_order])

        cleanup(objects)

        # Verify that the object were cleaned up in the reveresed
        # order of their creation.
        assert cleanup_order == list(reversed(init_order))

Разберу логику по кускам. Тест перебирает все возможные кобинации порядка создания объектов:

for init_order in permutations(range(3)):

Декоратор factory() возвращает фабрику create(), которая в свою учередь создает объект с методом cleanup(). Для создания объекта на коленке используется Mock. Релизация cleanup() запоминает порядок вызова в cleanup_order.

init() создает объекты в заданном порядке, cleanup() - чистит:

objects = init([factory(index) for index in init_order])

cleanup(objects)

Наконец, в самом конце мы проверяем, что порядок очистки противоположен порядку создания:

assert cleanup_order == list(reversed(init_order))

Все просто, не так ли? Запускаем тест и получаем облом:

>               assert cleanup_order == list(reversed(init_order))
E     assert [2, 2, 2] == [2, 1, 0]
E       At index 1 diff: 2 != 1
E       Use -v to get the full diff


rabbit_test.py:41: AssertionError

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

Ну-ка, еще разок

Thu, 08 Nov 2018 21:57:46 -0800

Питоний пакет retrying - универсальная заплатка для кода, который может поломаться из-за внешних причин. Например, socket.connect() может закончится ошибкой из-за непредвиденной ситуации в сети. Заворачиваем вызов в @retry и бац! Все работает.

@retry
def create_connection(address):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    return socket.connect(address)

Однако бездумное применение @retry, как нетрудно догадаться, приводит проблемам. Самый известный пример - вложенные @retry. @retry(stop_max_attempt_number=3) вложенный в другой @retry(stop_max_attempt_number=3) дает 9 повторов. Три уровня вложенности - 27 повторов.

Один раз использование @retry привело к тому, что IT заблокировало мою учетную запись. Банальная история - был некий скрипт, который при запуске спрашивал логин и пароль для авторизации. В один прекрасный день некто (не будем показывать пальцем, хотя это был Слонёнок) усовершенствовал скрип, завернув сетевой вызов в @retry. Отличная идея, за исключением того, что ошибка авторизации приводила к повторному запросу с тем же неправильным именем и паролем. После определенного числа попыток контроллер домена решил, что кто-то пытается подобрать пароль к учетной записи и заблокировал её.

Мораль истории - знайте свои ошибки в лицо и используйте параметр retry_on_exception.

Текстовые данные в юнит тестах

Sun, 05 Aug 2018 18:44:25 -0700

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

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

Как сделать код еще более понятным? К примеру, возьмем таблицу из предыдущего поста. Что с ней не так?

struct {
    int x;
    int y;
    std::string that_thing;
    std::string this_key;
    bool result;
} const cases[] = {
    {0, 0, "thing1", "key2", false},
    {0, 1, "thing1", "key2", false},
    {0, 2, "thing1", "key2", false},
    {0, 3, "thing1", "key1", true },
    {1, 0, "thing2", "key1", false},
    {1, 1, "thing2", "",     false},
    {1, 2, "thing2", "",     true },
    {2, 0, "",       "",     false},
    {2, 1, "",       "",     true },
    {2, 2, "",       "",     false},
};

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

Табличные юнит тесты

Wed, 01 Aug 2018 19:52:48 -0700

Расскажу об одной технике, которая, как мне кажется, позволяет писать более понятные и читаемые юнит тесты. Начну немного издалека. Допустим мы хотим убедится, что определенный кусок кода работает правильно. Если бы мы имели дело с игрушечным примером, то это наш тест мог бы Примерно вот так:

bool foobar(int x, int y)
{
    return (x + y) > 0 && ((x + y) % 3) == 0;
}

ASSERT_FALSE(foobar(0, 0));
ASSERT_FALSE(foobar(0, 1));
ASSERT_FALSE(foobar(0, 2));
ASSERT_TRUE (foobar(0, 3));
ASSERT_FALSE(foobar(1, 0));
ASSERT_FALSE(foobar(1, 1));
ASSERT_TRUE (foobar(1, 2));
ASSERT_FALSE(foobar(2, 0));
ASSERT_TRUE (foobar(2, 1));
ASSERT_FALSE(foobar(2, 2));
...

Такой тест достаточно легко читать. Достаточно понять конструкцию ASSERT_XXX(foobar(...)) после чего глаза сами фокусируются на входных значениях, автоматически отсеивая ненужный синтаксический мусор.

Однако, если взять реальный код, то подобный пример превратиться в гораздо менее удобочитаемого монстра:

std::unique_ptr<Foobar> rabbit =
    create_foobar_with_abc(parent,
        some_context,
        more_stuff + that + is_required + to_create_foobar,
        a,
        b,
        mock_c(),
        logger);

ASSERT_TRUE(
    rabbit->connect(
        this_thing,
        that_key,
        did_you_think_we_are_done_here ? no : hell_no));

ASSERT_TRUE(rabbit->wait_for_accept(timeout));

ASSERT_FALSE(rabbit->foobar(0, 0));

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

Как я провел прошлую пятницу

Sat, 07 Jul 2018 17:09:38 -0700

Расскажу как я провел прошлую пятницу. Провел я её пытаясь понять, почему простой как доска тест-кейс не работает.

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

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

К пятнице я добрался до момента, когда сценарий тест-кейса уже написан, но еще не работает. Сценарий вылетал по таймауту ожидая наступления одного из событий. При этом телеметрия четко показывала, что событие наступило и у теста был вагон времени, чтобы это заметить. Интересно, что точно такой же код, отслеживающий другую телеметрию работал как часы. Хм.

Skyrora

Tue, 22 May 2018 22:36:33 -0700

Ха. Прислал письмо рекрутер из британско-украинского ракетного стартапа Skyrora. Насколько я понимаю - деньги британские, а спецы южмашевские. Судя по сайту - вполне себе приличный ракетный стартап. Первая суборбитальная версия ракеты в разработке; вторая, орбитальная, в планах. Больше про компанию ничего не знаю, но все равно приятно, что в Украине есть такие стартапы. Было бы здорово, если бы у них получилось завоевать свое место под солнцем.

Рекрутер попросил пропиарить позицию Software Architect/C++ Developer, который будет заниматься системой управления ракеты-носителя. Позиция открыта в Днепре. Есть желающие дерзнуть? :-)

SubGit

Tue, 15 May 2018 22:46:12 -0700

Получил непрошенное подтверждение тезиса про вред реализации веток через операцию копирования в Subversion. Вторую неделю бодаюсь с импортом SVN в Git с помощью SubGit. SubGit довольно неплохо с этим справляется. Особенно хорошо то, что он может постоянно синхронизировать SVN и Git, делая переход с одного на другой плавным и безболезненным. Он даже со всякими противоестественными манипуляциями со структурой веток в SVN репозитории справляется.

Но и на старуху найдется свой Раскольников. При создании одного из зеркал был указан не корневой адрес SVN, а https://foobar/svn/xyz. Зеркало прекрасно жило своей зеркальной жизню, пока не было обнаружено, что часть истории отсутствует. Для её восстановления родился план - заново импортировать все из корня (https://foobar/svn), а затем, уже на стороне Git, - сшить старую и новую историю вместе.

Отличный был план. И, что самое главное, и SubGit и Git все эти фокусы позволяют и поддерживают. За одним маленьким исключением… Как выяснилось, менять адрес с https://foobar/svn/xyz на https://foobar/svn категорически не получается. Вернее получается, но результат выходит как-то не очень. SubGit пытается импортировать историю (и находит все правильные коммиты, что характерно), но затем пытается заново засунуть их обратно в SVN. SVN кричит “что вы в меня это пихаете?” SubGit ужасно смущается, бормочет многоэтажные стек-трейсы в лог и заодно сносит master к праотцам.

Эх… Буду теперь с git replace возится…

Ошибки дизайна

Sun, 22 Apr 2018 18:47:23 -0700

А давайте про ошибки в дизайне поговорим. Тем более, что задним умом мы тут самые умные… Я в последнее время много играюсь с миграцией Subversion на Git и многие их косяки так в глаза и лезут.

Начнем с Subversion. Во времена массового перехода с CVS на Subversion, одним из главных аргументов “за” была поддержка директорий и операций копирования/перемещения в Subversion. Было видно, что разработчикам поддержка копирования очень пришлась по душе. Насколько пришлась, что и ветки в Subversion создаются через копирование, а структура репозитория по-умолчанию - это знаменитые три директории trunk, branches и tags.

Я догадываюсь как принималось это решение. Что-нибудь в духе “прикиньте, одна операция поддерживает и копирование, и ветки, и метки. Не нужно писать новый код для отдельного пространства имен веток. У нас уже есть этот код”. Но если пересчитать набитые шишки, то становится понятно, что решение было так себе… не очень… совсем хреновое решение это было, как оказалось.

Почему? А вот почему. Корректная работа с путями файлов, не смотря на кажущуюся простоту, - это постоянный источник багов. Казалось бы, что тут может быть сложного, но в результате получается как с указателями - нет, нет, а обязательно один потеряется. А Subversion заставляет с путями работать.

Скажем количество шагов в пути для trunk и branches/foobar разная. Это значит, что любой скрипт должен это корректно обработать. Не существует способа найти все ветки в произвольном репозитории. Операция копирования не обязательно означает создание ветки - а значит без какого-нибудь соглашения не обойтись. Ну а мы знаем насколько хорошо люди выдумывают совместимые стандарты.

Использование копирования для создания веток автоматически означает, что Subversion создать рабочую копию из людой директории в репозитории. Отличная оптимизация, когда нужно выкачать один файл, но, опять же, это означает, что скрипты не могут делать массы полезных предположений о структуре репозитория. Практически сразу же вся эта гибкость запрещается и создается wiki страничка “чекаут делается так, а ветки называются только так, а всех кто делает не так - прибью нафиг”.

Теперь давайте про Git. Линус выбрал другую крайность. Вместо того, чтобы оставить поддержку копирования для файлов, но сделать нормальные ветки, он сделал нормальные ветки, но выкорчевал поддержку операций копирования. За одно под раздачу попали пустые директории.

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

Что же тут плохого, спросите вы? В данном случае проблема упирается в психологию людей. Да, соглашается подавляющее большинство разработчиков, - поддержка копирования и пустые директории в принципе не нужны. Но! Мы к ним так привыкли. Мы хотим линейную историю, явную поддержку копирования и пустые директории. Нам без них не уютно.

Вы будете смеяться, но это реальная проблема. Особенно, когда мигрируешь с Subversion на Git.

Но ведь оно раньше работало. Я мог сделать так и так.

Полностью согласен, но, на кой, простите, вам это нужно делать именно таким способом?

Но ведь это единственный правильный способ. Мы так всегда делали…

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

Уроки разработки полетного софта

Sat, 17 Feb 2018 21:00:54 -0800

Часто, когда речь заходит про космический софт, можно слышать “ну уж там-то код компилируется со всеми предупреждениями”, или “ну уж там-то наверняка запускается статический анализатор кода и все ошибки исправляются”, или “ну уж там то тесты покрывают код на 100%”. Как вы скорее всего уже догадались рая нет. Вернее, рай в планах был, но из-за превышения сметы успели достроить только ад. К счастью, костры успели развести только под половиной котлов, поскольку часть дров заменили бетонными шпалами, а расположение котлов забыли задокументировать.

Сайт NASA Lessons Learned полон таких историй. Сегодня мы пройдемся по результатам исследования Flight Software Engineering Lessons за авторством Ronald Kirk Kandt опубликованное на конференции AMCIS 2009 (Americas Conference on Information Systems). Автор исследования просуммировал результаты других работ, посвященных трудностям процесса разработки программного обеспечения, а также результаты расследования аварий реальных космических аппаратов.

Потеря связи с зондом Deep Impact в 2013 году

Wed, 14 Feb 2018 20:15:47 -0800

12 января 2005 года с мыса Канаверал стартовал зонд Deep Impact, созданный для изучение внутреннего состава кометы 9P/Темпеля. Зонд достиг кометы в июле 2005 года, после чего разделился на импактор и пролетную часть. 4 июля 2005 года 370 килограммовый импактор успешно столкнулся с ядром кометы на скорости около 10.3 км/с, выбросив в космос здоровенное облако пыли:

Согласно измерениям, проведенным космическим аппаратом Stardust в 2011 году, диаметр кратера, образовавшегося в результате столкновения, составил около 150 метров.

По завершению основной миссии, NASA направило зонд Deep Impact к комете 103P/Хартли в рамках расширенной миссии “EPOXI”. Пролет этой кометы состоялся 4 ноября 2010 года:

В конце 2011 года, аппарат был отправлен на перехват астероида (163249) 2002 GT пролет которого должен был состоятся в 2020 году. Однако в августе 2013 года контакт с аппаратом был потерян:

3 сентября 2013:
… Связь с аппаратом утеряна между 11 и 14 августа (связь с аппаратом поддерживается раз в неделю). Последний сеанс связи был проведен 8 августа. Проведенное расследование позволило установить причину неполадки. Дальнейшие усилия направлены на определение лучшего способа восстановить связь с аппаратом.

23 сентября 2013:
… все попытки передачи низкоуровневых аппаратных команд не увенчались успехом. На этом все возможные сценарии восстановления связи с аппаратом были исчерпаны. Мы рекомендовали NASA объявить аппарат утерянным. NASA официально заявило об утере аппарата в четверг 19 сентября.

Свежая презентация про полетный софт в SpaceX

Mon, 11 Dec 2017 19:22:00 -0800

Свежая презентация про полетный софт в SpaceX в целом, и про миграцию с make на Bazel в частности:

Основные моменты:

Два основных репозитория: один содержит полетный код, второй - код симуляции. Более миллиона строк C++ в каждом. Немного Python.
Используется своя версия Linux, поддержкой которой занимается отдельная команда.
C++ код собирается под несколько разных процессорных архитектур.
Полетный код для Falcon и Dragon собирается из одного репозитория.
“Test like you fly” - код тестируется в тех же самых условиях, что наблюдаются в полете. Софт и железо тестируются как единая интегрированная система.
Система непрерывной интеграции выполняет более 8 тысяч заданий в день.

Вторая половина презентации посвящена миграции с древней системы сборки на основе make на более современный Bazel. Эта часть будет интересна в основном тем, кто интересуется системами сборки кода.

Не число

Sun, 08 Oct 2017 19:23:03 -0700

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

Сегодня я хотел бы поговорить о такой особенности чисел с плавающей запятой, как “не число”. Он же NaN (not a number). NaN - это специальное значение, которое возвращается как результат некоторых операций - например результат деления ноля на ноль.

Непредсказуемость динамической памяти

Sun, 30 Jul 2017 13:03:30 -0700

Написал небольшую программу, демонстрирующую непредсказуемую стоимость выделения динамической памяти. Программа выделяет и освобождает N блоков одного размена и измеряет среднее время, затраченное на один вызов malloc() и один вызов free():

rr

Sun, 07 May 2017 18:56:38 -0700

Недавно наткнулся на rr (Record and Replay Framework) от Mozilla и я вам скажу, что это просто незаменимый инструмент для ловли неуловимых багов в отладчике. Это не первый и не единственный инструмент подобного плана. Соответствующая страница проекта описывает десятка три альтернатив. Из этого списка мне раньше доводилось работать только с iDNA, который впоследствии стал Time Travel Tracing (TTT). TTT мог записать процесс выполнения программы с точностью до инструкции и воспроизвести его в точности в прямом и обратном направлении. TTT был просто незаменим для ловли сложных багов и его главным недостатком было то, что TTT был внутренним инструментом, который Microsoft так и не выпустила как отдельный продукт.

rr тоже может записать выполнение процесса с точностью до инструкции и проиграть его назад и вперед. rr требует современного процессора, причем обязательно Intel, так как использует performance counters которые не реализованы в других процессорах. ARM и другие архитектуры тоже не поддерживаются. В обмен на это, rr практически не замедляет записываемый процесс. Скорость выполнения падает в 1.2 раза - сущие пустяки. Размер генерируемой записи тоже крайне скромен - в районе гигабайта за 10-15 минут выполнения “вычислительного” кода. Практически бесплатно. В пересчете на количество выполненных инструкций получается что-то вроде 0.1 бита на выполненную инструкцию.

Что интересно, rr базируется на очень простой идее: большая часть кода выполняется всегда одинаково. Если записать все случайные события (ввод/вывод, RDTSC, системный вызовы) и начальные условия (содержимое памяти), то процесс выполнения становится полностью детерминированным. Более детально можно почитать здесь: http://rr-project.org/rr.html.

Процесс отладки с помощью rr выглядит так:

Записываем процесс: rr record <program>
Запускаем запись в отладчике: rr replay
Проматываем до конца и смотрим чем вызван segfault.
Ставим watchpoint на память из которой читается плохой указатель.
Выполняем программу назад пока не сработает watchpoint.
Смотрим почему в память пишется плохой указатель и повторяем шаги 4-6 до победного конца.

Дополнительный бонус заключается в том, что все адреса при повторном воспроизведении сохраняются. Если нужная переменная находится по адресу 0x123fooba, то она там будет всегда. Отпадает необходимость выяснять где в памяти находится интересный кусок каждый раз при запуске отладчика. rr также может помечать вывод в stdout метками для быстрой перемотки в нужное место. Это помогает сопоставить код с интересными местами в лог файлах.

Само собой, у rr есть куча других ограничений. К примеру, он не работает под Windows, не поддерживаются все системные вызовы, не поддерживается циклическая запись (последние несколько минут выполнения процесса), поддерживается только одно процессорное ядро, и т.д. Тем не менее, если вы столкнулись с “невозможным” багом в Linux, rr - один из наиболее вероятных способов докопаться до источника проблемы.

Идеальный инструмент для просмотра кода

Sun, 27 Nov 2016 17:54:01 -0800

Здравствуйте. Меня зовут Алексей и я каждое утро просматриваю чужой код…

За последнее время пришел к выводу, что ни один из известных мне инструментов для просмотра кода (в смысле “code review”) решительно не годится для выполнения своей главной функции.

Налоговая декларация

Sat, 19 Mar 2016 22:41:18 -0700

В Штатах, и особенно в южной Калифорнии, о наступлении весны напоминает процесс заполнения налоговой декларации. Сначала, еще в январе, начинают приходить имейлы: “Ваша форма W-2/1098/1099-B/DIV/MISC будет готова к концу января. Потерпите”. Ближе к февралю начитают приходить обещанные налоговые формы. Потом активизируется TurboTax: “Спешите отправить Tax Return сейчас, пока мы еще добрые и даем скидку”. К апрелю активность TurboTax достигает максимума: “Скидку вы, конечно, профукали, но можно подать на продление и отложить час расплаты на полгода.”

Писать на фортране можно на любом языке

Wed, 29 Jan 2014 22:37:41 -0700

Господа, какой-же все-таки махровый &^%! Вот посмотрите сюда. Это код библиотеки OpenLIBM, которая, цитирую:

OpenLIBM is an effort to have a high quality standalone LIBM library.

Будни Chromium разработчика

Tue, 05 Feb 2013 01:12:53 -0700

Хотите знать как выглядит процесс коммита в Chromium? Есть у меня такие истории. Для затравки уточню терминологию. Chromium - это, фактически, open source версия Chrome. Если взять Chromium и добавить немного закрытого кода и логотип Google, то получится Chrome. А вот если добавить немного закрытого кода и логотип Яндекс, то получится Яндекс.Браузер. Исходники Chrome Remote Desktop, над которым работаю я с коллегами, тоже собираются из репозитория Chromium.

Так вот, про процесс коммита.

Трассировка описателей (AKA handle tracing)

Tue, 04 Dec 2012 23:23:13 -0800

Начиная с Windows XP в ядро встроена поддержка трассировки описателей ядра (AKA handle tracing). Включение трассировки имеет двойной эффект. Во-первых, все операции с ядерными описателями сохраняются в циклический буфер (откуда их можно потом прочитать). Во-вторых, при любой попытке использовать несуществующий описатель генерируется исключение STATUS_INVALID_HANDLE. Фактически, проверка корректности операций с описателями в Application Verifier - это тонкая обертка вокруг функций трассировки, предоставляемых ядром. Расширение отладчика !htrace - аналогично.