typedef

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

• заботливо раскиданная по коду отладочная печать на терминал и
• пресловутый «долгий пристальный взгляд».

Были еще встроенные в ОС средства протоколирования, но они именно в эти две недели не работали. Удивительное совпадение. Хотя нет, скорее, все дело в кривизне рук. Неважно.

Так вот, отладочная печать прекрасно себя зарекомендовала. Изучение длинных простыней протоколов из строк вроде «(kernDispatchThread) pre-switch ct=174380000 diff=55489 nn=4», «test 4»и даже просто «hahaha!!!» позволяют получить истинное удовольствие от расследования а-ля Хаус. Ну-ка, кто у нас тут вытеснил этот поток? Но вот аномальная последовательность строк найдена, и теперь никуда не денешься — придется разглядывать код, который эту аномалию продемонстрировал.

Казалось бы, самое время сказать: «Трепещите, о презренные байты! Склонитесь перед интеллектом Человека!». Но нет, байты трепетать отказываются, функции плодятся прямо на глазах, макросы-сволочи делают вид, что они функции, или даже того хуже — оперируют именами локальных переменных (ужас-ужас!). Вся эта компания разбегается по двум десяткам файлов, откуда, ехидно посмеиваясь, гадит в глобальные переменные, норовя смешать физическую и виртуальную адресацию.

Вот как-то так я и провел две недели.

И не переставало мне думаться, что текст в качестве носителья исходного кода всем хорош: и редактировать его легко, и всякие diff’ы со слияниями делать, и от платформы не зависит (ну, почти), да и сколько уже проверенных временем алгоритмов на строках есть. Вот только читать чужие исходники неудобно. Хорошая IDE позволяет от вызова функции перейти к ее определению, но серебряной пулей тут и не пахнет. Пока читаешь код вызванной функции, забываешь, что делала вызывающая. И хорошо еще когда в когнитивном процессе участвует две функции. А что если 10? Или 50?

В таком случае поможет только абстрагирование: надо поделить 50 функций на 5 групп, рассмотреть взаимодействие этих групп, а потом — внутри каждой в отдельности. Да, модульное программирование явно неглупые люди придумали. Вот только выделение абстракций — отдельная большая работа. Если мы читаем свой код, то эта работа уже сделана еще при его написании. А вот выделение абстракций на уже существующем коде… Вот тут-то его текстовая природа и подкладывает нам козу: чтобы выделить абстракции, нужно сначала код прочитать и понять.

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

В таком подходе есть ряд очевидных недостатков. Например, нужен гигантский монитор. И отсутствие аллергии на работу мышкой. И ширина строк кода должна быть вменяемой (обратили внимание, какие они короткие в демке?). Но в целом идея здравая: кто сказал, что код — это обязательно плоский текст? (Я не говорил.) При анализе чужого кода такая штука уж точно будет полезной.

P.S. Я давно уже дочитал «Организацию ЭВМ» и с пяток книжек сверху. Просто под линуксом не работает мой антикварный сканер. Постараюсь что-нибудь придумать.

(Еще не оценили)

 Loading ...

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

Но сейчас хочу поделиться впечатлениями от языка m4, который я внезапно выучил. Поскольку я тут понемногу готовлю мегапост (а скорее даже статью) про Autotools, то неизбежно заинтересовался, что это за странный язык m4, на котором написан Autoconf. Оказалось, на сайте GNU есть вполне приличный мануал по этому поводу. Есть даже чуть менее приличный мануал на русском.

История m4 уходит в глубину веков. Сначала появился макроязык GPM, аж в 1965 году. Потом Деннис Ричи, основательно перекроив GPM под нужды реального мира, написал m3. Затем к Ричи присоединился Керниган. Но ведь все знают, что когда Керниган и Ричи собираются вместе, обязательно выходит какая-нибудь нетленка. И вот эти два достойных мужа в едином порыве создают в 1977 году язык m4 (имя расшифровывается по аналогии с i18n и l10n). А уже в 1990 году появилась GNUтая версия. С тех пор мало что изменилось, разве что скорость выполнения немного подросла.

Мое знакомство с макроязыками ограничивалось до сих пор соответствующими средствами MASM на втором курсе института, да препроцессором языка C (который макроязыком может назвать только большой оптимист). К сишному препроцессору у меня была только одна претензия: на нем нельзя написать цикл. Представляете, как мне мало нужно было для счастья? Поэтому осилив за 5 часов чистого времени мануал по m4, я впал в состояние прострации и глубочайшего культурного шока. Язык не был похож ни на что известное мне до этого.

По мере чтения мануала я проходил следующие стадии:

1. Ммм, интересно как!
2. Сложно, блин. Черт, как же этот пример работает?..
3. Определенно, язык писали идиоты для дебилов!
4. Аааа, у меня в мозгу кавычки! Вытащите их!!!
5. Понял! Да тут же все просто!
6. Пожалуй, напишу на m4 генерацию документации для нашего проекта, а потом еще напишу парсер файлов определения локалей, а еще напишу…

На последней стадии нахожусь до сих пор. Рациональных объяснений этому не нахожу. Зато понял, что автор мануала не шутил, написав в самом начале:

Some people find m4 to be fairly addictive. They first use m4 for simple problems, then take bigger and bigger challenges, learning how to write complex sets of m4 macros along the way. Once really addicted, users pursue writing of sophisticated m4 applications even to solve simple problems, devoting more time debugging their m4 scripts than doing real work. Beware that m4 may be dangerous for the health of compulsive programmers.

В чем принципиальное отличие m4 от других языков? Есть языки императивные и декларативные, есть структурные, функциональные и объектно-ориентированные. Все они в конечном итоге нужны для построения программы, которая выполняет определенные действия. Еще есть языки текстовых фильтров: sed, awk и т.п. Они преобразуют входные данные в соответствии с заданными правилами. Язык m4 — порождающий. Программа, написанная на нем, не выполняется — она разворачивается в текст. Поначалу это несколько выносит мозг, но потом начинаешь ценить простоту и красоту подобных конструкций:

define(`quote', `ifelse(`$#', `0', `', ``$*'')')dnl
define(`foreach',
  `_args(`$0', `$#', 3)
   foreach1($1, $2, $3)'
)
define(`arg1', `$1')
define(`foreach1',
  `ifelse(
      quote($3), `',
      `',
      `define(`$1', `arg1($3)')$2`'$0(`$1', `$2', shift(shift(shift($@))))'
    )'
)

Ага, это именно то, о чем вы подумали. Цикл foreach, построенный на примитивах define, ifelse и рекурсии. Почти как в Lisp.

Да, синтаксис не блещет изяществом. Кроме того, программа не делится на строки; конец строки воспринимается буквально и попадает в порожденный текст (кроме определенных случаев). Но зато язык в действительности очень простой. В нем очень мало встроенных средств, дай бог наберется три десятка встроенных макросов. Но, как и любой язык с малым количеством базисных элементов, m4 требует определенной умственной акробатики при написании сложных конструкций. А свободное восприятие открывающих и закрывающих кавычек и нумерованных переменных a la Perl/bash/PHP — вопрос пары дней практики.

m4 на удивление непопулярен. В крупных проектах, за исключением Autoconf, замечен не был (UPD: еще sendmail, спасибо Юрию). Может быть, есть какие-то другие порождающие языки, намного красивее и удобнее? Пока же я вижу, что m4 очень простое и мощное средство, позволяющее сэкономить массу сил (масса сил… хм). Еще одно преимущество — m4 есть везде, где есть Autoconf, а это практически все *nix-системы.

Если интересно, могу развить тему и написать небольшое руководство.

(Еще не оценили)

 Loading ...

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

Подробнее можно посмотреть, например, у Лебедева или погуглить.

Реализовать висячую пунктуацию можно в разных типографских программах, таких как Adobe InDesign. Можно даже сделать в Web-страницах, и даже динамически. Но везде это сопряжено с известными трудностями: нельзя просто сказать «а сделай-ка мне висячую пунктуацию» и беззаботно топтать текст. Наиболее просто вариант предлагает LaTeX: нужно просто вставить следующие настройки в преамбулу:

\usepackage{microtype}
\SetProtrusion
{
encoding = T2A,
family = faq
}
{
« = {1000,     },
» = {    , 1000},
„ = {1000,     },
“ = {    , 1000},
( = {1000,     },
) = {    , 1000},
! = {    , 1000},
? = {    , 1000},
: = {    , 1000},
; = {    , 1000},
. = {    , 1000},
- = {    ,  500},
{,}= {    , 1000}
}
\DeclareMicrotypeSet{t2atext}{encoding=T2A}
\UseMicrotypeSet{t2atext}

Чтобы все это заработало, придется установить последнюю версию пакета microtype. Параметр faq в приведенном выше коде — это семейство шрифтов. Здесь я использую пакет шрифтов pscyr и семейство антиквенных шрифтов (aq).

Идея взята из поста Roman Odaisky на РСДН и ЖЖ-поста ogoldberg.

(6 голосов, средний: 4,33 из 5)

 Loading ...