дневник перевода компилятора Компонентного Паскаля на русский язык

Работы по ББЦБ (BlackBoxComponentBuilder) навсегда прекращены, т.к. A2OS - более интересный для наших задач вариант Оберон-подобной среды. В этом форуме хранятся темы про ББЦБ - пригодятся.
Закрыто
БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

дневник перевода компилятора Компонентного Паскаля на русский язык

Сообщение БудДен » 04.11.18 19:15

#blackboxcomponentbuilder #оберон

Проекет перевода компилятора, компоновщика и среды времени выполнения Оберона КП на русский язык. Речь идёт не столько о включении поддержки в компилятор русского языка (она там уже есть), а о переводе самих исходных текстов (идентификаторов и комментариев) на русский язык. Например, функция называлась «Import», а будет называться «Импортируй». При этом некоторые «таинственные» названия превращаются в более понятные, например «qualident» превращается в «РазбериИдентификаторВтчСКвалификатором». Конечная цель здесь - чтобы у России появился свой учебный компилятор-компоновщик-среда времени выполнения хорошего языка программирования, для учебных и промышленных целей. Причём такой, который будет на русском языке, постижим силами одного учащегося и понятен сверху донизу без необходимости в реверс-инжиниринге. На сегодня такого инструмента в России нет (или я о нём ничего не знаю).

Репозиторий:

https://gitlab.com/budden/oberonja

https://forum.oberoncore.ru/viewtopic.php?f=28&t=6287

По состоянию на 4 ноября (с праздником, кстати), все пр-ры модуля Парсер названы по-русски, причём я почти уверен в правильности всех названий.
Сейчас занимаюсь волшебными константами и типами. Их пока не переименовываю, а только лишь комментирую.
Последний раз редактировалось БудДен 15.01.19 18:08, всего редактировалось 5 раз.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 04.11.18 23:11

Нашлись два файла, завязанные на интерфейсы компилятора - DevAnalyzer и DevBrowser. Они несколько отстали от модификаций - будем чинить. Также выяснилось, что я зря не указал старые имена модулей при переименовании. Частично поправил. Разобрался почти со всеми "object modes", хотя точный смысл термина пока неясен.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 05.11.18 15:59

Обработал DevAnalyzer = НяАнализатор. Правда, диалог настроек не выжил, но в ББЦБ можно такой диалог сгенерировать. Анализатор - это подобие Lint, и он забавен.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 15.11.18 20:47

В связи с ухудшением материального положения работы будут заморожены, как только МихалНик доделает то, что делает сейчас. Ищутся спонсоры. Я думаю, что общая стоимость проекта - порядка 100 тыр.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 27.11.18 21:15

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

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 18.12.18 20:35

После 14-дневного перерыва сегодня сделал новую запись в репозиторий. Запись мелкая. Но главное - поступательное движение вперёд восстановлено. Теперь всё остальное будет во вдвойне фоновом режиме. И я здесь не написал, что ещё до перерыва сделал прототип полиморфизма, охватывающего не только записи, а и вообще любые типы. До окончательного результата далеко, но сделано главное - удалось (при помощи русификации) достаточно разобраться в компиляторе, чтобы это стало возможным. Результат примерно описан здесь:

https://zx.oberon2.ru/forum/viewtopic.p ... t=10#p3245

Теперь дальнейшее - дело техники.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 21.12.18 12:01

Ползти в направлении цели - переделал becomes на симв_присвой. Сломалась сборка, больше времени затратил на починку, чем на что-то полезное. Сборка очень хрупкая. Вчера ещё на ночь почитал про Аду и подумал - а нафиг нужен этот Оберон? Правда, я так понимаю с Адой свои тараканы в голове. Но часть того, что я хотел бы (например, арены) в Аде уже есть. И ОС на ней тоже делали.

Люди характеризуют Оберон как систему для "ограниченных ресурсов" - это правда, судя по тем кодам, которые я видел. Т.е. в качестве учебной системы она не очень подходит. Учебный код должен быть ясным, а код блекбокса оптимизирован в направлении компактности и местами - в направлении эффективности. Зачастую даже за счёт безопасности.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 21.12.18 13:59

Пока пил чай, переименовал {}()[] - и вот готов ещё один коммит.
Обязательно надо сделать отдельный режим VS Code для КП - потому что паскалевский режим всё время обновляется и затирает мои изменения, сделанные грязными руками.

MihalNik
Сообщения: 244
Зарегистрирован: 05.11.18 11:02

Re: дневник русификации компилятора компонентного Паскаля

Сообщение MihalNik » 21.12.18 15:03

БудДен писал(а):
21.12.18 12:01
Люди характеризуют Оберон как систему для "ограниченных ресурсов" - это правда, судя по тем кодам, которые я видел. Т.е. в качестве учебной системы она не очень подходит. Учебный код должен быть ясным, а код блекбокса оптимизирован в направлении компактности и местами - в направлении эффективности. Зачастую даже за счёт безопасности.
Но может взять более простую реализацию?
Оптимизиция должна, конечно, идти как-то отдельно, но она все-таки входит в студенческий уровень.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 21.12.18 17:02

Я взял ББ по той причине, что там уже есть какая-никакая среда. Люди раскручивают компилятор по спирали с нуля, а я тоже по спирали, но уже с большой высоты. Честно сказать, я очень не в восторге от многого в ББ. Но есть минимум, от которого нельзя отказаться: среда должна быть полной, т.е. должен быть динамический линкер и своя генерация в маш.код, а не генерация кодов для стороннего ассемблера. Если есть что-то проще ББ, обладающее теми же свойствами? Глагол не подходит, уже проверено. И плюс я не люблю GPL.

MihalNik
Сообщения: 244
Зарегистрирован: 05.11.18 11:02

Re: дневник русификации компилятора компонентного Паскаля

Сообщение MihalNik » 21.12.18 18:23

БудДен писал(а):
21.12.18 17:02
Я взял ББ по той причине, что там уже есть какая-никакая среда. Люди раскручивают компилятор по спирали с нуля, а я тоже по спирали, но уже с большой высоты. Честно сказать, я очень не в восторге от многого в ББ. Но есть минимум, от которого нельзя отказаться: среда должна быть полной, т.е. должен быть динамический линкер и своя генерация в маш.код, а не генерация кодов для стороннего ассемблера. Если есть что-то проще ББ, обладающее теми же свойствами? Глагол не подходит, уже проверено. И плюс я не люблю GPL.
FASM/NASM идут вроде по BSD. С лицензией универа Иллинойса для LLVM не очень понятно. Без стороннего ассемблера сразу либо проблема с архитектурами, либо с оптимизацией. Проблемы динамической связки и генерации решаются в любом языке за счет некоторой потери производительности введением косвенного уровня.
Если есть что-то проще ББ, обладающее теми же свойствами?
Тут скорее вопрос - что лишнее, ведь оптимизации можно резать а модули сливать вместе, сам код - перестраивать.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 21.12.18 20:15

В ББ модули, связанные с генерацией кода - около 6000 строк на КП, а ведь он довольно рыхлый. Про линкер не знаю. Сколько строк кода занимает NASM? Сделать лишний уровень косвенности легко только на словах, а на деле это тяжело. Т.к. в КП есть уже целый набор инструментов, включая пошаговый отладчик и инспектор данных на стеке. Любое изменение влияет сразу на большое количество частей системы. При этом там линковка динамическая на уровне модулей, а модули образуют дерево, т.е. не факт, что там нужен этот уровень.

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

Пока что ощущение такое, что компилятор в основном подлежит переписыванию. Основные модули (не считая тривиального лексера):

Д - 2300 строк
Использование - 300
Парсер - 1800
ФС - 1700

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

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 23.12.18 01:40

Не совсем про русификацию. Вчера наконец-то сделал отдельный режим для КП в VS Code, потому что раньше была только инструкция о том, как пропатчить режим Паскаля. Проблема в том, что Паскаль обновляется и изменения затираются.

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

В примерах есть довольно клиент и сервер. Вроде удалось написать код, к-рый берёт строку и выполняет соотв. команду, теперь нужно сделать более прилично по аналогии с DevCommanders.Execute (там есть обработка ошибок с помощью ловца исключений).

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 27.12.18 20:37

Одно цепляется за другое, стек задач растёт. Решил потихоньку ползти в сторону более полноценной поддержки VS Code. Для этого нужен сокет-сервер. Сокет сервер реализован ужасно в стиле 70-х, т.е. операции со списками вписаны прямо в тело функций. Такое г. не для нас. Пришлось немного поподбирать библиотеки контейнеров. Подходящей под вкус не нашёл, но получилось пока вот что https://gitlab.com/budden/nkp/blob/mast ... Страниц.kp

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

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

Осталось в этом направлении сделать достаточно немного, но теперь пора и поработать.

Помимо этого, расшифровал TProc, IProc, XProc и прочие абракадабры.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник русификации компилятора компонентного Паскаля

Сообщение БудДен » 02.01.19 01:00

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

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник перевода компилятора Оберона КП на русский язык

Сообщение БудДен » 04.01.19 01:37

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

Подбешивает меня уже этот Оберон. После лиспа это выглядит как пересадка с мерседеса на тачку, которую нужно руками толкать. Но ничего, ещё потерпим. Хотя, честно сказать, уже погуглил «Lisp bare metal».

atz
Сообщения: 139
Зарегистрирован: 21.12.18 22:45

Re: дневник перевода компилятора Оберона КП на русский язык

Сообщение atz » 04.01.19 17:35

КП настолько ужасен
Бгг... А как же хвалёное лисповое метапрограммирование? Неужели оно не обеспечивает решения требуемых задач? Ведь оно так везде расхваливается, как будто можно используюя такие инструменты ОС с нуля за неделю сделать =)

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник перевода компилятора Оберона КП на русский язык

Сообщение БудДен » 04.01.19 19:49

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

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник перевода компилятора Оберона КП на русский язык

Сообщение БудДен » 05.01.19 01:51

Переведено примерно за 2 месяца 17% названий процедур компилятора. Плюс к тому переведено ещё много другого, но не так просто посчитать.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: дневник перевода компилятора Оберона КП на русский язык

Сообщение БудДен » 15.01.19 18:06

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

Закрыто