Lua *

local ffi = require ("ffi")
local msg = ffi("user32.dll", "MessageBoxA")
msg(0, "Message", "Title", 0)

local glfw = ffi("glfw3")

Размер самой ffi.dll при этом получился аж 9 Кбайт, вот она целиком на картинке размером 32х96 пикселей. Можно сохранить это изображение, сконвертировать в bmp (хабр не умеет в bmp, пришлось дополнительно упаковать в png), потом руками удалить первые 54 байта заголовка (до 'MZ') и пользоваться.

Привет, Хабр! Эта статья о том, как тестируют компиляторы. Она будет интересна разработчикам  и тестировщикам компиляторов, а также всем, кто тестирует сложные технологии. Разберём проблемы тестирования LuaJIT и подходы к решению: неструктурированный фаззинг, синтаксический, семантический, сравнительный фаззинги и тестирование оптимизаций. Статья написана на основе доклада Сергея Бронникова из Tarantool на конференции Highload.

В заключительной части данного цикла, в котором я постарался на минимальном уровне создать более-менее удобную среду для начала (!) экспериментов по изучения возможностей перевода автоматизации работы с документами из Microsoft Office в «МойОфис».

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

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

Суть работы взаимодействия сервера и клиентской части следующая:

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

Т. к. сервер для игры является авторитарным, то клиентская часть должна была содержать.

Поскольку, худо ли - бедно, я добился удалённой отладки для надстроек (напомню, так почему-то  назвали разработчики «МойОфис» макросы с возможностью использовать пусть и примитивный, но набор контролов и форм), то зачем останавливаться на достигнутом?

Теперь передо мной встал вопрос об отсутствии банальной в XXI веке «фишке», к которой я привык, как программист о-о-очень избалованный современными IDE, и без наличия которой программирование меня быстро приводит в ярость, а именно – автодополнением кода. Как упоминал в первой ещё статье цикла, его нет даже во «встроенном редакторе» «МойОФис» (в кавычках, ибо на редактор это тянет слабо) для того, что там назвали макросами. То есть, хочешь писать макросы, открывай справочник по Lua API для макросов, и ищи там! Бесит, честно говоря. Но поскольку речь не о нём, то что же  мне предлагает  LuaRT (тоже самое есть и в ZeroBrane Studio, поэтому описанное далее подойдёт как родное и туда)?

Итак, после создания первой надстройки в офисном пакете «МойОФис», о чем можно почитать в  первой, вводной части данного цикла статей, следующим шагом у меня возникла идея, как бы представить весь код, в форме более удобной для дальней работы форме? Хотелось бы, чтобы весь код не был свален в одном месте, а разделён хотя бы по разным файлам. Да и отладка бы совсем не помешала!

Lua — это, пожалуй, мой любимый "маленький язык", с низкой когнитивной нагрузкой и простотой в изучении и использовании. Он встроен во многое ПО, такое как Redis, NGINX через OpenResty и Wireshark (прим. перевод.: и многое другое). Он также используется в качестве скриптового языка в таких играх, как World of Warcraft и Roblox через Luau (прим. перевод.: и многих других). Этот пост — краткое признание в любви языку с некоторыми примерами того, почему он мне так нравится.

Поскольку это первая моя публикация на Хабре, хотя как читатель я присутствую здесь уже довольно много лет, я скажу пару слов о себе. Вообще мой стаж как программиста, если учитывать и студенческие годы, когда я под руководством моего руководителя практики начал изучать С и С++ еще в 1992 году (откидываем программирование на калькуляторах, это всё таки баловство), уже более 30 лет. Много чем занимался в этой сфере, и что перепробовал по работе и чисто из интереса.

Несколько более «известным»  я стал с 2016 года в кругу тех, кто активно использует станки ЧПУ, как разработчик средств автоматизации (макросов) под CorelDraw. Тем не менее,  сегодня речь пойдет о другой автоматизации – офисной. В силу своей работы на гос службе, мне приходилось заниматься внедрением и поддержкой документооборота, а также автоматизацией разных рутинных задач. Поэтому тема не сказать, что для меня незнакомая. Но про автоматизацию в наших офисных пакетах (конкретно «МойОфис») можно сказать, что не знал почти ничего до нынешней зимы. И так как у меня появилось свободное время, и я решил более подробно изучить «МойОфис» в плане автоматизации, а конкретно того, возможно ли хоть как-то сделать создание автоматизации удобоваримым с точки зрения программирования и переноса макросов VBA из «MS Office», в Lua надстройки под «МойОфис».

Теоретически если вы решили пересесть с классического Vim на более современный его клон - Neovim - вам делать ничего особенного не надо. В файле ~/.config/nvim/init.vim прописать source ~/.vimrc ну и скачать или скопировать словари. Идея в том, что Neovim должен поддерживать все конфигурации Vim по умолчанию. Однако, если у вас установлено множество плагинов и разных к ним расширений, то с высокой вероятностью конфигурация загрузится с ошибками, предупреждениями и другими, не очень желательными нюансами. Да и вообще вся фишка, вся разница Neovim заключается в том, что он поддерживает настройки и плагины написанные на Lua вместо vimscript.

Lua - более современный интерпретируемый язык, на нем удобнее писать, его проще читать. А еще, считается, что работает интерпретатор на порядок быстрее родного языка. На счет порядка я бы засомневался, но действительно тяжелые плагины работают вроде как расторопнее и глаже. Впрочем и классический Vim известен не тем, что он медленный или глючный, так что тут спор скорее софистический. А вот с первыми тремя утверждениями я абсолютно согласен.

Более того для Neovim именно на Lua в последнее время выбор современных плагинов и расширений, что уж тут говорить, куда богаче. Вопрос даже не в том лучше ли эти аналоги, а в скорее в свежести, динамике развития и в целом в оптимизме сообщества. Очень похоже на то, что не сегодня так завтра Neovim повторит судьбу предшественника и займет свое место в распространенных дистрибутивах Linux в качестве стандартной замены устаревшему Vim. Заменит полностью? Ну, я бы не был так категоричен в этом вопросе, но вероятность такая существует.

Не смотря на очевидные успехи импортозамещения в сфере программного обеспечения, есть ряд трудностей «переходного периода», которые существенно усложняют жизнь миллионам пользователей на необъятных просторах нашей страны. Одна из таких «головных болей» – макросы. При переходе на российские офисные пакеты, требуется переписать множество VBA-макросов для MS Office. При этом, макросам на VBA посвящено множество книг и интернет-ресурсов. А вот про макросы в отечественных «офисах» информацию, пока, приходится собирать по крупицам.

В этой статье предлагается пример разработки макроса в табличном редакторе «МойОфис Таблица». Разработчики «МойОфис» не только заложили возможности расширения базовой функциональности своего «офиса» с помощью макросов, но и снабдили пользователей толковым «Справочником макрокоманд на языке программирования Lua».

Попробуем решить тривиальную задачу сравнения двух таблиц. В «экселевском» файле Verify.xlsx 3 листа – Contract, Act, Result. В таблице Contract содержатся данные о договорных объемах работ, в Act – о фактически выполненных.

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

Код программ данной главы можно скачать с Github по ссылке:

https://github.com/chetverovod/Mediastreamer2_LuaFilter

Приступим к практической реализации. Для этого можно вспомнить как создается новый фильтр, см. главу 4. В этой схеме источником звукового сигнала может быть либо сигнал с линейного входа звуковой платы (sound_card_read) либо генератор DTMFсигнала (dtmf_generator). Далее данные попадают на вход разрабатываемого Luaфильтра (lua_filter), который осуществляет их преобразование в соответствии с загруженным в него скриптом. Затем данные поступают на разветвитель (Tee), который из входного потока образует две копии, которые выдает на два выхода. Один из этих потоков поступает на регистратор (recorder) и на звуковую карту для воспроизведения (sound_card_write). Регистратор (*recorder*), он сохраняет их на диск в формате raw (wavфайл без заголовка). Таким образом мы сможем прослушать и записать результат работы Lua-фильтра.

Этот туториал описывает часть функционала плагина «Langmapper.nvim», ссылка на него будет в конце статьи. Для остальных, кто хочет настроить Neovim для работы с русской или другой раскладкой, описаны необходимые шаги и приведён упрощенный код.

В своей практике я встречался со множеством башенных кранов, начиная от “советских” КБ различных моделей и их модификаций, заканчивая современными кранами, в том числе Liebherr. Причем, среди последних я сейчас встречаюсь не только с новыми, а и со старичками, которые иногда старше меня)

Если с новыми кранами все более-менее хорошо (мощная система диагностики практически всех компонентов электросхемы, большой экран с отображением множества параметров, современная схемотехника с использованием ПЧ), то со старичками часто приходится повозиться. Да, релейно-контакторная схема не сложна, но годы дают знать свое.

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

Продолжая серию статей про разработку сервера для онлайн игр (адрес проекта http://mmogick.ru) на языке PHP в это части я хочу рассказать про безопасное добавления пользовательского кода для добавления функционала игровых механик. В статье я опишу существующие решения для PHP , сравню скорость работы приведу видео примеры.

Для тестов будет использовано следующее железо: