Для приготовления шаблонизатора mustach нам понадобится postgres и mustach. Можно также воспользоваться готовым образом.

Зачем нужен шаблонизатор в базе? Ну, во-первых, если шаблонизатор в базе, то и сами шаблоны тоже должны быть в базе. А зачем нужно хранить шаблоны в базе? Да потому, что шаблоны, как и данные, тоже могут зависеть от времени. Например, пусть в базе есть счета (это данные). Очевидно, что они зависят от времени: в этом месяце сумма одна, в следующем — другая, потом — третья и т.д. Но и шаблон счёта тоже может зависеть от времени: в этом году один, а в следующем уже другой (как это было с введением 20% ). Поэтому удобнее сами шаблоны тоже хранить в базе. Ну а шаблонизатор в базе удобен тем, что можно тут же в базе шаблонизировать, потом (тут же в базе) преобразовать в pdf и (тут же в базе) отправить на email. И всё это можно сделать асинхронно с помощью планировщика.

Цитата из документации GCC [1]:

Атрибут cleanup предназначен для запуска функции, когда переменная выходит из области видимости. Этот атрибут может быть применён только к auto-переменным, и не может быть использован с параметрами или с static-переменными. Функция должна принимать один параметр, указатель на тип, совместимый с переменной. Возвращаемое значение функции, если оно есть, игнорируется.

Если включена опция -fexceptions, то функция cleanup_function запускается при раскрутке стека, во время обработки исключения. Отметим, что атрибут cleanup не перехватывает исключения, он только выполняет действие. Если функция cleanup_function не выполняяет возврат нормальным образом, поведение не определено.



Атрибут cleanup поддерживается компиляторами gcc и clang.

В этой статье я приведу описание различных вариантов практического использования атрибута cleanup и рассмотрю внутреннее устройство библиотеки, которая использует cleanup для реализации аналогов std::unique_ptr и std::shared_ptr на языке C.

Я ловлю в далёком отголоске,
Что случится на моём веку.
(«Гамлет», Борис Пастернак)

Признаться, пишу на чистом C я не так уж и часто и за развитием языка уже давно не слежу. Но тут произошло два неожиданных события: С вернул себе звание популярнейшего языка программирования по версии TIOBE и случился анонс первой за долгие годы действительно интересной книги, посвящённой этому языку. Поэтому я провёл несколько вечеров за изучением материалов о C2x — следующей версии C.

Самыми, на мой взгляд, интересными нововведениями я и хочу поделиться с читателями Хабра.

Выкладываем оставшуюся часть перевода на русский руководства, несколько устаревшего, однако не потерявшего своей актуальности, поскольку этот учебник помогает вникнуть в «кухню» создания видеоприложений с помощью библиотек FFmpeg и SDL.

И хотя мы старались, в таком объёмном тексте неизбежны трудности перевода. Сообщайте о недочётах (желательно, в личных сообщениях) — вместе сделаем лучше.

Оглавление

Для приготовления получения типов колонок за один запрос нам понадобится postgres. Можно также воспользоваться готовым образом.

В данной публикации представлена транскрипция вебинара «Всесторонний статический анализ с применением продуктов Polyspace». Вебинар проводил Михаил Песельник, инженер ЦИТМ Экспонента).

Цель всех процессов разработки и верификации ПО заключается в том, чтобы убедиться в том, что в финальном программном обеспечении больше нет дефектов. Почему так важно убедиться, что ПО является надежным? Давайте подумаем о последствиях и затратах, связанных с ошибками в программном обеспечении.

Многим известна проблема трёхмерной графики — отсутствие легковесных кроссплатформенных решений в вопросе вывода текста.

Большинство реализаций позволяет использовать выбранный шрифт в виде текстуры. Публикуемая библиотека ttf2mesh реализует другой способ — она преобразует векторные символы TrueType шрифта в сеточные объекты. Это позволяет выводить текст в виде набора треугольников.

Такой подход имеет как важные преимущества, так и недостатки. Сложность описываемой далее задачи и созерцание великолепных форм шрифтового дизайна доставили массу удовольствия при разработке. Надеюсь, и Вам понравится.

В октябре 2019 года со мной случилась школа программирования 42, находящаяся во Фримонте, штат Калифорния. По возвращении из неё я упорно отказывалась отвечать на различные вопросы об учёбе и избегала делиться своими впечатлениями. Нужно было время прийти в себя. Более полугода спустя я готова рассказать свою историю о, возможно, самом необычном опыте в моей жизни.

От переводчика: предлагаю вашему вниманию перевод очень старой статьи, опубликованной 15 января 1983 года. Несмотря на столь внушительный возраст, статья показалась мне интересной, и возможно, что она будет полезной для кого-то и сегодня. На эту статью, кстати, ссылается раздел справки man locate(1) на opennet.ru: https://www.opennet.ru/man.shtml?topic=locate.

Краткое содержание

Статья описывает механизм быстрого поиска файлов в UNIX. Он объединяет два метода компрессии данных с новой техникой поиска строк, и предназначен для быстрого поиска произвольных файлов. Код, интегрированный в стандартную утилиту find, производит поиск в предварительно созданной базе данных, обновляемой ежедневно. Это отличает его от обычного механизма поиска совпадений ключа с кандидатами, которые генерируются «на лету» из разбросанной (по диску) структуры директорий.

База данных путей к файлам является инкрементально-кодированным, отсортированным в лексикографическом порядке списком (иногда называемом «сжатым спереди» файлом), который также подвергнут обычному биграмному кодированию с целью получения эффективного сжатия. Коэффициент сжатия составляет от 5 до 6 по сравнению с обычным ASCII-представлением. Список сканируется с использованием модифицированного линейного поиска, специально приспособленного для инкрементального кодирования, при этом типичное время, затрачиваемое алгоритмом, на 40-50% меньше, чем обычный поиск.

Только что вышла первая версия разработанного мной статически типизированного встраиваемого скриптового языка Umka. Он призван сочетать гибкость привычных скриптовых языков с защитой от ошибок типов на этапе компиляции в байт-код. Основная идея языка — Explicit is better than implicit — позаимствована из «дзена Python», однако должна приобрести здесь несколько иной и более очевидный смысл.

Сколь бы частными и субъективными ни были впечатления, побудившие меня взяться за разработку языка, я надеюсь, что замысел оказался не наивным. Под катом я кратко расскажу о возможностях языка и мотивах его создания.

Хотя данная информация уже устарела, оригинальный материал и по сей день является популярным источником вдохновения для различного полезнейшего контента по теме FFmpeg. При этом полного перевода оригинала на русский язык до сих пор нет. Исправляем досадное упущение, ибо лучше поздно, чем никогда.

И хотя мы старались, в таком объёмном тексте неизбежны трудности перевода. Сообщайте о недочётах (желательно, в личных сообщениях) — вместе сделаем лучше.

Оглавление

Спойлер: C++ не быстрее и не медленнее и вообще смысл не в этом. Эта статья является продолжением славных традиций развенчания мифов крупных российских компаний о языке Rust. Предыдущая была "Go быстрее Rust, Mail.Ru Group сделала замеры".

Недавно я пытался заманить коллегу, сишника из соседнего отдела, на Тёмную сторону Rust. Но мой разговор с коллегой не задался. Потому что, цитата:

В 2019 году я был на конференции C++ CoreHard, слушал доклад Антона antoshkka Полухина о незаменимом C++. По словам Антона, Rust еще молодой, не очень быстрый и вообще не такой безопасный.

Антон Полухин является представителем России в ISO на международных заседаниях рабочей группы по стандартизации C++, автором нескольких принятых предложений к стандарту языка C++. Антон действительно крутой и авторитетный человек в вопросах по C++. Но доклад содержит несколько серьёзных фактических ошибок в отношении Rust. Давайте их разберём.

Embox – это кросс-платформенная мультизадачная операционная система реального времени для встраиваемых систем. Она рассчитана на работу в условиях невысоких вычислительных ресурсов и позволяет запускать Linux-приложения на микроконтроллерах без использования самого Linux. Конечно, как и любые другие приложения, Embox баги тоже не обошли стороной. Данная статья посвящена разбору ошибок, найденных в коде проекта Embox.

Материал статьи взят с моего дзен-канала.

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

Отладка крафтовых фильтров

После того, как мы в предыдущей статье рассмотрели механизм перемещения данных в медиастримере будет логично поговорить о скрывающихся в нем опасности. Одна из особенностей принципа "data flow" состоит в том, что выделение памяти из кучи происходит в фильтрах, которые находятся у истоков потока данных, а освобождение памяти с возвращением в кучу делают уже фильтры, расположенные в конце пути потока. Кроме этого, создание новых данных и их уничтожение может происходить где-то в промежуточных точках. В общем случае, освобождение памяти выполняет не тот фильтр, что создал блок данных.

Я продолжаю цикл статей о языке программирования MSH. В одной из предыдущих статей я уже описывал спецификацию этого языка. Но спецификация не раскрывает всех особенностей языка. Тот пробел я и хочу устранить этой статьей. Не все конечно удалось описать, но в основном главные особенности вроде описал. Остальное отложим до лучших времен.

Когда только складывается образ языка, кажется что все логично и непротиворечиво. Но входе реализации языка возникают проблемы, которые приходится решать выбирая ту или иную стратегию. Сейчас когда интерпретатор языка готов, можно увидеть каким образом решал те или иные проблемы реализации.

Материал статьи взят с моего дзен-канала.

Механизм перемещения данных

• Блок данных dblk_t
• Сообщение mblk_t
• Функции работы с сообщениями mblk_t
• Очередь queue_t
• Функции работы с очередями queue_t
• Соединение фильтров
• Сигнальная точка графа обработки данных
• Закулисная деятельность тикера
• Буферизатор MSBufferizer
• Функции работы с MSBufferizer

В прошлой статье мы разработали свой собственный фильтр. Эту статью мы посветим устройству внутреннего механизма перемещения данных между фильтрами медиастримера. Это позволит в дальнейшем писать изощренные фильтры с меньшими усилиями.

DLL & Python

Недавно меня заинтересовала тема использования DLL из Python. Кроме того было интересно разобраться в их структуре, на тот случай, если придется менять исходники библиотек. После изучения различных ресурсов и примеров на эту тему, стало понятно, что применение динамических библиотек может сильно расширить возможности Python. Собственные цели были достигнуты, а чтобы опыт не был забыт, я решил подвести итог в виде статьи — структурировать свой знания и полезные источники, а заодно ещё лучше разобраться в данной теме.

Под катом вас ожидает статья с различными примерами, исходниками и пояснениями к ним.

В качестве входных данных выступает массив типа float. Программа организует отображение, растягивание, прокрутку графика.

Полгода назад мне захотелось создать лучший генератор псевдослучайных чисел (ГПСЧ) с какой-нибудь необычной архитектурой. Я думал, что начало будет лёгким, а по мере работы задача станет медленно усложняться. И думал, смогу ли я научиться всему достаточно быстро, чтобы справиться с самым сложным.

К моему удивлению, сложность возрастала не линейно. Побайтовое тестирование по критерию хи-квадрат оказалось очень трудным! Позднее столь же трудно было пройти тесты diehard. Я опубликовал текущие результаты, чтобы понять, какие ещё трудности меня ожидают. Однако тест PractRand в тот раз пройти не удалось.

Затем было очень трудно прохождение теста BigCrush.

Затем было очень трудно передавать 32 тебибайта данных при прохождении PractRand. Скорость стала проблемой. Мало было создать конструкцию, генерирующей десять мегабайтов в секунду, потому что прохождение PractRand заняло бы месяц. Но должен признаться, что пройти этот тест со скоростью гигабайт в секунду было очень трудно.

Недавно на просторах интернета мной был обнаружен физический движок Newton Game Dynamics. Зная, что в таких проектах обычно большой объём сложного кода, я подумал, что будет интересно проверить его статическим анализатором PVS-Studio. Мой энтузиазм ещё больше подстегнуло то, что мой коллега Андрей Карпов уже проверял данный проект в 2014 году, а значит, это ещё и хорошая возможность продемонстрировать развитие нашего анализатора за последние шесть лет. Также стоит отметить, что на момент написания статьи последний релиз Newton Game Dynamics датирован 27 февраля 2020 года, то есть данный проект тоже активно развивается последние 6 лет. Таким образом, надеюсь, что помимо нашей команды, данная статья будет интересна и разработчикам движка, которые смогут избавиться от некоторых багов и исправить свой код.