Добрая статья:
http://www.mount.ru/shop/dir.php?id=235 в целом соответствует моему опыту использования газа.
Конспективно:
- Минимальный: 30 грамм/человек/день
- пожалуй только на Jet Boil и прочих интегрированных системах или котелками с радиаторами плюс использование горелки только доведения до кипения и запаривание еды. У самого такого расхода не получалось.
- Стандартный: 60-90 грамм/человек/день
- в т.ч. готовка риса, гречки, но отсутствие топления снега и льда. Вода от 7-10 градусов. Каши из перловки и кукурузы - в пролёте. Наличие ветрозащиты. Котёл 2.7 л, для горелок, Ковея, алюминиевый.
- при наличии опыта общения с газовым оборудованием, использовании котлов с теплообменниками и эффективных горелок, можно рассчитывать на 40-50 грамм/человек/день. Но! Пока не наберёте свою статистику, лучше закладывать 60.
- Экстремальный: от 100 до 300, а то и выше грамм/человек/день
- топление снега, готовка на большой высоте: на берельском седле, по ощущениям, потребление было около 120 грамм.
- отсутсвие защитных ветровых стенок, экранов, неэффективные (костровые: с овальным дном или с нагаром, который является отличнымтеплоизолятором) или слишком большие котлы (больше 2-3 литров - уже много потерь, нужно озадачиться теплотканью).
Выводы:
- В низкогорье (до 2000-2500 м) и на равнине при отсутствии топления снега при готовке (т.е. будете не просто запаривать, а варить) можете уложиться в 60-70 грамм и меньше
- При топлении снега увеличьте до 90-100
- При увеличении высоты доведите до 120
Иногда получается комбинировать, к примеру:
- на Jet Boil или чём-то подобном натопить и накипятить воды и залить в термосы
- основное блюдо приготовить на горелке добавляя туда уже подогретую и натопленную воду
Стоить отметить, что готовка без наблюдения, при использовании котлов с нагаром (например, костровых), при пониженных температурах, при повышенных высотах всегда будет увеличивать расход газа.
При таком раскладе, расход выше чем чисто на 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 и обновить список пакетов:
После, нужно заменить все пакеты в названии которых (точнее версии) содержатся слова 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
Затем восстановить поломанные зависимости:
Поставятся уже дистрибутивные пакеты.
После этого можно восстановить 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, отображает корректно.
Послесловие
А не будет его. Сами выводы делайте. Лучше ссылок чуток накидаю:
Продолжаем отслеживать судьбу изменений, описанных в
post/2015/03/29/avcpp_api-2_rework_vexa_pervaja.
Как обычно, объём работ отличается от того, что было запланировано. Итак, что сделано:
- Работа со словарями и поддержка оных во всех местах, где только можно. Это вызвало необходимость разнести открытие входного потока и поиск информации о стриме (
post/2015/07/20/snova_ffmpeg_i_low-latency). Как следствие, добавился новый вызов:
av::FormatContext::findStreamInfo()
. Он может принимать коллекцию словарей для каждого стрима в потоке.
- Начата работа над фильтрами. Уже появилась базовая инфраструктура. Но пока нет понимания в каком виде оно должно получиться на выходе.
- В рамках чистки кода тотально переработана обработка ошибок. Теперь это делается через
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
Что осталось:
- Интерфейс опций
- Доделать фильтры
- Ревизия и чистка кода в т.ч. примеров.
Планируется, что это будет сделано в следующей, третье вехе.
Как обычно, за отзывы, багрепорты и пул-реквесты буду благодарен.
Для начала: создал репозиторий 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).
Данный функционал оооочень давно в QtC, но очень многие его не замечают. А ведь очень много проблем можно решить с его помощью. К примеру: править исходники локально, а потом засабмитить на билд-сервер и выполнить на нём процедуру билда. Если чуть поднапрячься, можно и парсинг ошибок разобрать.
Либо вызвать cppcheck на текущий проект, либо… что в голову взбредёт.
Чего хотелось бы, но нет
- Настройки лицензии (шапки для новых файлов) индивидуально для проекта.
- Замена отдельных частей Kit индивидуально для проекта
- Более гибкая система настройки устройств для Baremetal: сейчас устройство намертво привязано к Kit со своими настройками доступа к, примеру, OpenOCD и gdb. Вот для Cypress SDK нужно как минимум два: для основной прошивки и для Bootloader.
Засим пока всё.
В дополнение к моей прошлой заметке:
post/2014/09/24/x264_low_latency пару статей на эту же тему, но без привязки к x264:
Стоит отметить, что в первой статье наихудшие показатели показала avformat_find_stream_info()
, эта же функция не понравилась коллеге на работе, но без неё могут быть такие артефакты:
В общем,
согласно документации:
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”.
Сегодня для себя открыл:
-
http://habrahabr.ru/company/nerepetitor/blog/256317/
-
https://ru.wikipedia.org/wiki/%D0%A1%D0%BA%D0%BE%D0%BB%D1%8C%D0%B7%D1%8F%D1%89%D0%B0%D1%8F_%D1%81%D1%80%D0%B5%D0%B4%D0%BD%D1%8F%D1%8F
хотя, как оказывается, уже использовал раньше (в варианте простого скользящего). Только не знал, что это общеизвестный приём.