Проверка кросс-постинга.

Пост - мемориз.

Не всегда рисовать таблицы в Markdown разметке удобно, особенно добавлять/удалять колонки (со строками всё намного проще). Да и просто следить за соответствием вводимых данных конкретной колонке. И вот совершенно случайно набрёл на ресурс: Tables Generator

А конкретно: Markdown Tables Generator

В визуальной форме вводятся данные таблицы, потом нажимаем Generate и копируем полученный код в текст. Просто.

Для редактирования можно скопировать таблицу и импортировать её через “File → Paste table data…”, естественно при условии корректности данных. Кроме того, можно данные для таблицы импортировать из CSV (“File → Import CSV File…”), как работает эта функция я не проверял, скорее всего могут возникнуть проблемы с пробелами или разделителями.

Что ещё? Вообще там можно создавать таблицы не только в разметке Markdown, а в:

• LaTeX
• HTML
• Text
• MediaWiki (вот где абсолютный треш!)

Схожие ресурсы:

• TableConvert Online - в каком-то смысле, возможностей больше, но есть мелочи, например: нельзя задать выравнивание колонки.
• Typora - редактор Markdown, есть встренный редактор таблиц.
• Расширения для VSCode:
  • https://marketplace.visualstudio.com/items?itemName=RomanPeshkov.vscode-text-tables
  • https://marketplace.visualstudio.com/items?itemName=TomasHubelbauer.vscode-markdown-table-format
• Расширения для Atom:
  • https://atom.io/packages/markdown-table-editor

QMapShack умеет работать с сетевыми картами, которые представлены в виде тайлов с определённым соглашением о вызове. Что бы работать с подобными сервисами нужно создать файл-описание с расширением .tms. Описание формата можно почитать здесь.

До недавнего времени я обходился в основном картами OpenCycleMap, TMS файл для которых идёт вместе с QMS. А для нужных районов уже искал/скачивал листы карт ГГЦ (в народе: “новый” генштаб) и делал им обвязку в виде .vrt файла (такие карты содержать описание нужных преобразований, не затрагивая самих исходников карты, тем самым можно делать “обрезку карт” и они понимаются всем, что использует GDAL).

Но это дело малость меня достало и захотелось быстро под рукой иметь и ГГЦ карты. Естественно, при условии наличия доступа к сети и доступности сервисов.

Что возвращать из обработчика IOCTL в user-space если данный IOCTL не поддерживается? В нашем драйвере активно использовался ENOIOCTLCMD. Проблема в том, что он объявлен в linux/errno.h в заголовке которого написано (вольный перевод):

не использовать в пользовательском коде

В данном случае, под пользовательским кодом стоит понимать всё, что не собирается в дереве ядра. Кто-то может не согласить со мной в этом аспекте, но по соображениям переносимости - лучше этому следовать.

Кроме того:

• этого кода нет в пользовательских errno.h/cerrno;
• для этого когда strerror() вернёт что-то вроде: Unknown error 515 (номер может и отличаться);
• константы для этого кода ошибки нет на других платформах (Windows, MacOSX, FreeBSD).

Что использовать-то? А использовать не совсем очевидный: ENOTTY.

Изначально, да и согласно комментариям в include/uapi/asm-generic/errno-base.h:

Not a typewriter

При этом утилита пользовательского пространства errno из комплекта moreutils говорит:

ENOTTY 25 Inappropriate ioctl for device

Дополнительными аргументами:

• интернеты тоже подсказывают такую трактовку;
• в ядре Linux оно используется по такому же назначению.

В чём же отличие? Нашёл отличное объяснение в 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:

1. A General Overview of What Happens Before main()
2. Exploring Startup Implementations: Newlib (ARM)
3. Exploring Startup Implementations: OS X

Или серии:

• Embedded Cpp Series
• Migrating from C to Cpp

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.

В общем, читаем:

• https://gitlab.kitware.com/cmake/cmake/issues/18010

Решения:

• Обновляем CMake, к сожалению, на travis.org для OSX пока это сделать трудно, там через brew ставится, на момент написания статьи, 3.11.4;
• Используем target_include_directories();
• Используем как и раньше include_directories(), но лучше не надо;
• Не используем Object Library, что не всегда удобно.

Вопрос, а как можно из командной строки, установить DMG или tar.gz пакет CMake с cmake.org? Второй это просто тарбол, с определённой структурой, можно ли просто распаковать и установить PATH, указывающий на bin директорию внутри?