LLVM, чтоб его.

Баг 2008 года в LLVM портит мне жизнь. Берем тестовый файлик следующего содержания:

class RPC_Service
{
public:
  virtual ~RPC_Service ();
};
class EventLoggingInterface
{
  virtual void
    Ev (const char *file, int line, int sev, const char *fmt,
        ...) const = 0;
};
class RPCCore : RPC_Service, EventLoggingInterface
{
  virtual void
    Ev (const char *file, int line, int sev, const char *fmt, ...) const;
};
void
RPCCore::Ev (const char *file, int line, int sev, const char *format, ...) const
{
}

Выполняем команду:

/Developer/usr/bin/llvm-g++ thunk_error.cpp -c

И в результате получаем:

thunk_error.cpp:19: error: generic thunk code fails for method ‘virtual void RPCCore::Ev(const char*, int, int, const char*, ...) const’ which uses ‘...’

Неужели придется отказаться от LLVM? Интерфейс, в моем случае, поменять врятли удастся. Вобщем писать кроссплатформенный код это еще та засада

GDB. Легко и даже изящно.

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

Итак, по группам.

Запуск отладки

attach pid – присоединение к процессу с идентификатором pid для отладки.
set args args – установка args в качестве аргументов приложения.
run – запустить открытое приложение на отладку.
continue – продолжить выполнение приложения (например после того как сработала точка останова или в случае в присоединением к процессе).

Установка точек останова.

break file:line – установить точку останова на заданную линию заданного файла.
break func_name – установить точку останова на заданную функцию.
break – установить точку останова на текущую линию в файле.
watch – установка точки наблюдения за изменением состояния переменной (write).
rwatch addr – установка точки наблюдения за изменением состояния переменной (read). Например команда rwatch *0xfeedface, означает что необходимо наблюдать за изменением данных находящихся по адресу 0xfeedface.

Сигналы

handle SIGNAL_NAME nostop – не останавливаться на сигнале SIGNAL_NAME. Бывает очень полезно для SIGPIPE.

Управление отладкой

n – шаг, не заходя в функцию.
s – шаг в функцию.
fin – закончить функцию.

Просмотр состояния объектов

whatis – информация о типе объекта по указателю на него.
ptype – детальное описание типа.
print – распечатать значение объекта.
Кроме того, необходимо скачать файл stl-views.gdb, который легко гуглится по фразе “STL GDB evaluators/views/utilities”. Благодаря нему появляется возможность выводить содержимое контейнеров STL. Например, появляются команды pvector, pmap и т.д.

Сбор дополнительной информации

bt – показать вызовов.
i sharedlibrary – показать список загруженный динамических библиотек.
i threads – показать все активные потоки.
i line numb – отобразить информацию о линии с номером numb.
i thread – детальная информация по текущему потоку.
thread apply all command – применить команду command ко всем потокам. Очень полезно использовать thread apply all bt для вывода стека всех потоков.
frame – текущая позиция в отлаживаемом коде.
list – отобразить линию либо функцию. Если вызывается без аргументов, отображается текущая линия.
disassemble start end – диассемблировать код начинающийся по адресу start и заканчивающийся на адресе end. Команда бывает полезна в купе с i line.

Далее. Крайне желательно установить скрип который можно найти у IBM вот тут.
Благодаря ему открываются такие прекрасные команды как:

reg – вывести содержимое регистров.
dd addr – вывести содержание памяти по адресу addr в формате HEX | ASCII.

Самописные ништяки

Так же будут полезны команды загрузки/сохранения точек останова:

define bsave
shell rm -f brestore.txt
set logging file brestore.txt
set logging on
info break
set logging off
# reformat on-the-fly to a valid gdb command file
shell perl -n -e 'print "break $1n" if /^d+.+?( S+)$/g' brestore.txt > brestore.gdb
shell rm -f brestore.txt
end
document bsave
store actual breakpoints
end
define brestore
source brestore.gdb
end
document brestore
restore saved breakpoints
end

И вывод значений wchar_t строки:

define pwchar
echo "
set $c = ( wchar_t*)$arg0
while ( *$c )
if ( *$c > 0x7f )
printf "
[ %x]", *$c
else
printf "
%c", *$c
end
set $c++
end
echo "
n
end

Вобщем как-то так. Еще планирую написать о том, как искать падения по дампам при помощи GDB, что тоже довольно занимательно.

Смерть Symbian :(

Захожу я сегодня на Symbian Developer, а там! Вобщем, похоже, Нокия решила окончательно убить Symbian, т.к. проект закрывается 17 декабря сего года. Все что на нем есть сейчас можно будет заказать на CD. Тем не менее, на всякий случай, я исходники Symbian-a заначил.. Мало ли?

Да, Symbian SDK остается на сайте Nokia Developer, хотя основной акцент делается все же на QT SDK.

Но все равно грустно, единственная нормальная ОС для мобильных девайсов и тут такое. Эхх

Автосинхронизация с iSync

iSync – замечательное приложение позволяющее синхронизировать практически любой девайс с календарем и адресной книгой на локальном компьютере. По большому счету, у это приложения есть 2 недостатка причем если один из них обойти никак нельзя, то второй недостаток довольно легко обходится.
Во-первых, iSync работает только по Bluetooth. Похоже что тут ничего поделать нельзя, как это не печально. Во-вторых, iSync не умеет запускать синхронизацию по расписанию, но вот эта проблема решается довольно просто.
Заставить iSync синхронизировать календари и контакты самостоятельно можно 2-мя способами. Первый вариант это UNIX-way. Надо не так уж и много, написать небольшой AppleScript и задать расписание в cron.
Создаем iSyncAuto.scpt следующего содержания:

tell application "Finder"
set iSyncRunning to (number of items in (processes whose name is "iSync") is greater than 0)
tell application "iSync" to synchronize
tell application "iSync"
repeat while (syncing is true)
end repeat
if iSyncRunning is not true then
quit
end if
end tell

И добавляем в cton задачу:

crontab -e

* */6 * * * osascript path_to_script/iSyncAuto.scpt

Чтоб сильно не грузить батарею запускаем синхронизацию каждый 6-й час.

Но это сложный, не userfriendly и не Mac-way Теперь тоже самое, но по-Маковски.
Идем на сайт Apple и качаем приложение iSyncIt. Устанавливаем, запускаем, радуемся

Грабля в launchd

Неожиданно нарвался на граблю там, где уж совсем не ожидал ее найти, а именно в launchd. Вообще, launchd крайне удобен в управлении демонами, например при помощи него мы при запуске GUI из под пользователя поднимаем рутовый демон. Делается это довольно просто, создается plist и в переменную WatchPath указывается директория, по изменении которой должно запуститься приложение из ProgrammArgument. Сам plist помещается в директорию LaunchAgents для пользовательских приложений и LauchDaemons для системных.
Описанная выше часть работает как часы, и все бы ничего, если бы не возникла необходимость запустить по событию не только демон, но и само GUI. Казалось-бы все просто – добавляем WatchPath со ссылкой на ту же директорию, что и в случае с нашим демоном и вперед. Но вот тут то и зарыта грабля – демон стартует великолепно, а GUI нет. Чисто теоретически, такого происходить не должно, особенно с учетом того, что за директорией LaunchAgents следит launchd запущенный из-под пользователя, а за LauchDaemons рутовый. Но, это только теория, на практике все несколько иначе.
Лечиться созданием отдельной директории, используемой для запуска GUI приложения, которое уже в свою очередь поднимает демон.

Что не так с Java?

Меня долгое время мучил вопрос, почему приложения на Java такие тормозные? Если верить синтетическим тестам на The Computer Language Benchmarks Game, то в среднем приложения на Java работают всего-то в 2 раза медленнее при использовании памяти в 10 раз больше по отношению к C++ приложениям. В принципе, это не такой уж и большой разрыв. Хотя в этих тестах нет приложений на Objective-C, я думаю что результат для был-бы приблизительно тем же, ну может памяти тратилось бы не в 10, а в 5 раз больше, а ведь c приложениями на Objective-C можно нормально работать. Так в чем же дело?

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

Изучая примеры Open Source приложений под Android просто диву даешься, насколько безграмотно они написаны с точки зрения ограничения используемых ресурсов. Куча бесполезных абстракций, нагромождение паттернов (привет не понимаю зачем была создана GoF) и совершенно бездумное использование памяти. Достаточно показательный момент – основные советы разработчикам под Android сводятся к тому, что надо плодить меньше сущностей, больше думать о сложности используемых алгоритмов и менее фанатично относиться к ООП. Создается ощущение что появление GC, упрощение разработки и отдаление от проблем среды исполнения вызвало сильнейшую деградацию разработчиков.

Одно радует, теперь понятно почему на десктопах количество приложений написанных на C# или Java ничтожно мало