Cross Posting Test
Проверка кросс-постинга.
Проверка кросс-постинга.
Пост - мемориз.
Не всегда рисовать таблицы в Markdown разметке удобно, особенно добавлять/удалять колонки (со строками всё намного проще). Да и просто следить за соответствием вводимых данных конкретной колонке. И вот совершенно случайно набрёл на ресурс: Tables Generator
А конкретно: Markdown Tables Generator
В визуальной форме вводятся данные таблицы, потом нажимаем Generate и копируем полученный код в текст. Просто.
Для редактирования можно скопировать таблицу и импортировать её через “File → Paste table data…”, естественно при условии корректности данных. Кроме того, можно данные для таблицы импортировать из CSV (“File → Import CSV File…”), как работает эта функция я не проверял, скорее всего могут возникнуть проблемы с пробелами или разделителями.
Что ещё? Вообще там можно создавать таблицы не только в разметке Markdown, а в:
Схожие ресурсы:
QMapShack умеет работать с сетевыми картами, которые представлены в виде тайлов с определённым соглашением о вызове. Что бы работать с подобными сервисами нужно создать файл-описание с расширением .tms
. Описание формата можно
почитать здесь.
До недавнего времени я обходился в основном картами OpenCycleMap, TMS файл для которых идёт вместе с QMS. А для нужных районов уже искал/скачивал листы карт ГГЦ (в народе: “новый” генштаб) и делал им обвязку в виде .vrt
файла (такие карты содержать описание нужных преобразований, не затрагивая самих исходников карты, тем самым можно делать “обрезку карт” и они понимаются всем, что использует GDAL).
Но это дело малость меня достало и захотелось быстро под рукой иметь и ГГЦ карты. Естественно, при условии наличия доступа к сети и доступности сервисов.
Что возвращать из обработчика IOCTL в user-space если данный IOCTL не поддерживается? В нашем драйвере активно использовался ENOIOCTLCMD
. Проблема в том, что он объявлен в linux/errno.h
в заголовке которого написано (вольный перевод):
не использовать в пользовательском коде
В данном случае, под пользовательским кодом стоит понимать всё, что не собирается в дереве ядра. Кто-то может не согласить со мной в этом аспекте, но по соображениям переносимости - лучше этому следовать.
Кроме того:
errno.h
/cerrno
;strerror()
вернёт что-то вроде: Unknown error 515
(номер может и отличаться);Что использовать-то? А использовать не совсем очевидный: ENOTTY
.
Изначально, да и согласно комментариям в include/uapi/asm-generic/errno-base.h
:
Not a typewriter
При этом утилита пользовательского пространства errno
из комплекта
moreutils
говорит:
ENOTTY 25 Inappropriate ioctl for device
Дополнительными аргументами:
В чём же отличие? Нашёл отличное объяснение в
block/ioctl.c
:
* Is it an unrecognized ioctl? The correct returns are either
* ENOTTY (final) or ENOIOCTLCMD ("I don't know this one, try a
* fallback"). ENOIOCTLCMD gets turned into ENOTTY by the ioctl
* code before returning.
Не буду переводить, просто поясню: ENOIOCTLCMD
используется во внутренних реализациях, когда есть предположение, что обработку можно выполнить в каком-то стандартном русле, выполнить т.н. fallback. В пользовательское пространство должен вернуться ENOTTY
. Точка.
Буквально вчера столкнулся с таким вот поведением QtC:
С учётом того, что я собираю QtC из исходников master-ветки репозитория, первая мысль была: что-то поломали, нужно по быстрому разобраться и откатить. Но всё оказалось чуточку интереснее. Кому интересно - добро пожаловать под кат.
И снова из разряда рекомендаций для чтения и изучения, можно сказать, в продолжение Practical Guide to Bare Metal C++.
Очень много полезной информации в части применимости современного C++ для embedded разработки и не только.
К примеру, там очень интересный цикл статей “Exploring Startup Implementations”, который позволяет разобраться в C++ Runtime:
Или серии:
PS там же наткнулся на рекламу книжки “Real Time C++”, добавил в свой список.
Для Windows драйвер писать в QtC никто в здравом уме и трезвой памяти не будет. Поэтому речь дальше по процессу разработки драйвера для Linux. Я не буду касаться вопросов использования отладчика (KGDB), в основном посмотрим на вопросы запуска модуля ядра на удалённой системе.
Вот книжки, “Современные операционные системы” уже ушла все книги ушли:
Самовывоз.
По ссылке ниже вполне доходчивая инструкция:
В современном мире рекомендуется не использовать include_directories()
и target_include_directories()
, а экспортировать таргет в стиле пространства имён: Target::Target
, например так:
add_library(avcpp avcpp.cpp ...)
...
add_library(AvCpp::AvCpp ALIAS avcpp)
и задавать интерфейсные опции для таргета, например так:
target_include_directories(avcpp
INTERFACE
$<BUILD_INTERFACE:${CMAKE_CURRENT_LIST_DIR}>
$<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>
)
После чего задавать параметры как линковки, так и компиляции одной командой:
add_executable(foo main.cpp)
...
target_link_libraries(foo PUBLIC AvCpp::AvCpp)
Так вот, если вы используете CMake версии до 3.12, то такой подход не сработает для OBJECT_LIBRARY.
Иными словами, если вы решите пробросить параметры компиляции (не линковки) таким образом:
add_library(foo_common OBJECT foo.cpp)
target_link_libraries(foo_common PUBLIC AvCpp::AvCpp)
То получите сообщение об ошибке, примерно такого вида:
CMake Error at tests/CMakeLists.txt:10 (target_link_libraries):
Object library target "foo_common" may not link to anything.
В общем, читаем:
Решения:
target_include_directories()
;include_directories()
, но лучше не надо;Вопрос, а как можно из командной строки, установить DMG или tar.gz пакет CMake с cmake.org? Второй это просто тарбол, с определённой структурой, можно ли просто распаковать и установить PATH, указывающий на bin
директорию внутри?