Серия «Жестокие эксперименты»

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

Именно о нем пойдет сегодняшний рассказ.

Amsterdam Compiler Kit

Врядли среди читателей обнаружится аксакал живой пользователь этого удивительного проекта:

The Amsterdam Compiler Kit is a venerable piece of software that dates back to the early 1980s. It was originally written by Andrew Tanenbaum and Ceriel Jacobs as a commercial product; for many years it was also used as Minix’ native toolchain. After eventually failing as a commercial project, it was made open source under a BSD license in 2003 when it looked like it was going to be abandoned and the code lost.

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

Теперь подробнее, что там внутри и почему оно до сих пор шевелится представляет интерес:

The ACK contains compilers for ANSI C, K&R C, Pascal, Modula-2, Occam 1, and a primitive Basic. It contains code generators for a large number of architectures, mostly 8 and 16 bit machines; there are also a set of generic optimisation, linker and librarian tools.

В принципе стандартный набор языков для тех лет, но есть нюанс:

It contains assembler and linker support for: 6500, 6800, 6805, 6809, ARM, i80, Z80, Z8000, i86, i386, 68000, 68020, NS32016, S2650, SPARC, VAX, PDP11 and VideoCore IV.

Это уже несет определенный «вау-эффект», причем как для тех, так и для этих лет, поскольку даже для популярных clang и gcc столь широкая поддержка различных архитектур решается весьма нетривиально - путем форков и неофициальных патчей.

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

Современная версия ACK, разрабатываемая с 2003 года как открытый проект, поддерживает следующие платформы:

pc86, linux386, linux68k, linuxppc, linuxmips, cpm, rpi (VideoCore IV), pdpv7, msdos86 and msdos386.

Лично у меня глаз начал дергаться после cpm и pdpv7, msdos86 по сравнению с этим уже творческие мелочи.

Для юных читателей, не заставших даже дискет стоит пояснить, что CP/M это операционная система из 1970х, для примерно таких компьютеров:

Как выглядит PDP-7 уже показывал в предыдущей статье, но на всякий случай напомню:

И ACK дает вам возможность скомпилировать приложение в современном окружении в 2025м году, которое будет работать на этом.

Чтобы у вас не сложилось впечатление, будто ACK это только лишь про плешивых дедов пожилых программистов и их древние игрушки, покажу как выглядит заявленный выше VideoCore IV:

Как видите это уже вполне себе современная плата, используемая в различных устройствах.

Minix

Отдельно стоит упомянуть историю с Minix — той самой операционной системой, созданной тем самым Таненбаумом для обучения нерадивых студентов сложной теме разработки операционных систем.

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

Дело в том, что ACK когда-то был основным системным компилятором в Minix, при этом являясь коммерческим продуктом — поставлялся в виде готовых бинарников:

The ACK has been used as the standard Minix compiler for years. While the ACK was still commercial, this was done by distributing binaries; when it get opened, a version was forked off and is now used as part of the Minix base build.

Форк с поддержкой Minix мне был не особо интересен, поэтому искать не стал, тем более что в современной Minix 3 используется вполне стандартный clang.

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

Each language comes with its own runtime, so if you’re a C programmer you also get a libc. Compared to gcc, it is far smaller, faster and easier to port.

Стоило догадаться об этом, прочитав список поддерживаемых архитектур и прикинув как оно вообще может работать, но тем не менее.

Так что ACK это уникальный, редкий и необычный проект, позволяющий творить запредельную дичь вроде кросс-компиляции из FreeBSD в MS-DOS подручными средствами, которую вы могли видеть в шапке статьи.

Ниже я опишу процесс сборки и использования этого необычного проекта.

Сборка

Собирать буду по традиции на FreeBSD 14, поэтому часть требуемых шагов несколько отличается от стандартных.

Проект старый, разработка в git ведется давно, поэтому внутри репозитория присутствует множество разных веток, не актуальных для обывателя.

Чтобы не выкачивать всю эту дичь, я использовал ключ --depth -1, с которым будет выгружена только ветка по-умолчанию:

git clone --depth 1 https://github.com/davidgiven/ack.git

Таким образом собирать мы будем текущую на момент написания статьи версию:

ACK 6.0 is a ground-up reworking of the whole compiler suite, with a lot of the more archaic features removed.

Сборка проекта.. весьма своеобразна, поскольку основана на скриптах Python и немного Lua. Как гласит описание:

The version 5.0 build mechanism has been completely rewritten (twice).

И видимо это еще не конец.

Для сборки нужен достаточно банальный набор инструментов:

• любой ANSI C компилятор (автор использовал GCC)

• flex и yacc

• GNU make (gmake)

• Lua с библиотекой lua-posix

• Python 3.4 и выше

• ~2Гб свободного места

В трекере проекта и пул-реквестах есть сообщения от камрадов, использующих ACK на OpenBSD, так что врядли будут проблемы в куда более популярных Linux, Windows и MacOS.

Запускается сборка стандартным образом — вызовом GNU Make в корне проекта:

gmake

Поскольку автор собирал на FreeBSD, которая имеет определенную специфику в именовании инструментов, появится такая ошибка:

Происходит это из-за того, что lua во FreeBSD имеет постфикс версии:

Так что надо отредактировать Makefile в корне проекта и поменять значение переменной LUA=, добавив версию:

Следующая ошибка также специфична для FreeBSD, поскольку gcc у нас тоже с постфиксом версии:

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

Нужный файл называется ack/build/ab.mk и почему-то несмотря на название и расположение — не является генерируемым.

По аналогии с lua, добавляем постфикс версии и сохраняем:

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

Итоговый размер после завершения сборки, со всеми временными файлами получился размером в 1.7Гб, что несколько больше заявленного в требованиях:

По-умолчанию ACK устанавливается в каталог /opt/pkg/ack, поэтому запускаем из корня проекта:

mkdir -p /opt/pkg/ack
gmake install

Перед установкой будут запущены тесты, но далеко не все:

Итоговый каталог bin выглядит следующим образом:

Хотя основные бинарники находятся в ack/lib/ack:

Теперь переходим к самому интересному — к запуску и работе с ACK, это будет действительно весело.

В репозитории проекта находится каталог examples, где лежат примеры более-менее сложной логики на Си, Паскале и Бейсике, которые точно собираются и работают с помощью ACK.

Один из таких примеров под названием mandelbrot.c , выводящий в консоль с помощью символа * фрактал Мандельброта вы можете лицезреть в работе на заглавной картинке к статье.

Но поскольку мне был интереснее сам процесс компиляции и запуска приложений на разных экзотических архитектурах из древних времен нежели специфика каждой конкретной платформы, не стал заморачиваться сложной логикой, взяв в качестве эталона классический «Hello world!» на Си:

#include <stdio.h>

int main(void)
{
printf("Hello, alex0x08 \n");
return 0;
}

И собственно ниже покажу сборку и запуск этой нестареющей классики под крайне экзотические (по современным меркам) архитектуры.

Компиляция FreeBSD->MS-DOS

Компиляцию в COM-файл с последующим запуском можно увидеть на заглавной картинке, поэтому ниже покажу компиляцию в EXE под DOS:

/opt/pkg/ack/bin/ack -mmsdos386 -O hello.c -o hello.exe

Цитируя документацию:

msdos386 produces i386 MS-DOS 32-bit DPMI .EXE files

Поэтому для работы нужен запущенный DPMI-резидент — т. н. «расширитель памяти», который можно взять например тут.

Так это выглядит в записи:

Как видите запуск осуществлялся в известном эмуляторе DOS под названием Dosbox, установленном из пакетов FreeBSD.

Компиляция для CP/M

Продолжая исторический угар, показываю сборку и запуск под CP/M, напоминаю что это операционная система из 1970х (старше автора) а компьютеры, на которых она работала выглядели так:

Тут надо сделать небольшое отступление и рассказать про эмулятор CP/M, поскольку его в пакетах FreeBSD не нашлось — пришлось собирать руками.

RunCPM - Z80 CP/M emulator

Разработка ведется на Github, забираем исходники:

git clone https://github.com/MockbaTheBorg/RunCPM.git

При сборке будет описанная выше проблема с номером версии в названии исполняемых файлов компилятора GCC — стандартная для FreeBSD, поэтому необходимо в файле RunCPM/Makefile.posix в переменную СС= добавить номер версии:

Сама сборка запускается командой:

gmake posix build

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

mkdir disk
unzip ../../DISK/A0.ZIP
cp ../RunCPM .

В результате появится каталог A/0, внутри которого будут все управляющие команды CP/M, в корне будет запускаемый бинарник самого эмулятора.

Все готово к использованию, для проверки можно запустить эмулятор:

Должна быть отображена шапка с версией и работать команда DIR. Для завершения работы эмулятора введите EXIT.

Теперь можно переходить к сборке тестового приложения.

«Hello world» для CP/M

Для компиляции под эту систему достаточно указать ключ -mcpm:

/opt/pkg/ack/bin/ack -mcpm -O hello.c -o hello.com

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

cp ~/hello.com ./A/0/HELLO.COM

Запускаем эмулятор и вводим команду hello:

Круто?

Круто, но недостаточно, поскольку среди поддерживаемых ACK систем есть:

pdpv7 produces PDP/11 V7 Unix binaries

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

Компиляция для Unix v7 и PDP-11 в 2025м году (!)

Чтение этого абзаца прибавляет 100 баллов к инженерным навыкам.

Напоминаю как выглядел PDP-11:

Вот так выполняется компиляция из ACK для этого древнего монстра:

/opt/pkg/ack/bin/ack -mpdpv7 -O hello.c -o hello

Как ни странно и неожиданно, но стандартная утилита file, присутствующая во всех UNIX-системах с незапамятных времен честно показывает тип:

Apout — Simulate PDP-11 Unix a.out binaries

Для проверки я сначала запустил полученный бинарник на этом:

This program is a user-level simulator for UNIX a.out binaries. Binaries for V1, V2, V5, V6, V7, 2.9BSD and 2.11BSD can be run with this simulator. The user-mode PDP-11 instructions are simulated, and TRAP instructions are emulated by calling equivalent native-mode system calls.

Собирается оно под FreeBSD одной командой, поскольку внешних зависимостей нет:

export CC=gcc13
gmake

После сборки в корне проекта появится бинарник apout, так выглядит в работе запуск нашего «Hello world»:

Но разумеется сильно круче было бы попробовать запустить в реальном симуляторе PDP с Unix v7 на борту, что я и сделал.

SIMH

Эмуляцию PDP как впрочем и множества других исторических систем обеспечивает известный проект Open SIMH. Нужный нам Unix v7 заявлен на главной странице проекта в качестве ключевого примера:

For example Version 7 Unix, released in 1979, runs unchanged today on SimH.

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

На этот раз.

Забираем готовый образ диска с Unix v7 для PDP-11 отсюда, существует известная инструкция по полной установке с использованием образов установочной ленты:

Но автор решил не убивать еще неделю что это уже перебор, поэтому использовал готовый образ диска с Unix v7.

В архиве по ссылке будет файл unix_v7_rl.dsk , который необходимо распаковать:

mkdir v7
cd v7
unzip ~/uv7swre.zip

Дальше необходимо создать конфигурационный файл эмулятора:

set cpu u18 set cpu idle attach rl0 unix_v7_rl.dsk attach rl1 hello.tar boot rl0

Сохраните файл как simh-pdp11.ini, в том же самом каталоге v7 , куда был распакован образ диска.

Теперь надо создать tar-файл с собранным бинарником "Hello world" приложения:

cd ~
tar cvf hello.tar hello
cp hello.tar ~/v7/

Итоговый набор файлов должен выглядеть как-то так:

Запускаем эмулятор:

pdp11 simh-pdp11.ini

После появления приглашения в виде символа @ вводим:

boot

Появится древний предок современного Grub, загрузчик:

Вводим:

rl(0,0)rl2unix

Появится приглашение в виде символа # , что означает запуск Unix v7 в однопользовательском режиме:

Нажмите Ctrl - D для начала работы в многопользовательском режиме:

Появится хорошо знакомое любому юниксоиду приглашение авторизации. Введите root в качестве логина и пароля:

При первом запуске будет необходимо выполнить ряд дополнительных шагов. Создаем каталог для временных файлов:

mkdir /tmp

Создаем ссылки на устройства:

cd /dev
make rl

Таким образом со стороны запущенной в эмуляторе Unix v7 будет доступно устройство, эмулирующее ленту и можно будет добраться наконец до собранного на хосте бинарника:

cd /tmp
tar xvf /dev/rrl1

В результате в файловой системе появится тот самый файл hello, собранный на FreeBSD с помощью ACK:

Наконец сам запуск:

Ну кто еще вам спрашивается покажет такую красоту?

Эпилог

ACK имеет отличную портируемость и расширяемость, поэтому существует столь интересный форк этого проекта:

This fork of the Amsterdam Compiler Kit supports the Cray X-MP supercomputer and the COS operating system platform.

Его тоже удалось собрать и запустить, но ввиду невероятной сложности самобытности COS, история будет уже в отдельной статье. Следите за анонсами, как говорится.

Статья была опубликована на Хабре, оригинал как обычно в нашем блоге, все желающие получить обои с автографом (и не умеющие пользоваться нейросетями) должны будут повторить все описанные в статье шаги и прислать скриншот с работающим «Hello <username>» под Unix v7 на PDP, где username — ваш ник.

Казалось бы, какое отношение «хипстерские скрипты для веб» могут иметь к жестким реалиям встариваемых систем, со всей их низкоуровневой работой и ограниченными ресурсами?

Увы, но реальность в очередной раз оказалась куда интересней предубеждений, так и появилась на свет эта статья.

Что это и зачем

Начну как обычно с цитаты:

mruby is the lightweight implementation of the Ruby language complying with part of the ISO standard. mruby can be linked and embedded within your application.

Словом, это такая особенная реализация языка Ruby, с упором на встраивание и встраиваемые системы — да да, тот самый «кровавый embedded», где царствует чистый C, ссылочная арифметика, malloc() и прочие кошмары и ужасы для современного разработчика.

И вдруг в этом царстве Аида появляетесь вы весь в белом и пишете что-то такое, высокоуровневое:

extend Yeah::DSL
set port: 3000

get '/hi/{name}' do |name|
"Привет #{name}"
end

ENV['SHELF_ENV'] = 'production'

puts "Запуск.."
__main__ [0]

И.. оно просто работает:

И даже вот так:

Круто?

Сколько там пудов соли нужно скушать, чтобы так просто работать с юникодом из чистого С, тем более в embedded среде?

Кстати вся эта «радость хипстера» еще и собирается в очень небольшой бинарник:

Внутри будет «все и сразу»:

MRuby, все используемые библиотеки и само приложение.

Хотя на ЛОРе заметили, что «640кб хватит на всех» это как‑то многовато будет, все же напомню что мы живем в мире копеечных 128Гб флешек и битва за каждый байт свободного места уже не так актуальна как 10 лет назад.

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

Поддерживаемые платформы

К сожалению не удалось найти одним списком все поддерживаемые MRuby платформы, поэтому ограничусь только конкретными найденными примерами.

Из самого интересного:

разработка для Sega Dreamcast и Nintendo Wii, для POS-терминалов, встраивание в iOS приложения.

Ну и собственно встраиваемые системы:

1. ESP32 , шаблон проекта находится вот тут.

1. RP2040 (Raspberry Pi), пример проекта находится тут.

2. PIC32, пример вот тут.

Тестовый проект

Поскольку «малинки» в очередной раз под рукой не оказалось, было решено реализовать тестовый проект на банальном x86 — была собрана вся цепочка разработки, включая фреймворки, был реализован «Hello world» в виде веб‑приложения, работающего на встроенном веб‑сервере.

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

Для тестового проекта использовалось вот это «чудо»:

Yeah! is a DSL for quickly creating shelf applications in mruby with minimal effort

Если кратко, то это своеобразная попытка реализовать «мини‑Rails, работающий на мини‑Ruby». Вполне себе успешная, надо отметить.

А теперь самое важное:

Фреймворки для mruby представляют собой надстройку, которая в процессе собирает сам mruby и добавляет себя в собираемые бинарники.

Звучит сложно и выглядит страшно, но для embedded-среды является привычным делом.

Так что нам будет нужно получить бинарники mruby и mrbc с упакованным внутрь фреймворком yeah и всеми библиотеками, а затем использовать этот билд для сборки уже своего приложения.

Для сборки фреймворка Yeah! требуется внешний «большой» Ruby и rake, будут работать как 2.x так и 3.x версии.

Клонируем проект с фреймворком Yeah!:

git clone https://github.com/katzer/mruby-yeah.git

Поскольку по‑умолчанию собирается только компилятор mirbc, без интерактивной консоли (mirb) и интерпретатора (mruby), чего не хватит для нормальной разработки конечного приложения, добавляем в файл build_config.rb:

conf.gem :core => 'mruby-bin-mruby'
conf.gem :core => 'mruby-bin-mirb'
conf.gem :core => 'mruby-bin-mrbc'

И запускаем сборку:

rake compile

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

Первая — про заголовочный файл mingw.h:

In file included from /opt/work/tmp/mruby-yeah/mruby/build/repos/host/mruby-r3/r3/src/memory.c:34:
/opt/work/tmp/mruby-yeah/mruby/build/repos/host/mruby-r3/r3/src/mman.h:15:10: fatal error: _mingw.h: No such file or directory
15 | #include <_mingw.h>
| ^~~~~~~~~~
compilation terminated.
rake aborted!

В файле mman.h есть вот такая строка:

/* All the headers include this file. */
#ifndef _MSC_VER
#include <_mingw.h>
#endif

Переменная _MSC_VER не задается при сборке на FreeBSD, поэтому срабатывает вариант по умолчанию — для Windows и MinGW. В качестве исправления, я просто закомментировал этот блок, не заморачиваясь дальнейшими изысканиями.

Вторая ошибка также достаточно банальна и происходит из-за разницы в реализации функции mmap:

/opt/work/tmp/mruby-yeah/mruby/build/repos/host/mruby-r3/r3/src/mman.h:52:9: error: conflicting types for 'mmap'; have 'void *(void *, size_t, int, int, int, OffsetType)' {aka 'void *(void *, long unsigned int, int, int, int, unsigned int)'}
52 | void* mmap(void *addr, size_t len, int prot, int flags, int fildes, OffsetType off);
| ^~~~
In file included from /opt/work/tmp/mruby-yeah/mruby/build/repos/host/mruby-r3/r3/src/memory.c:27:
/usr/include/stdio.h:444:10: note: previous declaration of 'mmap' with type 'void *(void *, size_t, int, int, int, __off_t)' {aka 'void *(void *, long unsigned int, int, int, int, long int)'}
444 | void *mmap(void *, size_t, int, int, int, __off_t);
| ^~~~
rake aborted!

В этом же файле mman.h заменяем:

void* mmap(void *addr, size_t len, int prot, int flags, int fildes, OffsetType off);

на:

void* mmap(void *addr, size_t len, int prot, int flags, int fildes, __off_t);

И повторно запускаем сборку.

Если сборка прошла успешно то в папке build/host/bin будут готовые бинарники:

ls ./mruby/build/host/bin/
mirb mrbc mruby
Теперь с их помощью запускаем сборку уже нашего тестового приложения:

/opt/work/mruby-yeah/mruby/build/host/bin/mrbc -Btest_symbol ~/test.rb

Это сгенерирует файл test.c с вот таким контентом:

#include <stdint.h>
#ifdef __cplusplus
extern
#endif
const uint8_t test_symbol[] = {
0x52,0x49,0x54,0x45,0x30,0x33,0x30,0x30,0x00,0x00,0x01,0x3e,0x4d,0x41,0x54,0x5a,
0x30,0x30,0x30,0x30,0x49,0x52,0x45,0x50,0x00,0x00,0x01,0x0c,0x30,0x33,0x30,0x30,
0x00,0x00,0x00,0xcd,0x00,0x01,0x00,0x05,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x3d,
0x1d,0x02,0x01,0x1f,0x02,0x00,0x2d,0x01,0x02,0x01,0x10,0x02,0x03,0x0e,0x03,0x0b,
0xb8,0x2d,0x01,0x04,0x10,0x51,0x02,0x00,0x57,0x03,0x00,0x2e,0x01,0x05,0x01,0x1d,
0x01,0x06,0x51,0x02,0x01,0x51,0x03,0x02,0x24,0x01,0x51,0x02,0x03,0x2d,0x01,0x07,
0x01,0x06,0x02,0x47,0x02,0x01,0x2d,0x01,0x08,0x01,0x38,0x01,0x69,0x00,0x04,0x00,
0x00,0x0a,0x2f,0x68,0x69,0x2f,0x7b,0x6e,0x61,0x6d,0x65,0x7d,0x00,0x00,0x00,0x09,
0x53,0x48,0x45,0x4c,0x46,0x5f,0x45,0x4e,0x56,0x00,0x00,0x00,0x0a,0x70,0x72,0x6f,
0x64,0x75,0x63,0x74,0x69,0x6f,0x6e,0x00,0x00,0x00,0x0e,0xd0,0x97,0xd0,0xb0,0xd0,
0xbf,0xd1,0x83,0xd1,0x81,0xd0,0xba,0x2e,0x2e,0x00,0x00,0x09,0x00,0x03,0x44,0x53,
0x4c,0x00,0x00,0x04,0x59,0x65,0x61,0x68,0x00,0x00,0x06,0x65,0x78,0x74,0x65,0x6e,
0x64,0x00,0x00,0x04,0x70,0x6f,0x72,0x74,0x00,0x00,0x03,0x73,0x65,0x74,0x00,0x00,
0x03,0x67,0x65,0x74,0x00,0x00,0x03,0x45,0x4e,0x56,0x00,0x00,0x04,0x70,0x75,0x74,
0x73,0x00,0x00,0x08,0x5f,0x5f,0x6d,0x61,0x69,0x6e,0x5f,0x5f,0x00,0x00,0x00,0x00,
0x33,0x00,0x03,0x00,0x05,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x0e,0x34,0x04,0x00,
0x00,0x51,0x03,0x00,0x01,0x04,0x01,0x52,0x03,0x38,0x03,0x00,0x01,0x00,0x00,0x0d,
0xd0,0x9f,0xd1,0x80,0xd0,0xb8,0xd0,0xb2,0xd0,0xb5,0xd1,0x82,0x20,0x00,0x00,0x00,
0x4c,0x56,0x41,0x52,0x00,0x00,0x00,0x16,0x00,0x00,0x00,0x01,0x00,0x04,0x6e,0x61,
0x6d,0x65,0x00,0x00,0xff,0xff,0x45,0x4e,0x44,0x00,0x00,0x00,0x00,0x08,
};

Длинная "сопля" выше - ни что иное как готовый байткод mruby, записанный в виде статичного массива байт.

Параметр -Btest_symbol как нетрудно догадаться отвечает за название этого массива.

А вот так выглядит само приложение для запуска (файл test_stub.c):

#include <mruby.h>
#include <mruby/irep.h>
#include <test.c>

int
main(void)
{
mrb_state *mrb = mrb_open();
if (!mrb) { /* handle error */ }
mrb_load_irep(mrb, test_symbol);
mrb_close(mrb);
return 0;
}

Все что тут происходит это просто выдача байткода интерпретатору mruby при запуске обертки. Обратите внимание на строчку:

#include <test.c>

Это и есть включение файла с байткодом mruby.

Ну и наконец сборка конечного тестового приложения:

gcc -std=c99 -static -Os -s -I/opt/work/mruby-yeah/mruby/include -I. test_stub.c -o test_program /opt/work/mruby-yeah/mruby/build/host/lib/libmruby.a -lm -lpthread

Если все пройдет успешно, в текущей папке появится финальный бинарник test_program, который я запускал в самом начале.

Эпилог

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

Также как и правительству Японии, которая этот проект финансирует.

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

С нетерпением жду отзывов о реальном использовании.

P.S.

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

Буднично рассказываю как локализовать обычное корпоративное приложение на нечеловеческие языки: Клингонский и Р’льех.

Эээ.. думаю стоит начать с демонстрации результата — той самой нереальной локализации, ради которой все это и затевалось, чтобы всем сразу "все стало понятно".

Так выглядит версия на клингонском:

А вот так выглядит версия на Р'льех:

Ну и наконец банальный английский:

Вот так выглядит в работе переключение локализации:

Да, это самое обычное веб-приложение на Java, работающее в обычном браузере.

Матчасть

Чтобы вы смогли оценить сложность задачи «локализации на язык которого нет», стоит для начала рассказать как происходит обычная локализация — на обычные человеческие языки.

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

• Определение текущей локали

• Переключение локали

• Хранение локализованных строк

• Отображение локализованных данных

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

Вот так например выглядит хранение локализованных строк:

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

Locale locale = Locale.forLanguageTag("en_US");

Где en — это указание на английский а US — на страну США.

Не менее легко происходит и переключение между языками (в данном случае в Jakarta Faces):

FacesContext.getCurrentInstance().getViewRoot().setLocale(locale);

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

Язык которого нет

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

Что означает невозможность какой-либо работы «из коробки» с таким языком — без специальных шагов.

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

Клингонский

Фантастический, полностью выдуманный сценаристами сериала Star Trek язык расы инопланетян еще в 70х оказался невероятно популярным. Популярным настолько, что ныне существует целый институт, посвященный изучению вымышленного языка:

Институт клингонского языка (англ. the Klingon Language Institute, KLI) — независимая организация в Пенсильвании, США. Её цели — поддержка и развитие клингонского языка и клингонской культуры, представленных в вымышленной вселенной киносериала «Звёздный путь». Она поддерживается Paramount Pictures.

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

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

Например в ядро Linux:

In September 1997, Michael Everson made a proposal for encoding KLI pIqaD in Unicode, based on the Linux kernel source code. The Unicode Technical Committee rejected the Klingon proposal in May 2001

В официальный набор символов Unicode (линк):

September 1997: first Unicode proposal for pIqaD.1
May 2001: Rick McGowan submits Proposal to Reject Klingon
May 2001: Proposal to reject Klingon adopted by UTC (minutes)
November 2016: New Proposal for Encoding Klingon, showing lots of examples of usage
July 2020: Another New Proposal for Encoding Klingon. This one uses the correct “Klingon” names for the letters.
August 2021: Request to Remove Klingon from Non-Approval List, made in accordance with Ken Whistler’s suggestion from 2016, linked above.

Как видите фанаты "Star Trek" крайне упертые товарищи, которые уже второй десяток лет продолжают упорно осаждать двери офиса по адресу:

611 Gateway Blvd.
Suite 120

в Сан‑Франциско CA 94 080, где и располагается «The Unicode Consortium». Кстати вы также можете позвонить в консорциум Unicode на их офисный номер:

+1-408-401-8915

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

Удивительно (или нет), но в Microsoft тоже любят клингонский, настолько что добавили его поддержку в свой онлайн-переводчик:

При таком интересе технически продвинутой общественности, очень быстро появились готовые TTF-шрифты, использующие PUA область:

Since then several fonts using that encoding have appeared, and software for typing in pIqaD has become available

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

Вот так выглядит клингонский алфавит:

Р'льех

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

С названием есть небольшая неточность:

Cthuvian, which is also called R'lyehian, is a fictional language created by H. P. Lovecraft in "The Call of Cthulhu" and expanded upon by various authors.

Дословный перевод — «ктулхский» или «р'льехский», что (да простят меня подводные боги) показалось не очень благозвучным.

Поэтому я использовал термин Р'льех, который на самом деле означает иное:

Р’льех или Р'лайх (англ. R’lyeh) — вымышленный город, впервые упомянутый Говардом Филлипсом Лавкрафтом в рассказе «Зов Ктулху» (1928)[1]. С тех пор Р’льех стал неотъемлемой частью мифологии Лавкрафта и Мифов Ктулху. Р’льех описан в «Некрономиконе» Лавкрафта и «Cthaat Aquadingen» Брайана Ламли.

Алфавит выглядит как-то так:

Доступные TTF-шрифты для Р'льех не используют PUA-область Unicode, поэтому применение такого шрифта превратит все символы в месиво:

Но если переключиться на клингонский, будет виден ввод символов на нормальных языках:

В этом и заключается главная сила PUA-области и ее главная фишка.

Будете создавать локализацию на древнеегипетский или руническое письмо викингов — обязательно используйте шрифт с PUA-областью.

Тестовый проект

Для статьи был специально выбран самый «тру‑энтерпрайз» стек, чтобы показать насколько далеко продвинулись технологии локализации. Это не какие-то околонаучные экспериментальные языки или малоизвестные специализированные фреймворки и не дикий «low level» с песьеголовыми программистами на С, это самый настоящий технологический мейнстрим — тот вид разработки и набор технологий, с которыми вы (если занимаетесь разработкой) сталкиваетесь каждый день:

представьте любимый клиент-банк с локализацией на клингонском.

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

Вот что в меню:

JakartaEE 10, который в девичестве назывался JavaEE а в далеком детстве J2EE.

В качестве сервера приложений был взят IBM OpenLiberty — современный открытый потомок большой IBM Websphere Application Server, который IBM ныне продвигает в светлое корпоративное будущее как платформу для разработки микросервисов.

Технически тестовый проект представляет собой веб‑приложение (WAR), которое разворачивается на сервере приложений и по полной использует его ресурсы — все как в золотые годы JavaEE.

Но чтобы не загонять читателей в классические мытарства с установкой и развертыванием — был добавлен автозапуск приложения с автоматическим развертыванием (как в Spring Boot).

Внутри классика корпоративной разработки:

JPA, CDI, JSF и новое Servlet API 6 — уже полностью на аннотациях.

Все прямо как на настоящей работе в банке, где деньги платят.

И сейчас мы будем локализовывать все это на выдуманный язык из фантастического сериала 1970х.

Но прежде опишу стандатное — сборку и запуск.

Сборка

Для сборки используется обычный Apache Maven и последняя версия JDK (22+), забираем проект из репозитория:

git clone https://github.com/alex0x08/javaee-klingon.git

Затем запускаем сборку:

mvn clean package

Готовое приложение будет находиться в каталоге target:

В каталоге liberty находится распакованный сервер приложений Open Liberty, с установленным внутрь нашим приложением — за все эти радости отвечает специальный плагин (см. ниже).

Запуск

Как уже упоминалось выше, наш замечательный проект предназначен для запуска и работы на сервере приложений IBM Open Liberty.

Разумеется вы можете сходить по ссылке выше, прокрутить страницу вниз до раздела Releases, скачать версию 24.0.0.6+ с профилем Jakarta EE 10, развернуть и затем установить туда наше приложение.

Для настоящего развертывания в корпоративной среде обычно и делают. По крайней мере делали до эры докера.

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

Одной командой:

mvn liberty:dev

Произойдет скачивание IBM Open Liberty, распаковка, настройка, установка внутрь нашего приложения и немедленный запуск.

Вот так это выглядит из среды разработки Intellj Idea:

После запуска открываем страницу:

http://localhost:9080/kligonweb-1.0.1-RELEASE/guestbook.xhtml

и наслаждаемся.

Отображение

Начну с самого главного вопроса — с отображения символов несуществующего фантастического языка. Взгляните:

На скриншоте выше стандартный gedit, в настройках которого был задан клингонский шрифт для отображения основной части. Как видите использование PUA‑области Unicode в шрифте позволяет неплохо дружить символы обычного и фантастического языков.

Если приглядитесь — увидите сглаживание, работающее даже для глифов клингонского.

К сожалению для Р'льех не нашлось шрифта, использующего PUA‑область Unicode, поэтому при отображении происходит замена всех символов глифами Р'льех:

К сожалению нехватило времени для разработки с нуля шрифтов двух несуществующих языков, поэтому были взяты готовые.

Для клингонского:

Klingon pIqaD Mandel takes the Klinzhai or Mandel font glyphs (really a different alphabet from the KLI’s Standard pIqaD) and refits them for use as pIqaD.

и еще один для Р'льех:

I created this font based on the description by H.P. Lovecraft. Click here to download the Rlyehian font package, which includes two version of the font and a guide to understanding its use.

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

FontForge

Уже достаточно давно и успешно существует отличный открытый редактор шрифтов:

FontForge is a FOSS font editor which supports many common font formats. Developed primarily by George Williams until 2012, FontForge is free software and is distributed under a mix of the GNU General Public License Version 3 and the 3-clause BSD license.[2] It is available for operating systems including Linux, Windows,[3] and macOS,[4] and is localized into 12 languages

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

Вот так выглядит клингонский шрифт, открытый в этом редакторе:

Вот так выглядит процесс редактирования отдельного символа:

А вот так для сравнения выглядит шрифт для Р'льех:

Для полного погружения, вот так выглядит редактирование одного из этих стильных глифов:

Разумеется, можно было потратить какое‑то время и перенести глифы Р'льех в PAU‑область, что позволило бы использование шрифта по аналогии с клингонским — параллельно с другими языками.

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

На самом деле есть еще одна важная причина — показать вам два подхода к локализации, а не один:

второй вариант реализации шрифта с полной заменой всех символов на безумные иероглифы чем-то фантастическим (без использования PAU-области) встречается куда чаще.

Его точно стоит учитывать, поскольку скорее всего именно с таким шрифтом вы и столкнетесь, пытаясь работать с фантастическими языками.

Отображение в браузере

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

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

Регистрация TTF‑шрифта происходит путем использования CSS‑стиля и специальной директивы font‑face:

@font-face {
font-family: 'Klingon';
src: url("#{resource['Klingon-pIqaD-Mandel.ttf']}");
}
@font-face {
font-family: 'Rlyeh';
src: url("#{resource['Rlyehian.ttf']}");
}

Сложно выглядящая директива #resource[''] на самом деле уже часть парсера страниц JSF — EL-выражение, преобразующее относительный путь к указанному ресурсу в полный.

А вот так выглядит задание отдельных стилей для использования наших фантастических шрифтов:

.klingon {
font-family: 'Klingon';
}

Эти стили применяются выборочно, для включения фантастического шрифта при включенной перекодировке у сообщения:

<p class="card-text">
<h:outputText value="#{record.message}"
styleClass="#{record.translateKlingon ? 'klingon' : ''}"/>
</p>

Если сообщение было написано на клингонском pIqaD — оно будет пропущено через транслятор (см. ниже) и при отображении будет использован клингонский TTF‑шрифт.

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

Но это решение только для отдельных блоков сообщений, ведь есть еще глобальное переключение выбранной локали:

Для решения этой задачи, используется вот такая логика:

<h:outputStylesheet
name="style-klingon.css"
rendered="#{i18n.locale.variant eq 'KLINGON'}"/>
<h:outputStylesheet
name="style-rlyeh.css"
rendered="#{i18n.locale.variant eq 'RLYEH'}"/>

Суть ее в том что в зависимости от «variant» выбранной локали (см. ниже) подгружается тот или иной глобальный стиль:

* {
font-family: 'Klingon', sans-serif;
}
body {
background-image: url('klingon.jpg.xhtml');
}

Звездочка (*) означает что указанный шрифт должен быть применен ко всем элементам на странице, что и дает вот такой эффект глобальной локализации всего:

Также тут задается фоновая картинка в немного странном формате:

klingon.jpg.xhtml

На самом деле файл называется klingon.jpg и находится в каталоге webapp/resources, а постфикс .xhtml — особенность работы ресурсов в JSF, он нужен для правильной работы, хотя и выглядит полной дичью.

Переходим к следующей важной теме.

Транслятор

При локализации на несуществующий и неподдерживаемый язык существует еще одна проблема:

необходимо как-то работать с локализованным на такой язык текстом из стандарного окружения.

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

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

Если очень повезет, то пойдя этим путем можно получить что-то такое:

Есть способ лучше. Дело в том что ни один, даже трижды фантастический язык не существует в вакууме — для него в обязательном порядке создается:

Транслитера́ция (лат. trans- «через; пере-» + littera — «буква») — точная передача знаков одной письменности знаками другой письменности[1][2], при которой каждый знак (или последовательность знаков) одной системы письма передаётся соответствующим знаком (или последовательностью знаков) другой системы письма.

Даже если речь про например дотракийский — выдуманный сценаристами язык кхала Дрого из «Игры Престолов», к нему все равно в качестве приложения идет транслитерация на английском — актерам надо как-то учить произношение.

Более того, такая транслитерация существует и для самих человеческих языков, причем видимо для всех (исключений пока не встречал).

Например есть широко известный вариант написания кириллицы с помощью символов латиницы:

kotorii nazyvayetsa 'translit'

Нет людей в рунете старше 30ти, которые бы его никогда не видели.

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

Именно транслитерацию в латинские символы мы и будем использовать.

pIqaD

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

Настолько популярен, что есть даже «Гамлет» в переводе на клингонский, где используется pIqaD-транслитерация:

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

На основе его исходного кода (на Javascript) была написана моя реализация на Java, с помощью которой вот такие строковые ресурсы:

Превращаются во время работы приложения в те самые фантастические иероглифы:

Полный код реализации можно посмотреть вот тут.

Как видите тут происходит достаточно простая замена символов согласно таблице подстановки, с латинских на Unicode из PAU‑области — все внешне сложное, на самом деле устроено очень просто.

К сожалению (или к счастью — в зависимости от контекста), фантастический язык Р’льех из миров Лавкрафта куда менее популярен, поэтому получилось найти всего один рабочий транслятор:

Using the digital serpent's package, you can translate english to the language of the "old ones" Spread aimgr'luh

Занимается им некий китайский DevOps-инженер (надеюсь не в рамках должностных обязанностей), сам транслятор и написан на Python:

python test.py -t "I pray to the mother of skin"

Важным моментом является другой принцип работы — вместо транслитерации символов происходит подстановка слов или даже целых фраз:

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

у меня честно нет идей как могут выглядеть слова «Авторизация», «Назад» или «Сохранить» на языке древних.

Поэтому транслятор Р’льех используется только для ввода текста — чтобы найти истинных последователей показать как это работает.

Но перейдем к следующей интересной теме.

Нереальная локаль

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

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

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

Но для Java весь процесс более-менее отработан, описан и предсказуем:

в Java у локалей есть поддержка т. н. «variant» — специальной вариации языка, которая может быть сколь угодно нестандартной.

Сама локаль остается системной (в данном случае — английской), но при этом к ней добавляется специальный постфикс, означающий что используется «вариация»:

<h:form>
<h:selectOneMenu styleClass="form-select" style="width: 12em;"
value="#{i18n.language}" onchange="submit()">
<f:selectItem itemValue="en" itemLabel="English" />
<f:selectItem itemValue="en-US-KLINGON" itemLabel="Klingon" />
<f:selectItem itemValue="en-US-RLYEH" itemLabel="Rlyeh" />
</h:selectOneMenu>
</h:form>

Поскольку такие variants являются частью официального API, они поддерживаются всем прикладным ПО и библиотеками (за редкими исключениями).

В том числе они используются в механизме работы ResourceBundle:

Если включить «variant» в название файла с ресурсами — он будет найден и загружен при выборе локали с таким «variant». К сожалению стандартной реализации ResourceBundle оказалось недостаточно — хотелось получить перекодированный клингонский сразу из ресурсов, поэтому я сделал свою:

package com.Ox08.experiments.kligon;
import jakarta.annotation.Nonnull;
import jakarta.faces.context.FacesContext;
import java.util.Enumeration;
import java.util.Locale;
import java.util.ResourceBundle;
import java.util.logging.Level;
import java.util.logging.Logger;
/**
* Extended resource bundle, used to inject Klingon glyphs if Klingon locale
* used
*
* @Author <a href="mailto:alex3.145@gmail.com">Alex Chernyshev</a>
*/
public class KlingonedResourceBundle extends ResourceBundle {
public KlingonedResourceBundle() {
setParent(ResourceBundle.getBundle("i18n.messages",
FacesContext.getCurrentInstance().getViewRoot().getLocale()));
}
@override
public final void setParent(ResourceBundle parent) {
super.setParent(parent);
}
@override
protected Object handleGetObject(@Nonnull String key) {
// here will be extracted and substituted value
final Object v = parent.getObject(key);
if (!(v instanceof String vstring)) {
return v;
}
LOG.log(Level.INFO, "handleGetObject : {0}", vstring);
// current locale
final Locale l = FacesContext.getCurrentInstance().getViewRoot().getLocale();
// check if its Klingon and transliterate to glyphs
if ("KLINGON".equals(l.getVariant()))
return KlingonTranslator.transliterate(vstring);
// .. and for Rlyeh
if ("RLYEH".equals(l.getVariant()))
return RlyehTranslator.translate(vstring);

// otherwise - just respond 'as-is'
return v;
}
@override
@Nonnull
public Enumeration<String> getKeys() {
return parent.getKeys();
}
private static final Logger LOG = Logger.getLogger("BUNDLE-KLINGON");
}

Основное действие происходит в методе handleGetObject() ,сейчас разберу логику этого метода по шагам, благо она будет повторяться и в других местах.

Первым шагом происходит вызов такого же метода, но из родительского класса — для получения еще не перекодированного текстового шаблона:

final Object v = parent.getObject(key);

Затем происходит отбраковка по возвращаемому типу — мы работаем только со строками и все остальные варианты пропускаем:

if (!(v instanceof String vstring)) {
return v;
}

Дальше происходит получение текущей локали пользователя:

final Locale l = FacesContext.getCurrentInstance()
.getViewRoot().getLocale();

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

Затем в зависимости от значения «variant» вызывается перекодировщик для клингонского:

if ("KLINGON".equals(l.getVariant()))
return KlingonTranslator.transliterate(vstring);

или для Р'льех:

if ("RLYEH".equals(l.getVariant()))
return RlyehTranslator.translate(vstring);

Регистрация кастомной реализации ResourceBundle задается в файле с настройками Jakarta Faces (webapp/WEB-INF/faces-config.xml):

..
<resource-bundle>
<!--
Note that 'base name' points to specific class,
not to .properties file
-->
<base-name>com.Ox08.experiments.kligon.KlingonedResourceBundle</base-name>
<var>msgs</var>
</resource-bundle>
..

Там же указывается список поддерживаемых локалей, с учетом «variants»:

..
<locale-config>
<default-locale>en</default-locale>
<supported-locale>en_US_KLINGON</supported-locale>
<supported-locale>en_US_RLYEH</supported-locale>
</locale-config>
..

Наконец хранение выбранной пользователем локали происходит в отдельном сессионном бине:

package com.Ox08.experiments.kligon;
import jakarta.annotation.PostConstruct;
import jakarta.enterprise.context.SessionScoped;
import jakarta.faces.context.FacesContext;
import jakarta.inject.Inject;
import jakarta.inject.Named;
import java.io.Serializable;
import java.util.Locale;
import java.util.logging.Logger;
/**
* This bean stores selected locale, attached to user's session
*
* @author <a href="mailto:alex3.145@gmail.com">Alex Chernyshev</a>
*/
@Named("i18n")
@SessionScoped
public class LocaleBean implements Serializable {
@inject
private transient Logger log;
// current locale
private Locale locale;
/**
* Initializes current locale value
*/
@PostConstruct
void init() {
// take current locale from request
locale = FacesContext.getCurrentInstance().getExternalContext().getRequestLocale();
log.log(java.util.logging.Level.INFO,
"Current locale {0} , variant: {1}",
new Object[]{locale.toLanguageTag(), locale.getVariant()});
}
public Locale getLocale() {
return locale;
}
public String getLanguage() {
return locale == null ? null : locale.toLanguageTag();
}
public void setLanguage(String language) {
// get Locale object from language tag
locale = Locale.forLanguageTag(language);
// set it to current view root
FacesContext.getCurrentInstance().getViewRoot().setLocale(locale);
log.log(java.util.logging.Level.INFO,
"Switched locale to {0} , variant: {1}",
new Object[]{locale.toLanguageTag(), locale.getVariant()});
}
}

Поле «locale» из данного бина используется со стороны XHTML-страницы:

..
<f:view xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html"
..
locale="#{i18n.locale}">
..

Но это еще не все интесное и необычное, что хотелось бы раскрыть в рамках статьи.

Валидация данных

Как каша без масла протеина или водка без закуски — не бывает корпоративных приложений без валидации данных.

В Jakarta EE (как и в ее предшественнике JavaEE) для автоматической валидации входных данных используются механизмы из спецификации JSR 303 «Bean Validation».

В самом простом случае это выглядит как аннотирование полей класса:

..
@size(min = 3, max = 255)
private String title; // a title
@NotBlank(message = "{validation.message.not-blank}")
@Lob
@column(length = Integer.MAX_VALUE)
private String message; // message, stored as CLOB in database,
//so size is almost unlimited
@size(min = 3, max = 30)
@email
private String author; // author's email
..

Когда такой класс попадает в качестве входящего аргумента метода класса, управляемого CDI‑окружением, срабатывает автоматическая валидация и в интерфейсе появляются сообщения об ошибках:

Если ошибка имеет привязку к конкретному полю, за ее отображение отвечает отдельный блок:

<h:message for="f_message" errorClass="msg" />

если нет — она отображается через «глобальную свалку»:

<p>
<h:messages globalOnly="true" infoClass="msg" errorClass="msg" />
</p>

Теперь обратите внимание вот на эту строчку:

@NotBlank(message = "{validation.message.not-blank}")

Вместо текста сообщения, тут указан некий код, который автоматически заменяется на текст из специального ResourceBundle:

Вся эта логика является частью спецификации JSR303 и вообщем-то отлично работает без вашего участия — до тех пор пока не появляется необходимость сотворить какую-нибудь дичь.

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

Поэтому придется немного подумать.

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

Message interpolators are used by the validation engine to create user readable error messages from constraint message descriptors.

В итоге была написана собственная реализация такого «интерполятора»:

package com.Ox08.experiments.kligon;
import jakarta.validation.MessageInterpolator;
import jakarta.validation.Validation;
import java.util.Locale;
import java.util.logging.Level;
import java.util.logging.Logger;
/**
* Custom JSR 303 Message Interpolator, used to inject Klingon glyphs
* into JSR303 validation
*
* @author <a href="mailto:alex3.145@gmail.com">Alex Chernyshev</a>
*/
public class JSR303KlingonMessageInterpolator
implements MessageInterpolator {
// we need to have existing MessageInterpolator,
// to being used as parent
private final MessageInterpolator delegate;
public JSR303KlingonMessageInterpolator() {
// take default implementation from JSR303 configuration
this.delegate = Validation.byDefaultProvider()
.configure().getDefaultMessageInterpolator();
}
@Override
public String interpolate(String string, Context cntxt) {
LOG.log(Level.INFO, "interpolating {0}", string);
// without specified locale - just pass interpolation to delegate
return delegate.interpolate(string, cntxt);
}
@Override
public String interpolate(String string,
Context cntxt, Locale locale) {
LOG.log(Level.INFO,
"interpolating {0} with locale: {1}",
new Object[]{string, locale.toLanguageTag()});
// here will be extracted and substituted value
final String result = delegate.interpolate(string, cntxt, locale);
// check for Klingon locale and transliterate to glyphs
if ("KLINGON".equals(locale.getVariant()))
return KlingonTranslator.transliterate(result);

if ("RLYEH".equals(locale.getVariant()))
return RlyehTranslator.translate(result);

return result;
}
private static final Logger LOG = Logger.getLogger("JSR303-KLINGON");
}

Основная магия логика заключается вот в этих строках:

..
final String result = delegate.interpolate(string, cntxt, locale);
// check for Klingon locale and transliterate to glyphs
if ("KLINGON".equals(locale.getVariant()))
return KlingonTranslator.transliterate(result);

if ("RLYEH".equals(locale.getVariant()))
return RlyehTranslator.translate(result);

return result;

Как видите, локаль поступает на вход метода в готовом виде — ее не надо определять из контекста JSF, а вот в этом месте происходит получение оригинальной строки из файла с текстовыми строками:

final String result = delegate.interpolate(string, cntxt, locale);

Дальше в зависимости от наличия «variant» у локали, текст либо пропускается через транслятор либо отдается «как есть».

Регистрация кастомного интерполятора также имеет свою специфику — она происходит в отдельном XML-файле:

<?xml version="1.0" encoding="UTF-8"?>
<validation-config
xmlns="https://jakarta.ee/xml/ns/validation/configuration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/validation/configuration
https://jakarta.ee/xml/ns/validation/configuration/validatio..."
version="3.0">
<!-- register custom interpolator, used to retrieve i18n validation messages -->
<message-interpolator>com.Ox08.experiments.kligon.JSR303KlingonMessageInterpolator</message-interpolator>
</validation-config>

Который находится в файле src/main/resources/META-INF/validation.xml

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

Заметьте — не просто фантастический формат отображения а целый календарь!

Фантастические даты

Никогда не задумывались какой смысл закладывается в дату?

Что такое на самом деле 2024й год?

Фактически это означает что прошло 2024 года с рождения Иисуса Христа (по новому летоисчислению), что возможно не очевидно некоторым представителям молодого поколения, но вполне достаточно для жизни и работы цивилизации.

А что если вам надо использовать альтернативную систему расчета времени?

Миллион лет от последнего динозавра?

40 000 лет бесконечной войны?

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

Вселенная сериала Star Trek оказалась настолько продуманной и проработанной что там есть собственная система летоисчисления:

A stardate is a fictional system of time measurement developed for the television and film series Star Trek. In the series, use of this date system is commonly heard at the beginning of a voice-over log entry, such as "Captain's log, stardate 41153.7.

Именно ее поддержку я и решил реализовать:

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

Финальную реализацию можно посмотреть тут.

Но одной только реализации кастомного календаря оказалось мало — нужен еще один класс-конвертер, реализующий непосредственно конвертацию дат с этим календарем:

package com.Ox08.experiments.kligon;
import jakarta.faces.component.UIComponent;
import jakarta.faces.context.FacesContext;
import jakarta.faces.convert.Converter;
import jakarta.faces.convert.FacesConverter;
import java.time.ZoneId;
import java.time.ZonedDateTime;
import java.time.format.DateTimeFormatter;
import java.util.Date;
import java.util.Locale;
/**
* A custom converter for StarDate
* @author alex0x08
*/
@FacesConverter(value = "stardateConverter")
public class StarDateConverter implements Converter<Date> {
@Override
public Date getAsObject(FacesContext fc,
UIComponent uic, String string) {
final Locale l = fc.getViewRoot().getLocale();
if ("KLINGON".equals(l.getVariant()))
return StarDate.parseStarDate(string).getDate();

return Date.from(ZonedDateTime.parse(string,
DateTimeFormatter.ISO_DATE_TIME
.withZone(ZoneId.systemDefault())).toInstant());
}
@Override
public String getAsString(FacesContext fc, UIComponent uic, Date t) {
final Locale l = fc.getViewRoot().getLocale();
if ("KLINGON".equals(l.getVariant()))
return StarDate.newInstance(t).toString();
return DateTimeFormatter.ISO_DATE_TIME
.withZone(ZoneId.systemDefault())
.format(t.toInstant());
}
}

Активируется этот конвертер автоматически благодаря наличию аннотации:

@FacesConverter(value = "stardateConverter")

И автоматически же применяется для всех полей с типом Date, проходящих через бины, управляемые CDI.

Внутри уже традиционная логика получения текущей локали:

final Locale l = fc.getViewRoot().getLocale();

Затем при наличии клингонского «variant» происходит либо преобразование из объекта в строку с учетом кастомного календаря:

if ("KLINGON".equals(l.getVariant()))
return StarDate.parseStarDate(string).getDate();

либо из строки в объект (также с учетом StarDate):

if ("KLINGON".equals(l.getVariant()))
return StarDate.newInstance(t).toString();

На этом красивая история о нереальном подходит к концу, подведем итоги.

Итоги и выводы

В современных реалиях и с использованием современных инструментов нет серьезных препятствий для локализации на любые неведомые языки — искусственные или настоящие.

Отсутствие официальной поддержки «из коробки» в инструментах разработки и даже отсутствие символов в таблице символов Unicode — не является проблемой для настоящего джедая.

Первым шагом необходимо разработать или найти готовый TTF‑шрифт для вашего языка и проверить его отображение в системе и браузере — если планируется веб‑разработка.

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

Вся дальнейшая работа сведется к включению транслятора в ключевых местах проекта.

P.S.

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

Хотите довести до дурки любимого преподавателя компьютерных наук или навсегда прослыть «особенным» среди коллег, сразу после немедленного увольнения?

Ниже патентованный метод, с которым вас точно не забудут.

Электронная дичь

Ладно, допустим вы не имеете отношения к ИТ или не занимаетесь непосредственно разработкой ПО. Возможно вы начинающий веб‑разработчик, умеющий только в лендинги и сайты‑визитки — словом вы никогда прежде не слышали об экзотерических языках программирования и их ярчайшем представителе:

Brainfuck — один из эзотерических языков программирования, придуман Урбаном Мюллером (нем. Urban Müller) в 1993 году, известен своим минимализмом. Название языка можно перевести на русский как вынос мозга, оно напрямую образовано от английского выражения brainfuck (brain — мозг, fuck — вынос), т. е. заниматься ерундой. Язык имеет восемь команд, каждая из которых записывается одним символом. Исходный код программы на Brainfuck представляет собой последовательность этих символов без какого-либо дополнительного синтаксиса.

Понимаю, тяжело воспринять фразу «экстремальный минимализм» по отношению к языку программирования, поэтому вот вам небольшая иллюстрация:

>+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.>>>++++++++[<++++>-] <.>>>++++++++++[<+++++++++>-]<---.<<<<.+++.------.--------.>>+.>++++++++++.

Да это исходный код программы.

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

Разбираем по шагам:

>++.

в ячейке 1 добавление 2 к 70 и вывод на печать ASCII-кода 72, т.е. буквы «Н».

>+.

в ячейке 2 добавление 1 к 100 = 101, печать буквы «e»

+++++++..

в этой же ячейке добавление 7 к 101 = 108, печать «l» дважды

+++.

в этой же ячейке добавление 3 к 108 = 111, печать «o»

И так далее и тому подобное:

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

Теперь, если вы занимаетесь разработкой и более‑менее подкованы в программировании — вернитесь обратно к картинке выше и задумайтесь: что именно автор тут для вас приготовил:)

Транспилеры и компиляторы

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

Начнем с транспилера:

A source-to-source translator, source-to-source compiler (S2S compiler), transcompiler, or transpiler is a type of translator that takes the source code of a program written in a programming language as its input and produces an equivalent source code in the same or a different programming language. A source-to-source translator converts between programming languages that operate at approximately the same level of abstraction, while a traditional compiler translates from a higher level programming language to a lower level programming language.

Максимально упрощая, транспилер — такой специальный компилятор, для превращения исходного кода на одном языке в исходный код на другом языке.

Очень часто используется на практике, в том числе в современных и сверхпопулярных языках вроде Java или.NET.

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

Теперь про интерпретатор:

In computer science, an interpreter is a computer program that directly executes instructions written in a programming or scripting language, without requiring them previously to have been compiled into a machine language program.

По‑сути это такой «разнорабочий от мира ПО», который сам ничего не умеет, зато отлично выполняет простые последовательные команды.

И наконец «его величество» компилятор:

In computing, a compiler is a computer program that translates computer code written in one programming language (the source language) into another language (the target language). The name «compiler» is primarily used for programs that translate source code from a high-level programming language to a low-level programming language (e.g. assembly language, object code, or machine code) to create an executable program.[1][2]

Да это «та самая программа с помощью которой создаются другие программы», в изначальном смысле этого слова.

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

В теории.

Именно эту дичь мы сейчас и будем творить.

Но все же объясню чуть подробнее, для обывателей:

программировать на самом Brainfuck безумно тяжело и ничего сложнее «Hello, World» у вас не выйдет пока вы не рехнетесь, но если использовать транспилер, — становится возможно писать код уже на С (или С‑подобном языке) и гораздо более интересные вещи.

Например можно взять домашнее задание по числам Фибоначчи:

include "std.bfx"

function main()
{
prints("f[0] = ");
let a = scand();

prints("f[1] = ");
let b = scand();

prints("Up to n = ");
let n = scand();

prints("0: "); printd(a); endl();
for (let i = 0; i != n - 1; ++i)
{
printd(i + 1); prints(": ");
printd(b); endl();

let tmp = b;
b += a;
a = tmp;
}

printd(n); prints(": ");
printd(b); endl();
}

И сдать его в таком интересном виде (фрагмент):

>>>[-]++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.>[-]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.>[-]++++++++++++++++++++++++++++++++++++++++++++++++.>[-]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.>[-]++++++++++++++++++++++++++++++++.>[-]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.>[-]++++++++++++++++++++++++++++++++.<<<[-]+>>[-]>[-]>[-]+>[-]+>[-]+>[-]>[-]>[-]+>[-]+>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]>[-]<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<[-]>>>>>[>>>>>[-]>>[-]>[-]<<<<<[>>>>+>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<[-]>>>[-]<<<<<[>>+>>>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<<[>[<<[-]+>>[-]]<[-]]>>>>[-]>[-]<<<<<<[>>>>>+>+<<<<<<-]>>>>>>[<<<<<<+>>>>>>-]>[-]+>[-]>[-]<<<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<[-]>[-]]<<<[>>>>>[-]>>[-]>[-]<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>+>+<<<<<<<<<<<<<<<-]>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>-]<<[-]>>>[-]<<<<<<<<<<<<<<<[>>>>>>>>>>>>+>>>+<<<<<<<<<<<<<<<-]>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>-]<<<[>[<<[-]+>>[-]]<[-]]>>>>[-]>[-]<<<<<<[>>>>>+>+<<<<<<-]>>>>>>[<<<<<<+>>>>>>-]>[-]+>[-]>[-]<<<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<[-]>[-]]<<<[>>>>>[-]+>[-]+>[-]>>[-]>[-]<<<<<[>>>>+>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<[-]>>>[-]<<<<<[>>+>>>+<<<<<-]>>>>>[<<<<<+>>>>>-]<<<[>[<<[-]+>>[-]]<[-]]>>>>[-]>[-]<<<<<<[>>>>>+>+<<<<<<-]>>>>>>[<<<<<<+>>>>>>-]>[-]+>[-]>[-]<<<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<[-]>[-]]<<<[>>>>>,>[-]>[-]<<[>+>+<<-]>>[<<+>>-]<<<<<<<[-]]>>[[-]]<<<<<<<<<[-]>[-]>>>>>>>>>>>>[<<<<<<<<<<<<<+>+>>>>>>>>>>>>-]<<<<<<<<<<<<[>>>>>>>>>>>>+<<<<<<<<<<<<-]<<<<<<[-]]>>[[-]]>>>>>[-]>>[-]>[-]<<<

Полный вариант занимает ~1.6Mb одной строкой, представляте как обрадуется любимый преподаватель такой оригинальной работе?

Главное чтобы вас потом не нашли.

Теперь перейдем к инструментарию для наших веселых шалостей.

Гримуар

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

Bfpy

Автор этого замечательного проекта объявил личный джихад здравому смыслу:

BFPY is an alternative Python runtime that uses Brainfuck as a bytecode.

Для тех кто еще не оценил всю мощь по одной цитате выше, приведу небольшой пример кода:

#!/usr/bin/env python3.4
# coding: utf-8

from bfpy.instruction import Instruction
from bfpy.bytecode import Bytecode
from bfpy.machine import Machine

def test(x,y):
return x + y

def main():
bc = Bytecode.from_function(test, x=40,y=2) #42
print(bc)
vm = Machine(bc)
vm.run()
print(vm.current)

if __name__ == '__main__':
main()

Вот так это чудо выглядит в работе:

Теперь немного разберем логику, для погружения в безумие лучшего понимания.

Вот эта замечательная строка генерирует код Brainfuck из байткода Python:

bc = Bytecode.from_function(test, x=40,y=2) #42

Что вы и видите на скриншоте выше, где сам вывод на печать делает данная инструкция:

print(bc)

Следующий блок интерпретирует код на Brainfuck и выводит на печать:

vm = Machine(bc)
vm.run()
print(vm.current)

Вся эта радость отлично встраивается например в Python‑скрипт работающий с нейросетями, тем самым добавляя новую грань смысла слову «blackbox», которым так любят прикрывать свои провалы ML‑разработчики.

К сожалению этот проект очень далек до завершения:

For instance, BFPY can only translate arithmetic operations (addition, subtraction, multiplication, floor division and power). There is still a lot of features to implement for it to be a proper Python runtime alternative

Поэтому если у вас есть лишний $1млн и ненависть к человечеству — можете проинвестировать в этот замечательный проект. Деньги пойдут автору на лечение в лучшей дурке.

Brainfix

Следующий проект зашел немного дальше в своем безумии, поэтому именно с его помощью мы с вами и сделаем тестовое приложение:

BrainFix is a compiler/language that takes a C-style language (although the syntax slowly evolved to something very close to Javascript for some reason) and compiles this into BrainF*ck, an esoteric programming language consisting of only 8 operations.

Забираем исходный код и пробуем собрать:

git clone https://github.com/jorenheit/brainfix
cd brainfix
make

К сожалению при сборке появится такая ошибка:

Чтобы ее исправить достаточно закомментировать это условие выбора в makefile:

ifeq ($(GAMING_MODE_AVAILABLE),1)

Нет, я тоже не догадываюсь для чего компилятору Brainfuck мог понадобиться игровой режим, но конечный результат должен быть таким:

CC=g++
CFLAGS= -c -O3 -Wall --std=c++2a -fmax-errors=2 #-Wfatal-errors
SOURCES=interpreter/bfint.cc interpreter/main.cc

OBJECTS=$(SOURCES:.cc=.o)
EXECUTABLE=bfint

all: $(SOURCES) $(EXECUTABLE)

#ifeq ($(GAMING_MODE_AVAILABLE),1)
#$(EXECUTABLE):$(OBJECTS)
# $(CC) $(OBJECTS) -o ../$@ -lncurses
#
#.cc.o:
# $(CC) $(CFLAGS) -DUSE_CURSES lt; -o $@
#
#else

$(EXECUTABLE):$(OBJECTS)
$(CC) $(OBJECTS) -o ../$@

.cc.o:
$(CC) $(CFLAGS) lt; -o $@
#endif

После правки сборка успешно завершается:

В результате сборки в корневом каталоге появится готовый бинарник bfx, запускаем и наслаждаемся:

Теперь пробуем собрать тестовый пример, с помощью вот такой простой и очевидной команды:

./bfx -o program.bf -O1 -I ./std -t int16 bfx_examples/hello.bfx

Результат:

Для проверки корректности, вставляем полученный код Brainfuck в онлайн-интерпретатор:

Там еще много интересных примеров, но большие программы будут ощутимо долго компилироваться в код на Brainfuck, имейте ввиду.

Но едем дальше.

BFC

Как лаконично описывает проект его автор: «an industrial‑grade Brainfuck compiler» и он при этом совсем не врет:

bfc includes an extensive range of optimisations. This page discusses the techniques used, and gives examples of BF programs that are transformed in each case.

Написана эта штука разумеется на Rust (неужели вы сомневались?) и сейчас мы будем ее пенетри.. ээ использовать.

Забираем исходники:

git clone https://github.com/Wilfred/bfc.git

Собирается это чудо сумрачного гения вот такой командой:

RUSTFLAGS='-L /usr/local/lib' cargo build --release

Поскольку дело происходит на FreeBSD (неужели я забыл об этом упомянуть?), с помощью переменной окружения RUSTFLAGS необходимо указать путь /usr/local/lib, который почему‑то не учитывается сборщиком cargo.

Также на машине должен быть сам Rust и 14я версия LLVM.

Зато теперь вы тоже знаете как использовать Rust на FreeBSD, надеюсь эти знания помогут вам построить успешную карьеру в ИТ-индустрии а не наставят на путь экстремального ИТ-терроризма.

В результате успешной сборки в каталоге ./target/debug появится готовый к использованию бинарник bfc:

Что же мы будем делать с оптимизирующим компилятором Brainfuck? Разумеется использовать для всего хорошего и замечательного:

./target/release/bfc /opt/work/tmp/brainfix/program.bf

Это тот самый пример с «Hello world!» сгенерированный выше из С‑подобного кода, который с помощью замечательного оптимизирующего компилятора превратился в настоящее приложение:

Итого

Повторим еще раз всю цепочку для лучшего запоминания:

Код на С‑подобном языке → транспилер Brainfix → компилятор Bfc → готовое приложение

В чем отличие от обычной разработки:

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

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

Правда весело?

Примерно из-за таких милых шалостей мои бывшие преподы до сих пор меня помнят мою фамилию.

Ну а если вас попросят написать тестовое задание, вставив в постановку фразу «на любом известном вам языке» — теперь вы знаете как и на чем его делать.

P.S.

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

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