Добрый вечер, Александр!
«Моя логика такова: использование персоналок будет однозначно сокращаться, а
код, на них ориентированный, плохо переносится в другие перспективные нынче
среды, такие как интернет-серверы, интернет-клиенты и различные гаджеты.»
Вероятно, Вы правы, нужно думать о поддержке серверного ПО.
Но у меня компилятор самоприменимый и разрабатывается на персональной машине,
поэтому основной пользователь работает на персоналке. Также компилятор может
собрать и запустить два суперкомпилятора, написанные на Рефале-5: SCP4 и
MSCP-A, они тоже предназначены для запуска на персоналках в первую очередь.
Так что имеет смысл в первую очередь сделать собственную работу комфортной:
оптимизировать компилятор для сборки себя.
«Хотя я, при отсутствии тестировщика (или хотя бы „ночной сборки“)»
Для начала достаточно организовать набор самопроверяющихся тестов. Т.е. папку,
в которой лежит батник и исходники-тесты. Батник перебирает все файлы, каждый
исходник собирает и запускает — файл должен без ошибок откомпилироваться и не
упасть. В самом исходнике может быть проверка вроде (пишу для примера на
Рефале-5, т.к. не знаю ваш синтаксис):
$ENTRY Go { = <Check <Mul 2 2>> }
Check { 4 = }
Программа перемножает 2 на 2 и сверяет результат с 4. Если результат работы
будет чем-то другим, то функция Check упадёт с ошибкой невозможности
отождествления. Так исходник будет сам себя проверять.
После этого время от времени запускать батник и убеждаться, что ничего не
сломалось. Можно запускать или перед каждым коммитом, или после каких-то
серьёзных изменений в коде.
Рекомендую написать батник так, чтобы, если он вызывается без аргументов, то
запускаются все тесты, иначе запускаются тесты, перечисленные в аргументах
командной строки. Отлаживать будет удобнее.
В дальнейшем можно набор тестов расширить тестами на синтаксические ошибки — на
них компилятор/интерпретатор не вылетает, а корректно сообщает об ошибке (и
дальше не компилирует/не интерпретирует), и на намеренное падение (такие у меня
тоже есть).
У меня вот эти автотесты распухли настолько, что требуют около часа времени. И
распухли от декартова произведения различных режимов.
Вот так они у меня выглядят: refal-5-lambda/autotests at master ·
bmstu-iu9/refal-5-lambda (github.com)
<https://github.com/bmstu-iu9/refal-5-lambda/tree/master/autotests> .
Вот более простые и обозримые тесты в других моих проектах:
• refal-5-framework/tests/parser at master · Mazdaywik/refal-5-framework
(github.com)
<https://github.com/Mazdaywik/refal-5-framework/tree/master/tests/parser>
• Refal-05/autotests at master · Mazdaywik/Refal-05 (github.com)
<https://github.com/Mazdaywik/Refal-05/tree/master/autotests>
Тесты не надо специально сидеть и сочинять. Начальный набор тестов насочинять,
конечно, нужно, так, чтобы он охватывал основные возможности системы. А дальше
тесты пишутся в двух случаях: ошибки и новая функциональность.
Выявили какую-то ошибку. Воспроизводим её. Тест для воспроизведения уменьшаем.
Уменьшаем. Уменьшаем. Получается маленький автотест. Исправляем ошибку — новый
автотест стал проходить. Коммитим его одновременно с исправлением ошибки.
Появился ещё один автотест.
Хотим добавить новую функцию. Скажем, новую встроенную функцию или новую
синтаксическую конструкцию. Пишем автотест, её проверяющий (один или
несколько). Реализуем функциональность, чтобы автотест проходил. Коммитим
одновременно новую функцию и автотест к ней. Появился ещё один автотест.
«сломал систему так, что уже месяц, наверное, не могу восстановить
работоспособность»
Если бы были автотесты, можно было бы при помощи git bisect быстро найти
коммит, который всё ломает.
Не исключаю, что автотесты Вы и без меня хорошо знаете, и уже давно их
используете. Я пишу в рассылку, а в ней не все подписчики могут быть знакомы с
этой полезной практикой.
С уважением,
Александр Коновалов
From: Александр Гусев gusev_aleksandr_AT_mail.ru <refal@botik.ru>
Sent: Thursday, May 20, 2021 11:32 AM
To: refal@botik.ru
Subject: Re[4]: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e
Добрый день, Александр!
Мы перед собой видим совсем разные задачи. Локальный суперэффективный
компилятор для персонального использования и серверный «монстр»,
ориентированный на работу через интернет. Моя логика такова: использование
персоналок будет однозначно сокращаться, а код, на них ориентированный, плохо
переносится в другие перспективные нынче среды, такие как интернет-серверы,
интернет-клиенты и различные гаджеты. Это же касается и точек сопряжения с
различными сетевыми сервисами — я не могу ограничиться С рантайм библиотекой.
Всегда можно откатиться на более ранний коммит. И при сравнении можно
сравнивать старый коммит с актуальным.
У меня в этом году два дипломника развивают компилятор: один переделывает
оптимизацию прогонки, другой — оптимизацию специализации. Сначала я думал
добавить для них дополнительные режимы работы, но отказался от этой идеи. И так
у меня есть грёбаная куча режимов. Для тестирования нужно проверять почти
декартово произведение, т.к. некоторые ошибки вылезали только при комбинации
режимов. Добавлять ещё два — это значит, увеличивать время работы тестов на
2×2=4 раза, ибо декартово произведение. Поэтому я не стал добавлять режимы,
решил, что для тестов производительности достаточно сравнивать текущий код с
коммитом, помеченным тегом.
Для успешных серверных продуктов сотни настроек — не беда (так считается).
Пример вроде плохой для следования, но это как-то работает. Хотя я, при
отсутствии тестировщика (или хотя бы «ночной сборки»), сломал систему так, что
уже месяц, наверное, не могу восстановить работоспособность. Критическое
изменение было упущено, а сложность кода превышена. Те самые «успешные серверы»
пишутся и сопровождаются сотнями людей с мощными средствами командной работы и
управления проектами.
«Изобретая велосипед» я несколько уже устал от обилия деталей в задаче, но
постепенно набираюсь соответствующего опыта и даже начал интересоваться, что же
делают коллеги в своих вотчинах. )) И по-хорошему завидую тем, кто может часть
работы перепоручить студентам. У меня пока так не получается.
С уважением,
Александр Гусев
gusev_aleksa...@mail.ru <mailto:gusev_aleksa...@mail.ru>
