Лабиринтное уплотнение представляет собой (как можно догадаться даже из самого названия) создание искусственных барьеров на пути среды, где возникает её турбулентность, которая при достаточно высоких скоростях среды, сама по себе выступает барьером для прохождения потока:
Эдак можно и до колеса с лопатками дооптимизироваться :)
В конфиге написано timeout=30s. Раньше было timeout=5s. Кто-то увеличил значение в три раза. Почему? Git blame показывает, кто это сделал. А вот причина – утеряна.
Надо в commit message писать «зачем поменялось», а не «что поменялось» (это и так по диффу видно).
Складывается впечатление что KasperskyOS как бы не при чем даже в примере который выбран для демонстрации.
В этом примере cross-build.sh собирает образ KasperskyOS с веб-сервером и другими задействованными программами. И затем запускает в QEMU то что получилось. QEMU там "свой", вместе с SDK устанавливается.
По поводу написания конвертера в html. Готовый взять не получится, т.к. логика местами совсем разная. Я пытался что-то посмотреть, но там столько строчек кода...
Не надо переписывать чужой код, надо найти расширяемую библиотеку на своем любимом языке программирования, и написать немножко своего кода для расширения. Все стандартные фичи маркдауна будут обрабатываться готовым, надежным и протестированным кодом из библиотеки. Для нестандартных но полезных найдется множество сторонних расширений. И только что-то свое, уникальное и инновационное придется закодировать самому.
Например, вы пишете на Python. Берете Python-Markdown. Изучаете его Extension API. Пишете и публикуете экстеншн для всего того что вам не хватает.
И все в выигрыше. Вы экономите время, написав совсем немножко кода, а не полноценный парсер с нуля. Комьюнити в выигрыше – можно подключить в свой проект новую фичу парой строчек в конфиге, и не надо изучать 15-й стандарт. Читатели, ждущие вашего контента тоже в выигрыше – они читают вашу новую поэму/пьесу/статью, а не ждут пока автор допилит новый парсер для ее публикации.
Сразу было поставлено жёсткое ограничение: разметка не включает в себя оформительские инструменты, а передаёт только смысловые акценты и структуру текста.
Я бы посоветовал взять готовый парсер маркдауна с максимальным набором нужных для своих задач фич (из коробки, или в уже готовых расширениях). Недостающие фичи реализовать в своих расширениях. А писать вообще всё с нуля... Ну не знаю... Я делился опытом использования markdown для художественной литературы в статье https://habr.com/ru/articles/720584/, там без самописных расширений обошлось.
Эдак можно и до колеса с лопатками дооптимизироваться :)
А потом попросят поиск по всем файлам проекта, воркспейсы, интеграцию с git и другие IDE-фичи… Не лучше ли сделать экстеншн для готового IDE?
Для такого сценария подойдет плагин для IDE. Например:
https://marketplace.visualstudio.com/items?itemName=nickdemayo.vscode-json-editor https://marketplace.visualstudio.com/items?itemName=lal.smart-json-editor https://marketplace.visualstudio.com/items?itemName=slaugaus.visual-json
Надо в commit message писать «зачем поменялось», а не «что поменялось» (это и так по диффу видно).
Перепроверил свои старые статьи десятилетней давности... Всегда писал с длинными тире.
В этом примере
cross-build.shсобирает образ KasperskyOS с веб-сервером и другими задействованными программами. И затем запускает в QEMU то что получилось. QEMU там "свой", вместе с SDK устанавливается.Серьезно? Пост три часа провисел, и никто не оставил коммент про "методы рационального мышления"??? :-)
Помещался:
На закате можно и без фильтра: https://habr.com/ru/articles/393597/
Тем не менее, многие пассажирские самолеты случайно окажутся в тени Луны. А некоторые может даже и специально: Рейс Анкоридж-Гонолулу задержали на 25 минут чтобы порадовать умбрафилов на борту
Когда уже будут результаты? :)
Подойдет тем у кого нет других приложений офиса, а есть только Teams.
В Teams есть настройка:
Не надо переписывать чужой код, надо найти расширяемую библиотеку на своем любимом языке программирования, и написать немножко своего кода для расширения. Все стандартные фичи маркдауна будут обрабатываться готовым, надежным и протестированным кодом из библиотеки. Для нестандартных но полезных найдется множество сторонних расширений. И только что-то свое, уникальное и инновационное придется закодировать самому.
Например, вы пишете на Python. Берете Python-Markdown. Изучаете его Extension API. Пишете и публикуете экстеншн для всего того что вам не хватает.
И все в выигрыше. Вы экономите время, написав совсем немножко кода, а не полноценный парсер с нуля. Комьюнити в выигрыше – можно подключить в свой проект новую фичу парой строчек в конфиге, и не надо изучать 15-й стандарт. Читатели, ждущие вашего контента тоже в выигрыше – они читают вашу новую поэму/пьесу/статью, а не ждут пока автор допилит новый парсер для ее публикации.
https://code.visualstudio.com/api/language-extensions/syntax-highlight-guide
Как вы будете делать две ссылки в одной строке?
Из того комментария:
Совпадение не нужно, у Грубера в стандарте записано: "Any number of underlining =’s or -’s will work".
А вот это категорически приветствую :-)
Я бы посоветовал взять готовый парсер маркдауна с максимальным набором нужных для своих задач фич (из коробки, или в уже готовых расширениях). Недостающие фичи реализовать в своих расширениях.
А писать вообще всё с нуля... Ну не знаю...
Я делился опытом использования markdown для художественной литературы в статье https://habr.com/ru/articles/720584/, там без самописных расширений обошлось.
Про "включения" не особо уловил идею, но похоже вы заново изобретаете admonitions