6 часов – это общий лимит работы Action-скрипта для каждого запуска (в бесплатной версии), он у меня просто завис первый раз из-за MsgBox’а – я сразу не понял этого, поскольку не знал сколько требуется обычно времени на тесты. Запускал поздно ночью, не дождался и только утром увидел, что задача отвалилась. Потом разобрался с TestRunner’ом.
На самом деле там очень мощное железо используется (многоядерные Xeon’ы, SSD и 12 GB RAM на каждую копию виртуальной машины), поэтому время сборки и тестирования должно быть заметно меньше, чем на локальном железе, доступном большинству разработчиков-энтузиастов. Для сравнения, сколько времени у вас сейчас занимает полная сборка со всеми дистрибутивами (без тестов)?
На самом деле, чтоб написать System.Threading.Tasks.Parallel.Invoke - компилятор не нужен…
Понятно. Ну, я тоже и не посмотрел бы что именно вы делали, но за пару дней до того как вы тут написали - смотрел сюда в основной репе (по другой причине) и стало интересно, чем это так всё покрыло.
А у меня, кстати, в POCGL примеры не только компилируются. Мой тестировщик для каждого .pas файла (в папке тестов и в папке примеров) создаёт текстовый .td (test data) файл. По-умолчанию в режимах тестирования примеров ставится компиляция, но это легко поменять.
К примеру, тут - я сделал так, чтоб тест выполнялся и проверял правильность своего вывода.
А ещё в случае ошибки (компиляции или выполнения) - проверяется не просто существование ошибки, но ещё и весь её текст, как тут.
Ну а если где то что то не совпадает с ожидаемыми результатами тестирования - выводится месседжбокс, спрашивающий, заменить ли содержимое .td файла.
Вообще я собирался предложить подобную систему разработчикам паскаля, когда буду более уверен в её годности. Но автоматическая сборка и тестирование на стороне гитхаба таки больше подходит на маштабе паскаля. Даже если бы у них не были такие мощные сервера.
Поэтому, пусть то что у меня наработано в POCGL - будет вам как proof-of-concept, показывающий что такое подробное тестирование не только реально, но и прекрасно работает в проектах меньшего маштаба.
Ну и, если что, весь код там распространяется с Unlicense, поэтому его можно “заимствовать” сколько хотите. Хотя я сам за велосипеды и написание собственного кода с 0.
Проверьте символы переносов строк в тестах форматирования.
У меня последняя стадия всё время выдаёт ошибку сразу на всех файлах, даже в оригинальной репе, без моих изменений. @Kotov вроде смотрел - и решил что дело именно в том, что тип переносов строк не игнорируется. Если исправлять в .Net коде - достаточно использовать .Remove(#13) для ожидаемого и полученного после форматирования кодов.
Удобно! Вот только надо бы продумать, как быть с надежным и универсальным сравнением сообщений от компилятора на разных подключаемых языках: pabcnetcclear.exe общается только по-английски, а встроенный в IDE и pabcnetc.exe – уже минимум на 3.
Ну, если подключать .dll файлы компилятора - можно ручками выбирать язык. Текущий тестировщик это сейчас и делает (кроме последней части про выбор языка).
И выполняю тесты я не запуском .exe файлов, а загружая их сборку в отдельный домен (чтоб потом можно было полностью отгрузить) и выполняя оттуда. Таким образом я получаю объект типа Exception, а не “может текст, а может вылет, как системе захочется”.
Но это же, поидее, должно позволить настроить язык .Net ошибок прямо из тестировщика. Правда я ещё не пробовал, потому что с такой проблемой ещё не сталкивался. Всё же у меня был ноут с русской вин7 и сейчас комп с англ. вин10, а тексты ошибок всё те же.
Дело в том, что в тех же виртуалках гитхаба (WS 2016/2019) все только на английском по дефолту, а разработчики Паскаля все русскоязычные. Если собираетесь предлагать ваше решение для проекта, надо будет убедиться, что оно надежно работает не только при локальном тестировании с кастомными русскими настройками, но и на стандартных виртуальных образах гитхаб-раннеров.
Вообще я думал что вы первый собираетесь что то предлагать, но ок, закопался глубже в это:
В инициализации модуля PABCSystem:
var locale_str := 'ru-RU';
... // тут locale_str пытается менять, но в итоге никогда не меняет
System.Threading.Thread.CurrentThread.CurrentUICulture := System.Globalization.CultureInfo.GetCultureInfo(locale_str);
Gets or sets the current culture used by the Resource Manager to look up culture-specific resources at run time.
На сколько я знаю - “Resource Manager” это и есть то, что подгружает вещи как тексты ошибок.
Поэтому на моей англо-язычной вин10 у меня и выдаёт русские сообщения об ошибках.
Ну и, раз у вас тестировщик запустился на сервере гитхаба и ArgumentException на строчке с CurrentUICulture не выдал - значит, наверное, их эмулятор уже имеет встроенную русскую культуру и волноваться не о чем.
Но вообще, @Admin, посмотрите на переменную __CONFIG__. Что она там делает, а точнее почему она есть и ничего не делает.
И то, что англо-язычным пользователям дают англо-язычный перевод IDE, но ошибки всё равно показывает на русском - это так задумано?
Кроме того, даже если бы внутренности компилятора или IDE использовали эту переменную - выполнение .exe отдельно всё равно выдавало бы тексты ошибок на русском.
По моему то что язык ошибок по умолчанию ставит на русский - это не правильно. Надо, как минимум, оставлять стандартный язык, который выбирает система, если в переменной __CONFIG__ ничего нету.
@ProMix не ожидайте адекватность анализатора кода в не законченном коде. Из за . в конце другой строки анализатор кода вылетает недочитав файл, поэтому и не обновляет своё понимание переменной matr.
Ну, не весь неправильный код будет ломать анализатор кода, если синтаксически всё правильно написано. То есть если после . написать вызов не существующего метода - анализатор кода сможет дочитать файл до конца и починится.
Конечно это плохо, но разработчики говорят что с текущей структурой компилятора (части которого используете анализатор кода) - реализовать анализатор кода, игнорирующий неправильные части программы не выйдет.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021