Прошло 2 месяца после первой (но конечно же не последней) конференции PiterJS conf. Для активистов сообщества это был своего рода праздник, к которому долго готовишься и столько же отходишь. В этой статье хочу подвести итоги, анонсировать публикацию докладов, понастальгировать и чуть-чуть похвастаться.

Итак, ранее мы начали наш рассказ о Lexer языка PHP. Стоит обратить внимание на следующие его особенности:

За окном вечер пятницы, а это значит самое время написать пост на Хабр.
Сейчас я расскажу о замечательной «машине», которая служила мне верой и правдой в самом начале моего пути как программиста.
Встречайте, ноутбук AST PenExec 3/25 SL!
Его отличные по тем временам характеристики:

• Процессор — 80386
• Память — базовая 640Кб + «расширенная» 3264Кб, итого 3904Кб
• Жесткий диск — 40Мб(прям как в «той» песне)
• Операционная система — DOS + сверху «Microsoft Windows for Pen Computing 1.0»
• Дополнительно — стилус на батарейках(к сожалению надо ремонтировать) и внешний дисковод для 3 дюймовых дискет
• Год выпуска — предположительно 1993

Ну как, интересно посмотреть на картинки сего девайса?

Добро пожаловать в учебник «Создание языка программирования с LLVM». Этот учебник знакомит вас с созданием простейшего языка программирования, и при этом показывает, каким оно может быть легким и интересным, а также даёт вам начальные знания, которые вы затем сможете применить на других языках программирования. Код в этом учебнике также может быть использован в качестве стартовой площадки для ваших творений с помощью LLVM.

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

Добро пожаловать в Главу 2 учебника «Создание языка программирования с LLVM». В этой главе мы увидим, как использовать лексический анализатор, созданный в Главе 1, чтобы построить полный синтаксический анализатор для нашего языка Kaleidoscope. После того, как у нас будет готов парсер, мы будем строить Abstract Syntax Tree (AST) (Абстрактное синтаксическое дерево).

Добро пожаловать в Главу 4 учебника «Создание языка программирования с LLVM». Предыдущие главы (1-я, 2-я и 3-я) описывали реализацию простейшего языка программирования и добавление в него ​​поддержки генерации LLVM IR. В этой главе описаны две новых техники: добавление поддержки оптимизатора и добавление поддержки JIT-компилятора. Эти дополнения продемонстрируют как получить хороший, эффективный код для нашего языка программирования Kaleidoscope.

Disclaimer: Описываемый инструмент имеет спорную репутацию. Я не призываю использовать его где ни попадя, только знакомлю с используемыми понятиями, дабы уменьшить некоторым трепет перед технологией.

Написанные исходники, а также текстовую копию статьи можно найти на гитхабе.

Что такое parse_transform

parse_transform — механизм изменения AST перед компиляцией. Предназначен для изменения значения конструкций (семантики), не выходя за синтаксис Эрланга.

К сожалению, в Сети мало информации про это, что делает порог вхождения весьма высоким для не-гуру эрланга.

Что мы будем делать

В рамках данной статьи я немного рассказажу про AST эрланга, приведу пример простых трансформаций, а так же покажу процесс написания parse_transform для создания stateless gen_server-а (задача имеет не особо много смысла, но в качестве примера использования сгодится), а в конце дам ссылку на набор начинающего транформатора.

Предыстория

Мы разрабатываем небольшой портал на Grails и используем Spring Security для управления безопасностью. Плагин spring-security для Grails достаточно удобен и до последнего момента от него не требовалось сложной функциональности.

Недавно был обнаружен неприятный момент в использовании аннотаций @Secured для методов контроллеров Grails. Проблема заключается в том, что аннотации обрабатываются во время исполнения и преобразуются в набор правил для адресов «Адрес -> Набор требуемых ролей». Такой подход порождает ряд проблем в Grails-контроллерах в действиях сохранения/удаления данных, поскольку они отправляют данные на основной URL контроллера, то приходиться во-первых аннотировать контроллер, во вторых — невозможно задать различные ограничения для таких запросов.

Речь пойдёт о том, как решить проблему и приобрести хороший инструмент для управления правилами безопасности.

Меня очень заинтересовала статья Самая короткая запись асинхронных вызовов в tornado или патчим байткод в декораторе, не столько с практической точки зрения, сколько с точки зрения реализации.
Всё-таки модификация байткода в рантайме это слишком опасная и ненадежная операция. И уж наверняка не поддерживаемая альтернативными интерпретаторами Python.

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

Последнее время часто приходится работать с такой мощной возможностью Groovy как Compile-time AST Transformations.

Так как я не люблю излишнюю динамику, то бОльшая часть проверок DSL на валидность у нас происходит на этапе компиляции, а так же мы используем очень много генерации кода. Поэтому каждый день приходится сталкиваться с составлением ASTNode-ов вручную.

def someVariable = new ConstantExpression("someValue");
def returnStatement = new ReturnStatement(
    new ConstructorCallExpression(
        ClassHelper.make(SomeCoolClass),
        new ArgumentListExpression(someVariable)
    )
);

До боли знакомые конструкции, не правда ли? Хотите, чтобы было вот так?

def someVariable = macro { "someValue" }
def returnStatement = macro { return new SomeCoolClass($v{ someVariable }) }

Или даже так?

def constructorCall = macro { new SomeCoolClass($v{ macro { "someValue" } }) }

В данной статье речь пойдёт о моём решении этой проблемы, максимально близком к родному решению Groovy — github.com/bsideup/MacroGroovy

Предыдущая статья серии была посвящена теории парсинга исходников с использованием ANTLR и Roslyn. В ней было отмечено, что процесс сигнатурного анализа кода в нашем проекте PT Application Inspector разбит на следующие этапы:

1. парсинг в зависимое от языка представление (abstract syntax tree, AST);
2. преобразование AST в независимый от языка унифицированный формат (Unified AST, UAST);
3. непосредственное сопоставление с шаблонами, описанными на DSL.

Данная статья посвящена второму этапу, а именно: обработке AST с помощью стратегий Visitor и Listener, преобразованию AST в унифицированный формат, упрощению AST, а также алгоритму сопоставления древовидных структур.

Содержание

• Обход AST
  
  • Visitor и Listener
  • Различия в Visitor в ANTLR и Roslyn
  • Грамматика и Visitor в ANTLR
  • Альтернативные и элементные метки в ANTLR
• Типы узлов унифицированного AST
• Тестирование конвертеров
• Упрощение UAST
• Алгоритм сопоставления древовидных структур
• Заключение

В нашем проекте PT Application Inspector реализовано несколько подходов к анализу исходного кода на различных языках программирования:

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

Наш цикл статей посвящен структуре и принципам работы модуля сигнатурного поиска (PM, pattern matching). Преимущества такого анализатора — скорость работы, простота описания шаблонов и масштабируемость на другие языки. Среди недостатков можно выделить то, что модуль не в состоянии анализировать сложные уязвимости, требующие построения высокоуровневых моделей выполнения кода.

К разрабатываемому модулю были, в числе прочих, сформулированы следующие требования:

• поддержка нескольких языков программирования и простое добавление новых;
• поддержка анализа кода, содержащего синтаксические и семантические ошибки;
• возможность описания шаблонов на универсальном языке (DSL, domain specific language).

В нашем случае все шаблоны описывают какие-либо уязвимости или недостатки в исходном коде.

Весь процесс анализа кода может быть разбит на следующие этапы:

1. парсинг в зависимое от языка представление (abstract syntax tree, AST);
2. преобразование AST в независимый от языка унифицированный формат;
3. непосредственное сопоставление с шаблонами, описанными на DSL.

Данная статья посвящена первому этапу, а именно: парсингу, сравнению функциональных возможностей и особенностей различных парсеров, применению теории на практике на примере грамматик Java, PHP, PLSQL, TSQL и даже C#. Остальные этапы будут рассмотрены в следующих публикациях.

Зачем нужно

Различная фильтрация есть везде. Например, файрволл netfilter (iptables) имеет свой синтаксис для описания пакетов. В файле .htaccess апача свой язык, как определять, кому давать доступ к каталогу, кому нет. В СУБД свой очень мощный язык (SQL WHERE ...) для фильтрации записей. В почтовых программах (thunderbird, gmail) — свой интерфейс описания фильтров, в соответствии с которыми письма будут раскидываться по папкам.

И везде — свой велосипед.

Для бухгалтерской программы вам может быть удобно позволить пользователю выбрать, кому будет повышена зарплата (все женщины, а так же мужчины возрастом от 25 до 32 лет, либо же до 50 лет если у мужчины имя Вася). И каждому подходящему повысить по пользовательскому выражению ( + 2000 рублей + 20% от прежней зарплаты + по 1000 рублей за каждый год стажа)

Для интернет-магазина (или его админки) — найти все ноутбуки, с памятью от 4 до 8 Gb, которых на складе более 3 штук, но не Acer, или даже Acer, если стоят меньше 30 000 рублей.

Конечно, можно присобачить свою сложную систему фильтров и критериев, сделать для них веб-интерфейс, но проще было бы все сделать в пару строк?

src="(RAM>=4 and RAM<=8 and stock>3 and not brand=='Acer') or (brand=='Acer' and price<30000)"
success, result = evalidate.safeeval(src,notebook)

Захотелось мне сделать шаблонизатор, чтобы как slim, теги чтобы автоматом закрывались и прочее. Красиво же так:

html
  head
    title
        - yield "Плюшка!" + " Чашка чаю!"

Но и этого мне мало, хочу чтобы не было своего недоязыка, хочу чтобы просто питоновские конструкции. А кто захочет себе в ногу стрельнуть и бизнес логики в шаблоны навалить, то это проблема начинашек, мне зачем мучаться размазывая код вьюх в папки типа utils, template_tags и прочее?

А и еще можно кстати угореть так уж угореть — а пусть шаблоны через новый механизм импорта в python 3 тянутся. И если надо что-то от другого шаблона себе вставить, то тоже пусть также работает.

А еще, еще пусть каждый шаблон это генератор!

Захотелось получить статистику Java исходников и узнать, сколько в среднем бывает параметров у методов, методов в классах, конструкторов и т. д. Вопрос не совсем праздный, потому что на основе этих данных можно вычислить оптимальный размер по умолчанию для контейнеров для этих сущностей в программной модели кода (AST), чтобы сэкономить память. В частности, речь идет о проекте Spoon. С помощью этой библиотеки я и провел анализ, кстати.

Что может быть логичнее, чем протестировать статистику исходников JDK, чтобы делать некие предположения о любом Java-коде. Попутно я собрал самые необычные экземпляры — например, методы с наибольшим кол-вом параметров.

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

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

Метапрограммирование реализовано в той или иной мере в очень разных языках; если не рассматривать экзотические и близкие к ним языки, то самым известным примером метапрограммирования является С++ с его системой шаблонов. Из «новых» языков можно рассмотреть D и Nim. Одна из самых удачных попыток реализации метапрограммирования — язык Nemerle. Собственно, на примере этой четверки мы и рассмотрим сабж.

Метапрограммирование — интереснейшая тема; в этой статье я попытаюсь разобраться, что же это такое, и каким оно должно быть в идеальном случае.

Сейчас я работаю над senjin/gglsl — библиотекой для программирования шейдеров с помощью Groovy, о которой недавно писал.

Здесь я опишу три подхода к анализу AST (abstract syntax tree), все на примерах под-задач, вытекающих одна из другой и связанных общим контекстом: рекурсивные функции, паттерн Visitor, и паттерн-матчинг.
Паттерн-матчинг реализован на Java и доступен на GitHub.

В статье расскажу как можно писать на Java для Arduino.

Почему Java? Если кратко — just for fun!

Я Java программист и в свободное время играюсь с Arduino и хотелось перенести свои знания Java в мир микроконтроллеров и embedded устройств.

На данный момент есть несколько возможностей запускать Java на embedded устройствах. В этой статье я рассмотрю их.

Однажды, сидя вечером перед компьютером и предаваясь меланхолии и мыслям о бренности всего сущего, я задумчиво набрал в поиске одного крупного сайта по поиску работы аббревиатуру «LLVM», не надеясь, впрочем, увидеть там что-то особенное, и стал просматривать небогатый, прямо скажем, улов.

Как и следовало ожидать, почти ничего особенного не нашлось, однако одно объявление меня заинтересовало. В нём были такие строки:

«Кого мы возьмем «не глядя» или уровень выполняемых задач:
Вы скачали любой open source проект, собираемый при помощи gcc (объем исходного кода более 10 мегабайт) и для самого большого файла cpp смогли построить AST дерево при помощи clang с –fsyntax-only;
Вы скачали любой open source проект, собираемый при помощи Visual C++ (объем исходного кода более 10 мегабайт) и для самого большого файла cpp смогли построить AST дерево при помощи clang с –fsyntax-only;
Вы смогли написать утилиту, которая выделит все места деклараций и использования локальных переменных, а также все функции, не определенные в данном файле».

Ну что же, подумал я, какое-никакое, а развлечение на вечер.

Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage).

Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего.

Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь?

Ответ на этот вопрос даёт мутационное тестирование.