Компиляторы *

Всем привет! Меня зовут Ефимов Михаил, я профессиональный разработчик с 2010 года и начинающий contributor в CPython.

Итак, название статьи говорит, что генераторные выражения сломаны. О чем вообще речь? Посмотрим на такой код, не содержащий никаких import:

g = (x for x in range(10))
g.gi_frame.f_locals['.0'] = range(20)
list(g)

Устанавливаем с официального сайта новенький Python 3.13.0. Запускаем интерпретатор в режиме консоли, копируем в консоль эти строки кода, ожидаем увидеть содержимое списка...

А содержимого никакого нет, да и консоль закрылась - интерпретатор завершил работу. В зависимости от того, на какой операционной системе был запущен код, будет сформирован Segmentation Fault или его вариации. Например, Windows использует обозначение STATUS_ACCESS_VIOLATION, но суть та же.

Что ж, всё честно, crash на месте, а теперь давайте разбираться, что вообще произошло. Благо, строчек у нас всего три, так что мы можем подробно описать все объекты, вызовы методов и функций.

Этой статьей начинаю краткий цикл о трех языках программирования, знакомство с которыми считаю очень важным для любого профессионала в программировании: Форт, Лисп и Оберон.

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

Команда Rust рада сообщить о новой версии языка — 1.82.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.

Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.82.0 вам достаточно выполнить команду:

$ rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.

Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках.

Привет, Хабр! Меня зовут Алексей Салтыков, я инженер-программист в команде КОМПАС-3D. Решил поделиться соображениями насчет оптимизаций в С++ глазами обычного разработчика. Хочется сразу предупредить, что статья никого ни к чему не призывает. Цель – наглядно показать, как незначительные трансформации кода могут помочь компилятору лучше оптимизировать код и насколько это вообще эффективно.

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

В ходе такой работы нам исключительно пригодился подход под названием «дата-ориентированное проектирование». Это идея, согласно которой при структурировании кода требуется отталкиваться от специфики тех данных, с которыми приходится работать.

Дата-ориентированное проектирование часто используется при программировании игр, где именно от скорости среды выполнения зависит, что вы сможете и чего не сможете сделать. В последнее время эта парадигма стала активнее применяться и в других предметных областях, например, в разработке компиляторов для Zig и Rust, а также в других проектах, где акцент делается на ускорении среды выполнения, например, в  Mold и Bun.

Эндрю Келли, создатель Zig, выступил с отличной лекцией Practical Data-oriented design, которая служит введением в основные идеи, лежащие в основе DoD. В этой статье я покажу, как мы изменили компилятор roc, переработав его с учётом некоторых из этих идей.

В этом посте разобраны некоторые фокусы, причуды и фичи языка C (некоторые из них – весьма фундаментальные!), которые, казалось бы, могут сбить с толку даже опытного разработчика. Поэтому я потрудился сделать за вас грязную работу и (в произвольном порядке) собрал некоторые из них в этом посте. Примеры сопровождаются ещё более вольными краткими пояснениями и/или листингами (некоторые из них цитируются).

Конечно же, здесь я не берусь перечислять абсолютно всё, так как факты из разряда «функция nan() не может устанавливать errno, поскольку в определённых ситуациях поведёт себя как strtod()» не слишком интересны.

ВНИМАНИЕ: сам факт попадания тех или иных вещей в эту подборку  не означает автоматически, что я рекомендую или, наоборот, не рекомендую ими пользоваться! Некоторые из приведённых примеров никогда не должны просачиваться за пределы списков наподобие этого, тогда как другие примеры невероятно полезны! Уверен, что могу положиться на ваш здравый смысл, дорогие читатели.

Привет, Хабр! Я Кирилл Кузин — старший разработчик компании Ви.Tech, IT-дочки маркетплейса ВсеИнструменты.ру. Мы поддерживаем 4 кластера Kubernetes, каждый из которых включает от 200 до 215 нод. Ежемесячно выполняется более 1 миллиона пайплайнов, а на наш сайт ежедневно заходят до 2 миллионов уникальных пользователей.

И в этой статье расскажу о том, как оптимизировать работу сервиса с помощью PGO (Profile-Guided Optimization) - инструмента, изучаемого нашей компанией. На примере кейса разберем, как использование этого инструмента ускоряет выполнение задач и снижает нагрузку на систему.

Что делает PGO? Как он влияет на производительность? Мы сравним результаты работы с и без него, а в конце подведем итоги, чтобы дать объективную оценку результатам.

Всем привет! Сейчас за окном осенние деньки 2024 года. Вещает Пройдаков Евгений. Сейчас я руковожу группой разработки среды исполнения языка eXtraction and Processing в R&D департаменте Positive Technologies.

Доменно специфичный язык eXtraction and Processing является важной частью движка поведенческого анализа, используемого в таких продуктах Positive Technologies, как MaxPatrol SIEM и PT ISIM. Сегодня хотелось представить вашему вниманию выжимку нашего R&D процесса в экспериментах с WebAssembly. Узнаем, что такое WebAssembly. Поймём, как его можно встроить в программный продукт. Коснёмся инструментов разработки и сред исполнения WebAssembly. А также в рамках одной статьи пройдём путь от постановки задачи до результатов по разработке среды исполнения для доменно специфичного языка программирования. Кроме того, мы разберем некоторые проблемы, которые могут появиться у вас при попытке собрать и отладить большой С++ проект под WebAssembly. Материал может быть особенно полезен тем, кто хочет использовать WebAssembly за пределами веб‑браузера.

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

Представлена утилита-надзиратель, что последовательность определения static функций совпадает с последовательностью объявляения static функций.

У нас в организации есть обязательное правило оформления исходников, которое звучит так:

Порядок объявления С-функций должен совпадать с порядком определения С-функций.

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

Алгоритм синтаксического анализа кода на основе Shunting Yard — скажем "нет" рекурсии

Преимущество модифицированного Shunting Yard над рекурсивным спуском заключается в его способности эффективно работать с более сложными синтаксическими конструкциями и грамматиками, которые не поддерживаются рекурсивным спуском. Благодаря использованию стеков для управления состояниями и операторами, алгоритм избегает проблем с глубокой рекурсией и может обрабатывать конструкции, требующие динамического изменения контекста. Это делает его более универсальным и производительным решением для построения абстрактного синтаксического дерева (AST) без ограничений на тип грамматик, характерных для рекурсивного спуска.

Функционал GDB существенно сужается, когда приходится иметь дело с файлами, из которых убраны отладочные символы (получаются так называемые «урезанные бинарники»). Функции и имена переменных превращаются в бессмысленные адреса. Для установки контрольных точек приходится отслеживать адреса нужных нам функций из внешнего источника. Также нужно выводить в консоль структурированные значения и после этого корпеть над дампом памяти, пытаясь вычленить, где именно пролегают границы полей.

Вот почему этим летом, работая в Trail of Bits, я расширил Pwndbg — плагин для GDB. Поддерживает его мой наставник Доминик Чарнота. Я добавил в инструмент две фичи, благодаря которым практическая отладка урезанных бинарников сближается с аналогичной работой, знакомой нам из работы с отладчиком в IDE. Теперь в Pwndbg интегрирован инструмент Binary Ninja, позволяющий лучше выяснять специфику GDB+Pwndbg, а также выводить дамп структур Go, чтобы отлаживать бинарники Go стало удобнее.

Команда Rust рада сообщить о новой версии языка — 1.81.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.

Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.81.0 вам достаточно выполнить команду:

$ rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.

Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках.

Недавно я получил по почте от Сэма Джонсона этот вопрос. Вот слегка отредактированное письмо Сэма:

«Возьмём для примера этот код в локальной области видимости функции:

int a;

a = 5;

Многие люди считают, что инициализация происходит в строке 1, потому что веб-сайты наподобие cppreference дают такое определение: "Инициализация переменной предоставляет его начальное значение на момент создания".

Однако я убеждён, что инициализация происходит в строке 2, потому что [в разных хороших книгах по C++] инициализация определяется как первое существенное значение, попадающее в переменную.

Можете ли вы сказать, какая строка считается инициализацией?»

Отличный вопрос. На Cppreference написано правильно, и для всех классовых типов ответ прост: объект инициализируется в строке 1 вызовом его стандартного конструктора.

Но (а вы ведь знали, что будет «но») для локального объекта фундаментального встроенного типа наподобие int ответ будет... чуть более сложным. И именно поэтому Сэм задал этот вопрос, ведь он знает, что язык достаточно свободно обращается с инициализацией таких локальных объектов по историческим причинам, имевшим в то время смысл.

Короткий ответ: вполне допустимо говорить, что переменная получает своё исходное значение в строке 2. Но заметьте, что я намеренно не сказал «Объект инициализируется в строке 2», к тому же и код, и этот ответ обходят молчанием более важный вопрос: «Ну ладно, а что, если код между строками 1 и 2 попробует считать значение объекта?»

Статический анализ — это очень мощный инструмент, позволяющий следить за качеством кода. Предлагаем вместе попробовать написать простой Lua анализатор на Java, чтобы понять, как устроены статические анализаторы кода внутри.

Согласно описанию,

Tree-sitter — это инструмент для генерации синтаксических анализаторов и библиотека инкрементного синтаксического анализа. Он может создавать конкретное синтаксическое дерево для исходного файла и эффективно обновлять синтаксическое дерево по мере редактирования исходного файла.

Но как Tree-sitter справляется с языками, в которых необходима стадия препроцессинга?

Если вы никогда не пробовали смотреть как код на C++ разворачивается компилятором в код Assembly – вас ждёт много сюрпризов, причём, не нужно смотреть какой-то замудренный исходный код полный templates или других сложных конструкций: рассмотрите следущий snippet:

Обратите внимание: в этой статье речь идёт об отладчиках, работающих с нативным кодом – например, GDB, LLDB, Visual Studio C++. Отладчики для управляемых и скриптовых языков работают примерно так же, но могут отличаться детали реализации.