typedef

Не люблю, когда make выплевывает километры всякого мусора. Зачем мне для каждого файла полный вызов gcc со всеми флагами? Спасибо, я эти флаги сам задавал, знаю что к чему. Зато среди всей этой ерунды пропустить что-то важное — проще простого. Значит, надо как-то выделить важное, а неважное вовсе не показывать. Вот какой я мудрый!

В обычных Makefile’ах все просто:

chset.c: chset.lex
        @echo "  FLEX  $(@:.c=)"
        @$(LEX) --outfile=$@ $<

Символ ‘@’, указанный перед командой, подавляет вывод на stdout, оставляя возможность увидеть ошибки, выводимые в stderr. Строчка-подсказка выводится как раз для того, чтобы увидеть, на каком этапе сборки произошла ошибка, если таковая будет.

При использовании Autotools все становится сложнее, тут уже одними собачками не обойдешься. Интересное решение предлагает Shave: он подменяет вызовы компилятора и libtool на вызовы своих сценариев, которые молча выполняют все что нужно, а выводят только краткую диагностику, как в предыдущем примере. Вот так, например:

[nkalex@stables build]$ make
Making all in src
CC    main.o
CC    msg.o
CC    ctype.o
CC    collate.o
CC    charset.o
CC    ldefpars.o
CC    locopts.o
CC    chset.o
CC    ldeflex.o
LINK  localedef

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

1. Делаем нормально собирающийся проект, использующий Automake и Autoconf.
2. Скачиваем Shave по адресу http://download.lespiau.name/shave.
3. Сценарии shave.in и shave-libtool.in кладем в корневой каталог проекта.
4. Файл shave.m4 копируем в файл acinclude.m4 в корневом каталоге проекта.
5. Вносим изменения в configure.ac:
   1. даже если не используем libtool, добавляем строку

      LT_INIT

   2. добавляем сценарии Shave в AC_CONFIG_FILES, чтобы получилось как-то так:

      AC_CONFIG_FILES([
      shave
      shave-libtool
      Makefile
      src/Makefile
      ])

   3. сразу перед AC_CONFIG_FILES добавляем строчку

      SHAVE_INIT(.,enable)

6. Если не пользовались до этого libtool, в корневом каталоге нужно вызвать

   $ libtoolize
   $ automake --add-missing

7. Profit!

Теперь по умолчанию Shave включен, и вывод при сборке будет кратким. Чтобы все-таки посмотреть подробный вывод, нужно добавить ключ в вызов configure:

$ configure --disable-shave

Грабли, на которые я наступил, заключались в необходимости включить поддержку libtool. Без этого вызов SHAVE_INIT выдает крайне невнятную диагностику в духе syntax error, и пришлось читать shave.m4, чтобы разобраться, в чем, собственно, дело.
(2 голосов, средний: 5,00 из 5)
 Loading ...

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

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

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

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

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

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

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

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

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

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

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

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

 Loading ...

Наверное, искусственному разуму в недрах CiteULike не понравились мои легкомысленные высказывания в его адрес, и он решил мстить… Или просто у разработчиков руки смонтированы в неправильное место? Сейчас разберемся.

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

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

Было особенно обидно, что исчезновение не сопровождалось никакими спецэффектами вроде клубов дыма, воя сирен или хотя бы надписи в профиле «статья такая-то удалена». Я согласен даже на отсутствие объяснения причин (это позволяет предположить, что я чего-то недопонял), но какое-то уведомление должно быть! Нет, раздел «Library» нагло врет: «You haven’t added any articles to your library yet».

Еще одна статья, закинутая в порыве последней надежды, сумела пережить ночь, после чего отправилась вслед за своими почившими товарищами. Черная дыра прям, даже заходить теперь туда страшно. Вдруг и меня засосет? И не останется от меня ничего, только надпись у жены в паспорте: «You haven’t married any man yet». Стивен Кинг отдыхает.

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

Другое преступление, не менее тяжелое, — молчание в экстренной ситуации. Большая удача, что стерлись первые же добавленные статьи. А что если бы я туда напихал 400 статей, а потом некоторые из них взяли бы и исчезли? Я мог не заметить потери важной информации. Замалчивание таких случаев исключает возможность доверия. Подвел сейчас — значит, может подвести и потом.

Нет, я не буду писать разработчикам. К ним применима та же логика. Придется все же браться за дело самому.

(1 голосов, средний: 5,00 из 5)

 Loading ...

Я довольно продолжительное время носился с идеей написать  программу для управления личной библиотекой научных источников (книг, статей, отчетов и т.д.). Мои потребности были нехитрыми, но одних средств файловой системы явно не хватало.

С одной стороны, в иерархической структуре вроде дерева каталогов расположить все мои источники просто невозможно. Например, гипотетическая статья о моделировании протокола TCP относится сразу к нескольким категориям, скажем, «моделирование» и «TCP». Это теговый подход, и возможность хранить такие пометки и осуществлять по ним поиск уже была бы большим подспорьем. Еще лучше, чтобы система категорий/тегов была иерархической, чтобы можно было пометить статью тегами «моделирование%имитационное моделирование» и «передача данных%сетевые протоколы%стек TCP/IP%TCP». В принципе, это реализуемо с помощью ссылок, но, во-первых, это муторно, а во-вторых, у ссылок предостаточно ограничений. В будущем этим должны будут заниматься теговые ФС, но сейчас этот вариант не подходит.

С другой стороны, помимо семантических меток, прикрепленных к источнику, хотелось бы еще хранить и некоторую дополнительную информацию:

• статус (прочитано/срочно прочитать/просмотреть и забыть);
• библиографические данные, желательно с возможностью автоматического экспорта в BibTeX;
• любая другая присоединенная информация, например, конспект, ссылка на сайт издательства или просто какие-то заметки.

К счастью, я не успел начать писать свою программу, когда нашел CiteULike. Это ровно то, о чем я говорил. Даже не буду вдаваться в подробности и описывать фичи. Большая часть из них мне не нужна, а остальное я уже описал выше. Позволю себе только пару оговорок:

• теги таки не иерархические;
• при экспорте в BibTeX добавляются мусорные поля вроде citeulike-article-id и priority, которые, впрочем, несложно вычистить;
• много всякой лишней ерунды, загромождающей интерфейс (явно не обошлось без feature creature);
• существующую локальную библиотеку статей переносить туда придется долго и с трудом; настольная программа могла бы большую часть работы сделать самостоятельно, пройдя по иерархии каталогов и индексируя файлы.

В целом штуковина полезная, но не без недостатков. Будет у меня свободное время — напишу свою правильную версию, с блэкджеком и прочей атрибутикой.

UPD: прежде чем пользоваться CiteULike, ознакомьтесь со следующим постом. Редакция изменила свое мнение.

(1 голосов, средний: 5,00 из 5)

 Loading ...

Возникла у меня такая задача: в действиях одной из целей Makefile выбрать из каталога файлы по маске *.eps и скормить их программе epstopdf. Проблема в том, что epstopdf принимает в командной строке только один файл. Нужен цикл. Я нашел два решения.

Первое — использовать шелловский for:

build:
    for epsfile in `ls *.eps`;\
    do\
        epstopdf $$epsfile;\
    done

Здесь две хитрости: экранирование концов строк (потому что for — фактически одна команда) и использование $$ перед именем переменной (потому что иначе она будет считаться макросом Make).

Второй способ использует возможности самого Make:

%.pdf: %.eps
    epstopdf $?
 
build: $(patsubst %.eps, %.pdf, $(wildcard *.eps))

Такой подход имеет большое преимущество: теперь epstopdf не будет вызываться для EPS-файлов, которые не изменились с момента последнего вызова. К тому же это короче, хотя и, как мне кажется, хуже воспринимается визуально.

К сожалению, все это не удастся сократить до такого:

build: $(wildcard *.eps)
    epstopdf $?

Здесь макрос $? развернется в строку, содержащую имена сразу всех EPS-файлов, что противоречит условию.

(1 голосов, средний: 5,00 из 5)

 Loading ...

Любителям посидеть в рабочее время на башоргах и ЖЖ посвящается. Изначальная идея «пинарика» была проста — наглядно продемонстрировать себе, что жизнь, мол, проходит мимо, пора бы уже что-нибудь существенное сделать. Закрашиваешь, закрашиваешь ячейки, и прям видишь, как на глазах сокращается отведенное тебе время.

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

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

(2 голосов, средний: 5,00 из 5)

 Loading ...