Чисто декларативная заметка.
Недавно случилась беда: грохнул о бетонный пол свою Platinum Balance F. Пером. Которое сломалось. Осталась такая же ручка с пером M, которая, вроде, всем хороша, но сильно большая подача у неё.
На момент покупки превалировало желание попробовать F перо этого производителя, так как перья F того же Pilot показались слишком уж тонкими и цепкими к бумаге, поэтому вариантов ответа на вопрос: “как уменьшить подачу чернил?” особо не искал. Плюс в голове упорно витала мысль, что таких способов нет.
Но когда не стало ручки, чьё письмо меня более чем устраивало, пришлось выводить из резерва M-ку. И вопрос уменьшения подачи чернил стал очень остро.
Спека PKGBUILD позволяет сделать финт ушами и автоматически сгенерировать пакет с отладочной информацией, которую можно ставить, а можно и не ставить (занимает приличное количество места в распакованном виде).
Ещё эта спека позволяет в один проход создать несколько пакетов. Допустим разделить на основную часть и документацию или общие библиотеки, которые могут использоваться другими приложениями и бинарники.
Всё это становится очень интересным в контексте использования с AUR. Когда я ушёл с Arch Linux, разделённые (split) пакеты в нём были роскошью. Сейчас они поддерживаются. А вот как обстоят дела с помощниками (helpers, далее по тексту: хелперы), которые собирают и устанавливают в систему?
Можно сделать при помощи Netifrc:
Три шага:
- правим /etc/conf.d/net, настраиваем свой интерфейс
IFACE.
- для нужного сетевого интерфейса (
IFACE) делаем симлинк:ln -s /etc/init.d/net.lo /etc/init.d/net.IFACE
- если нужно стартовать автоматом:
rc-update add net.IFACE default
* вручную: service net.IFACE start/stop/restart
Собственно вот такое обновление:
[2017-05-28 10:33] [ALPM] upgraded libelogind (228.3-1 -> 229.3-1)
[2017-05-28 10:34] [ALPM] upgraded elogind (227.2-1 -> 229.3-1)
Самый простой вариант: откатиться. Прочие смотрятся тут:
Прицепом:
UPD: Последнее
обновление (2017-06-20) починило проблему:
- elogind -> 229.6-1
- libelogind -> 229.6-1
Если создать USB-устройство, которое реализует интерфейс пера или тачскрина с абсолютными координатами, задать для осей X и Y значения:
и сделать (эмуляция) хотя бы одно перемещение, то, как минимум, Windows 8, 8.1 и 10 реагируют BSOD и перезагрузкой. Linux работает нормально.
Поход был в прошлом году, вот немного фото:
Собственно, официальнее некуда:
Размеры, рекомендации по типовому использованию и так далее.
Они же - компоненты для поверхностного монтажа. Мне они в последнее время всё больше нравятся для домашнего прототипирования и поделок: меньше занимают места при хранении и если руки дошли до печатной платы, не нужно сверлить кучу дырок. Но маркировка и обилие корпусов - это адъ.
Вот хорошая PDF которая может помочь разобраться:
Дополнительные ссылки:
-
https://en.wikipedia.org/wiki/Surface-mount_technology - тут есть про размеры корпусов в метрических и имперских единицах (становится понятно откуда берутся обозначения типа 1206, 0805), расшифровки аббревиатур (SMD/SMA/SMT/etc)
-
http://www.smd.ru/ - можно использовать как каталог, что бы сориентироваться
- на Али можно поискать наборы для диодов, стабилитронов, транзисторов (китайских популярных)
Пока лучший, что я нашёл, обзор новых фич C++17 с примерами и информацией о поддержке в компиляторах:
А вот обзор от команды Яндекса, которая теперь представляет
РГ21 C++ Россия:
Вот и другие авторы начинают подтягиваться, в том числе - официальные источники:
Или век живи - век учись.
Проблема описана здесь:
https://stdcpp.ru/proposals/1386b162-0cde-49b7-a41e-90f2d9ee477c.
Суть: зачем передавать бинарный предикат и значение, если нужное значение можно временами захватить в лямбду и не передавать вторым аргументом компаратору.
Пробуем включать TransferServices плагин в Blueman и получаем что-то вроде:
Ключевое:
org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'org.bluez.obex': no such name
Исправления два:
- добавить в атозагрузку при логине
/usr/lib/bluetooth/obexd
- подсказать dbus автоматически спавнить его при обращении
Собственно Bluez предоставляет сервис-файл для второго варианта, только он рассчитан на работу с systemd, и поэтому Exec указывает в /bin/false.
Gentoo нам подсказывает:
что нужно вместо /bin/false указать полный путь до obexd, т.е. /usr/lib/bluetooth/obexd. После чего передача файлов волшебным образом заработает сама.
Файл для редактирования: /usr/share/dbus-1/services/org.bluez.obex.service
ЗЫ ссылка на заметку:
ЗЗЫ неприятно что такие сервис-файлы нельзя переопределить через /etc/dbus/service/. Или я не смог?
Буквально сегодня открыл для себя Imported Targets. При использовании их для модулей поиска, очень упрощает и систематизирует код.
Для примера, если вам нужно подключить ZLIB к проекту, при классическом подходе пишется что-то вроде:
cmake_minimum_required (VERSION 3.1)
project(Foo)
find_package(ZLIB)
add_definitions(${ZLIB_DEFINITIONS})
include_directories(${ZLIB_INCLUDE_DIRS})
add_executable(foo_target
main.cpp)
target_link_libraries(foo_target ${ZLIB_LIBRARIES})
Какие проблемы в коде выше?
- Добавляется новая библиотека, нужно не забыть добавить переменные в три места:
1.
add_definitions()
2. include_direcrories()
3. target_link_libraries()
- Мы забыли ключевое слово
REQUIRED в find_package() и узнаем, что у нас нет ZLIB или на компиляции или на линковке (так как других условий и проверок нет, предполагаю: данная библиотека необходима).
- Область действия
add_definitions() и include_directories() - глобальная (на самом деле нет: все таргеты в текущем CMakeLists.txt во всех далее включённых, но не суть) и распространяется на все таргеты. Что не есть хорошо.
Возможно что-то ещё, чего я не заметил.
Последний пункт можно обойти уже написав более навороченный код:
cmake_minimum_required (VERSION 3.1)
project(Foo)
find_package(ZLIB)
add_executable(foo_target
main.cpp)
target_include_directories(foo_target ${ZLIB_INCLUDE_DIRS})
target_compile_definitions(foo_target ${ZLIB_DEFINITIONS})
target_link_libraries(foo_target ${ZLIB_LIBRARIES})
От проблемы глобальности ушли, но остальные две остались.
А вот, начиная с CMake 3.1 код выше можно переписать так:
cmake_minimum_required (VERSION 3.1)
project(Foo)
find_package(ZLIB)
add_executable(foo_target
main.cpp)
target_link_libraries(foo_target
ZLIB::ZLIB)
И теперь правильно подтянутся и параметры для компиляции, причём только для указанного таргета, и параметры линковки. А кода стало меньше. Более того, если библиотека не найдена, то цели ZLIB::ZLIB существовать не будет и вызов cmake завершится с ошибкой. А чем раньше ошибка вылазит - тем лучше.
Как это делается? А достаточно просто, маинтейнеру модуля поиска нужно в конце добавить строчки вида:
if (ZLIB_FOUND AND NOT TARGET ZLIB::ZLIB)
add_library(ZLIB::ZLIB UNKNOWN IMPORTED)
set_target_properties(ZLIB::ZLIB PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${ZLIB_INCLUDE_DIRS}"
INTERFACE_COMPILE_OPTIONS "${ZLIB_DEFINITIONS}"
INTERFACE_LINK_LIBRARIES "${ZLIB_LIBRARIES}")
endif()
Код для FindZLIB.cmake на самом деле несколько другой, но общую суть он отражает.
Соглашение для таких тергетов простое:
PkgName::PkgComponent
где PkgName соответствует имения пакета, которое передаётся в find_package() (или имя модуля без префикса Find и суффикса .cmake), а PkgComponent - внутренний компонент внутри модуля. Если такой компонент один, он соответствует PkgName. Примеры:
ZLIB::ZLIBThreads::ThreadsQt::Widgets (см FindQt.cmake)
Кстати, вместо проверки:
if (ZLIB_FOUND)
Можно использовать:
if (TARGET ZLIB::ZLIB)
да, более многословно, но везде фигурирует только одно имя таргета.
Кроме того, эти таргеты можно использовать и совместно с target_include_directories() и target_compile_definitions().
В общем, я крайне рекомендую в свои модули добавить несколько строчек, которые привнесут несколько большей унификации. От старых добрый переменных вас тоже никто отказываться не заставляет :)
ЗЫ ЕМНИП то такой синтаксис можно было использовать и до 3.1, с 3.1 оно появилось в некоторых модулях, которые поставляются с самим CMake.
Иногда приходится использовать mainline не из основных репозиториев, а отсюда:
Причин тому может быть несколько. Начиная от желания быть на острие атаки, и заканчивая тем, что на новых ядрах решена проблема характерная для вашего железа или другого окружения. У меня, к примеру, только с 4.10 перестал уходить в тотальный перегрев процессор при использовании Turbo Boost.
Беда этих ядер, что нет полезных пакетов linux-tools, которые требуются таким приложениям как perf и turbostat. И их нужно собрать самому, причём так, что бы они соответствовали версии ядра. Рассмотрим как это сделать, на примере 4.10.
