С праздником, коллеги! Что бы не было в вашем коде:

#define TRUE FALSE

Добрая статья: http://www.mount.ru/shop/dir.php?id=235 в целом соответствует моему опыту использования газа.

• Статья выше на WEB Archive: https://web.archive.org/web/20170911003435/http://www.mount.ru/shop/dir.php?id=235

Конспективно:

1. Минимальный: 30 грамм/человек/день
   • пожалуй только на Jet Boil и прочих интегрированных системах или котелками с радиаторами плюс использование горелки только доведения до кипения и запаривание еды. У самого такого расхода не получалось.
2. Стандартный: 60-90 грамм/человек/день
   • в т.ч. готовка риса, гречки, но отсутствие топления снега и льда. Вода от 7-10 градусов. Каши из перловки и кукурузы - в пролёте. Наличие ветрозащиты. Котёл 2.7 л, для горелок, Ковея, алюминиевый.
   • при наличии опыта общения с газовым оборудованием, использовании котлов с теплообменниками и эффективных горелок, можно рассчитывать на 40-50 грамм/человек/день. Но! Пока не наберёте свою статистику, лучше закладывать 60.
3. Экстремальный: от 100 до 300, а то и выше грамм/человек/день
   • топление снега, готовка на большой высоте: на берельском седле, по ощущениям, потребление было около 120 грамм.
   • отсутсвие защитных ветровых стенок, экранов, неэффективные (костровые: с овальным дном или с нагаром, который является отличнымтеплоизолятором) или слишком большие котлы (больше 2-3 литров - уже много потерь, нужно озадачиться теплотканью).

Выводы:

1. В низкогорье (до 2000-2500 м) и на равнине при отсутствии топления снега при готовке (т.е. будете не просто запаривать, а варить) можете уложиться в 60-70 грамм и меньше
2. При топлении снега увеличьте до 90-100
3. При увеличении высоты доведите до 120

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

1. на Jet Boil или чём-то подобном натопить и накипятить воды и залить в термосы
2. основное блюдо приготовить на горелке добавляя туда уже подогретую и натопленную воду

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

При таком раскладе, расход выше чем чисто на Jet Boil, но проще готовить на палатку из 3-4 человек плюс меньше расход, чем чисто на горелке.

Пост буду уточнять по мере появления свежих наблюдений. Ещё есть старый пост: Газовые смеси и холод, который поможет сориентироваться при использовании газа в походе.

Временами, при сборке ловится такое:

/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status

При этом в системе наблюдается такое:

$ locate libGL.so
/usr/lib/i386-linux-gnu/mesa/libGL.so.1
/usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0
/usr/lib/insync/libGL.so.1
/usr/lib/nvidia-346-updates/libGL.so
/usr/lib/nvidia-346-updates/libGL.so.1
/usr/lib/nvidia-346-updates/libGL.so.346.82
/usr/lib/x86_64-linux-gnu/mesa/libGL.so
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
/usr/lib/x86_64-linux-gnu/primus/libGL.so.1
/usr/lib32/nvidia-346-updates/libGL.so
/usr/lib32/nvidia-346-updates/libGL.so.1
/usr/lib32/nvidia-346-updates/libGL.so.346.82

Т.е. вроде всё есть, но чего-то не хватает. А не хватает того, что они живут в директориях, которые не видны линковщику. Для рантайма средство есть через aternatives:

x86_64-linux-gnu_gl_conf
x86_64-linux-gnu_egl_conf

Для девелопмента должен стоять пакет libgl1-mesa-dev. После его установки станет так:

$ ls -l /usr/lib/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 13 марта 12 08:47 /usr/lib/x86_64-linux-gnu/libGL.so -> mesa/libGL.so

Проблема в том, что пакет стоит, а файла нет… Скорее всего были какие-то нюансы при обновлении или ещё чего. Лечится:

sudo apt-get install --reinstall libgl1-mesa-dev

Собственно, не только стек, но и ядро 3.19

Основная ссылка: http://www.opennet.ru/opennews/art.shtml?num=42744

Команда для обновления:

sudo apt-get install --install-recommends linux-generic-lts-vivid xserver-xorg-core-lts-vivid xserver-xorg-lts-vivid xserver-xorg-video-all-lts-vivid xserver-xorg-input-all-lts-vivid libwayland-egl1-mesa-lts-vivid

Стоит отметить, что при наличии PPA xorg-edgers у вас не получится обновиться: нужно сначала вычистить этот PPA и все установленные из него пакеты заменить на дистрибутивные. Но воспользоваться для этого ppa-purge не получится: удивитесь количеству конфликтов.

Я делал вручную по следующему алгоритму…

<WRAP center round alert 60%> ВНИМАНИЕ!!! СЛЕДУЙТЕ ДАННЫМ ИНСТРУКЦИЯМ ТОЛЬКО В СЛУЧАЕ, ЕСЛИ ВЫ РЕАЛЬНО ПОНИМАЕТЕ, ЧТО ДЕЛАЕТЕ. УБИТЬ СИСТЕМУ ТАК ПРОЩЕ ПРОСТОГО.

Перво-наперво: выполняйте команды из чистой консоли, а не из терминала. Если вы не понимаете о чём речь, лучше тут и остановиться.

Далее, для простоты на x86_64 системах стоит удалить i386 пакеты - они ставились, например, при установке Skype, TeamViewer или Wine. Соответсвенно, сами программы тоже снесутся. На всякий случай стоит сохранить список:

dpkg -l | grep :i386 | awk '{print $2}' > i386_list.txt

После чего нужно их удалить:

dpkg -l | grep :i386 | awk '{print $2}' | xargs sudo apt-get remove

Нет стоит использовать purge на этой стадии.

Затем нужно удалить в настройках apt репозиторий xorg-edgers и обновить список пакетов:

sudo apt-get update

После, нужно заменить все пакеты в названии которых (точнее версии) содержатся слова xedgers ,sarvatt и ricotz, а так же пакеты:

• ppa-purge
• wayland
• i915 которые содержатся в данном репозитории, но не соответствует правилам вышеприведённым правилам именования, на пакеты из основного репозитория.

Сделать этом можно в два этапа. Сначала удаляем пакеты игнорируя все зависимости:

dpkg -l | grep 'xedgers<br/>|sarvatt<br/>|ricotz' | awk '{print $2}' | xargs sudo dpkg -r --force-depends ppa-purge wayland i915

Затем восстановить поломанные зависимости:

sudo apt-get install -f

Поставятся уже дистрибутивные пакеты.

После этого можно восстановить i386 пакеты и доставить пакеты ppa-purge, i915, если необходимо.

После данных действий, можно будет обновить стек xorg.

Кусок кода:

    auto ecod = make_error_code(std::errc::resource_unavailable_try_again);
    auto econ = make_error_condition(std::errc::resource_unavailable_try_again);
    assert(ecod == econ);

Согласно документации ассерт не должен срабатывать. Компилятор GCC 4.8 и 4.9 в Linux Mint собирает код и выдаёт такое при запуске:

$ ./webserver
webserver: webserver.cpp:661: int main(int, char**): Assertion `ecod == econ' failed.
Aborted

Внезапно.

GCC 5.1 собирает и нормально обрабатывает ситуацию.

В спеке USB Audio Class есть описание чудного компонента - “Selector Unit (SU)”, который позволяет переключать несколько входов на один выход. Терминах USB спецификации: несколько Input Terminals (IT) к одному Output Terminal (OT). Сразу отмечу, что к каждому юниту может быть прикреплён строковый дескриптор, который его описывает. Если такое поведение не нужно, то ставится ноль и используется имя соответствующей USB функции (UAC в нашем случае) или устройства как такового, если дескриптор для функции тоже не задан, в общем - иерархия.

Но самый смак, как он обслуживается в разных операционных системах. Рассмотрим триаду: Windows (конкретно Win8), Linux (Ubuntu 14.04), MacOSX (TBD).

Windows

У вас 16 входов, между которыми нужно переключаться без потери стрима? Получите 16 отдельных устройств для записи с одинаковыми именами к которым система сама добавит #1, #2 и так далее, начиная со второго! Основой для имени будет выбран тип терминала (Микрофон, к примеру) и имя функции (ну или устройства)! Причём переключаться можно путём выбора дефолтного устройства для записи. Остальные устройства помечаются при этом как временно недоступные. Windows лучше знает, что показывать пользователю: вдруг производитель железки какую каку в имени написал!

UAA появилась ещё в XP, а воз почти и не тронулся. Прекрасный UI.

Linux

Стандартный контрол звука в Юнити входы не увидел. Но показал честно одно устройство. Откуда будет идти звук - гадай (привет pulseaudio!). GNOME Alsa Mixer - вообще какую-то муть вывел. А вот консольный alsamixer, правильно отобразил карту, а при выборе её - селектор для входов. При этом корректно отобразились строковые описания входов. Как обычно для Linux: UI отстрой, консоль рулит!

Возможно - это кривые настройки у убунты. Сегодня проверю на Mint. Но универсальный и самый дружественный способ один: выбрать в alsamixer.

Mac OS X

Версию уточню. Сам не любитель маков. НО! Это единственная система в которой это сделано для человеков: устройство отображается одно, к нему подписывается сколько у него есть входов и выходов и даётся возможность выбрать вход, если он переключается через Selector Unit. Блеск.

Завтра уточню по поводу имён, но, вроде как, аналогично alsamixer, отображает корректно.

Послесловие

А не будет его. Сами выводы делайте. Лучше ссылок чуток накидаю:

• Technical Note TN2274: USB Audio on the Mac
• USB Audio 2.0 Class Driver for Windows - да, из коробки её нету. В Linux есть, в Маках есть, а в Windows нет. Выкусите. Пруфы: раз, два (отсюда по двум редиректам пришел к пункту раз), три
• Спеки на USB классы
• Обзорные статьи по UAC:
  • http://electronix.ru/forum/index.php?act=Attach&type=post&id=19450
  • http://florian.nouwt.com/wiki/index.php/USB_Audio_Class#Selector_Unit - тут иконки для рисования схем можно урвать, жаль, что не SVG :)
  • https://doc.micrium.com/display/USBDDOCV403/Audio+Class+Overview
  • http://york.wikidot.com/usb-audio

Продолжаем отслеживать судьбу изменений, описанных в post/2015/03/29/avcpp_api-2_rework_vexa_pervaja.

Как обычно, объём работ отличается от того, что было запланировано. Итак, что сделано:

1. Работа со словарями и поддержка оных во всех местах, где только можно. Это вызвало необходимость разнести открытие входного потока и поиск информации о стриме ( post/2015/07/20/snova_ffmpeg_i_low-latency). Как следствие, добавился новый вызов: av::FormatContext::findStreamInfo(). Он может принимать коллекцию словарей для каждого стрима в потоке.
2. Начата работа над фильтрами. Уже появилась базовая инфраструктура. Но пока нет понимания в каком виде оно должно получиться на выходе.
3. В рамках чистки кода тотально переработана обработка ошибок. Теперь это делается через std::error_code, который передаётся опциональным аргументом в те функции фейл которых может приводить к неоднозначностям в будущем. Если переменная для кода ошибки не передана, будет выброшено исключение av::Exception которое будет содержать данный код. Планируется, что набор исключений расширится под каждую сущность. Данные изменений повлекли достаточно сильные изменений в API, требующие изменений в коде приложений, которые их используют. При обработке ошибок стоит учитывать категорию оных. На дынный момент используется, как минимум три: * avcpp_category() - для внутренних ошибок AvCpp * ffmpeg_category() - для ошибок, пришедших от FFmpeg * system_category() - для системных ошибок, в основном так рапортуются ошибки выделения памяти при помощи встроенных av_alloc() (когда владение принимается FFmpeg’ом и он сам освобождает, как следствие, использовать new/new[] нет возможности). Целесообразность использовать std::bad_alloc обдумывается.

Ну и главное, реорганизация бранчей:

• все наработки первой вехи выделены в отдельный бранч api-2.0 (исправляются только ошибки)
• старый мастер стал бранчем api-legacy (для совместимости, самостоятельно тут ничего не исправляется, только принимаются мерж-реквесты)
• вся разработка перемещена на бранч master

Что осталось:

1. Интерфейс опций
2. Доделать фильтры
3. Ревизия и чистка кода в т.ч. примеров.

Планируется, что это будет сделано в следующей, третье вехе.

Как обычно, за отзывы, багрепорты и пул-реквесты буду благодарен.

Для начала: создал репозиторий PPA, куда буду с разной периодичностью бубликовать снапшот QtC из master-бранча. Кроме того, туда же поместил свой плагин CMakeProjectManager2:

https://launchpad.net/~adrozdoff/+archive/ubuntu/qtcreator-git

Установка:

sudo add-apt-repository ppa:adrozdoff/qtcreator-git
sudo apt-get update
sudo apt-get install qtcrator-git qtcreator-git-plugin-cmake2

Для разработчиков плагинов будет полезен пакет qtcretor-git-dev который ставит в /usr/src/qtcreator-git заголовочники и .pri файлы. Пример использования можно поглядеть в спеках отстройки qtcreator-git-plugin-cmake2:

sudo apt-get install qtcrator-git-dev

Ну а теперь фичи.

Кодовая модель

Уже давно появились приятные дополнительные инструменты вроде “Reparse Externally Changed Files” (удобно при наличии внешних генераторов, тот же протобуф) и “Inspect C++ Code Model…”, позволяющая понять, что не так при парсинге и отослать более вменяемый отчёт.

Сравнительно же недавно появилась возможность задавать индивидуально для каждого файла дополнительные директивы препроцессора: “Additional Preprocessor Directives…”. Очень удобная штука, когда парсинг почему-то затыкается (например какая-то опция может подхватываться из переданных CXXFLAGS) - обозначил и вперёд! Или правишь код на одной системы, а нужно исправить блок для другой: определяем “#define WIN32” и пробуем что получилось. Для быстрого доступа служит иконка с “#” в верхнем правом углу рядом с номером строки и колонки.

GUI

Тоже появилось сравнительно давно, многие просили: открытие в новом окне (Window -> Open in New Window иди Ctrl+E,4). Удобно при навигации и рефакторинге при наличии нескольких мониторов.

CMake

Про свой плагин не пишу. В мейнстриме появилась возможность задавать не один фиксированный cmake, а разные для разных наборов инструментов (Kits).

External Tools

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

Либо вызвать cppcheck на текущий проект, либо… что в голову взбредёт.

Чего хотелось бы, но нет

1. Настройки лицензии (шапки для новых файлов) индивидуально для проекта.
2. Замена отдельных частей Kit индивидуально для проекта
3. Более гибкая система настройки устройств для Baremetal: сейчас устройство намертво привязано к Kit со своими настройками доступа к, примеру, OpenOCD и gdb. Вот для Cypress SDK нужно как минимум два: для основной прошивки и для Bootloader.

Засим пока всё.

В дополнение к моей прошлой заметке: post/2014/09/24/x264_low_latency пару статей на эту же тему, но без привязки к x264:

• Minimizing the initial delay - профилировка цепочки запуска входного потока
• Minimizing the latency in realtime communication

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

• ошибки при чтении фрейма (av_read_frame())
• может случаться примерно такое: https://github.com/h4tr3d/avcpp/pull/7#issuecomment-122670538
• может ещё чего.

В общем, согласно документации:

The above code attempts to allocate an AVFormatContext, open the specified file (autodetecting the format) and read the header, exporting the information stored there into s. Some formats do not have a header or do not store enough information there, so it is recommended that you call the avformat_find_stream_info() function which tries to read and decode a few frames to find missing information.

Суть: просто открыть файл не всегда достаточно, что бы делать предположения о некоторых параметрах файла. Походу, с этим нужно просто смириться или попытаться предпринять меры из ссылки 1, а именно зарезать параметры probesize и analyzeduration в 32 (минимально допустимое значение).

Слишком много параметров сборки появилось. Поэтому на досуге да под эгидой нового продукта наваял правила для сборки кода при помощи CMake: https://github.com/h4tr3d/fx3-cmake

Под виндой нужно обязательно указывать генератор: при использовании cs-make поставляемого вместе с SDK это “MinGW Makefiles”.