понедельник, июня 15, 2015

Настройка планшета Wacom Intuos Pro под Debian/Ubuntu и KDE 4/5

Чтобы не забыть, запишу куда-нибудь.
У wacom intuos pro есть четыре лампочки вокруг express ring. Подвиндами они показывают активность одного из четырёх режимов, в которых может работать express ring — это просто четыре варианта настроек. Переключаются режимы кнопкой в центре кольца.
Под линуксами планшет работает без проблем сразу после включения. Только express keys по дефолту ни на что не настроены, а express ring работает просто скроллом. Из четырёх лампочек горит всегда первая.
Express keys и express ring легко настраиваются из systemsettings в кедах (для гнома тоже есть конфигурялка, но специально на неё не смотрел). Но про переключение режимов и лампочек эта конфигурялка не знает. Точнее, у неё есть понятие профиля настроек, и даже можно настроить хоткей на их переключение, но с лампочками на планшете они не связаны.
Ядерный драйвер wacom умеет управлять этими лампочками. Для этого надо записать число от 0 до 3 в файлик /sys/bus/usb/devices/*/*/wacom_led/status_led0_select. Только вот этот файлик по дефолту доступен на запись только руту.
Отсюда возник вот такой набор костылей: https://github.com/portnov/wacom-intuos-pro-scripts.
Правила udev 99-local.rules запускают скрипт wacom-setup.sh, который запускает chmod, чтобы разрешить простым юзерам запись в тот файлик в /sys.
К кнопке посередине кольца средствами кед (или другими) привязывается какое-нибудь редкоиспользуемое сочетание клавиш. На это же сочетание средствами кед (или другими) вешается скрипт wacom-switch-mode.sh, который прибавляет единичку к значению в файлике (переключает лампочку) и вызывает скрипт wacom-ring-mode.sh, который вызывает xsetwacom, чтобы переназначить функции express ring.
В принципе, переключать настройки можно не через xsetwacom, а дёргая кде-шную конфигурялку через dbus, чтобы она переключала профили. Всё это красиво работает под 4ми кедами.
Ещё одна засада: в текущем состоянии в KDE5 конфигурялка вакомов не работает от слова совсем. Она вроде как портирована на KF5, но этот порт в дистрибутивы не включён. И в дебианах/убунтах он просто так не соберётся, потому что требует libxcb-xinput, которого под дебианами/убунтами нет, т.к. он самими разработчиками libxcb считается unstable и по дефолту с xcb не собирается. Если кому нечего делать, может попробовать собрать libxcb-xinput под дебиан или убунту.
Ситуация несколько облегчается тем фактом, что в kubuntu 15.04 похоже поставляется не чистокровные KDE5, а помесь из компонентов KDE 4 и 5. В частности, можно запустить конфигурялку вакомов от четвёртых кед: kcmshell4 kcm_wacomtablet. Но, модуль кедов, который собственно управляет планшетами, он тоже от четвёртой версии, и потому в пятой по дефолту не запускается. Чтобы настройки работали и применялись, надо в автозапуск кедов добавить запуск этого модуля командой qdbus org.kde.Wacom /kded loadModule wacomtablet. Только из systemsettings в пятых кедах сейчас есть баг, из-за которого скрипт в автозапуск добавить можно, но работать он не будет. Так что надо написать *.desktop-файл, который будет запускать скрипт, который будет запускать qdbus, и положить этот desktop-файл в ~/.config/autostart.

вторник, ноября 20, 2012

LiveMath IV



Дошли руки собрать очередную версию LiveMath.

LiveMath — это LiveDVD, содержащий большой набор свободного математического ПО. Предполагается для использования в основном в демонстрационных целях, но может также использоваться для постоянной работы.

Картинка для привлечения внимания:

(на картинке слева вверху FriCAS считает интегралы в специальных функциях, а справа R выводит графики по данным, включенным в поставку для примера).

В этот раз LiveMath основан на Ubuntu 12.10 (Quantal), плюс некоторое количество дополнительного софта. LiveMath IV содержит (среди прочего):

Системы компьютерной алгебры:

  • Maxima 5.27 (http://maxima.sourceforge.net) - полнофункциональная система аналитических вычислений.
  • Fricas 1.1.8 (http://fricas.sourceforge.net) и OpenAxiom 1.4.1 (http://open-axiom.org)  - обе актуальные версии мощной системы компьютерной алгебры Axiom.
  • YaCas 1.3.2 (http://yacas.sourceforge.net) - еще одна система компьютерной алгебры.
  • PARI/GP 2.5.1 (http://pari.math.u-bordeaux.fr/) - широко используемая компьютерно-алгебраическая система, разработанная для быстрых вычислений в теории чисел (факторизации, алгебраическая теория чисел, эллиптические кривые...).
  • GAP 4r4p12 (http://www.gap-system.org/) - свободно распространяемый, открытый и расширяемый программный комплекс для применения в области вычислительной дискретной математики, в частности, теории групп.
  • Mathomatic 15.8.2  (http://www.mathomatic.org/) - переносимая, универсальная программа, которая может решать, упрощать, группировать, дифференцировать, интегрировать и сравнивать алгебраические выражения.

Системы автоматизации доказательств:

  • ACL2 4.3 (http://www.cs.utexas.edu/users/moore/acl2/) - язык программирования для моделирования компьютерных систем и средство, помогающее доказывать свойства этих моделей.
  • Coq 8.3.pl4 (http://coq.inria.fr/) - система автоматизированного построения доказательств, с помощью которой, кроме всего прочего, была решена проблема четырех красок.
  • Agda2 2.3.0 (http://wiki.portal.chalmers.se/agda/pmwiki.php) - язык программирования с зависимыми типами и система автоматизации доказательств.
  •  Prover9/Mace4, Otter и пр.

Системы численных вычислений:

  • SciLab 5.3.3  (http://www.scilab.org/) - пакет научных программ для численных вычислений, предоставляющий мощное открытое окружение для инженерных и научных расчетов.
  • GNU Octave 3.6.2 (http://www.octave.org/) - язык высокого уровня, предназначенный для выполнения математических вычислений;
  • FreeMat 4.0 (http://freemat.sourceforge.net/) - свободная среда для быстрой разработки, научного прототипирования и обработки данных, имеет интерфейс и синтаксис языка, подобные MatLab.
  • Yorick 2.2.02 (http://yorick.sourceforge.net/) -специализированный С-подобный язык для создания симуляторов с упором на скорость вычислений.
  •  Dynare 4.3.0 (http://www.dynare.org/).

Образовательные программы:

  • Kig 4.9.2 (http://edu.kde.org/kig/), Geogebra 4.0.34.0 (http://geogebra.org), DrGeo 1.1.0  — интерактивная геометрия.
  • KAlgebra 4.9.2
  • KMPlot 4.9.2 — средство для построения графиков.

Обработка и визуализация данных:

  • Gnuplot 4.6.0
  • Mayavi2 4.1.0 (http://code.enthought.com/projects/mayavi/#Mayavi2) - открытый пакет научной 2D и 3D визуализации данных.
  • OpenDX 4.4.4 (http://www.opendx.org/) - программное средство для анализа данных в графическом виде, визуализации научных данных.
  • GGobi 2.1.10 (http://www.ggobi.org/) - среда визуализации многомерных данных;
  • QtiPlot 0.9.8.8 - позиционируется как замена для Microcal Origin - программа для несложной статистической обработки данных, построения всяческих графиков.
  • Grace 5.1.22 (http://plasma-gate.weizmann.ac.il/Grace/) - программа для подготовки двумерных графиков по численным данным.
  • PAW 2.14.04 (http://cern.ch/paw/) - интерактивная программа анализа и графического представления результатов. Может применяться для анализа большого и очень большого объёма данных.
  • ROOT 5.34.00 (http://cern.ch/root/) - наследник PAW, интерактивная система обработки и визуализации очень больших объёмов научных данных.
  • GNU R 2.15.1 (http://r-project.org/) - мощный язык статистических вычислений, используемый профессиональными статистиками.
  • GRETL 1.9.9 (http://gretl.sourceforge.net/) - система эконометрического анализа.
  • Udav 0.7.1.2 (http://udav.sourceforge.net/) - инструмент визуализации данных.

Работа с графами

  • Tulip 0.5.11
  • GraphThing 1.3.2
  • Cytoscape 2.8.3
  • Rocs 1.7.2

Научные редакторы:

  • TeXLive 2012.20120611 - полноценный дистрибутив TeX.
  • TeXmacs 1.0.7.15  (http://texmacs.org) - текстовый редактор для набора математических и прочих научных текстов, также позволяет включать в документ сессии FriCAS, Maxima, Octave, SciLab и других систем компьютерной математики. Данная версия использует Qt, так что выглядит заметно приятнее старых, и работает несколько шустрее.
  • Kile 2.1.2 (http://kile.sourceforge.net/) - интегрированная среда подготовки документов с помощью TeX.
  • Texmaker 3.4 (http://www.xm1math.net/texmaker/) - интегрированная оболочка для LaTeX.
  • TeXworks  0.5- лёгкая оболочка для LaTeX.
  • LyX 2.0.3.

Также LiveMath IV содержит среду XFCE 4.10, LibreOffice 3.6.2. Для "больших" систем (ROOT, PAW, R, Octave) включена значительная часть имеющихся в репозиториях Ubuntu пакетов. Для многих изначально "консольных" систем включены GUI-обёртки, для некоторых по несколько, на выбор. К большинству программ есть документация. Возможна установка системы на жёсткий диск с помощью стандартного установщика Ubuntu.

Полный список установленных пакетов.

Загрузить образ ISO. (2 GB). Образ гибридный: можно записать на DVD или на флешку. Выложен образ на моём домашнем сервере, суперскоростей не обещаю.


К сожалению, у меня нет времени, чтобы тестировать все эти программы. То, что я протестировал - работает. Багрепорты принимаются в комментариях или на e-mail portnov at bk dot ru, но мгновенного исправления не обещаю.

LiveMath сделан с помощью Ubuntu Construction Kit (http://uck.sourceforge.net/), так что каждый, в принципе, может сделать себе нечто подобное. Вероятно, это окажется проще, чем качать моё изделие.

четверг, октября 11, 2012

Домашняя бухгалтерия в командной строке, yet another

Сделал вот ещё одно приложение для «домашней бухгалтерии в командной строке», в стиле ledger или hledger, но лучше :)
Называется YaLedger (yet another ledger).
Код: https://gitorious.org/yaledger
README: https://gitorious.org/yaledger/yaledger/blobs/master/README.ru
Умеет:
  • Автоматический выбор корреспондирующих счетов по настраиваемым правилам, так что в большинстве случаев достаточно записывать только одну половину проводки;
  • Сверку балансов счетов — можно указать, что в данный момент на счёте такая-то сумма, и yaledger автоматически сделает проводку, чтобы его данные сходились с указанными;
  • Шаблоны проводок; периодические проводки; автоматическое выполнение проводок при определённых условиях;
  • Чтение проводок из нескольких файлов;
  • Чтение проводок из форматов CSV и HTML (выписки из телебанков);
  • Само собой, работу с разными валютами;
  • Учёт курсовой разницы (из-за разницы между курсами купли/продажи)
  • Загрузку курсов валют ЦБ РФ;
  • Умную обработку дублирующихся записей;
  • Несколько отчётов: балансы счетов, обороты по счетам итп.
Сделано на haskell, с учётом основных (моих) требований:
  • Это приложение именно для домашней бухгалтерии, так что вести журнал проводок должно быть максимально просто (например, мне лень для каждой проводки указывать два счёта).
  • Я хочу, чтобы приложение оперировало более-менее стандартными объектами бухгалтерского учёта. Ну, например, hledger не использует таких сущностей, как "дебет" или "кредит", он просто прибавляет к балансу число, которое может быть отрицательным и положительным; yaledger ведёт себя более похоже на "взрослые" системы, учитывая отдельно кредитовые и дебетовые полупроводки.
  • Мне лень, да и некогда особенно, заниматься отладкой; поэтому максимально возможное количество проверок я переложил на систему типов, а там, где в компайл-тайме особенно ничего не проверишь — сделал так, чтобы система типов заставляла меня проверять всё что можно (например, невозможно кредитовать дебетовый счёт, не сойдутся типы; а если в данном случае неизвестно, кредитовый это счёт или дебетовый, компилятор заставит явно написать проверку).
Что-то вроде документации (неполной) тут:  http://redmine.iportnov.ru/projects/yaledger/wiki.

Эту штуку я использую в течение всего периода её разработки (чуть больше месяца :)). У меня работает, но баги, конечно, возможны.

Это пока что-то типа пре-релиза. На днях допишу документацию и выложу на hackage.

пятница, октября 28, 2011

Введение в прикладное программирование под GNU/Linux

Это конспект, который я готовил для доклада на конференции, проводившейся местным университетом совместно с нашей LUG. Доклад «для самых маленьких», так что профессионалам просьба не жаловаться на поверхностность и обзорность.

Аудитория

Эта статья расчитана на два вида читателей. Во-первых, это люди, имеющие опыт программирования под MS Windows, но не имеющие такого опыта под GNU/Linux. Во-вторых, это люди, не имеющие опыта программирования вовсе. Однако, я предполагаю, что читатель в общем знаком с общепринятой в программировании терминологией, и ему не нужно объяснять, например, что такое «программа», «функция», «компилятор» или «отладка».

Средства разработки

Я буду рассматривать разработку с использованием тех средств, которые являются наиболее «родными» для GNU/Linux. К ним относятся:

  • Язык программирования C

  • Командная оболочка bash

  • Текстовые редакторы Vim и Emacs

  • Компилятор GCC

  • Отладчик GDB

  • Утилита для сборки проекта GNU make

  • Система управления версиями Git

  • Оконная система X11

Выбор именно этих средств не является догмой. Каждое из выше перечисленных средств может быть при желании заменено на другое. Однако, обычно под фразами наподобие «среда разработки Linux» понимается именно этот набор инструментов.

Языки программирования

Наиболее «родным» языком программирования для GNU/Linux является C. Это обусловлено следующими факторами:

  • GNU/Linux заимствует многие идеи (практически, идеологию) операционной системы UNIX;

  • Операционная система UNIX была написана на языке C (собственно, этот язык создавался именно для написания этой ОС);

  • Соответственно, ядро Linux и системное окружение GNU написаны тоже на C.

Ниже я буду рассматривать разработку с использованием языка C. Однако, этот выбор не является догмой. Другими популярными при разработке под GNU/Linux языками являются C++, Python, Perl. Конечно, могут использоваться и любые другие языки.

Среда разработки

В течение последних двух десятилетий очень широкое распространение получили т.н. IDE — интегрированные среды разработки. Такая среда включает в себя текстовый редактор, компилятор, отладчик, средства сборки проекта и мн.др. Такие среды есть и под GNU/Linux (наиболее популярны Eclipse, NetBeans, IDEA, KDevelop, Anjuta). Однако, история разработки под UNIX-подобные системы показывает, что IDE не являются не только единственным, но и наиболее эффективным средством разработки. Практически, правильный ответ на вопрос «какая самая лучшая IDE под GNU/Linux» — это «GNU/Linux это и есть IDE».

Часто можно встретить мнение, что большой проект без IDE разрабатывать невозможно. Это мнение легко опровергается. Первые версии UNIX писались даже не в Vim (его тогда ещё не было), а в Ed. Это так называемый «построчный» текстовый редактор, в котором вы можете редактировать за раз только одну строку текста. Весь файл на экране не отображается. В случае с UNIX по-другому и быть не могло — у разработчиков не было никаких экранов, а общение с системой осуществлялось при помощи телетайпов. Современное ядро Linux пишется в основном в редакторах Emacs и Vim.

Многие утилиты UNIX вызывают «текстовый редактор по умолчанию». Команда, запускающая текстовый редактор по умолчанию, берётся из переменной окружения $EDITOR. Некоторые утилиты смотрят сначала в переменную $VISUAL, и, лишь если она не установлена, в переменную $EDITOR. Это исторически сложившееся поведение: к старым компьютерам зачастую не было подключено никакого дисплея, а только телетайп, поэтому запускать экранный (визуальный) редактор смысла не было. В современных дистрибутивах обычно по умолчанию оказывается EDITOR=vi или EDITOR=nano. Указать использование другого редактора для одной команды можно так:

EDITOR=emacs some-command

Чтобы использовать нужный редактор по умолчанию всегда, нужно добавить в файл ~/.profile строчку типа

export EDITOR=emacs

Исторически сложилось так, что «настоящими» текстовыми редакторами для программистов являются только Vim и Emacs (просто из-за того, что у них самая долгая история развития именно в качестве текстовых редакторов для программистов). Остальные редакторы находятся в положении догоняющих.

Командная оболочка

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

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

ОС семейств DOS и Windows заимствовали некоторые функции командной оболочки из UNIX, однако их авторы пошли на существенные упрощения, из-за чего функционал COMMAND.COM и cmd.exe получился сильно урезанным. PowerShell вполне на уровне, но работает существенно по-другому.

В рамках этой статьи я ограничусь использованием командной оболочки bash (как наиболее распространённой и используемой по умолчанию в большинстве дистрибутивов) для запуска компилятора и других средств разработки. Хороший обзор использования командной оболочки можно найти, например, в известной книге [kernigan_pike].

Документация

Все средства разработки и библиотеки в GNU/Linux обычно довольно хорошо документированы. Традиционно для документации используется специальный формат и утилита для его просмотра — man. Документация в системе делится на несколько разделов:

  1. Команды пользователя (например, ls, gcc или man)

  2. Системные вызовы — API ядра ОС

  3. Библиотечные функции

  4. Драйвера и т.п

  5. Форматы файлов

  6. Игры и т.п

  7. Различные обзоры подсистем

  8. Команды, используемые для системного администрирования

Для вызова раздела документации по имени нужно указать это имя при вызове команды man (например, man ls). Иногда разделы с одинаковым названием есть сразу в нескольких разделах документации документации. Указать конкретный раздел можно при вызове man (например, man 3 printf).

Более подробную информацию о справочной системе man см. в man man.

Утилиты системного окружения GNU часто используют для документации формат info. См., например, info Coreutils.

Компилятор

Сейчас существует много компиляторов языка C, более-менее совместимых с различными стандартами. Тем не менее, пока что в среде GNU/Linux наиболее применимым остаётся компилятор C, входящий в комплект GNU Compilers Collection (GCC). Этот компилятор, кроме стандарта C, поддерживает некоторое количество расширений стандарта. Эти расширения, в частности, широко используются в исходных текстах ядра Linux. В последнее время появляются компиляторы, способные скомпилировать ядро Linux (например, llvm-clang, или EKO).

Компилятор GCC запускается из командной оболочки командой вида

gcc [OPTIONS] program.c

где program.c — имя входного файла. Кроме того, по стандарту POSIX, компилятор может быть запущен командой cc program.c (cc — от "C compiler").

При обычном запуске компилятор пытается создать исполняемый файл. По умолчанию, выходной файл называется a.out (такое название осталось от древних версий UNIX). Другое название можно задать с помощью опции компилятора -o, например,

gcc -o program program.c

При сборке программы из нескольких модулей компилятору можно подавать на вход несколько исходных файлов или файлов объектного кода, например,

gcc -o program main.c module1.o module2.o …

Чтобы только скомпилировать один исходный файл в объектный код (не пытаясь собрать исполняемый файл), нужно дать команду вида

gcc -c module.c

(имя выходного файла по умолчанию будет module.o).

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

Статическая библиотека в UNIX-подобных системах представляет собой архив (старинного формата ar), включающий набор объектных файлов. Такой архив создаётся командой вида

ar r libsomething.a module1.o module2.o …

Имена файлов библиотек традиционно начинаются с префикса lib.

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

gcc -shared -o libsomething.so module1.c module2.c …

Для использования библиотеки при сборке программы её нужно указать компилятору при помощи опции -l, например

gcc -o program -lm program.c

(здесь будет использоваться файл библиотеки libm.so, префикс lib компилятор подставляет по умолчанию). По умолчанию компилятор собирает программу, использующую динамические библиотеки. Если нужно использовать статические версии библиотек, компилятору нужно указать опцию -static.

Подробную информацию об опциях gcc см. в man gcc.

Hello, world!

Считается, что традиция начинать изучение языка программирования с написания программы, выводящей строку "Hello, world!", пошла с книги Кернигана и Ричи "Язык C" [kernigan_richie]. В случае с языком C эта программа выглядит следующим образом:

#include <stdio.h>

int main(int argc, char* argv[]) {
printf("Hello world!\n");
return 0;
}

Чтобы запустить эту программу, этот текст нужно записать в файл с именем, скажем, hello.c, и из директории, в которой расположен этот файл, дать команду вида

gcc -o hello hello.c

Впрочем, в случае такой простой программы достаточно дать команду

make hello

(я поясню ниже, почему эти две команды работают одинаково). В результате в той же директории появится исполняемый файл с именем hello. Запустить его можно командой

./hello

Порядок сборки

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




На входе компилятор имеет в общем случае набор файлов с исходными текстами. Перед началом собственно компиляции эти файлы обрабатываются т.н. препроцессором (программа cpp). Главная функция этой программы — выполнение директив вида #include . Встретив такую директиву, препроцессор вставляет содержимое указанного файла (в данном случае, stdio.h) на место этой директивы. Препроцессор понимает ещё некоторые директивы, но сейчас на них останавливаться я не буду.

После препроцессора выполняется собственно компиляция. Из исходных файлов на этом этапе получаются т.н. объектные файлы. Это файлы, содержащие исполняемый машинный код, но ещё не готовые для запуска. Главное, чего в них недостаёт — это адреса вызываемых библиотечных функций. Например, код функции printf() содержится в библиотеке libc. А в объектном файле содержится только имя этой функции. Кроме того, объектный файл содержит имена всех объявленных в нём функций.

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

Собственно программа gcc представляет собой так называемый драйвер (driver). Она запускает упомянутые выше программы (или только некоторые из них, в зависимости от опций), чтобы получить исполняемый файл.

Второй пример: решение квадратных уравнений

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

#include <stdio.h>
#include <math.h>

/* solve: calculate roots of square equation.
* a, b, c are coefficients in equation.
* Roots would be stored at x1, x2.
* Return value: count of real roots.
*/
int solve(double a, double b, double c,
double* x1, double* x2) {
double D = b*b - 4*a*c;
double sqrtD;

if (D > 0) {
sqrtD = sqrt(D);
*x1 = (-b - sqrtD)/(2.0 * a);
*x2 = (-b + sqrtD)/(2.0 * a);
return 2;
} else if (D < 0)
return 0;
else {
*x1 = -b/(2.0*a);
return 1;
}
}

int main (int argc, char* argv[]) {
double a,b,c;
double x1, x2;
int roots_count;

// Input coefficients
printf("A: ");
scanf("%lf", &a);
printf("B: ");
scanf("%lf", &b);
printf("C: ");
scanf("%lf", &c);

// Solve the equation
roots_count = solve(a,b,c, &x1, &x2);

// Output results
switch (roots_count) {
case 0:
printf("No (real) roots.\n");
break;
case 1:
printf("One root: %0.4lf\n", x1);
break;
case 2:
printf("Two roots: %0.4lf and %0.4lf\n",
x1, x2);
break;
}

return 0;
}

По аналогии с предыдущим примером, запишем этот текст в файл square.c и попытаемся скомпилировать его командой

gcc -o square square.c

Но на этот раз мы получим ошибку примерно такого вида:

/tmp/cc6RNFIi.o: In function `solve': square.c:(.text+0x6d): undefined reference to `sqrt' collect2: ld returned 1 exit status

В чём здесь дело? Ясно, что компилятору почему-то не понравился вызов функции sqrt(). Причём, он жалуется уже не на файл исходного кода, а на объектный файл (вот этот cc6RNFIi.o). Это означает, что исходный файл благополучно скомпилировался, а проблемы возникли на стадии компоновки (что можно видеть и по упоминанию в тексте ошибки программы ld — это стандартный в GNU/Linux компоновщик). Компоновщик не смог найти функцию sqrt(). В данном случае, это произошло из-за того, что эта функция содержится в библиотеке libm, а мы не просили компилятор использовать её. Чтобы избавиться от этой ошибки, нам нужно изменить команду компиляции на следующую:

gcc -o square -lm square.c

Такая команда должна отработать без ошибок и создать исполняемый файл square.

При сборке любой достаточно сложной программы нам придётся использовать несколько библиотек, и, возможно, понадобится указывать ещё какие-то опции компилятору. Команда может получиться довольно длинная. Что же, каждый раз набирать её вручную? Нет. Один из принципов философии UNIX гласит: «Всё, что может быть автоматизировано, должно быть автоматизировано». Здесь нам пригодится одна из древнейших UNIX-утилит — программа make. Чтобы воспользоваться ею, нужно написать файл с именем Makefile (в той же директории, что и наш исходный файл) со следующим содержимым:

square: square.c         $(CC) -o $@ -lm $<

Теперь собрать исполняемый файл можно просто дав команду make. Как это работает?

Make

Утилита make предназначена для сборки программ (хотя может использоваться для автоматизации многих других похожих задач). Она читает файл с именем Makefile и видит в нём набор правил. Каждое правило определяет три вещи: цель (goal, т.е. то, что нужно собрать), список исходных файлов и набор команд, которые нужно выполнить, чтобы собрать цель из исходных файлов. В примере выше, square — это имя цели, square.c — единственный в данном случае исходный файл (если их несколько, они перечисляются через пробел), а вторая строчка — команда. В команде могут использоваться переменные. Некоторые из переменных имеют специальное значение. В частности, в любом правиле $@ обозначает имя цели, а $< — первый исходный файл. Переменная $(CC) указывает на компилятор C, используемый в системе по умолчанию (в большинстве случаев это gcc, но бывает и что-нибудь другое).

В имени цели и списке исходных файлов может использоваться подстановочный символ %. Например, такое правило:

%.o: %.c   $(CC) -c $<

обозначает, что файлы с именем, заканчивающимся на .o, нужно собирать из соответствующих файлов с суффиксом .c.

Кроме того, make заранее знает некоторое количество правил по умолчанию. Среди них есть упомянутое в последнем примере, а также правило

%: %.c   $(CC) -o $@ $<

Благодаря этому правилу, в примере с «Hello, world!» просто команда make hello запускала cc -o hello hello.c.

По набору правил make составляет граф зависимостей целей друг от друга и от исходных файлов, и выполняет только те команды, которые нужны для сборки цели, указанной в командной строке. Если не указано никаких целей, то собирается первая цель, описанная в Makefile.

Более подробную информацию об этой утилите см., например, в man make.

Управление версиями

Для управления версиями исходного кода может использоваться любая VCS. Однако, раз уж мы говорим о GNU/Linux, рассмотрим вкратце систему, используемую для разработки ядра Linux: git. По git существует довольно обширная документация, в т.ч. и на русском языке. См. например, мою статью [vcs_git] или известную серию статей [los-t_git].

Для начала использования git нужно создать репозиторий — хранилище для версий файлов. Это делается командой

git init

Теперь можно добавлять файлы в репозиторий. Но нам не нужно отслеживать версии некоторых файлов, а именно: объектных файлов и исполняемых файлов. Чтобы сразу исключить их из рассмотрения git, напишем файл .gitignore следующего содержания:

*.o square hello

Теперь команда

git add .

добавит в репозиторий все файлы в текущей директории, кроме упомянутых в файле .gitignore. После этого можно делать коммит командой

git commit

По этой команде откроется текстовый редактор по умолчанию. Тут нужно будет написать комментарий к коммиту. В данном случае достаточно строчки типа «Initial commit».

Отладка

Для отладки в Linux используется отладчик gdb. Но сначала, для того, чтобы программу было удобно отлаживать, её нужно скомпилировать с опцией -g. Сейчас нам достаточно изменить Makefile, приведя его к виду

square: square.c         $(CC) -o $@ -lm -g $<

и пересобрать программу.

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

Отладка запускается командой вида

gdb ./square

Если отлаживаемой программе нужно передать какие-то опции командной строки, их можно указать здесь же:

gdb ./some-program -a -b

При запуске отладчика появляется приглашение командной строки вида:

GNU gdb (GDB) 7.2-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later  This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.  Type "show copying" and "show warranty" for details. This GDB was configured as "i686-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /home/portnov/LUG/src/square...done. (gdb)

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

К наиболее часто используемым командам относятся:

list

Напечатать очередной кусок исходника (печатается 10 строк). Можно указать конкретные номера строк после имени команды, например l 10,15.

run

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

break

Установить точку останова. Номер строки, на которой нужно установить точку останова, указывается после имени команды.

next

Выполнить одну строку программы.

print

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

display

Добавить выражение к списку постоянно отображаемых. Значения этих выражений будут показываться после исполнения каждой команды. Рядом с каждым выражением печатается его номер в списке. Удалить выражение из списка можно командой undisplay с номером выражения.

quit

Выход из отладчика.

Более подробную информацию по GDB см. в man gdb.

Оконная система X11

Исторически в UNIX не было и не могло быть никакой графической среды, потому что не было графических дисплеев. Графическая среда для UNIX появилась примерно тогда, когда появились распространённые графические дисплеи: в 1984. Сначала она называлась W (от Window), затем её усовершенствовали и назвали следующей буквой алфавита — X, следующая версия называлась X2… Сейчас имеем X11.

X11 представляет собой, прежде всего, сетевой протокол поверх TCP/IP и UDP/IP. У протокола есть клиент и есть сервер. Клиент посылает последовательность запросов вида «нарисуй мне окошко», «нарисуй на нём кнопочку», а сервер их исполняет. Один из главных принципов X11 — «определять механизмы, а не политики». Протокол предоставляет возможность, скажем, рисовать окошки, а как именно они будут отображаться — не определяет.

Наиболее распространённым X-сервером сейчас является Xorg (http://x.org); всё ещё жив XFree86; под Windows актуален Xming; выпускаются аппаратные X-серверы — комплекты «монитор + клавиатура + мышка», в которых поддержка серверной функциональности X11 реализована аппаратно — такие комплекты используются в качестве графических терминалов.

Протокол X11, в отличие от, скажем, HTTP, является бинарным, а не текстовым — это сделано из соображений экономии пропускной способности сетевого соединения и простоты разбора запросов сервером. Но это усложняет создание клиентов этого протокола: собирать замысловатые бинарные X11-запросы заведомо сложнее, чем, например, текстовые HTTP-запросы. Поэтому для написания X-клиентов используются специальные библиотеки функций, формирующих и отправляющих серверу X-запросы. Наиболее распространена библиотека libX11. Более современным вариантом является libxcb.

Запросы X11 весьма низкоуровневые. Например, чтобы реализовать функциональность кнопки, нужно нарисовать в окне прямоугольник, написать в нём текст, ждать в цикле нажатия кнопки мыши, и при каждом нажатии проверять, где щёлкнули — внутри прямоугольника или вне него. Поэтому стали появляться так называемые тулкиты — библиотеки, являющиеся высокоуровневыми обёртками над libX11.

Исторически первым тулкитом был Athena3D. Потом были Motif и Tk. Сейчас наиболее распространены GTK+ и Qt (Qt, строго говоря, представляет собой не X11-тулкит, а многоцелевой кроссплатформенный набор библиотек, который может использоваться в качестве X11-тулкита).

Hello, world на GTK+

В качестве примера рассмотрим следующую программу. Она показывает окно с одной кнопкой. При нажатии на эту кнопку появляется сообщение «Hello, world».

#include <gtk/gtk.h>

// This function displays message dialog.
// main_window parameter should be set to parent window of the dialog.
void message_box (GtkWindow* main_window, gchar *message) {
GtkWidget *dialog, *label, *content_area;

// Create a dialog
dialog = gtk_dialog_new_with_buttons ("Message",
main_window,
GTK_DIALOG_DESTROY_WITH_PARENT,
GTK_STOCK_OK,
GTK_RESPONSE_NONE,
NULL);
// Create a label
content_area = gtk_dialog_get_content_area (GTK_DIALOG (dialog));
label = gtk_label_new (message);

// On "response" signal (it's called when user clicks a button in
// the dialog), destroy the dialog.
g_signal_connect_swapped (dialog,
"response",
G_CALLBACK (gtk_widget_destroy),
dialog);

// Add a label
gtk_container_add (GTK_CONTAINER (content_area), label);
// Show the dialog
gtk_widget_show_all (dialog);
}

// Callback for delete-event signal
static gboolean delete_event( GtkWidget *widget,
GdkEvent *event,
gpointer data )
{
// If return TRUE, window will not be closed.
// This may be used to preven closing window in some situations.
return FALSE;
}

// Callback for destroy signal
static void destroy( GtkWidget *widget,
gpointer data )
{
// End main GTK+ event loop
gtk_main_quit ();
}

// Callback for button click
static void hello ( GtkWidget *widget,
gpointer data )
{
// "data" parameter represents main window here
message_box(GTK_WINDOW(data), "Hello, world!");
}

int main( int argc,
char *argv[] )
{
GtkWidget *window;
GtkWidget *button;

// Init GTK+
gtk_init (&argc, &argv);

// Create main window
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);

// Set up callbacks for some signals
g_signal_connect (window, "delete-event",
G_CALLBACK (delete_event), NULL);

g_signal_connect (window, "destroy",
G_CALLBACK (destroy), NULL);

// Set window borders width
gtk_container_set_border_width (GTK_CONTAINER (window), 10);

// Create labeled button
button = gtk_button_new_with_label ("Hello World");

// Set up callback for "clicked" signal of the button.
// Pass main window as second parameter.
g_signal_connect (button, "clicked", G_CALLBACK (hello), (gpointer)window);

// Pack the button into window
gtk_container_add (GTK_CONTAINER (window), button);

// Show the button
gtk_widget_show (button);

// Show the window
gtk_widget_show (window);

// Run main GTK+ event loop.
gtk_main ();

return 0;
}

Собирается эта программа командой вида

gcc -o gtk-hello $(pkg-config --cflags gtk+-2.0) $(pkg-config --libs gtk+-2.0) gtk-hello.c

GTK+ — довольно сложно устроенный набор библиотек, поэтому, чтобы не указывать все нужные библиотеки и опции компилятора вручную, мы используем здесь программу pkg-config, которая печатает опции компилятора, нужные для использования GTK+.

Дополнительная литература

[raymond] Реймонд, Эрик С. Искусство программирования для UNIX. — Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 544с., ил.

[kernigan_pike] Керниган Б., Пайк Р. UNIX. Программное окружене. — Пер с англ. — СПб: Символ-Плюс, 2003. — 416с., ил.

[kernigan_richie] Керниган Б., Ритчи Д. Язык программирования C. — Пер. с англ. — Москва: Вильямс, 2006. — 304 с.

[vcs_git] Портнов И. Системы контроля версий. Git. URL: http://iportnov.blogspot.com/2008/06/git.html

[los-t_git] Los-t. Git guts (серия статей в ЖЖ). URL: http://los-t.livejournal.com/tags/git+guts


вторник, марта 29, 2011

Изготовление презентаций из Asciidoc с помощью Beamer

В одном из недавних постов я говорил, что из Asciidoc-разметки можно сделать много всяких разных выходных форматов. Среди всего прочего, можно делать и презентации. Не слишком «навороченные», правда, но для многих случаев этого хватает.

Схема такая:



Сначала из Asciidoc делаем DocBook. Это можно сделать командой вида asciidoc -b docbook input.txt. Только вот по такой команде получится файл в формате DocBook 4.5, а моя XSL-таблица понимает только DocBook 5.0+. Поэтому берём конфигурационные файлы asciidoc для изготовления DocBook 5.0, например, отсюда, и даём команду вида

asciidoc -b topic input.txt

Получается файл input.xml. Теперь берём XSL-таблицу, преобразующую DocBook 5.0+ в TeX-овский исходник, например, здесь (эта таблица заведомо не полная, но для моих задач хватает; кому не хватит — добавляйте туда свои шаблоны :)), и даём команду вида

xsltproc beamer.xsl input.xml > presentation.tex

Ну а теперь компилируем этот исходник командой вида

xelatex presentation.tex

(может понадобиться запустить эту команду несколько раз, чтобы проставились все ссылки и т.п).

Таким образом сделана, в частности, упомянутая в одном из предыдущих постов презентация (из вот такого исходника).

воскресенье, марта 27, 2011

Об изготовлении EPUB из DocBook

Тут не так давно я уже упоминал, что из DocBook можно делать, в том числе, и EPUB. Однако процесс не вполне тривиальный; мне кажется, его стоит расписать несколько подробнее.

Вот тут в IBM DeveloperWorks описан такой процесс. Однако изготовленный по этому рецепту файл будет обладать парой недостатков:

  • Это будет файл устаревшего формата «Open Epub»;

  • В нём не будет внедрённых шрифтов.

Такой файл благополучно открывается чем-нибудь типа Okular. Однако AdobeViewer на читалках типа PocketBook 301+ в таких файлах показывает русские буквы вопросиками. Это происходит из-за того, что встроенного шрифта в файле нет, AdobeViewer пытается использовать шрифт по умолчанию, а в нём нет русских букв.

Так что будем делать «более правильный» EPUB. «Нормальный» EPUB-файл — это zip-архив, в котором содержатся следующие вещи:

  • Файл с именем «mimetype»; этот файл обязательно должен идти первым в архиве, не должен быть сжат, и его содержимым должна быть строка «application/epub+zip» (без символа новой строки в конце).

  • Директория с именем «META-INF»; в ней — файл container.xml. Примеры содержимого этого файла можно нагуглить, главное что в нём должно быть прописано — ссылка на файл contents.opf (OPS/contents.opf).

  • Директория с именем «OPS»; В ней — HTML-файлы с собственно содержимым книги, картинки к ним, шрифты (файлы *.ttf), и файл contents.opf и таблица стилей CSS.

Для того, чтобы сделать такой файл из имеющегося DocBook-файла book.xml, нужно проделать следующее:

  1. Выполнить команду вида:

    xsltproc --stringparam epub.oebps.dir OPS/ \
    --stringparam epub.embedded.font Ubuntu-R.ttf \
    --stringparam html.stylesheet style.css /usr/share/xml/docbook/stylesheet/docbook-xsl/epub/docbook.xsl \
    book.xml

    Здесь вместо «Ubuntu-R.ttf» можете указать какое-нибудь другое имя шрифтового файла. Путь к epub/docbook.xsl на вашей системе может быть и другим, подставьте ваш. Эта команда создаст директори META-INF и OPS в текущей директории.

  2. Скопировать откуда-нибудь или написать таблицу стилей OPS/style.css. Стили можно настраивать на ваш вкус, но надо учитывать следующее:

    • Если вы предполагаете, что документ будут читать на E-Ink устройстве, то не делайте слишком сложную цветовую гамму; экран мало того что чёрно-белый, так ещё не очень хорошо показывает тонкие оттенки. Идеально было бы обойтись 4мя или 8ю оттенками серого (включая чёрный и белый).

    • В таблице должны быть правила, указывающие конкретные шрифты, наподобие следующих:

      @font-face {
      font-family: "Ubuntu";
      font-style: normal;
      font-weight: normal;
      src: url(Ubuntu-R.ttf)
      }

      @font-face {
      font-family: "Ubuntu";
      font-style: normal;
      font-weight: bold;
      src: url(Ubuntu-B.ttf)
      }

      @font-face {
      font-family: "Ubuntu";
      font-style: italic;
      font-weight: normal;
      src: url(Ubuntu-I.ttf)
      }

      @font-face {
      font-family: "Ubuntu";
      font-style: italic;
      font-weight: bold;
      src: url(Ubuntu-BI.ttf)
      }

      @font-face {
      font-family: "DroidSansMono", monospace;
      font-style: normal;
      font-weight: normal;
      src: url(DroidSansMono.ttf)
      }

      pre {
      white-space: pre-wrap;
      font-family: "DroidSansMono", monospace;
      font-size: 85%;
      }

      (имена шрифтов, конечно, укажите ваши).

  3. Скопировать откуда-нибудь файлы шрифтов (*.ttf) в директорию OPS/.

  4. Исправить файл OPS/content.opf, добавив туда ссылки на шрифты. Это делается строчками вида:



    <item id="font2" href="Ubuntu-I.ttf" type="application/x-font-ttf"/>

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

  5. Собрать собственно EPUB-файл командами вида

    $ echo "application/epub+zip" > mimetype
    $ zip -0Xq my-book.epub mimetype
    $ zip -Xr9D my-book.epub META-INF OPS
  6. (Опционально) Проверить получившийся файл при помощи программы epubcheck командой вида

    java -jar epubcheck.jar my-book.epub

Получившийся файл my-book.epub должен нормально читаться как на компьютере, так и на книгочиталках.

суббота, марта 19, 2011

Небольшое разъяснение по комментариям

В разных постах в комментариях товарищи меня корректируют — где-то я ошибся, где-то что-то перепутал. Я специально не вношу изменения в пост — чтобы было видно, что вот тут я ошибался, а вот тут меня исправили.